注：這邊博文分享的是我們處理故障過程中發生的事實，故障的確是在我們將博客系統從 .NET 5.0 版回退到 .NET Core 3.1 版恢復的，但不一定是 .NET 5.0 本身的問題，有可能是巧合，也有可能是我們的應用代碼不能適應 .NET 5.0 的某些變更，我們會進一步排查與驗證。
自從博客系統升級 .NET 5.0 之后遇到的詭異故障（一、二、三、四），今天它又出現了，就在前天剛剛故障之后， 就在昨天 .NET 5.0 正式版剛剛發布之后，出現了。
今天晚上（11月12日）我們在 19:30 左右進行了一次發布，發布后特地進行了觀察，當時沒有出現故障，滿以為這次發布相安無事，但后來還是慢慢發生了故障，直到 20:30 左右產生大范圍影響，大量請求響應緩慢。在這次故障過程中，我們試遍了之前的所有方法（除了回退 .NET 5.0）都無濟於事，在我們幾乎絕望之時，我們把目光轉向了我們曾經專門“洗白”過的 .NET 5.0，我們沒有任何理由懷疑 .NET 5.0，但是除了 懷疑 .NET 5.0，我們已經走投無路。
在22:00左右，我們帶着非常復雜的心情，不報任何希望（也不希望有希望）地進行了從 .NET 5.0 回退到 .NET Core 3.1 操作
./deploy-blog.sh 2.3.73
結果，在回退完成后，竟然恢復了正常，恍如夢中。。。
難道又是一次巧合，剛好故障在這個時間點恢復，我們正好進行了回退操作。。。
我們現在茫然不知所措，似乎鐵證如山，似乎 .NET 5.0 不可能出現如此大的問題。。。我們先冷靜冷靜，然后再仔細分析與排查。
非常抱歉，今天 20:30~22:00 左右博客站點再次出現的故障給您帶來了很大的麻煩，請您諒解。
【更新】
2020-11-13 07:55，博客系統恢復為 .NET 5.0 版運行。（注：.NET 5.0 版與 .NET Core 3.1 之間相差30個發布，這個降級影響比較大。另外，如果真的是 .NET 5.0 引起的，如果發生故障，可以立即回退到 .NET Core 3.1 恢復。）
2020-11-13 10:56，接下來我們會采用排除法，一個一個懷疑點排查與驗證，第一個懷疑對象是 memcached 客戶端 EnyimMemcachedCore 。
2020-11-13 20:57，發布了后續博文 《.NET 5.0 背鍋案》第1集：驗證 .NET 5.0 正式版 docker 鏡像問題
2020-11-16 15:56，發布了后續博文 《.NET 5.0 背鍋案》第2集：碼中的小窟窿，背后的大坑，發現重要嫌犯 EnyimMemcachedCore
2020-11-16 22:09，發布了后續博文《.NET 5.0 背鍋案》第3集-劇情反轉：EnyimMemcachedCore 無罪，.NET 5.0 繼續背鍋
2020-11-20 14:10，發布了結案博文《.NET 5.0 背鍋案》第7集-大結局：捉拿真凶 StackExchange.Redis.Extensions 歸案