淺談在數(shù)字化運營服務(wù)管理/ITSM中的事件管理中之“故障復(fù)盤”（二）——如何高效組織故障復(fù)盤

作者：秦鴻林 紫羚云 CGO兼SaaS負責(zé)人 上一篇《淺談在數(shù)字化運營服務(wù)管理/ITSM的事件管理之“故障復(fù)盤”（一）——故障復(fù)盤的重要性及總體要求》，我們只談了故障復(fù)盤的必要性和價值。本篇著重分析如何高效組織故障復(fù)盤。并在下一篇中，重點闡述故障復(fù)盤中的一些注意事項，并給出一個故障復(fù)盤的檢查表，從各個維度提升故障復(fù)盤的質(zhì)量和效果。 筆者從公開渠道，收集了2023年以來發(fā)生的幾起典型的故障： 2023年3月29日，3 月 29 日，#唯品會崩了#的話題登上熱搜。 后續(xù)，唯品會發(fā)布了關(guān)于 329 機房宕機故障處理公告：此次南沙機房重大故障，影響客戶達 800 多萬，判定為 P0 級故障，對負責(zé)人予以免職處理。 同日，某云廠商發(fā)布公告稱“監(jiān)測到廣州五區(qū)部分云服務(wù)異常（CLB、COS、Redis、WAF、TKE、控制臺等）,目前工程師正在緊急處理中”，微信、QQ 等均出現(xiàn)功能異常。微信包括語音呼叫、賬號登錄、朋友圈以及支付在內(nèi)的多個功能無法正常使用，QQ 文件傳輸、QQ 空間、QQ 郵箱等也同樣出現(xiàn)問題。最終該云廠商將事件定級為“公司一級故障”，管理層認為，這次事故暴露出容災(zāi)設(shè)計方案和應(yīng)急預(yù)案不完善的隱患，有關(guān)業(yè)務(wù)部門的風(fēng)險防范意識不到位，所以對大量相關(guān)領(lǐng)導(dǎo)做出了處罰。其中一高級副總裁被通報處理，兩位總經(jīng)理和總監(jiān)被處以降級和免職處罰…… 3月21日，#東財崩了#登上微博熱搜。 據(jù)悉，東方財富APP在當日上午、下午均出現(xiàn)長時間用戶登錄異常、持倉顯示異常、無法交易等情況。3月21日A股下午開盤后，有網(wǎng)友反饋饋，東方財富軟件再次崩了。 6月19日，“‘券商一哥’系統(tǒng)崩了”上了熱搜…… 按照2021年6月4日證監(jiān)會發(fā)布的《證券期貨業(yè)網(wǎng)絡(luò)安全事件報告與調(diào)查處理辦法》，當集中競價交易系統(tǒng)以外的實時交易系統(tǒng)出現(xiàn)嚴重異常， 且故障持續(xù)時間30分鐘以上的屬于重大事件；若故障持續(xù)時間10分鐘以上的屬于較大事件……不管是經(jīng)濟損失，還是對于券商本身的聲譽、對券商信息技術(shù)部門的負責(zé)人的影響，都是不言而喻的。 這幾起典型的故障，都是血淋淋的教訓(xùn)，影響、損失都非常巨大。一定不要浪費任何一個故障，不要浪費每次復(fù)盤，改進提升，避免更多更大故障，更大損失。 三、如何有效組織故障復(fù)盤？ 首先，我們需要建立故障復(fù)盤的機制和文化，這里核心就是確定故障復(fù)盤的方式和模板，其次是鼓勵相關(guān)干系人積極參與。 1、確定故障復(fù)盤的方式 故障復(fù)盤流程應(yīng)該明確定義故障的復(fù)盤的模板，比如故障的時間線、哪些人參與、輸出什么、責(zé)任方分類、改進措施模板等，團隊內(nèi)部各角色的職責(zé)，并明確涵蓋審查及跟蹤故障的信息、注意事項和隨后必須采取的行動。 筆者之前的一個做法，就是每周至少定期組織一次，最近一周的故障一起上“故障復(fù)盤會”，在上會前，會要求各個責(zé)任人提前準備好故障處理報告初稿。這里的故障，主要是指的是影響到系統(tǒng)可用性的故障或重大的風(fēng)險和隱患，包括基礎(chǔ)設(shè)施和IT系統(tǒng)的故障，不包括桌面的故障和不影響系統(tǒng)可用性的故障，這里的故障，也不限于重大故障，也包括影響有限的，影響時長較短的故障，甚至是一些風(fēng)險隱患。 2、團隊成員積極參與 在故障復(fù)盤過程中，應(yīng)該鼓勵團隊成員主動參與。與會人員還應(yīng)該有足夠的廣度，足夠技術(shù)深度，以便在分析故障時能夠理解各種數(shù)據(jù)和工具。 這點非常重要，故障復(fù)盤，很多時候不是運維一家的事情，有時候需要將研發(fā)，甚至業(yè)務(wù)方或者產(chǎn)品線一起參與，涉及到廠家的，廠家的參與也是非常重要的。目的是提升參與度，從各個不同的崗位視角分析故障，一起改進。因為IT系統(tǒng)的故障，很多時候和架構(gòu)、程序本身有關(guān)，甚至業(yè)務(wù)需求有關(guān)系，比如有些因為特殊的原因，倉促的上線，首次UAT修改缺陷形成的版本沒有很好的回歸測試導(dǎo)致的版本質(zhì)量問題等。 組織會議復(fù)盤，當面溝通效率更高、能快速平息故障，解決問題。對于一般故障，也可以在運維小組范圍內(nèi)組織復(fù)盤會議。 在故障復(fù)盤會上，涉及到重大故障的，管理層的參與和專家的參與也是非常關(guān)鍵的。管理者和專家，因為經(jīng)驗和視野原因，可能會更快更好看到深層次的問題。管理層的參與，對于問題最終的解決，優(yōu)化改進措施最終落地都是有幫助的。 注意：ITIL使用了LACMT模型：也就是領(lǐng)導(dǎo)者（Leader）、管理者（Administrator）、協(xié)調(diào)者/溝通者（Coodinator/communicator）、方法和技術(shù)專家（Methods and techniques expert）、技術(shù)專家（Technical expert），也可以用來參考在事件管理，包括故障復(fù)盤中各個參與角色及其職責(zé)。 以下是日常如何有效組織故障復(fù)盤的幾個步驟： 1、回顧，收集故障的信息和數(shù)據(jù) 作為第一步，回顧故障，需要整理相關(guān)故障的信息和數(shù)據(jù)，可以按照時間線來梳理。這些數(shù)據(jù)可以來自團隊成員、日志記錄、監(jiān)控系統(tǒng)等。在這個過程中，還應(yīng)該包括有關(guān)故障的影響范圍以及對用戶、客戶的影響程度。這里就是前面提到的時間線，從故障發(fā)現(xiàn)到處置完畢的整個環(huán)節(jié)做回顧，包括故障發(fā)生、故障發(fā)現(xiàn)、響應(yīng)時間、嘗試處置時間、診斷時間、應(yīng)急預(yù)案啟動時間、應(yīng)急恢復(fù)時間等，通過時間線，還原整個故障處理行動。 2、分析故障原因 利用收集到的故障信息和數(shù)據(jù)，團隊可以分析這個故障的原因，從根本上確定必須采取哪些措施避免再次發(fā)生。包括： --分析故障發(fā)現(xiàn)、定位、恢復(fù)過程的問題，定位時間是否可以更短？ --處理過程中可觀測可感知能力，異常部分是否有監(jiān)控？是否有告警？告警是否及時準確？ --收到告警后的響應(yīng)、處理、分析判斷是否及時、準確？ --是否有按照要求進行必要的通報、升級？ --是否有應(yīng)急預(yù)案，以及啟動應(yīng)急預(yù)案是否正確？ --應(yīng)急處理的協(xié)同是否有效？ --分析故障對業(yè)務(wù)的影響？影響到的服務(wù)，業(yè)務(wù)，用戶情況。 --對可用性指標的影響？ --故障的根本原因是什么？是否有設(shè)計原因？在架構(gòu)層面是否有脆弱點？ --日常運維保障是否到位？應(yīng)該做的例行工作（例如巡檢）是有按照要求做到位？ --故障是臨時解決，還是永久解決？ 3、總結(jié)及制定解決方案和改進措施 確認大家分析清楚，達成一致意見后，根據(jù)分析結(jié)果，制定解決方案，并且準備計劃執(zhí)行故障解決措施。 總結(jié)本次故障帶來的經(jīng)驗教訓(xùn)并達成一致的意見。 這里很重要的工作，就是對故障進行定性、定級、定責(zé)（這個要慎重，在堅持原則的基礎(chǔ)上，要盡可能充分討論、分析達成一致，避免異議甚至申訴），要是不涉及到考核和績效，可以盡快確定下來，反之，涉及到績效，和外部供應(yīng)商涉及到商務(wù)事宜的，要慎之又慎。關(guān)于故障的定級定責(zé)，后續(xù)再專門寫一篇文檔來分享。 這里總結(jié)一些常見的要點： --總結(jié)對業(yè)務(wù)的影響、損失、范圍； --業(yè)務(wù)影響時長，對業(yè)務(wù)的受影響的程度； --總結(jié)觀測和感知方面的問題，涉及到監(jiān)控告警、發(fā)現(xiàn)、響應(yīng)、定位等過程； --總結(jié)設(shè)計問題，包括基礎(chǔ)架構(gòu)、軟件架構(gòu)、產(chǎn)品研發(fā)、上線等； --總結(jié)應(yīng)急處理協(xié)同的問題； --總結(jié)定性：包含代碼質(zhì)量、測試質(zhì)量、流程規(guī)范、變更操作、容量規(guī)劃、產(chǎn)品邏輯、硬件設(shè)備、預(yù)案失效、原廠故障等等； --定級：對事件級別的一個正式確定。 --定責(zé)：運維、開發(fā)、測試、產(chǎn)品團隊、第三方廠商等； --總結(jié)改進措施，如何減少和防范類似故障的再次發(fā)生？ --如果再次發(fā)生，又如何快速發(fā)現(xiàn)？是否可以快速解決？哪些活動可以自動化? --研發(fā)和測試環(huán)節(jié)，是否可以改進，可以提前發(fā)現(xiàn)或規(guī)避問題？方案是否可以優(yōu)化？ --軟件架構(gòu)是否可以做得更好？是否有技術(shù)債需要消除？如果是有變更控制不嚴格，還涉及到變更流程的優(yōu)化改進。 --容量管理是否需要改進？ --是否涉及到安全相關(guān)工作的改進？ 這里其實可以比較多，因為從ITIL事件管理的活動來說，就涉及到其它大量的ITIL實踐，從多個相關(guān)的實踐總結(jié)和改進是完全可能的和必要的：

上面提了一些總結(jié)的維度，其實價值流和流程、組織和人員、信息和技術(shù)、合作伙伴和供應(yīng)商也是一個不錯的維度，也是一個不錯的思考框架：

4、發(fā)布故障復(fù)盤總結(jié) 至關(guān)重要的一環(huán)是記錄措施的確定與結(jié)束。故障復(fù)盤的記錄應(yīng)該識別在復(fù)盤過程中確定或制定的任何措施。這些記錄有助于存檔，監(jiān)督并檢查系統(tǒng)或服務(wù)的改善和穩(wěn)定性。對于復(fù)盤的結(jié)果、故障處理報告，需要正式通報利益相關(guān)方，包括風(fēng)控部門、責(zé)任部門、業(yè)務(wù)部門，視故障是否涉及機密，擴大范圍讓其他人引以為戒。 故障處理報告，也要及時上傳到ITSM知識庫，納入到知識庫管理。 5、跟進改進措施落地情況 隨著解決方案的得出，還應(yīng)該進行后續(xù)跟蹤活動，以保證問題徹底消失，并避免其再次產(chǎn)生。這里的除了在例會，下一故障復(fù)盤會跟進之外，盡可能考慮在線化，比如是部分需要深入分析的和改進的，納入問題管理流程來管理，涉及到變更的，及時提交RFC等。