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

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

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

1.1 4月8日騰訊云故障

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

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

3）故障復(fù)盤過程騰訊云官方給出了整個(gè)故障的處理過程

圖片

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

4）官方也給出了改進(jìn)措施，有以下幾點(diǎn)

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

1.2 7月2日阿里云故障

1）故障概述北京時(shí)間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訪問異常問題恢復(fù)。

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

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

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

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

1.6 9月10日阿里云新加坡機(jī)房故障

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

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

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

圖片

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

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

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

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

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

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

圖片

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

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

1.8 11月11日支付寶故障

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

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

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

1.9 12月11日OpenAI故障

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖片

基礎(chǔ)設(shè)施層的故障所謂牽一發(fā)而動(dòng)全身，會造成全局性的影響，因此在底層架構(gòu)設(shè)計(jì)的時(shí)候要盡可能的考慮這個(gè)點(diǎn)故障了會有什么影響、影響范圍是多少，能否做到高可用、是否可以應(yīng)急切換、逃生機(jī)制、故障隔離措施等。比如7月2日阿里云因?yàn)楣饫|線路被挖斷、8月19日網(wǎng)易云音樂因?yàn)樵拼鎯收稀?月26日上海電線因?yàn)榫W(wǎng)絡(luò)設(shè)備故障、9月10日阿里云新加坡機(jī)房因?yàn)榛馂?zāi)等，都是基礎(chǔ)設(shè)施層的故障導(dǎo)致的，而且故障恢復(fù)時(shí)間長。

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

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

圖片

參考資料：

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

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

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

4、OpenAI 宕機(jī)故障復(fù)盤，這次真的是 Kubernetes惹的禍

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