1.故障處理原則
-
-
1.1?恢復業務優先
恢復業務優先是指，不管在任何情況下，也不管任何級別的故障，都要先做到恢復業務，這個和故障定位不同，也有很多人會產生歧義，覺得如果不找到問題的根源，如何能恢復業務，下面我舉一個例子說明二者的差別：如果 A 應用調 B 應用時，調用失敗，這時我們要怎么做？方法一，排查問題，尋找A到B之間會經過哪些環節，找到其中的出問題的環節，比如HA連接異常，進行重啟或者擴容恢復。方法二，從A應用的服務器去ping B應用的網絡，如果端口，網絡聯通，那么直接綁定B服務器的hosts。一般而言，第二種方法時間會短，如果A和B之間是跨機房訪問，那么方法一排查時間會更長，雖然破壞了A到B之間的架構平衡，但是能馬上見效，這就是我們所說的以恢復業務優先。1.2?及時升級
這個比較好理解，任何故障在發生時，對故障的影響任何人只能做一個簡單的預測，所以要及時升級到你的領導那里，讓他掌握第一手的信息，協調資源，如果有如下情況，那么必須馬上上升：- 有明確業務影響，例如PV，UV，購物車，訂單或者支付等業務指標波動。
- 非常重要的業務的嚴重以上的告警故障，比如北斗核心業務，核心的組件等。
- 處理時效明顯超長（時效參考故障處理時效定義）。
- 有高級別領導，監控中心或者客服已經關注到這個故障。
- 很明確超出了自己的能力范圍。
注意：任何運維故障，運維的領導必須是第一個知道的人，如果他從別的人或者部門中知道這個故障，那么就很被動，而且是故障處理人失職表現。
2.故障處理方法論
故障處理一般會分為三個階段，故障前，故障中和故障后，故障前是指故障的定位分析，故障中是指故障處理過程，故障后是指故障總結，故障總結很重要，這個會單獨放到一章，故障定位很雜，以后會單獨去寫，這里主要講一下故障中的一些運維常用的方法。
2.1故障服務來看運維處理故障方法
如果從故障服務來看，運維恢復業務最重要的三個方法是：重啟，隔離和降級。重啟：重啟包括服務重啟和服務器重啟（os重啟）兩種，在發生故障中，任何中涉及到的環節，都可以重啟來完成，重啟的一般順序是，故障對象>故障對象上游>故障對象下游，一般離故障對象越遠，重啟順序越靠后。以今天的 RabbitMQ 故障為例：當已經知道 RabbitMQ 發送消息失敗的時候，那么就要對它進行重啟，如果還沒生效，那么則對他上游（消息生產者）進行重啟，還不行就對下游，消息消費方進行重啟。這里需要注意的是，千萬千萬不要想著去定位，比如發現重啟的對象指標都正常，則不進行重啟，時刻謹記，是在恢復業務，不是在定位故障。隔離：隔離是指對故障的對象從集群中抽離的過程，目的是讓故障對象不在提供服務，隔離的方法包括以下兩種，按照常用頻率排序：- 調整上游權重為零，如果架構上有自檢測機制，那么也可以直接停止故障對象的服務，讓上游健康探測時效。
-
通過綁定hosts或者配置路由的方式，繞開故障對象。比如智能路由管理域關閉某一條線路。
這里需要注意的是，防止雪崩效應。
降級：降級是指為了防止產生更大的故障所采取的一種預案，一般而言，降級一定不是當下生產的給用戶的最優狀態，即使沒有技術影響，也會或多或少帶來一些業務的影響，比如唯品花降級等，雖然用戶可以通過其他渠道進行支付，但會帶來不好的用戶體驗和一些用戶影響。降級不僅僅是運維的事情，要聯合業務研發或者說推動業務研發一起去實施，孫子兵法有云：為將者，未慮勝，先慮敗，因此做任何一個項目時，首要考慮的不是這個項目能取得多少業績，而是要考慮的是，如果出現異常怎么辦？以 CDN 管理為例：
我們要求開發提供的預案有：
-
任何時候，核心域，都可以更換到備用域名，并且是分鐘級生效。
-
核心域必須有重試機制，當訪問一個域名失敗時，APP能夠直接回源到源站。
-
前端業務重試提供開關功能，可以一鍵關閉重試機制（主要擔心源站會被重試打垮）
項目如此，核心應用和組件也要如此，作為應用負責人，必須要考慮的是，如果這個對象發生重大故障時，是否有預案可以使用，并且要把這些預案觸發條件，執行人等都要明確下來。上述操作方法，尤其是重啟和隔離有一個重要的前提，那就是，對象必須是無狀態的，如果需要開發重試，那么要求必須是冪等的。對象無狀態除非是非常特殊的業務，可以臨時存在外，其余是不可以的，所以生產上對象應該只有三種狀態：-
-
-
2.2 從故障影響方去看運維故障處理方法
一個故障發生后，影響方會分為兩類：外部用戶和內部用戶2.2.1.外部用戶
外部用戶的處理會比較麻煩，處理的思路是，如何把外部用戶轉變成內部用戶，比如，一個供應商打不開公司的網站，這時要做的是有兩個方面：-
自己在本地模擬是否可以重現，如果可以重現，那么就不是用戶到IDC之間公網問題，是內部系統問題，那么變成內部用戶處理。
-
如果自己在本地模擬不能重現，那么多找幾個內部用戶模擬，防止自己環境問題，同時，讓用戶進行hosts綁定到其他入口，排除DNS，一些外網鏈路問題，如果這時用戶在綁定hosts后，訪問正常，那么恢復業務，同時可以確認大概率是外部問題。
如果上述兩個方面都不行，那么就比較麻煩了，這時要收集一些必要的外部用戶信息才能進行處理，比如出口IP，所用客戶端版本等等，這里建議收集信息有個模版，一次性完成，因為外部用戶處理時效往往會花在溝通成本上。2.2.2 內部用戶
內部用戶包括內部應用自身調用問題和內部使用人員發現問題，這時的操作方法參考2.1來處理。2.3?故障處理過程中的組織架構
故障處理一般需要有三撥人同時行動
- 故障處理者，他們的職責就是盡快恢復業務。
- 故障定位者，他們的職責是當故障處理者方法失效或者需要查找問題根因時，解決故障。
- 信息傳遞者，他們的職責是對故障處理，故障定位傳遞有效信息，同時對外部傳遞故障進展信息。
往往運維這三類人不會同時存在，比如在凌晨值班時，只需要故障處理者處理即可，恢復業務后，第二天由故障定位者去找根因及優化措施。
當然，三撥人可以復用。
3.故障總結
故障總結是個大活，每一次故障發生，都要盡量從根源去解決，同時避免發生重復故障和類似故障，PDCA，一次次改進。由于故障總結會涉及到故障的定責，所以這里需要寫一些注意事項，尤其是對待故障中蠻不講理的人。降級，從某種角度來說，是運維的最后保命手段，必須要注意。
