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

1、2024年信息系統(tǒng)主要故障盤點

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

1.1 4月8日騰訊云故障

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

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

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

圖片

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

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

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

1.2 7月2日阿里云故障

1）故障概述北京時間2024年07月02日10:04，阿里云監(jiān)控發(fā)現(xiàn)上海地域可用區(qū)N網(wǎng)絡(luò)訪問出現(xiàn)異常，經(jīng)阿里云工程師緊急介入處理后，于10:35完成網(wǎng)絡(luò)切流調(diào)度后，10:42訪問異常問題恢復。

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

3）故障原因經(jīng)過調(diào)查發(fā)現(xiàn)，此次故障的根本原因是機房光纜中斷，導致網(wǎng)絡(luò)訪問異常。雖然阿里云采用了多可用區(qū)的架構(gòu)設(shè)計，但此次故障發(fā)生在單個可用區(qū)內(nèi)，導致該區(qū)內(nèi)的服務受到影響。

1.3 7月19日微軟windows系統(tǒng)藍屏事件

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

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

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

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

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

1.4 8月19日網(wǎng)易云音樂故障

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

圖片

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

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

1.5 8月26日上海電信城域網(wǎng)設(shè)備故障

1）故障概述8月26日下午5點30分左右，上海部分電信寬帶用戶突然發(fā)現(xiàn)無法正常上網(wǎng)。這一突發(fā)事件迅速在社交媒體上發(fā)酵，許多用戶紛紛抱怨“電信斷網(wǎng)”“無法連接互聯(lián)網(wǎng)”，甚至有用戶調(diào)侃稱“上海電信崩了”。上海電信客服表示，部分寬帶業(yè)務發(fā)生異常，正在全力搶修排障。18時05分，經(jīng)過緊急搶修，上海電信全面恢復業(yè)務。上海電信市場部及“中國電信上海客服”官微相繼發(fā)布聲明，對故障給用戶帶來的不便表示歉意，并表示將加強巡查，排查風險點，確保網(wǎng)絡(luò)穩(wěn)定。故障持續(xù)時間35分鐘。

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

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

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

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

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

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

圖片

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

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

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

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

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

上交所競價平臺的系統(tǒng)架構(gòu)圖如下：

圖片

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

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

1.8 11月11日支付寶故障

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

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

3）故障原因據(jù)支付寶消息，因系統(tǒng)消息庫出現(xiàn)局部故障，導致部分用戶的支付功能受到影響。具體細節(jié)未透露。

1.9 12月11日OpenAI故障

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

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

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

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

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

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

2、信息系統(tǒng)安全事件啟示

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

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

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

MTBF = MTTF + MTTR，MTBF越長，表示系統(tǒng)持續(xù)提供正確服務的時間越長；MTTR越短，表示系統(tǒng)從故障中恢復的速度越快。因此，在出現(xiàn)信息系統(tǒng)故障時，快速的應急恢復，提高業(yè)務連續(xù)性是生產(chǎn)運維的關(guān)鍵。

2.1 信息系統(tǒng)故障的輿情影響

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

2.2 信息系統(tǒng)的網(wǎng)絡(luò)安全因素

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

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

2.3 基礎(chǔ)組件的關(guān)鍵性

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

圖片

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

2.4 SRE穩(wěn)定性建設(shè)

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

圖片

參考資料：

1、盤點2023年信息系統(tǒng)安全事件

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

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

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

5、https://status.openai.com/incidents/ctrsv3lwd7976、對商業(yè)銀行開展業(yè)務連續(xù)性建設(shè)的思考和建議——以互聯(lián)網(wǎng)生產(chǎn)故障為鑒