互聯網故障管理體系建設，看這一篇就夠了
一、故障及故障管理定義
業界故障管理均基于ITIL演化而來，根據實際情況精簡流程以適配互聯網的精益迭代。
1、ITIL中的定義
故障：①非計劃性的IT服務中斷，或者IT服務性能的下降。②配置項的失效，即便沒有影響到服務。
故障管理：對所有故障進行處理的流程。
故障管理的目標：盡快恢復服務到正常運行，并且最小化對業務運營的不利影響，從而盡可能地保證服務質量和可用性的水平。
2、業界較完善定義
故障：除用戶方環境或者用戶自身操作引起的外，其他無論什么原因導致服務中斷、服務品質下降或者用戶服務體驗下降。
故障管理：圍繞故障生命周期采取的一系列活動和流程，包括故障等級定義、故障發現、故障響應、故障應急、故障恢復、故障復盤及持續改進。
故障管理的目標：預防可預知的問題，快速恢復不能預知的問題，不再重復已發生的問題。
二、為什么要做故障管理
無論是理論還是實踐，均證明故障只要有發生的可能，它總會發生。所以為了保障業務穩定性，需提前發現、解決風險，及時發現、定位原因、快速恢復故障，同時要確保改進措施有效落地、避免故障重復發生，我們需要建立一個規范可遵循、閉環的故障管理體系。
三、故障管理怎么做
故障管理就是圍繞故障全生命周期管理，形成體系閉環、持續改進。
無論是理論還是實踐，均證明故障只要有發生的可能，它總會發生。所以為了保障業務穩定性，需提前發現、解決風險，及時發現、定位原因、快速恢復故障，同時要確保改進措施有效落地、避免故障重復發生，我們需要建立一個規范可遵循、閉環的故障管理體系。
1、故障等級定義
1.1 故障序列
故障管理部門（例如質量部門、NOC、運維管理部門等）可根據實際情況定義故障序列，以下為目前業界可參考的序列，一類序列一般分為4級，級別數字越小嚴重程度越高。
- P（PRIORITY）序列：技術基礎序列，為故障處理的綜合優先級。
- D（DATA）序列：數據質量序列，綜合數據資產等級與數據影響因素。
- R（RISK）序列：輿情風險序列。
- S（SLA）序列：衡量影響SLA嚴重程度。
1.2 故障定級
以P序列舉例：
故障定級建議分為通用型和業務型兩類，業務線型故障定級標準不得低于通用型故障定級標準。
通用型故障等級由故障管理部門定義，可包含受影響用戶數、受影響商家數、客訴增量、資金損失等通用指標。通用型故障場景在業務線型故障場景未覆蓋情況下兜底。
業務型故障等級由故障管理部門聯合業務團隊基于用戶視角共同定義，以下為業務型故障定級舉例。公司內部工具也可按照此模板定義故障級別以納入故障管理。
2、監控告警
核心是業務監控關聯故障等級定義做到故障及時發現。
告警本身要做到智能告警以提升告警準確率，例如智能閾值、智能基線、根因算法等。
3、故障應急
問題升級為故障后，由故障管理部門及時通告故障信息，拉起故障處理群/電話會議，協調、跟進、監督故障處理直至恢復。
由于故障管理部門需要7X24應急響應，有條件的公司可以參考google的SRE、阿里的GOC組建團隊，成員分布不同時區，實現日出而作，日落而息。
4、故障恢復
故障發生后的第一要務是恢復業務，預案、重啟、降級、隔離、切流、飽和式應急等，都是可選的方案。
5、故障復盤
5.1、故障復盤時效
為確保問題、風險能夠得到足夠重視，并及時制定改進措施，建議P1P2級別故障1個工作日內完成復盤，P3P4故障3個工作日完成復盤，其他序列故障可參考P序列時效性。
5.2、故障復盤準備工作
為提升復盤會議效率，故障管理人（復盤會議主持人）應該在會議之前整理如下信息：
- 故障處理過程：必須包含故障注入、故障發生、故障發現、故障響應、初因定位、恢復執行、故障恢復、根因定位等核心時間點及操作，其他關鍵時間點及操作視實際情況補充。
- 影響業務：具體到下跌時段、下跌比例，資金損失金額。
- 用戶/商家影響情況：理論影響量，來電、在線咨詢量
- 故障根因及對應根因分類：設備故障、代碼問題、流程規范、應急災備、容量等。
5.3、故障復盤重要關注點
- 故障預防：是否變更觸發
- 故障發現：發現時長，發現來源，監控優化
- 應急響應：響應時長
- 故障恢復：恢復時長，恢復措施沉淀，改進
- 改進措施：基于以上信息制定可驗的證改進措施，完成時間點，負責人
6、持續運營
持續運營是個廣義的概念，除了故障數據各種維度晾曬、經驗傳承、文化宣導外，最主要的是通過故障數據分析，識別故障各個生命階段的薄弱點、風險點，針對薄弱點、風險點有專項改進。
比如多次未灰度直接發布引起重大故障，變更制度、變更平臺是否可強管控；故障恢復主要依賴代碼發布導致恢復慢，是否可打造及時恢復文化，針對常見故障場景是否能沉淀快恢預案等。
四、對故障管理工作者的建議
故障管理路長且艱，以下給故障管理同學的建議，希望共勉。
1. 積極主動、認真負責
- 風險、問題跟進不到位，演變成故障的數量會增多
- 故障跟進不到位，影響面會擴大
- 故障根因不明確，改進措施可能無效
- 改進措施無效，故障還會重復發生
2. 敢于質疑
- 監控發現是否及時
- 故障處理過程是否可優化，有沒有人為失誤
- 業務影響面統計是否真實
- 故障原因是否是本次故障的根因
- 改進措施制定是否合理
3. 自我提升
故障管理者不是統計、記錄文員，要以架構師嚴格要求自己，能夠指出故障各個階段存在的問題，并能夠獨立承擔對應優化專項。
