回顧2024年信息系統安全事件時有發生，作為一線運維人員對這些生產安全故障當抱有敬畏之心，并從中總結經驗教訓，分析原因，不能簡單的調侃為開猿節流、降本增笑的結果。本文簡要盤點2024年發生的主要信息系統安全事件，并從中得到一些啟示和反思，以期更好的復盤總結到實際的工作之中。

1、2024年信息系統主要故障盤點

• 2024年4月8日騰訊云控制臺故障
• 2024年7月2日阿里云故障
• 2024年7月9日微軟系統藍屏事件
• 2024年8月19日網易云音樂故障
• 2024年8月26日上海電信城域網設備故障
• 2024年9月10日阿里云新加坡機房故障
• 2024年9月27日上交所交易故障
• 2024年11月11日支付寶交易故障
• 2024年12月11日OpenAI故障

1.1 4月8日騰訊云故障

1）故障概述4月8日15點23分，騰訊云團隊收到告警信息，云API服務處于異常狀態；隨即在騰訊云工單、售后服務群以及微博等渠道開始大量出現騰訊云控制臺登錄不上的客戶反饋。

2）故障影響故障發生后，依賴云API提供產品能力的部分公有云服務，也因為云API的異常出現了無法使用的情況，比如云函數、文字識別、微服務平臺、音頻內容安全、驗證碼等。此次故障一共持續了近87分鐘，期間共有1957個客戶報障。

3）故障復盤過程騰訊云官方給出了整個故障的處理過程

圖片

• 15:23，監測到故障，立即執行服務的恢復，同時進行原因的排查；
• 15:47，發現通過回滾版本沒能完全恢復服務，進一步定位問題；
• 15:57，定位出故障根因是配置數據出現錯誤，緊急設計數據修復方案；
• 16:02，對全地域進行數據修復工作，API服務逐地域恢復中；
• 16:05，觀測到除上海外的地域API服務均已恢復，進一步定位上海地域的恢復問題；
•  16:25，定位到上海的技術組件存在API循環依賴問題，決定通過流量調度至 其他地域來恢復；
•  16:45，觀測到上海地域恢復了，此時API和依賴API的PaaS服務徹底恢復，但控制臺流量劇增，按九倍容量進行了擴容；
• 16:50，請求量逐漸恢復到正常水平，業務穩定運行，控制臺服務全部恢復；
• 17:45，持續觀察一小時，未發現問題，按預案處理過程完畢。

4）官方也給出了改進措施，有以下幾點

• 變更管理：定期執行預定的變更策略模擬演練，確保在真實故障發生時，能夠迅速切換到恢復模式，最小化服務中斷時間。
• 服務架構：優化服務部署架構，通過分層架構、代碼審查和監控等手段，避免API服務中潛在的循環依賴問題。
• 逃生通道：提供API服務逃生通道，當故障發生時，可供調用方快速切換。
• 沙箱驗證：完善自動化測試用例庫，在系統變更前通過沙箱環境對變更內容進行嚴格驗證。
• 灰度發布：實施灰度發布策略，逐步推廣新功能或配置更改，按集群、可用區、地域逐步生效，以便在發現問題時能夠迅速回滾。
• 異常熔斷：引入異常自動熔斷機制，當檢測到系統異常時，能夠立即中斷變更過程。
• 故障處理：對故障處理流程進行全面升級，確保實時更新故障處理進度和預計恢復時間點，提升故障報告發布效率。
• 信息透明：在對外發布的故障通知中，清晰闡述受影響的業務范圍、故障根因及預計修復時長，保持透明度。
• 看板優化：優化騰訊云健康狀態看板的信息展示邏輯，解除對云API等云服務的依賴，通過引入緩存和容災機制，確保即使在云服務出現故障時，能準確、及時地傳遞故障信息。

1.2 7月2日阿里云故障

1）故障概述北京時間2024年07月02日10:04，阿里云監控發現上海地域可用區N網絡訪問出現異常，經阿里云工程師緊急介入處理后，于10:35完成網絡切流調度后，10:42訪問異常問題恢復。

2）故障影響此次故障導致對象存儲、云數據庫與Kubernetes服務等關鍵服務出現故障，同時影響了使用阿里云服務的多個平臺，包括B站和小紅書等，用戶在這些平臺上無法正常使用瀏覽歷史、關注內容、消息界面、更新界面、客服界面等功能，也無法進行評論、發彈幕等操作。

3）故障原因經過調查發現，此次故障的根本原因是機房光纜中斷，導致網絡訪問異常。雖然阿里云采用了多可用區的架構設計，但此次故障發生在單個可用區內，導致該區內的服務受到影響。

1.3 7月19日微軟windows系統藍屏事件

1）故障描述2024年7月19日，“微軟藍屏”上榜全球熱搜。具體說，Windows10系統出現了藍屏死機（BlueScreenofDeath）的問題。電腦卡在“恢復”界面，該界面顯示：“看起來Windows沒有正確加載。如果您想重新啟動并再次嘗試，請在下方選擇“重新啟動我的電腦”

2）故障影響因該事件崩潰的設備多達850萬臺，影響范圍幾乎覆蓋全球，涉及了涵蓋航空公司、電視廣播、醫療機構、銀行金融等眾多行業，預計經濟損失以數十億計。

3）故障原因微軟也發布了一份全面調查報告，提供了根本原因的技術概述?！白锟準住笔怯擅绹W絡安全企業CrowdStrike的軟件更新錯誤引發的。CrowdStrike給所有設備推送了一個“更新”，卻觸發了某些Windows的bug，導致了系統藍屏。

通過分析大量的崩潰報告，微軟發現這些記錄都指向了CrowdStrike的驅動程序csagent.sys。通過調閱故障時系統留下的崩潰轉儲，微軟再現了崩潰發生時的場景——首先查看崩潰線程的Trap Frame后，發現引發異常的指令是一條針對R8寄存器、指向內存的讀操作。進一步觀察Trap Frame附近的指令，又發現在該讀操作之前，有一個對R8的空值檢查，檢查失敗才會繼續執行后續的讀操作。但是檢查R8指向的虛擬地址后，微軟發現它指向了一個非法地址，導致內核訪問違規，從而引發了此次崩潰。

另外，Crowdstrike也解釋了流程層面的原因——在上線前的測試過程中，未能檢測到更新中的“有問題的內容數據”。慶幸的是國內的企業受此次事件的影響較小，

1.4 8月19日網易云音樂故障

1）故障概述8 月 19 日下午 2 點半左右，大量網易云音樂用戶發現平臺出現大面積訪問困難、歌曲加載失敗等故障現象?！熬W易云音樂崩了”的話題迅速登上微博熱搜榜，成為網絡熱議的焦點。網易云音樂官方微博迅速發布聲明，承認由于基礎設施故障導致各項功能無法正常使用，并表示技術團隊正在全力以赴進行修復。官方還澄清了關于“網易云音樂開發者刪庫跑路”的傳言，強調沒有刪庫也沒有跑路。

圖片

2）故障影響故障導致網易云音樂的會員中心、創作者中心和商城等功能全部受到影響，用戶無法正常使用這些功能，也對網易云音樂服務的穩定性提出了質疑。在激烈的市場競爭中，網易云音樂的這次故障事件可能使其面臨客戶流失的危險。

3）故障原因有消息透露和云存儲的擴容有關，加上降本增效，故障排查也花了近2個小時。也有來自網易內部的技術人員透露，此次事故可能與網易在貴州機房的遷移有關。具體原因官方未披露。

1.5 8月26日上海電信城域網設備故障

1）故障概述8月26日下午5點30分左右，上海部分電信寬帶用戶突然發現無法正常上網。這一突發事件迅速在社交媒體上發酵，許多用戶紛紛抱怨“電信斷網”“無法連接互聯網”，甚至有用戶調侃稱“上海電信崩了”。上海電信客服表示，部分寬帶業務發生異常，正在全力搶修排障。18時05分，經過緊急搶修，上海電信全面恢復業務。上海電信市場部及“中國電信上?？头惫傥⑾嗬^發布聲明，對故障給用戶帶來的不便表示歉意，并表示將加強巡查，排查風險點，確保網絡穩定。故障持續時間35分鐘。

2）故障影響故障導致部分云寬帶用戶無法正常使用網絡服務，影響了用戶的日常工作和娛樂。用戶在社交媒體上表達對故障的失望和不滿，對上海電信的品牌形象造成了一定影響。

3）故障原因根據上海電信的官方通報，斷網的原因是城域網設備故障，導致部分寬帶業務中斷。城域網（Metropolitan Area Network，簡稱MAN）是指在一個城市范圍內建立的計算機通信網絡，屬于寬帶局域網的一種。它的傳輸媒介主要是光纜，傳輸速率通常在100兆比特每秒以上，可以覆蓋整個城市范圍。城域網的核心作用是將一個城市內不同地點的主機、數據庫以及局域網等互相連接起來，實現數據和信息的高速傳輸。作為城市信息化建設的重要基礎設施，城域網承擔著大量的數據傳輸任務。一旦城域網設備出現故障，便會導致大面積的網絡中斷和服務中斷。

1.6 9月10日阿里云新加坡機房故障

1）故障概述9 月 10 日上午，阿里云因新加坡可用區 C 數據中心發生火災，導致主要科技公司服務中斷，火災原因已確定為鋰電池爆炸。據外媒報道，10 日早上約 8 點發生的機房火災，截至 11 日下午 8 點，已持續 36 小時，仍未完全撲滅。

2）故障影響根據阿里云發布的官方聲明，關鍵云產品受到影響，包括云數據庫 Redis、MongoDB、RDS MySQL，對象存儲 OSS，表存儲 OTS 以及云原生大數據計算服務 MaxCompute。同時，托管在該機房的其他科技公司，如Lazada和字節跳動，也遭受了嚴重服務中斷。

3）故障原因據阿里云官方聲明，異常因新加坡機房鋰電爆炸導致火災及升溫。鋰離子電池內部化學反應持續生成熱量并提供燃料，導致自燃復燃，增加了滅火難度。

圖片

1.7 9月27日上交所交易故障

1）故障概述2024年9月27日，股市開盤后不久，據投資者反應，上交所交易系統出現延遲現象。至上午10時后，在多個股票交易軟件上，上證指數、上證50和科創50等多個指數，分時走勢幾乎走成直線。有券商亦反映稱，上交所（委托、撤單）異常（交易通道堵塞），上交所正在緊急處理，深交所、北交所正常。

2）故障影響上交所股票競價交易系統，包括上證指數、上證50、科創50等多個指數分時走勢異常，以及部分股票的交易和撤單功能受影響。

2024年9月27日開盤后，市場氣氛熱烈，交易量爆炸
9點32分左右，各券商柜臺就陸續注意到上交所和深交所的訂單回報較平日開盤時段有較大延遲，上交所甚至有訂單 ACK 超過 10 秒的情況，隨后兩個交易所回報時間都似乎逐步恢復正常
9點39分左右，市場上有投資者開始反應，當日上交所訂單掛單無響應
9點40分，上交所的溝通群里，開始出現反饋說當日競價平臺回報不正常
接近10點，市場上已經有大量投資者發現掛單沒成交，準備撤單后繼續掛單，發送撤單請求后，上交所的撤單也沒有響應
10點02分左右，許多基金公司的人員反應當日上交所訂單大量異常，不少券商柜臺的運維人員也反饋，關于上交所訂單的延遲/無回報警告正在刷屏，上交所技術公司已知悉此情況，正在排查中
隨后，上交所官網發布公告稱：“本所關注到，今日開盤后本所股票競價交易出現成交確認緩慢的異常。本所已在第一時間關注到相關情況，正在就相關原因進行排查。”
10點15分，上證指數開始接近平拉直線
10點18分左右，傳言上交所準備進行主備切換
11點13分，有些券商發現上交所訂單正在開始恢復逐步消化，有的分區正常，有的分區依舊不正常(比如茅臺的行情已恢復，但是招商銀行的行情依舊在拉直線)
11點30分，午間休市，上交所系統故障事件變成了熱門談資，隨后成為激活沉睡賬戶、召喚新股民入市的又一重大新聞
12點25分左右，陸續吃完午飯的券商柜臺人員發現，上交所 TDGW 在休市期間打印了一些錯誤日志，并且做了線路的自動切換
13點00分，下午開市，上交所行情不再拉直線，但是回報卻較慢
13點08分，上交所行情雖然正常推送，但是成交量卻不太正常，看起來行為像是做了流量控制
15點00分，股票收盤，但是各家券商依舊還能收到成交回報
17點30分，上交所的競價平臺依舊在向券商推送訂單和成交回報信息
接近18點00分，各家券商陸續得到通知，無需等待上交所的推送結果，當日清算以中證登的結果為準
次日(2024年9月28日)，上交所進行例行全網測試，并通知于2024年9月29日增加一次通關測試，并緊急發布一個 TDGW 新版本

3）故障原因當日股市交易活躍，市場委托量非常大，導致交易系統處理速度變慢，成交確認延遲。交易系統在處理大量委托時，未能及時響應，導致部分交易和撤單功能異常。

上交所競價平臺的系統架構圖如下：

圖片

上交所和深交所的撮合部分都支持分區(上交所稱為 set，深交所稱為 partition)，即全市場的所有標的分為n組，每組放在一個撮合服務中，所以當一個撮合服務出現問題時，并不會影響全市場的標的。而且此架構支持橫向擴展的，即隨著時代發展，當市場成交量上漲之后，交易所可以在未來增多分區，以減少單個分區上的壓力。

針對此次故障，2024年9月29日，上交所在非交易日進行全網測試，以驗證交易系統的準確性和穩定性。此前，9月27日上交所因“爆單”導致系統故障，測試旨在模擬實盤壓力，避免類似問題再現。測試包括競價和綜合業務平臺，涉及券商、公募基金等金融機構，但不開放給普通股民。

1.8 11月11日支付寶故障

1）故障概述2024年11月11日上午，“支付寶崩了”話題登上微博熱搜。部分網友反映支付寶App無法正常使用，遇到了同一筆訂單被扣款三次、余額寶轉賬至余額后余額顯示為0、線下支付后商家未收到款項但銀行卡已被扣款等問題。此外，還有用戶遇到余額寶提現未到賬、花唄還款扣款成功但賬單沒清等情況。此故障不影響用戶資金安全，截至上午10時50分，故障已得到修復。

2）故障影響部分用戶在支付過程中出現各種異常提示，影響正常購物支付。包括同一筆訂單被多次扣款、支付失敗、交易創建失敗等。另外余額寶提現功能出現問題，資金遲遲未到賬；花唄還款出現扣款成功但賬單未清除的情況。

3）故障原因據支付寶消息，因系統消息庫出現局部故障，導致部分用戶的支付功能受到影響。具體細節未透露。

1.9 12月11日OpenAI故障

1）故障概述2024年12月11日下午3點16分至晚上7點38分（太平洋時間），OpenAI遭遇了前所未有的長時間服務中斷。此次故障影響了OpenAI旗下的幾乎所有服務，包括廣受歡迎的ChatGPT及其開發者API、Sora、Playground和Labs等。

2）故障影響2024年12月11日下午3：16至晚上7：38期間，所有OpenAI服務都經歷了嚴重降級或完全不可用。ChatGPT晚上7：01完全恢復、API的所有模型在晚上7：38完全恢復、Sora在晚上7：01完全恢復。

3）故障原因OpenAI在事后發布的故障報告中披露，此次故障的主要根源在于新部署的遙測服務意外導致Kubernetes控制平面過載，進一步引發了關鍵系統的連鎖性故障。具體來說：

• 遙測服務配置錯誤：新部署的遙測服務配置存在缺陷，導致所有節點向Kubernetes控制平面發送了大量且高資源消耗的API請求，超過了控制平面的處理能力。
• 測試環境不足：測試環境未能充分模擬生產環境的大規模集群場景，因此未能提前發現這一問題。
• 監控不足：缺乏對Kubernetes控制平面負載和性能的實時監控，導致問題未能及時被發現和預警。

4）故障后續優化為防止類似事件再次發生，OpenAI計劃采取一系列改進措施，包括增強分階段部署、故障注入測試及控制平面緊急訪問機制等。

• 穩健的分階段部署：加強對所有基礎設施變更的監控，確保任何故障的影響范圍有限且能夠被及時發現。
• 故障注入測試：通過故意引入錯誤的變更來測試系統是否能夠正確地檢測并回滾這些變更。
• 控制平面緊急訪問機制：實施“破窗機制”，確保工程師在任何情況下都可以訪問Kubernetes API服務器。
• 解耦Kubernetes數據平面和控制平面：將Kubernetes數據平面與控制平面分離，以便控制平面在處理任務關鍵型服務和產品工作負載時不會承擔負載。
• 快速應急恢復：為集群啟動所需的資源實施改進的緩存和動態速率限制器，并運行定期練習，以快速正確啟動的明確目標快速替換整個集群。

2、信息系統安全事件啟示

在2023年12月8日國家網信辦發布的《網絡安全事件報告管理辦法（征求意見稿）》對網絡安全事件分級做了規定，分為：特別重大網絡安全事件、重大網絡安全事件、較大網絡安全事件和一般網絡安全事件，其中規定了影響范圍、影響時長，重要和關鍵信息系統的服務中斷時間等，特別提到在網絡社交媒體上的影響。

系統架構中描述系統可靠性和穩定性有三個指標：MTTR（Mean Time To Recovery，平均恢復時間）、MTTF（Mean Time To Failure，平均失效時間）和MTBF（Mean Time Between Failures，平均無故障時間）

• MTTR：MTTR衡量的是系統從出現故障到恢復正常工作所需的平均時間。這個時間包括了故障的發現、定位、修復以及系統重新投入使用的所有步驟。
• MTTF：MTTF指的是設備或系統在正常運行狀態下，從啟動到發生第一次故障所經歷的平均時間。它主要關注產品使用期間的非老化失效。
• MTBF：MTBF指的是系統在兩次相鄰故障之間的平均運行時間。這個指標考慮了系統的維修和維護能力。

MTBF = MTTF + MTTR，MTBF越長，表示系統持續提供正確服務的時間越長；MTTR越短，表示系統從故障中恢復的速度越快。因此，在出現信息系統故障時，快速的應急恢復，提高業務連續性是生產運維的關鍵。

2.1 信息系統故障的輿情影響

隨著短視頻和自媒體的日益普及，信息傳播的速度極快，尤其是通過網絡媒體，信息可以在短時間內迅速傳播到全球范圍。信息系統一旦發生故障，相關信息會迅速被公眾知曉，形成輿情熱點。尤其是涉及公眾切身利益，如金融服務、網絡通信、電子商務等，更容易引起公眾的廣泛關注，這一類信息系統故障的敏感性和關注度較高，使得相關輿情成為輿論焦點。隨之而來的是相關監管機構的調查、問責和整改，最終不僅損壞相關企業的和機構的公信力，引起信任危機，而且對長期的形象和聲譽產生深遠的影響。

2.2 信息系統的網絡安全因素

或許大家對2023年11月工行海外的勒索病毒事件還歷歷在目，網絡安全也是需要時刻警惕的，尤其是提供公共基礎服務以及保持敏感數據的企業，提供有效措施來應對網絡安全攻擊。

• 以人行和監管總局為代表的監管機構制定網絡安全策略，對系統軟件進行高危漏洞、高危補丁的修復，高危端口的整改。這些安全防控策略短期來看會增加企業的成本，因為涉及到存量漏洞的整改以及實施層面面臨各種困難，長期來看能夠針對不同類型的網絡攻擊進行防范，確保系統的安全性。
• 信息系統軟件自主可控的必要性，基礎軟件尤其是核心CPU、操作系統和數據庫等基礎軟件實現自主可控，防止留有后門不受操控和干擾，從而有效防止數據泄露、篡改和破壞。以微軟CrowdStrike藍屏事件為例，國內很少受到波及因為不使用該軟件，也就不存在問題?，F在使用國芯、信創操作系統和數據庫，重要信息系統已經逐步全棧信創改造，實現自主可控。
• 數據備份和物理隔離：對于關鍵系統和數據，可以采用物理隔離的方式，防止病毒通過網絡傳播到內部系統。同時對重要數據進行備份，確保在發生網絡攻擊或系統故障時能夠迅速恢復數據，并制定好應急預案。

2.3 基礎組件的關鍵性

談起基礎組件，又得拿出下面這張非常經典的圖，無論產品的頂層設計多么的富麗堂皇，底層基礎設施不牢靠，一個不起眼的基礎組件出現異常的時候整個產品就會瞬間崩塌。所以在系統高可用架構設計的時候，需要想一想哪些基礎模塊可能是影響全局的但又存在單點、變更的時候是否會影響到、有沒有充分的應急預案等。

圖片

基礎設施層的故障所謂牽一發而動全身，會造成全局性的影響，因此在底層架構設計的時候要盡可能的考慮這個點故障了會有什么影響、影響范圍是多少，能否做到高可用、是否可以應急切換、逃生機制、故障隔離措施等。比如7月2日阿里云因為光纜線路被挖斷、8月19日網易云音樂因為云存儲故障、8月26日上海電線因為網絡設備故障、9月10日阿里云新加坡機房因為火災等，都是基礎設施層的故障導致的，而且故障恢復時間長。

2.4 SRE穩定性建設

信息系統穩定性建設需要跨團隊的協作，開發和運維團隊需要打破專業之間壁壘，將上層應用、平臺和基礎設施全線打通，實現故障信息共享，降低溝通成本，故障快速定位和處置。從故障預防、故障發現、故障定位、故障恢復和故障改進等方面入手，利用混沌工程進行故障模擬和測試、出現故障時利用熔斷、限流、容災切換等技術優先保障業務連續性，并利用全鏈路和可觀測技術手段實現故障的快速發現和定位，最后對生產事件復盤分析并優化改進，實現“1-5-10”北極星指標。

圖片

參考資料：

1、盤點2023年信息系統安全事件

2、騰訊云4月8日故障復盤及情況說明，騰訊云

3、上交所2024-09-27系統故障時間線梳理及分析

4、OpenAI 宕機故障復盤，這次真的是 Kubernetes惹的禍

5、https://status.openai.com/incidents/ctrsv3lwd7976、對商業銀行開展業務連續性建設的思考和建議——以互聯網生產故障為鑒