老司機帶你出坑:請收下這份 運維故障處理 指南

老司機帶你出坑:請收下這份 運維故障處理 指南

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,一次次改進。

由於故障總結會涉及到故障的定責,所以這裡需要寫一些注意事項,尤其是對待故障中蠻不講理的人。

降級,從某種角度來說,是運維的最後保命手段,必須要注意。

END

頂部