故障管理中的涅槃重生

對於任何一個技術團隊，如果要問大家，讓大家最痛苦、最不願面對的事情是什麼，我想答案只有一個，那就是：故障。

寫故障相關的文章，也比較痛苦，著實感覺有點費力，因為故障這個事情，跟技術、管理、團隊、人員息息相關，是需要一整套體系來保障的。後來想想，Google為了介紹穩定性和SRE的職責，可以出厚厚一本書，就能明白穩定性和故障管理這項系統工程的複雜度了。

所以，思來想去，這篇文章還是聚焦一下，聚焦在故障的事後階段，作為一個經歷了無數故障的技術管理者，把我在經歷了煎熬和痛苦之後的一點點體會總結出來的，共勉。

也希望我們每一個人和團隊都能夠在故障的涅槃重生中達到升華。

1、接受下面這個現實

系統正常，只是該系統無數異常情況下的一種特例。(From SRE ,by John Allspaw)

故障，是一種常態，任何一個軟體系統都避免不了，國內最牛的BAT避免不了，國外最牛的Google、Amazon、FB、Twitter等等也避免不了，業務體量越大，系統越複雜，問題和故障就越多，這個是必然的。

可能有人會問，那也沒見到這些大型網站整天出問題或不可訪問啊，其實這反而說明了這些公司的技術是非常牛的，他們在故障隔離、快速恢復、容災切換這些方面做的實在太好了，以至於一般的問題和故障，根本不會影響到業務訪問和體驗。

對於故障的態度上面，要接受現實，擁抱風險，所以我們的目標和注意力不應該是消除故障，或者不允許故障發生上，而是應該考慮Design for Failure，也就是怎麼讓我們系統更健壯，在小打小鬧的問題面前，仍然可以巋然不動，甚至是出現了故障，怎麼能夠讓業務更快恢復起來。

2、故障永遠只是表面現象，背後技術和管理上的問題才是根因

再用另外一個意思表達一下，就是永遠不要將主要注意力放在故障本身上，一定要將注意力放到解決技術和管理的問題上去。

這個邏輯一定是，技術和管理上的問題，積累到一定量通過故障的形式爆發出來，所以故障是現象，是在給我們嚴重提醒了。

所以，對於故障的理解更深入一下，應該轉化成考慮下面幾個問題才對：

a、為什麼會頻繁出故障？進一步考慮，是不是人員技術不過硬？人為操作太多，自動化平台不完善？線上敬畏意識不夠？

b、為什麼一個小問題或者某個部件失效，會導致全站宕機？進一步考慮，是不是業務高速發展，技術架構上是不是耦合太緊，任何一個小動作可能都是最後一根稻草？是不是容量評估靠拍腦袋，系統扛不住才知道容量出問題了？是不是限流降級等保障手段缺失，或者有技術方案，但是落地效果不好？

c、為什麼發生了故障沒法快速知道並且快速恢復？進一步考慮，監控是不是不完善？告警是不是太多人員麻木？定位問題效率低，遲遲找不到原因？故障隔離是不是還不夠完善？故障預案是不是紙上談兵？

d、。。。。。

總結下來，任何一個故障的原因都可以歸結到具體的技術和管理問題點上，在故障復盤過程中，通常會聚焦在某個故障個例上，歸納出來的是一個個非常具體的改進措施。但是這個時候對於管理者來說，要能夠關注到更全局的關鍵點上。比如，是不是應該考慮有更加完善的發布系統，減少人為操作；是不是應該有整體的穩定性平台建設，包括限流降級、開關預案、強弱依賴、容量評估、全鏈路跟蹤等子系統，以及建設完成後，應該如何一步步的落地；還有，故障預案和演練應該如何有效的組織起來，畢竟這些是從全局考慮，自上而下的一個過程。

這裡還想表達兩個觀點：

第一個，出問題，管理者要先自我反省看問題出在哪兒，不能一味的揪著員工的錯誤不放，員工更多的是整個體系中的執行者，做的不到位，一定是體系上還存在不完善的地方或漏洞，比如上述的問題，這個點上，管理者應該重點反思才對。

第二個，強調技術解決問題，而不是單純地靠增加管理流程和檢查環節來解決問題，技術手段暫時無法滿足的，可以靠管理手段來輔助。比如我上面提到的基本就都是技術手段，但是要建設完善肯定是要有一個過程，特別是對於創業公司，不可能一下就有完善的自動化體系，這時可以輔以一些管理措施，比如靠宣傳學習，提升人員的線上安全穩定意識，必要的double check，複雜操作的checklist等，但是這些只能作為輔助手段，一定不能是常態，必須儘快的將這些人為動作轉化到技術平台中去。單純的管理手段還是靠人，跟之前沒有本質區別，同時效果上很難被量化評估，同時還增加了管理成本。

3、定標準，定原則

故障定級標準，這個標準主要為了判定影響程度，各方能夠基於統一的標準判斷。同時也是避免復盤過程中技術支持判定故障很嚴重，但是責任方認為沒什麼大不了的這種情況出現。比如分P0-P4幾個級別，比如電商，就會主要以交易下跌、支付下跌、廣告收入這些跟錢相關的指標為衡量標準，根據具體數據對應到不同等級。關於可用性和可靠性，這個可以借鑒業界通用的MTBF、MTTR、MTTF這幾個指標來衡量。

故障定責原則，主要目的是判定責任方，避免我認為是你的責任，你認為是我的責任，大家相互推脫的情況出現。比如，舉個簡單的例子，介面變更，變更方要通知到對應的依賴方，如果未通知，變更方承擔責任，如果已通知，依賴方未及時做出調整，依賴方承擔責任，通知形式已公告和郵件為準。

這裡面還有一個角色，我們稱之為技術支持，也有的團隊叫NOC，這個角色就是來跟蹤故障處理和復盤的。運作模式上，技術支持有權對故障做出定級和定責，有點像法院法官的角色，而上面的兩個標準就像是法律條款，法官依法辦事，做到公平公正。

這裡只簡單介紹下原則，因為每個公司的業務形態和特點不一樣，裡面的具體內容可能也不一樣，評判標準也不同，這裡就不細說了，推薦Google SRE這本書，有很多很細緻的執行層面的建議，可以參考下，有興趣也可以線下交流。

4、出現故障到底要不要處罰？

這個也是上次在EGO微信小組討論的內容，重新整理了下。

故障的事後處理，我的建議，這裡一定要區分好兩個概念，就是定責和處罰，定責 ≠ 處罰。

定責就是這件事情一定要有人承擔責任，並且負責後續改進措施落地。定責一般是故障復盤的後來確定的，通過這個過程找到根因，制定改進措施，最終判定責任方，會議和公開場合只體現責任團隊，故障系統上會記錄到具體責任人，但是這個欄位不公開。

這個過程，就一個原則：對事不對人。因為故障復盤這個事情，每個團隊都會去做，具體的過程和方式方法沒有太大差別，所以這裡不講具體過程和方法。

回到大家都關心的是不是處罰這個問題上來，也就是是否跟薪資、獎金、績效考核、晉陞資格等等這些跟利益相關的事情掛鉤？我的觀點是，不能一刀切，不能上綱上線。

這裡首先問一個問題，處罰的目的是什麼？其實說的直白一點，目的就是想讓責任人長記性，別再出紕漏。這個地方再提個問題，到底什麼事情是長了記性，知道了痛之後，就可以有效降低再犯錯誤的概率的？

概括來講就是，由於主觀意識薄弱、低級且重複的失誤造成嚴重後果的故障，解決的就是這個主觀意識上的問題，這樣講可能不具有指導意義，建議做法就是設定高壓線，比如：

a、未經發布系統，私自變更線上代碼和配置；

b、未經授權，私自在業務高峰期進行硬體和網路設備變更；

c、未知授權，私自在生產環境進行測試性質的操作；

d、未經授權，私自變更生產環境數據信息；

d、。。。。。

通過高壓線去加強安全穩定意識，目的要讓每一個人對線上都有敬畏心理，因為有太多的嚴重故障都是因為無意識或意識薄弱導致，特別是那種自我感覺沒問題，命令就噼里啪啦敲到線上去了。如果意識到位，絕大多數嚴重問題都是可以避免的。所以，意識提升一定要放在第一位。

高壓線是什麼？建議我們在宣傳的時候，不要只講高壓線這個名詞，最好形象地說明一下後果，「明確告知哪裡是高壓線，一定不要碰。如果還不注意，不管主觀和還是客觀，高壓線碰上就是個死。這裡面不管是非要嘗試下電壓刺激，還是出門打醬油不小心踩上了，還是高壓線掉下來不小心被碰到了，只要觸碰到，後果都是一樣的」。（不寒而慄）

高壓線就是要堅決杜絕，碰一次就要讓責任人疼一次，這個時候，責任人敬畏意識和主觀意識提升了，人為失誤才會減少，這樣的處罰才是有效果的。

5、處罰的「負」作用遠超我們的想像

前面講到，定責不是處罰，就事論事，員工哪些地方做的不到位，是能力不夠，還是經驗不足，這些東西主管可以基於事實，很正式，甚至嚴肅地表達出來，通常情況下，員工也大都是可以接受。同時幫助員工進一步分析一下出現這些問題是因為哪些方面的不足導致，應該怎麼提升會更好，或者員工自身有什麼求助訴求，主管要能夠給到一些承諾去幫助改進。

這種情況下，員工的感受是，主管還是尊重我，他現在是在幫助我，並沒有否認和放棄我。

但是，話題和目的如果一旦轉到處罰相關的事情，員工一般會有兩種類型的反應，一種是消沉低落（反正都是我的錯，你說咋樣就咋樣）；另外一種是極力地反抗和質疑，比如他會質疑你，憑什麼罰我不罰別人，又不是我一個人的問題等等。

這個時候，處罰我 = 否認我，員工的注意力也會從怎麼改進這個點上轉移到你為什麼要處罰我這個點上來了，在這種消極情緒和氛圍中再去溝通什麼改進措施，就沒有任何效果了。作為管理者，也就非常容易陷入到與被溝通者的反覆解釋中，他質疑一句，你就解釋一堆，但是他壓根就沒聽進去。

我們的經驗，定責跟績效強掛鉤，團隊就陷入這種恐慌、質疑、挑戰以致最終相互不信任的局面。員工害怕或甚至拒絕承擔責任，寧可少做不做，也不願多做多錯，團隊溝通成本上升，運作效率自然下降。特別是一個故障如果是涉及多方的，撕逼扯皮推脫就開始了，都想著把責任撇乾淨，甚至出現當眾相互指責，背後議論紛紛的情況，破壞了整個團隊的團結和信任，這個負面效應殺傷力極大，其實遠比罰款帶來那點損失大的多了。

大家可以關注下團隊氛圍，如果是撕逼扯皮多了，協作效率下降了，極有可能的原因之一就是處罰措施使用不當了。

後來我們取消掛鉤，對於出現的故障有專門的系統記錄，然後把這件事情放到員工一個Q，半年，甚至一年表現中整體進行判斷，如果員工整體的表現都是不錯的，甚至是突出的，說明員工已經改正或者那件事情確實是偶爾的失誤導致，這種情況下員工仍然會有好的績效。但是如果是頻繁失誤、頻繁出問題，這種情況下也就沒什麼特別好說的了，用結果說話就好了。

我的團隊中，就出現過有員工導致了線上嚴重故障，當個Q績效較差，但是因為全年表現突出，年終仍然是優秀的情況；也有員工，因為連著兩個Q連續觸碰高壓線，全年又無明顯突出的表現，年終績效也就不理想的情況。

6、目的是鼓勵做事，而不是處罰錯誤

理解一個系統應該如何工作並不能使人成為專家，只能靠調查系統為何不能正常工作才行。（From SRE ，by Brian Redman）

這裡還有幾種情況要特別注意，當一個故障發生之後，主管一定要注意員工出問題的事情的背景是什麼。比如我直接列舉幾個情況：

a、比如這件事情是不是本身就極具挑戰性，需要嘗試某個新技術或解決方案，而團隊、業界和社區可能都沒有可供直接借鑒的經驗，結果在落地的過程中踩到了一些坑，導致出現問題。

這種情況在成熟的技術和產品中出現也極其容易出現，比如開源產品有時候不翻源碼都不知道某個地方埋著深坑，即使商業產品，像Oracle在他的官方bug庫里列著一堆已知bug，就是告訴你我是有問題的啊，你們用的時候自己小心著點別踩，踩了是你自己沒注意，但是一般不出問題沒人會去把整個bug list都去看一遍。

b、業務高速發展時期，業務量成指數級增長時，團隊人員技能和經驗水平整體上還沒法很好地應對時，這個時候可能任何一個小的動作都是那最後一根稻草。

c、員工在接受任務時，是不是團隊中沒有足夠的人手，是員工發現了問題站出來主動承擔的？

這幾種情況在團隊中還是會經常出現的，或者概括一點說，員工在主動承擔別人做不了或不願做的事情的情況下，只要不是涉及觸碰高壓線的或者造成什麼不可挽回的損失的，一定要優先鼓勵肯定，傳遞信任，而不是批評和處罰（定責該怎麼定就怎麼定，目的是改進）。何況，如果不出問題，可能很多主管壓根都沒有關注過員工在做的事情，過程中是否有困難，是否需要支持等等，這本身就是管理者的失責。

這樣的員工大都是責任心和積極性很強的，一個事情沒做好，其實內心裏面都不知道自責了多少遍，作為管理者，這個時候沒有任何必要再去批評他，甚至是處罰，而是要鼓勵他，幫助他，支持他，這個時候反而會達到「知恥而後勇」的激勵效果。

在當前這種新業務和新形態不斷湧現，又要求快速迭代的形式下，軟體開發這種技術工作很大程度上還是要依賴員工的創造性和創新性，所以在上面提到背景下，管理者一定要對故障有一定容忍度，員工努力做事的積極性一旦被打擊，變得畏首畏尾起來，也就談不上什麼技術進步和突破了，而且想要再恢復起來就非常非常困難，最終極大概率地會導致優秀人才流失，為別人做了嫁衣。

所以，團隊內部一定要營造出鼓勵做事向前沖的氛圍，而不是製造擔心犯錯誤被處罰的恐慌氛圍。

最後，總結

寫了很多，其實都是故障經歷的多了，一點點體會總結出來的，上面提到的一些反模式，我自己經歷過，自己也簡單粗暴地干過，直到目前也也不敢說現在我自己就能百分百完全做的很好。有時候道理我們都懂，但是往往實際做的時候，一個不注意，導向就變掉了。

故障這件事情，跟技術、管理、團隊、人員息息相關，會涉及到方方面面的細枝末節，非常複雜，也相當考驗管理者的技術管理水平，所以，以上只能算是經驗，或者叫做教訓更確切一些，分享出來，共勉。