故障管理：故障定級和定責

故障管理的第一步是對故障的理解，只有正確地面對故障，我們才能夠找到更合理的處理方式。今天就來和你分享關于故障定級和定責方面的經驗。

故障的定級標準

上期文章中介紹到，如果我們的注意力僅僅盯著故障本身，就非常容易揪著責任人不放，進而形成一些負面效應，所以我們要將更多的注意力放到故障背后的技術和管理問題上。

但是，這并不是說對故障本身就可以不重視，相反，故障發生后，一定要嚴肅對待。這里就需要制定相應的標準和規范來指導我們的處理過程。這個過程并不是一定找出誰來承擔責任，或者一定要進行處罰，而是期望通過這樣的過程，讓我們能夠從故障中深刻地認識到我們存在的不足，并制定出后續的改進措施。

這里有一個關鍵角色，我們稱之為技術支持，也有的團隊叫 NOC（Network Operation Center）。這個角色主要有兩個職責：一是跟蹤線上故障處理和組織故障復盤，二是制定故障定級定責標準，同時有權對故障做出定級和定責，有點像法院法官的角色，而上面的兩個標準就像是法律條款，法官依法辦事，做到公平公正。

所以，這里的一個關鍵就是我們要有明確的故障定級標準。這個標準主要為了判定故障影響程度，且各相關利益方能夠基于統一的標準判斷和評估。

現實情況中，因為各方受到故障的影響不同，對故障影響的理解也不同，所以復盤過程中，經常會出現下面這兩種爭執場景。

技術支持判定故障很嚴重，但是責任方認為沒什么大不了的，不應該把故障等級判定到如此之高；
技術支持認為故障影響較小，但是受影響方卻認為十分嚴重，不應該將故障等級判定得這么低。

遇到這種情況，技術支持作為故障判定的法官，就必須拿出嚴格的判定標準，并說明為什么這么判定。
我們將故障等級設置為P0~P4這么5個級別，P0為最高，P4為最低。對于電商，主要以交易下跌、支付下跌、廣告收入資損這些跟錢相關的指標為衡量標準。對于其它業務如用戶IM等，主要區分業務類型，制定符合業務特點的定級標準。兩個示例如下。

交易鏈路故障定級標準示例：

用戶IM故障定級標準示例：

故障定級的標準，會由技術支持與各個業務研發團隊進行點對點的細節溝通討論，從業務影響角度把影響面、影響時長這些因素串聯起來。這樣即使在后續出現爭執，也會有對應的標準參考。這個標準可能覆蓋不到有些故障影響或特例，但是技術支持可以根據自己的經驗進行“自由裁量”。同時，每個季度或半年對標準進行一次修訂和完善。

這樣，我們前面提到的爭執就會越來越少，再加上我們內部樹立了“技術支持角色擁有絕對話語權和決策權”的制度，執行過程中就會順暢很多。

對于P0故障，通常是由兩個級以上的P1故障疊加造成的，這說明已經發生了非常嚴重的全站故障。

不同的故障定級，在故障應對時采取的策略也就不同。一般來說，P2及以上故障就需要所有相關責任人馬上上線處理，并及時恢復業務。對于P3或P4的問題，要求會適當放寬。整個過程，技術支持會給出一個基本判斷，然后會組織召集臨時故障應急小組處理。

關于全年全站，或者分業務的可用性和可靠性，這個可以借鑒業界通用的MTBF（Mean Time Between Failures，平均故障間隔時間）、MTTR（Mean Time To Recovery ，平均修復時間）、MTTF（Mean Time To Failure ，平均失效前時間）這幾個指標來衡量，這里我們就不詳細介紹了。

故障的定責標準

上述的故障定級標準，主要是用來判定故障等級，使得故障相關方不至于過分糾結在等級標準上。而故障定責的主要目的是判定責任方。這就需要有明確的故障定責標準，我認為有兩個主要目的。

避免扯皮推諉。比如我認為是你的責任，你認為是我的責任，大家爭執不清，甚至出現詆毀攻擊的情況。
正視問題，嚴肅對待。不是為了處罰，但是作為責任方或責任團隊一定要正視問題，找出自身不足，作為改進的主要責任者，來落地或推進改進措施。

關于第一點，避免扯皮推諉，大概是很多團隊都會遇到的非常頭疼的問題，也是最令人生厭的問題，所以避免這樣的問題，就必須得有相對清晰的定責標準。

比如我們經常會提到的運維背鍋的說法，這種情況出現的場景經常是，某個核心功能出現了故障，有大量超時或失敗，對應的開發定位一下，說我的代碼沒有問題，場景也沒復現，這個應該是運維負責的主機、網絡或者其他基礎服務有問題吧，這個責任很輕易地就甩給了運維。類似的上游把責任推脫到下游的情況是經常出現的。

我們自己的實踐，是嚴禁這種情況出現的。也就是作為受影響方，開發負責人有責任端到端地把問題定位清楚，只有當定位出來的問題確實是發生在運維的某個部件時，才允許將責任傳遞，否則不允許出現將自己的問題簡單排除，就推斷或者感覺應該是其他責任方的問題，然后終止后續排查或者指定下游責任方的情況出現。

當然，在這個過程中，如果需要配合，是可以要求各方投入支持的，因為共同的目標還是要清晰定位問題，找到解決方案。

這時候，就更加需要開放和寬松的氛圍，如果大家始終朝著如何擺脫責任或甩鍋的目標行事，就會出現非常負面的效應，這一點后面我們會詳細分享。

關于定責，我們劃分了幾個維度，我簡單示例如下。

變更執行
比如變更方沒有及時通知到受影響方，或者事先沒有進行充分的評估，出現問題，責任在變更方；如果通知到位，受影響方沒有做好準備措施導致出現問題，責任在受影響方；變更
操作的實際影響程度大大超出預期，導致受影響方準備不足出現故障，責任在變更方。

服務依賴
比如私自調用接口，或者調用方式不符合約定規則，責任在調用方；如果是服務方沒有明確示例或說明，導致調用方出現問題，責任在服務方等等。

第三方責任
比如機房IDC電力故障、服務器故障、運營商網絡故障等等，如果確實是不可抗力導致，責任在第三方；但是因自身的冗余或故障預案問題導致故障，責任在應用Owner。

有了這樣的原則，在故障復盤時，就可以有效減少不和諧氛圍的出現。因為每個公司的業務形態和特點不一樣，里面的具體內容可能也不一樣，上述的定責標準可能不完全適用，所以僅供示例參考。如果你在日常深受故障定責的困擾，建議盡快把規則明確起來，并能夠與各方達成一致，這樣就會最大程度地減少扯皮推諉的情況出現。

總結

今天我們討論了故障管理中的定級和定責標準。蘑菇街在這方面的具體管理執行中，還是取得了不錯的效果，所以分享出來，歡迎你留言與我討論。

總結

以上是生活随笔為你收集整理的故障管理：故障定级和定责的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。