故障管理：故障應急和故障覆盤

時間 2021-01-19

原文原文鏈接

故障管理：故障應急和故障覆盤

上週咱們分享了故障管理中，應該如何對待故障，怎樣作好故障定級和定責方面的管理工做。今天我就和你分享當故障真正發生後，咱們在故障通報和故障覆盤方面的實踐經驗。服務器

故障應急

當故障真實發生後，帶來的影響不只僅是技術層面的，更多的是業務層面的，好比用戶和商家的批量投訴，交易量下跌，廣告資損等等。而這些影響又會產生巨大的外部壓力，並傳遞到技術團隊，這時若是沒有很好的故障應對機制，技術團隊就很容易陷入慌亂，不知所措。網絡

咱們可否有效應對這種突發且高壓的情況，我以爲有兩個方面十分關鍵。架構

第一方面，業務恢復預案。

這也是咱們在故障應急狀態下必定要堅守的第一原則：優先恢復業務，而不是定位問題。這就須要咱們事先有充足的預案准備以及故障模擬演練，這就跟咱們前面介紹的各類穩定性保障措施相關，經過穩定性平臺的建設，與咱們可以預見到的，以及咱們經歷過的故障場景相結合，當發生故障時可以第一時間執行對應的恢復預案。工具

同時，預案的執行不能僅僅在故障發生時才執行，而是應該把故障模擬和恢復演練放在平時。我在團隊中常常傳遞的一個理念就是：凡是沒有演練過的預案，都是耍流氓。也就是若是咱們在平常系統穩定的狀態下都不敢執行預案，或者執行了沒效果，那真到了故障發生後，在更爲複雜的情況下，預案100%也是不敢作的，由於這種異常狀態下，咱們還要考慮執行了預案是否會致使次生故障。學習

關於故障模擬，能夠分爲不一樣層面來梳理，好比：開發

IDC層面，如電力切換、UPS切換、核心網絡設備切換，單設備故障等，這些故障是能夠經過人爲破壞進行模擬的，模擬手段相對簡單，可是破壞力和影響面會很大，因此作以前必定要準備充分。咱們會按期1~2個月作一次相似的模擬演練，涉及機房配合的，也會提早跟運營商約定好時間；
系統層面，如CPU、磁盤IO、網絡IO、網絡時延、丟包等異常場景，這些都有開源或Linux系統自帶的工具支持，好比Stress工具模擬CPU升高，dd模擬磁盤IO，tc模擬網絡問題；
應用層面，最典型的就是RT升高，拋出異常，返回錯誤碼等等，這裏仍是會用Spring的註解功能，在運行時模擬異常情況，而後有針對性地看各類限流降級和開關預案策略可否生
效。

關於故障模擬，我再次向你推薦Netflix的Chaos Engineering，介紹得很是全面。同步

第二方面，有效的組織協調。

故障發生後的排障和恢復操做，每每須要多個技術團隊協做完成，這時就須要有必定的應急機制，來確保相關人員可以快速響應和高效協做。同時，由於對業務形成的影響致使業務團隊會承受不少外部壓力，這時也須要有統一的口徑對外反饋，好比大體緣由（對外不用詳細），影響面以及預估恢復時長等等，從而確保信息的透明，避免各類不着邊際的猜想對公司信譽形成的影響。團隊協作

這時，咱們前面介紹到的技術支持這個角色就起到了很是關鍵的做用。對內，要有效組織技術團隊的集中和協做；對外，負責對接業務部門同步信息，同時屏蔽各方對技術團隊和故障處理人員的干擾。監控

出現一個嚴重故障後，技術支持一般要作以下幾個關鍵事項。配置

肯定故障影響面及等級。故障會經過監控、告警、業務反饋或用戶商家投訴幾個渠道反饋過來，這時技術支持會根據故障定級標準，快速作出初步判斷，確認影響面，以及故障等級。
組織應急小組。對於沒法立刻恢復或仍須要定位排查的故障，會直接將相關技術團隊的主管和骨幹開發人員召集到一塊兒，一般是專用的會議室，並確認故障處理主要指揮者，一般是受影響業務的技術負責人，好比商品出現故障就由商品的技術團隊主管指揮排障，交易出現故障就由交易技術團隊主管指揮，若是是全站性的故障一般會由技術總監直接介入負責指揮。
信息通報。完成上述第一步後，一般會給相關技術和業務團隊通報故障初步信息，包括登記、影響面、故障簡述以及主要處理團隊和責任人。完成第二步，組織起應急小組以後，每隔必定時間，如15~30分鐘要對進展作一次信息同步。同時，若是等級和故障信息有變，也要同步出來，直至故障排除，業務恢復。爲了保證溝通的順暢，技術支持並不與處理故障的人員直接溝通，而是經過指揮者溝通，這樣確保高效溝通，同時也確保處理故障的人員可以相對地專一在故障處理上，而不是響應來自各方的詢問，甚至是質問。

因此，總體總結下來，故障應急過程就是：功夫要下在平時，注意建設各類工具和平臺，同時要儘量地考慮和模擬各類故障場景。這就像一支軍隊在平時必定要作各類軍事演習同樣，而後就是臨場發揮。當故障真正出現時，要有完善的應急機制，立刻可以有效運轉起來，而不是慌亂無措。

故障覆盤

上面介紹了故障應急，那接下來咱們再看故障管理的下一個階段，也就是故障發生以後的覆盤。

首先，咱們必定要先搞清楚覆盤的目的。覆盤的目的是爲了從故障中學習，找到咱們技術和管理上的不足，而後不斷改進。雖然咱們不肯意故障發生，可是從故障中學習，反而是提高團隊和員工能力的最佳手段，因此咱們必定要辯證地看待故障這件事情。

同時，切忌將覆盤過程和目的搞成追究責任或實施懲罰，這對於團隊氛圍和員工積極性的打擊是很是大的。這一點在前面的內容中已經詳細介紹過，這裏就再也不重複了。

在覆盤過程當中，技術支持仍然要起到關鍵做用。

召集覆盤會議。會提早將故障信息發給故障處理的參與方，準備覆盤過程當中須要討論的問題，視狀況決定是否邀請業務方人員參會；
組織會議流程。協調和控制會議中的討論，也就是俗稱的控場；
對故障定級定責。起到相似「法官」的判決做用，根據前面講到的標準執行；
明確後續改進行動及責任人，錄入系統並按期跟蹤。

覆盤會議中，一般會有哪些關鍵環節呢？

第一，故障簡單回顧。主要針對故障發生時間點，故障影響面，恢復時長，主要處理人或團隊作簡要說明。
第二，故障處理時間線回顧。技術支持在故障處理過程當中會簡要記錄處理過程，好比每一個操做的時間點，責任人，操做結果，甚至是中間的溝通和協做過程，好比幾點幾分給誰打了電話，多長時間上線的等等，這個過程要求客觀真實便可。業務恢復後，會發給處理人進行覈對和補充。這個時間線的做用很是關鍵，它能夠相對真實地再現整個故障處理過程。
第三，針對時間線進行討論。回顧完上述時間線以後，咱們會提出過程當中存在的疑問，這一點會對主要處理人產生必定的壓力，因此必定要保持對事不對人。一般咱們會針對處理時長過長、不合理的環節提出質疑，好比爲何告警沒有發現問題，而是用戶投訴反饋的？爲何從發生故障，到有人上線響應拖了很長時間？爲何對應的場景沒有限流、降級和開關等預案？爲何預案執行了沒有生效？爲何沒有作灰度發佈和驗證等等？經過這些問題和細節的討論，咱們會找出明顯的不足，記錄下過程當中的改進點。
第四，肯定故障根因。經過討論細節，咱們對故障根因進行判斷，並再次對故障根因的改進措施進行討論。在這個環節和上個環節中，一般會有不少討論甚至是爭論，技術支持要發揮的做用就是控制好場面，就事論事，必定不要讓討論失控，演變成相互指責和批鬥會，一旦有這種苗頭，技術支持必定要及時干預並給出警告。
第五，故障定級定責。根因肯定後，結合前面已經確認的故障影響面，就能夠對故障定級定責了，這裏還要依賴前面咱們介紹到的故障標準。不過，定責時，咱們會讓責任方團隊和相關處理人員在場，小範圍告知，這樣作主要是考慮責任人的我的感覺。若是無異議，就造成故障完結報告；若是有異議，則能夠向上級主管反饋，直至技術團隊負責人（CTO或技術VP）爲止。
第六，發出故障完結報告。故障完結報告的主要內容包括故障詳細信息，如時間點、影響面、時間線、根因、責任團隊（這裏不暴露責任人）、後續改進措施，以及經過本次故障總結出來的共性問題和建議。這樣作的主要目的是保證信息透明，同時引覺得戒，指望其它團隊也可以查漏補缺，不要犯一樣的錯誤。

按期總結故障案例

除了例行的故障應急和故障覆盤，咱們還會按期對一個時期內的故障案例進行總結。好比按照一個季度、半年和整年的週期，這樣能夠更容易地發現一些共性問題，以便於研發團隊在穩定性建設方面的規劃。

舉個例子，2017年年末，咱們總體總結了整年的故障案例，對P0~P2嚴重級別的故障進行分類彙總，就發現整年第三方緣由的故障，以及數據類的故障佔了很大比例。

咱們再往細節分析，發現第三方緣由的故障，多數是機房IDC的電力、網絡切換，單臺服務器硬件故障致使的。這些在單次故障覆盤時，很容易歸因於第三方，可是從整年來看，咱們認爲根因上，仍是咱們的系統健壯性不夠，在限流降級以及平常的故障模擬演練上，還有很大的提高空間。因此，咱們就拉上研發團隊的主管和骨幹員工，從新看這些故障，從新制定出穩定性提高的改進措施。

同時，在故障定級定責方面，由第三方緣由致使的故障，後續再也不做爲故障根因，而只做爲觸發因素。因此，在故障覆盤時必定要制定出咱們自身須要改進的措施。

針對數據類故障，咱們總結後發現大多集中在「有狀態業務」發佈過程當中。代碼和配置發佈能夠走發佈系統，有完善的流程支持，但數據的變動卻更多地依賴人工操做，且流程和周邊部件的配合上也不成熟。因此，咱們就明確下來，要加大對有狀態業務的發佈和數據變動工具的支持，將經驗固化下來，而不是靠人。