如何快速處理線上故障

線上故障通常是指大規模的影響線上服務可用性的問題或者事件，通俗點講就是：掉『坑』裡了，這個『坑』就是線上故障！線上故障的處理過程可以形象地表達為：『踩坑』、『跳坑』、『填坑』、『避坑』。

線上故障的處理不僅是一項技術活，更是對技術人員/技術團隊反應能力、決策能力、判定能力、組織能力的考驗。面對突發的生產故障，需要快速定位問題，找到解決方案，快速實施解決方案並不是一件容易的事情。本文主要包括如下內容：線上故障處理的目標、思路、步驟、基礎設施。

任何動物一旦掉進坑里，明智的做法一定是：跳坑-->填坑-->避坑，線上故障處理的過程也一樣，優先順序從高到低，線上故障處理的目標如下：

『跳坑』——快速恢復線上服務，或者將對線上服務的影響降到最低。

線上服務的可用性決定著服務者的客戶利益，影響著公司的收益。一旦線上環境不可用，無法服務使用者，給公司/團隊帶來經濟利益損失的同時，更為嚴重的會給公司/團隊帶來惡劣的名聲。所以一般公司都會對線上環境提出穩定性和可靠性的要求，這也是團隊乃至部門的kpi。為此，遇到生產故障後的第一要務是：恢復生產服務，即使不能完全恢復線上服務，也要想盡辦法將對線上服務的影響降到最低。

『填坑』——找到問題原因，根本上解決問題。

在恢復線上服務，盡最大限度減掉對使用者/公司/團隊帶來的影響後，我們需要徹查問題，搞清楚故障發生的根本原因，從根本上解決問題。通常情況下，『填坑』和『跳坑』是同步在做的，完成『填坑』也就意味中『跳坑』成功，但是也有一些緊急情況下的特別『跳坑』方法，比如重啟服務，或者服務降級/熔斷等等，實際並未在當時完成『填坑』，而是先採取非常規手段『跳坑』，之後再慢慢『填坑』。

『避坑』——舉一反三，消滅隱患。

找到了根本原因，解決了問題之後，我們需要舉一反三，以此及彼，想想在這個故障排查和處理過程中，那些環節存在弱點？那些流程/規範/制度需要優化？這類問題是否在其他系統或者團隊中也存在？通過這樣的反思和自我批評，形成乙份線上事故報告，不斷完善流程，避免再次踩坑，也在團隊中交流經驗，共同提高。

依據線上故障處理的目標及目標的優先順序，線上排障的第一目標是恢復線上服務或者降低對線上服務的影響，關鍵點在於快速二字，在『跳坑』-『填坑』之後，再行回溯總結，以便『避坑』。因此，可以將線上故障處理的步驟分為：

其中前三步是『跳坑』行為，後面一步包含了『填坑』和『避坑』。

上述步驟並不是說要從上到下順序進行，建議在不亂陣腳的情況下，並行去做，因為通常線上故障後會緊急啟動故障處理程式，運維、開發、測試、產品各個角色都會參與進來，這時候分工下去，並行去做，不斷彙總訊息，做出判斷，以求快速排障，恢復服務。這個思路類似於作業系統的fork/join設計思想，目的在於提高效率。

在無法快速找到故障原因的時候，需要果斷跳過故障定位環節，直接進行故障排除，比如採用服務降級、伺服器擴容等手段，確保對線上服務降到最低且可控。等到線上服務'撐'過去之後，我們再慢慢定位故障原因，根本上解決問題。

下面我們會對這四個步驟進行詳細說明。

線上故障一般可以通過如下幾種途徑傳遞到開發/運維人員手中，按照從上到下的順序，故障的嚴重程度依次變高。

上述途徑傳遞過來的資訊僅僅只是線上故障苗頭，並非一定就發生了大規模的線上故障，所以首先需要確認的是這是不是一次線上故障？還是只是個例生產問題？是否和本系統有關係？一般來講：『系統監控告警』和『業務監控告警』的情況下，大部分都和本系統有關，且可能是線上故障；而『主動發現』和『生產事件上報』則需要做甄別，可以根據上報事件個數或者問題復現的方式來評估是否是大規模線上故障，或者跟蹤日誌資訊或者特定使用者問題追溯來確定。至於『關聯系統故障追溯』的情況，首先不要慌，先從巨集觀上確定本系統服務正常，一般可以檢查是否有伺服器監控報警，是否有業務監控報警等來確定，如果上游或者下游提供了日誌，可以通過日誌進行追蹤，從而確定本系統是否存在故障。

因此在得到一些線上故障苗頭之後，可以通過以下途徑確定是否是線上故障：業務監控告警、上報事件個數、問題重現、伺服器監控等。這些途徑可以並行進行，靈活組合，有時候乙個手段就能確定，有時候需要組合多個手段予以判定。

一旦確定是線上故障後，我們需要快速定位故障點，找到問題原因，以便對症下藥，快速排除故障。

故障定位是乙個不斷『收集資訊--假設--驗證--嘗試』的迴圈過程，基本思路：拿到線上資訊，產生懷疑點，拿到更詳細的資訊，進行推理驗證，必要時刻，找到可行的驗證措施，進行可控的嘗試，或者在測試環境進行業務測試重現，效能測試重現。

可能存在的懷疑點有：

為此，可以通過如下幾方面收集資訊，以便支撐你的懷疑點：

很多故障並不是由於單一原因造成的，而是多個條件同時滿足時才出現的，所以，需要多收集資訊，綜合得到的資訊，產生懷疑點，快速推理和驗證，最後找到問題點，定位到故障。這個過程中可以集合大家的力量，並行去check各個點，並快速反饋資訊。

不一而足，需要逐步積累。下圖是對上面描述的總結。

故障定位的初期，一般會先通過郵件+**的方式進行溝通，如果幾分鐘之後事態變糟糕，且沒有眉目，則需要緊急啟動會議形式的聯合排障，所有相關人員需要放下手頭事情，集中到乙個特定會議室進行聯合排障。這樣的好處也在於能夠迅速共享資訊，快速做出決策。聯合排障人員通常會包括：開發、運維、測試、產品，主力應當是開發和運維，測試和產品需要幫忙快速確認一些東西，如復現問題，或者確認業務邏輯等。

從上面可以看到，故障定位過程中，追求『快速』二字，為此多項事情是並行去做的。為了避免出現群龍無首的慌亂局面，需要有乙個主心骨坐鎮，把握排障的方向並最終做出決策，這個人是master，需要冷靜沉著，且要能排程盡可能多的資源，所以技術leader或者運維leader會比較合適。這個類似於分布式系統的設計思路。

另外，在故障定位過程中，獲得的線上一線資訊需要通過某種形式記錄下來，郵件往來是一種比較好的方式，在完成通訊和資訊共享的基礎上，也無形中保留了現場。其他的資訊包括：error log，dump檔案，伺服器各個指標的狀態值等等。

這裡需要特別指出乙個特別的場景：無法定位故障的情況下如何迅速排除故障。

很多時候無法及時找到故障原因，必須直接進入故障排除，這時候的思路就在於：盡最大可能降低線上服務影響了。可以採用的手段有如下幾項:

還是那句話，故障排除的原則是：確保線上服務快速恢復，不能完全恢復的情況下，確保線上服務盡可能少地受到影響。

故障回溯的目的是在故障排除後，冷靜地回溯整個線上故障的發現/定位/排除過程，找出流程中/架構中/制度中的缺陷，並將該缺陷消滅掉，同時推而廣之到其他系統。在『跳坑』--『填坑』之後，我們需要通過故障回溯的過程達到『避坑』的效果，即要保證自己能『避坑』，也保證團隊/公司能夠避開類似的坑。

故障回溯的過程，因人因團隊而異，最重要的是要有嚴肅的『形式』和最終的產出物。之所以提到嚴肅的『形式』，是因為線上故障無小事，一定要讓大家牢記在心。

總之，故障回溯的最終的目標不是為了追責，更重要的是讓大家長記性，避免後續再次踩坑，而且線上故障報告的產出物一定要有，一方面是經驗的積累，便於分享，另一方面也讓當事人擼清楚事件過程，吃一塹長一智。

前面談了線上故障處理的目標、思路和步驟，回過頭來看下，要快速準確地定位和排除線上故障，需要很多基礎設施支撐，它們是線上故障處理的『後勤保障』。結合上面的內容歸納總結如下：

通過告警，能讓我們迅速知道自己的服務出了問題，通過監控可以從時間維度進行對比分析，找到可疑點，進而定位故障。

監控通常分為：

服務監控——包括吞吐量、時延等，這些指標至少包括：最大值、平均值，通過這些指標可以判斷單個服務的變化情況和健康程度；

業務監控——包括訪問量、錯誤率等，乙個業務場景往往會包含多個服務呼叫，因此通過業務監控，可以發現一些關聯問題。

告**面，需要根據實際情況和業務場景進行閾值設定，告警閾值的設定是乙個動態調整的過程。

監控系統最基本的需要保證：按照時間序列進行統計、對比。

日誌trace體系的幾個關鍵點：

對於事件上報，一般的公司會有專用的通道給到一線客服人員，客戶人員填報工單，上報事件，關鍵點在於事件處理中擔任『路由』角色的人員，他需要對業務系統比較熟悉，對於上報的問題能快速確定相關的業務系統和負責人，並通知到對方，這個角色既要熟知業務，也要熟知系統架構和組織架構，這個角色一般會交由專門人員處理，稱之為『二線』人員，或者由運維人員兼職。

排查生產事件/故障時，推薦進行集中版本，便於快速共享資訊，同時需要有乙個master，以便把握大的方向，並快速完成決策。

以上，對線上故障處理的目標、思路、步驟及基礎設施進行了討論，先總結如下：

線上故障處理——大量異常堆疊日誌輸出影響服務可用性

如何快速處理線上故障

如何快速處理線上故障

線上故障處理

如何應對線上故障

相關推薦