線上故障通常是指大規模的影響線上服務可用性的問題或者事件，通俗點講就是：掉‘坑’里了，這個‘坑’就是線上故障！線上故障的處理過程可以形象地表達為：‘踩坑’、‘跳坑’、‘填坑’、‘避坑’。
線上故障的處理不僅是一項技術活，更是對技術人員/技術團隊反應能力、決策能力、判定能力、組織能力的考驗。面對突發的生產故障，需要快速定位問題，找到解決方案，快速實施解決方案并不是一件容易的事情。本文主要包括如下內容：線上故障處理的目標、思路、步驟、基礎設施。
本文是依據平時經歷的生產故障排查和處理，總結一些膚淺的方法論，以求共同探討，共同提高，歡迎探討。
線上故障處理的目標
任何動物一旦掉進坑里，明智的做法一定是：跳坑-->填坑-->避坑，線上故障處理的過程也一樣，優先級從高到低，線上故障處理的目標如下：
跳坑
‘跳坑’——快速恢復線上服務，或者將對線上服務的影響降到最低。
線上服務的可用性決定著服務者的客戶利益，影響著公司的收益。一旦線上環境不可用，無法服務用戶，給公司/團隊帶來經濟利益損失的同時，更為嚴重的會給公司/團隊帶來惡劣的名聲。所以一般公司都會對線上環境提出穩定性和可靠性的要求，這也是團隊乃至部門的kpi。為此，遇到生產故障后的第一要務是：恢復生產服務，即使不能完全恢復線上服務，也要想盡辦法將對線上服務的影響降到最低。
填坑
‘填坑’——找到問題原因，根本上解決問題。
在恢復線上服務，盡最大限度減掉對用戶/公司/團隊帶來的影響后，我們需要徹查問題，搞清楚故障發生的根本原因，從根本上解決問題。通常情況下，‘填坑’和‘跳坑’是同步在做的，完成‘填坑’也就意味中‘跳坑’成功，但是也有一些緊急情況下的特別‘跳坑’方法，比如重啟服務，或者服務降級/熔斷等等，實際并未在當時完成‘填坑’，而是先采取非常規手段‘跳坑’，之后再慢慢‘填坑’。
避坑
‘避坑’——舉一反三，消滅隱患。
找到了根本原因，解決了問題之后，我們需要舉一反三，以此及彼，想想在這個故障排查和處理過程中，那些環節存在弱點？那些流程/規范/制度需要優化？這類問題是否在其他系統或者團隊中也存在？通過這樣的反思和自我批評，形成一份線上事故報告，不斷完善流程，避免再次踩坑，也在團隊中交流經驗，共同提高。
線上故障處理的思路
依據線上故障處理的目標及目標的優先級，線上排障的第一目標是恢復線上服務或者降低對線上服務的影響，關鍵點在于快速二字，在‘跳坑’-‘填坑’之后，再行回溯總結，以便‘避坑’。因此，可以將線上故障處理的步驟分為：
其中前三步是‘跳坑’行為，后面一步包含了‘填坑’和‘避坑’。
上述步驟并不是說要從上到下順序進行，建議在不亂陣腳的情況下，并行去做，因為通常線上故障后會緊急啟動故障處理程序，運維、開發、測試、產品各個角色都會參與進來，這時候分工下去，并行去做，不斷匯總消息，做出判斷，以求快速排障，恢復服務。這個思路類似于操作系統的fork/join設計思想，目的在于提高效率。
在無法快速找到故障原因的時候，需要果斷跳過故障定位環節，直接進行故障排除，比如采用服務降級、服務器擴容等手段，確保對線上服務降到最低且可控。等到線上服務'撐'過去之后，我們再慢慢定位故障原因，根本上解決問題。
下面我們會對這四個步驟進行詳細說明。
故障發現
線上故障一般可以通過如下幾種途徑傳遞到開發/運維人員手中，按照從上到下的順序，故障的嚴重程度依次變高。
•主動發現——可能是開發或者運維不經意間查看生產環境的error日志，或者例行檢查監控項時，看到了一些異常的現象，進而發現了故障；•系統監控告警——通常包括cpu、內存、io、tcp連接數、disk、線程數、GC、連接池等各個服務器指標異常，可能是服務器出現了異常，但是業務還未受到大面積影響；•業務監控告警——如用戶登錄失敗率增加，訂單堆積量增大，則意味中系統的異常已經很嚴重，影響了業務處理；•關聯系統故障追溯——上游系統或者下游系統的故障處理郵件/電話追溯，可能和本系統有關系，而且情況已經變得很糟糕了，需要快速定位；•生產事件上報——通常業務異常帶來的影響傳遞到用戶，再從用戶傳遞到客服人員，再到技術人員手里，會存在一定時延，所以一旦有生產事件上報，這個時候嚴重性已經到了最高，技術人員的壓力也會增大，因為會有領導的關注，產品經理的詢問和催促，客戶人員的焦慮帶來的壓力。
上述途徑傳遞過來的信息僅僅只是線上故障苗頭，并非一定就發生了大規模的線上故障，所以首先需要確認的是這是不是一次線上故障？還是只是個例生產問題？是否和本系統有關系？一般來講：‘系統監控告警’和‘業務監控告警’的情況下，大部分都和本系統有關，且可能是線上故障；而‘主動發現’和‘生產事件上報’則需要做甄別，可以根據上報事件個數或者問題復現的方式來評估是否是大規模線上故障，或者跟蹤日志信息或者特定用戶問題追溯來確定。至于‘關聯系統故障追溯’的情況，首先不要慌，先從宏觀上確定本系統服務正常，一般可以檢查是否有服務器監控報警，是否有業務監控報警等來確定，如果上游或者下游提供了日志，可以通過日志進行追蹤，從而確定本系統是否存在故障。
因此在得到一些線上故障苗頭之后，可以通過以下途徑確定是否是線上故障：業務監控告警、上報事件個數、問題重現、服務器監控等。這些途徑可以并行進行，靈活組合，有時候一個手段就能確定，有時候需要組合多個手段予以判定。
故障定位
一旦確定是線上故障后，我們需要快速定位故障點，找到問題原因，以便對癥下藥，快速排除故障。
故障定位是一個不斷‘收集信息--假設--驗證--嘗試’的循環過程，基本思路：拿到線上信息，產生懷疑點，拿到更詳細的信息，進行推理驗證，必要時刻，找到可行的驗證措施，進行可控的嘗試，或者在測試環境進行業務測試重現，性能測試重現。
可能存在的懷疑點有：
1、新版本發布有問題
2、潛在的程序bug被激發，比如在訪問量暴增的情況下，并發bug被激發
3、業務量暴漲
4、遭遇攻擊，如活動期間羊毛黨刷積分等
5、上游服務調用異常，如上游系統升級httpclient后，將長連接改為短連接
6、下游服務異常，下游服務宕機
7、網絡問題
8、服務器故障，如磁盤滿，內存爆掉等
9、應用故障
10、數據庫故障
為此，可以通過如下幾方面收集信息，以便支撐你的懷疑點：
1、最近新版本的發布情況
2、本服務的異常/error日志
3、本服務的調用量變化情況，是否存在暴漲？
4、本服務的吞吐量，是否出現下降？
5、本服務的時延，是否出現突然增大？
6、服務器TCP的鏈接情況，是否存在大量的CLOSE_WAIT？
7、服務器的cpu使用率，是否突然飆升？
8、服務器的disk，磁盤空間是否已經用完？
9、服務器的內存，內存是否爆掉？
10、數據庫或者存儲是否掛掉？
很多故障并不是由于單一原因造成的，而是多個條件同時滿足時才出現的，所以，需要多收集信息，綜合得到的信息，產生懷疑點，快速推理和驗證，最后找到問題點，定位到故障。這個過程中可以集合大家的力量，并行去check各個點，并快速反饋信息。
由于組合情況眾多，這里只將明顯的故障定位場景列出，更多的需要總結歸納：
1、發布了最新版本，且故障最早出現時間在版本發布之后，很大程度上時由于新版本發布帶來的問題，可能是bug，也可能是部署出現問題；
2、未發布新版本，業務訪問量猛增，服務時延增大，吞吐量先上升后下降，到最后服務直接不可用，可能原因是：業務量暴漲/遭遇攻擊/上游服務異常調用；
3、未發布新版本，部分服務失敗，服務錯誤率增加，業務訪問量增加，可能原因是業務訪問量增大激發了潛在的并發bug，或者出現了io瓶頸等；
4、業務訪問量并未增加，但是服務時延下降，吞吐量下降，服務錯誤率增加，且服務器TCP的CLOSE_WAIT增大，這時候需要懷疑下游依賴服務是否異常。
5、業務訪問量并未增加，服務大范圍不可用，日志中出現大量數據庫錯，很明顯數據庫可能出現問題，或者應用的數據庫連接池出現問題。
不一而足，需要逐步積累。下圖是對上面描述的總結。
故障定位的初期，一般會先通過郵件+電話的方式進行溝通，如果幾分鐘之后事態變糟糕，且沒有眉目，則需要緊急啟動會議形式的聯合排障，所有相關人員需要放下手頭事情，集中到一個特定會議室進行聯合排障。這樣的好處也在于能夠迅速共享信息，快速做出決策。聯合排障人員通常會包括：開發、運維、測試、產品，主力應當是開發和運維，測試和產品需要幫忙快速確認一些東西，如復現問題，或者確認業務邏輯等。
從上面可以看到，故障定位過程中，追求‘快速’二字，為此多項事情是并行去做的。為了避免出現群龍無首的慌亂局面，需要有一個主心骨坐鎮，把握排障的方向并最終做出決策，這個人是master，需要冷靜沉著，且要能調度盡可能多的資源，所以技術leader或者運維leader會比較合適。這個類似于分布式系統的設計思路。
另外，在故障定位過程中，獲得的線上一線信息需要通過某種形式記錄下來，郵件往來是一種比較好的方式，在完成通信和信息共享的基礎上，也無形中保留了現場。其他的信息包括：error log，dump文件，服務器各個指標的狀態值等等。
故障排除
一旦定位到故障原因，對癥下藥地排除故障就不是什么難事了，具體的措施可以參考下圖中的總結：
這里需要特別指出一個特別的場景：無法定位故障的情況下如何迅速排除故障。
很多時候無法及時找到故障原因，必須直接進入故障排除，這時候的思路就在于：盡最大可能降低線上服務影響了。可以采用的手段有如下幾項:
1、服務降級——定位到某些服務有異常，但不清楚異常出現的原因，直接將這些服務降級，確保其他服務不受影響；
2、服務緊急擴容——無法定位到是哪些服務造成的，服務器資源彪升，扛不住壓力時，緊急擴容服務器；比如惡意攻擊、營銷活動，秒殺等場景帶來的突發情況；
3、回退版本——有新版本發布，但是不能迅速確定是否和新版本有關系，先做版本回退，確保線上服務回到上一個穩定版本。
還是那句話，故障排除的原則是：確保線上服務快速恢復，不能完全恢復的情況下，確保線上服務盡可能少地受到影響。
故障回溯
故障回溯的目的是在故障排除后，冷靜地回溯整個線上故障的發現/定位/排除過程，找出流程中/架構中/制度中的缺陷，并將該缺陷消滅掉，同時推而廣之到其他系統。在‘跳坑’--‘填坑’之后，我們需要通過故障回溯的過程達到‘避坑’的效果，即要保證自己能‘避坑’，也保證團隊/公司能夠避開類似的坑。
故障回溯的過程，因人因團隊而異，最重要的是要有嚴肅的‘形式’和最終的產出物。之所以提到嚴肅的‘形式’，是因為線上故障無小事，一定要讓大家牢記在心。
至于如何達到‘嚴肅’，可以參考如下形式：
1、可以和kpi掛鉤。慎用，可能會傷害到技術人員的心，造成‘懶政’現象——“多干多出事，少干少出事”出現；
2、可以實施追責制度。同上；
3、還可以進行郵件或者會議形式的討論，廣而告之。
總之，故障回溯的最終的目標不是為了追責，更重要的是讓大家長記性，避免后續再次踩坑，而且線上故障報告的產出物一定要有，一方面是經驗的積累，便于分享，另一方面也讓當事人擼清楚事件過程，吃一塹長一智。
可以參考的一個流程如下：
線上故障處理的‘后勤保障’
前面談了線上故障處理的目標、思路和步驟，回過頭來看下，要快速準確地定位和排除線上故障，需要很多基礎設施支撐，它們是線上故障處理的‘后勤保障’。結合上面的內容歸納總結如下：
完善的監控/告警體系
通過告警，能讓我們迅速知道自己的服務出了問題，通過監控可以從時間維度進行對比分析，找到可疑點，進而定位故障。
監控通常分為：
1、服務器監控——針對操作系統資源使用情況(比如cpu使用率、內容使用率、磁盤空間、io、network等)，容器健康程度（內存使用情況、線程數、GC情況等），Application健康程度的（服務的可訪問性等）;
2、服務監控——包括吞吐量、時延等，這些指標至少包括：最大值、平均值，通過這些指標可以判斷單個服務的變化情況和健康程度；
3、業務監控——包括訪問量、錯誤率等，一個業務場景往往會包含多個服務調用，因此通過業務監控，可以發現一些關聯問題。
告警方面，需要根據實際情況和業務場景進行閾值設定，告警閾值的設定是一個動態調整的過程。
監控系統最基本的需要保證：按照時間序列進行統計、對比。
完善的日志trace體系
在線上故障處理過程中，日志尤其重要，通過日志能夠定位到問題或者bug細節。在分布式架構的系統中，多實例的部署導致日志分散在多臺機器上，靠人肉查看耗時費力，效率低下；另一方面，業務發展壯大后，業務系統越來越多，系統間依賴越來越多，各個業務系統的日志需要通過唯一的標識串聯起來，否則會出現信息斷層的問題，日志變得無用。所以完善的日志trace系統非常必要。
日志trace體系的幾個關鍵點：
1、有唯一的標識串聯上下游系統日志
2、能自動收集分布式應用日志
3、日志收集時延不能超過10分鐘（具體時間試實際情況而定，如果時延太長，日志沒有多大意義）
4、支持多種形式的查詢/過濾/統計等
5、可以看到時間序列上的變化趨勢
推薦使用開源的日志架構：logstash+elasticsearch+kibana。
完善的故障處理機制
線上故障處理的要點在于快速，所以需要有完善便捷的事件流轉機制和故障處理機制來保證：生產事件能快速推送到相關責任人進行聯合排除，保證事件排查過程中快速共享信息，快速完成決策。
對于事件上報，一般的公司會有專用的通道給到一線客服人員，客戶人員填報工單，上報事件，關鍵點在于事件處理中擔任‘路由’角色的人員，他需要對業務系統比較熟悉，對于上報的問題能快速確定相關的業務系統和負責人，并通知到對方，這個角色既要熟知業務，也要熟知系統架構和組織架構，這個角色一般會交由專門人員處理，稱之為‘二線’人員，或者由運維人員兼職。
排查生產事件/故障時，推薦進行集中版本，便于快速共享信息，同時需要有一個master，以便把握大的方向，并快速完成決策。
總結
以上，對線上故障處理的目標、思路、步驟及基礎設施進行了討論，先總結如下：
1、線上排障的第一目標是恢復線上服務或者降低對線上服務的影響，關鍵點在于快速二字，在‘跳坑’-‘填坑’之后，需要總結以便‘避坑’。
2、一切的流程或者手段都是為‘快速’二字服務的，所以線上故障是最高優先級的任務，任何人需要第一時間予以響應；同時，盡早地反饋故障問題，盡早地集結各個角色，群策群力地進行排障值得提倡；這個過程中，需要有一位有‘威望’的master坐鎮，主持大局；在保證有序推進的情況下，盡可能地并行地收集信息，進行嘗試。這個有點分布式架構的味道了，master坐鎮，slave并行干活，提高效率。
3、一切的流程或者手段都是為‘快速’二字服務的，所以線上故障是最高優先級的任務，任何人需要第一時間予以響應；同時，盡早地反饋故障問題，盡早地集結各個角色，群策群力地進行排障值得提倡；這個過程中，需要有一位有‘威望’的master坐鎮，主持大局；在保證有序推進的情況下，盡可能地并行地收集信息，進行嘗試。這個有點分布式架構的味道了，master坐鎮，slave并行干活，提高效率。
4、必須要有一個‘嚴肅’的形式讓當事人及旁觀者‘吃一塹長一智’，線上故障處理報告是必須的產出物。
5、為了更加高效的處理線上故障，需要有完善的基礎設施支撐：監控/告警體系、日志trace體系、事件流轉機制。
對于線上排障的流程整理了一個大圖，如下：
參考資料
本文中部分觀點來源于goole出版的《google SRE》一書，這本書中有很多實用的且經過實踐證明了的詳盡的例子，感興趣的伙伴可以讀一讀！
》》END《《
