線上故障是我們技術同學經常遇到，也是技術成長中經常要經歷的事。從故障中我們可以吸取到很多教訓，變得越來越有經驗。
但是並不是每乙個團隊/技術同學在應對故障的處理方式上，都能做到合理和科學。
下面我就從線上故障的應對和處理方面，簡單的聊一聊我的看法。
故障發生時的處理：
1、快速定位故障
在複雜的系統架構中，尤其是微服務架構中，一旦發生故障可能會出現「多公尺諾骨牌效應」，系統會由乙個故障點波及到其他關聯的模組。
那麼一旦定位不及時，不僅僅會擴大故障，還可能會由於多個模組都在報錯、報警，給故障源的定位帶來困難。
因此我們要有一套快速的故障定位方法。我比較推薦的就是 全鏈條投入排查。即一旦發現線上故障，當前系統以及相關系統所對應的開發、運維、測試等方向，各抽調對口人，全都叫到線上去處理問題，各自排查各自模組/服務，如果排查自己負責的範圍沒有問題就可以在旁邊待命，以備在需要的時候進行配合。重點就是從一開始就一起介入。
不要小看這一點，看似平淡無奇，但實際場景下，要能保證有序的這麼去做到，還是挺難的，亞馬遜都是通過一套制度和任務分配系統來保障這種全鏈路排查方案得以持久實施的。
其實這麼做的目的就是在跟故障搶時間。
我們平時大多數情況下是怎麼做的呢，收到乙個線上功能的錯誤報告，然後對應功能的前端同學開始排查，排查了半天，發現是後端介面不正常，將問題轉到後端同學繼續排查，後端同學經過一段時間排查後，發現是運維問題或者是依賴的其他模組的問題，就再次將問題轉到運維或者其他專案組，然後後者接手開始排查。這樣來來去去，等定位到真正故障源的時候，黃花菜都涼了，不僅導致服務長時間的不可用，而且故障隨著時間的推移也在不斷擴大波及面，問題也越來越難以定位。
2、故障止損和恢復
在故障源定位之後，一般恢復系統的常用手段無非下面幾種：
- 重啟：部分問題是可以通過重啟的手段來臨時恢復的，以保障系統的暫時可用，但後續還需有其他方法徹底解決問題
- 限流和降級：這其實還是乙個臨時手段，通過將部分非核心系統進行降級和限制流量處理，來避免核心業務受到影響
- 回滾：如果屬於更新的**bug導致的問題，一般可通過回滾上乙個程式版本來迅速恢復，不過會導致部分新功能不可用
- 緊急更新：這個方式會經常被用到，明確定位問題源後，迅速修復**或元件，然後快速更新上線，比較依賴整個團隊的上線協同能力
故障發生前的準備
故障發生後的覆盤
說到故障後覆盤，離不開的乙個話題就是程式設計師的追責和懲罰。這其實是另乙個要討論的主題了，不過這裡，我簡單的描述一下我的觀點：對於線上事故，理應追究責任，但無需懲罰（特別嚴重的問題或特別不能容忍的錯誤以外），最重要的其實是做好善後工作，避免下次再犯，從根本上反思，刨根問底，找出問題的根源。這其實也就是下面要聊到的 「ask some whys」。
重點來聊聊覆盤要做的事情吧
另外就是ask some whys：
多問幾個為什麼，這也是需要團隊成員在一起問自己和問對方的。比如：為什麼沒有進行灰度發布（如果灰度發布能避免問題的話），為什麼測試沒有覆蓋到，為什麼故障處理耗時這麼久，等等，根據當前故障進行層層反問和深挖。
如何快速處理線上故障
線上故障通常是指大規模的影響線上服務可用性的問題或者事件，通俗點講就是 掉 坑 裡了，這個 坑 就是線上故障！線上故障的處理過程可以形象地表達為 踩坑 跳坑 填坑 避坑 線上故障的處理不僅是一項技術活，更是對技術人員 技術團隊反應能力 決策能力 判定能力 組織能力的考驗。面對突發的生產故障，需要快速...
如何快速處理線上故障
線上故障通常是指大規模的影響線上服務可用性的問題或者事件，通俗點講就是 掉 坑 裡了，這個 坑 就是線上故障！線上故障的處理過程可以形象地表達為 踩坑 跳坑 填坑 避坑 線上故障的處理不僅是一項技術活，更是對技術人員 技術團隊反應能力 決策能力 判定能力 組織能力的考驗。面對突發的生產故障，需要快速...
如何應對介面級的故障？
介面級故障的典型表現就是系統並沒有宕機，網路也沒有中斷，但業務卻出現問題了 導致介面級故障的原因一般有下面幾種 解決介面級故障的核心思想和異地多活基本類似 優先保證核心業務和優先保證絕大部分使用者。降級降級指系統將某些業務或者介面的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。降級的核心...