大型系統的運維要從哪些方面抓起——從被動到主動

一個大型的互聯網系統，意味着大用戶量、業務模塊多、服務器多、各類資源佔用多，在拿到一個大型的互聯網應用，運維保障工做應該從哪些方面抓起呢？

首先仍是先看運維的目標，追求更高的SLA、更低的成本。全部事情都是以這個目標爲出發點，SLA指更高的服務質量，落實到數據上就是線上服務的可用性和性能，可用性是3個9的時候能不能達到4個9？能不能持續保持4個9？平均響應時間是100ms的時候能不能優化到80ms？更低的成本指的是在一樣的SLA下，能不能用更少的服務器、更精簡的架構跑起來？全部的制度和自動化工具，都是爲完成這一目標。

再看SLA和成本，二者並非獨立的，通常而言高SLA意味着高成本，例如用10臺服務器跑的服務改用100臺服務器跑，服務性能和質量的SLA確定是有提高的，因此這兩個指標實際上是一個對立與統一的平衡，兩個之間此消彼長，共同進步。當SLA和成本產生衝突時，爲了服務的穩定性，咱們通常的作法也是先穩住服務質量，再考慮優化成本，也能夠說用成本先穩定住質量，再慢慢找出用這麼多服務器、這麼多資源的緣由，畢竟若是服務質量沒有了、用戶流失了，一切都是零。

更高的SLA其實意味着更少的線上故障，若是咱們以此爲出發點去梳理運維的工做的全貌，其實要抓的工做階段就變成了故障前、故障中、故障後，咱們要儘可能加大故障前的工做投入，減小流入故障中的問題數量，一旦流入故障中，咱們要想辦法快速止損，止損完在故障後作好故障覆盤，造成改進措施避免同類問題再次發生，繼而流轉到故障前，循環往復.........爲了更形象的理解，畫了一張圖來展示。

上圖將運維的工做從故障生的角度分紅了8大塊，每一塊可能對應了不少個系統和制度做爲支撐，所有造成了整個運維服務體系，咱們平常作的工具和制度就是爲了每一個業務環節執行的更高效，PS 對於大型系統運維的一個關鍵在於各類標準化，標準化意味着批量操做意味着整齊劃一，如今拆開了說一下這8塊工做。

一、故障前—目標：減小問題流入「故障中」

①抓-變動

故障不是平白無故的就生髮了，不少發生在於變化，變化當中很大的一個又是迭代上線，從每一年故障的歷史數據看，有很大一部分故障都是因爲上線變動形成的，因此要嚴管變動，控制好質量後再上線。

管理變動主要是控制線上的「馬路殺手」，要作好單元測試、集成測試、線上灰度，而後再全量上線，保障萬無一失，從成本的角度看，上線後再回滾也是成本最大的一種方式，影響了用戶，而後還要從新返工。

有些變動類故障不是上線後立刻能發現的，好比java程序的full gc，可能上線一天後才能發生，因此這個時候要一些制度做爲輔助，好比說重大節日前幾天就不容許上線了，下班時間要找老闆審批後走緊急上線等等，加大非正常時間上線的變動成本，讓開發和運維對線上服務慢慢培養起敬畏之心。

②抓-容量

容量的管理關乎到質量和成本，不少時候對於容量是模糊和缺失的，具體表現就是發生了容量故障、看到了cpu和內存報警了纔想到擴容，公司要優化成本抓機器使用達標率才知道縮容，基本是被動的，並且沒有量化數據。沒有量化的容量管理就像中國廚師作飯一下，根據經驗多加點鹽、少加點醋，這個多和少憑的是感受，基本是不可主動管理的，對某我的的經驗依賴性很大。

再提成本，容量的管理對成本是相當重要的，有了容量數據，再結合目前的用戶就知道目前的服務器數量合理不合理，有多少浪費的，又或是須要擴容了，有了容量數據也能夠暴露不少性能問題，好比一臺32核128G的機器才跑10個QPS，這顯然是不合理和須要重點優化的。

根據實際經驗，容量的指標必定要用業務指標不要用機器指標，舉個例子，不少時候若是代碼質量差，好比前面說的10QPS，機器的CPU、內存等跑的反而挺高的，這個時候應該擴容麼？業務指標通常指像QPS、在線用戶數、長連接數量等這些，理論狀況下，先有了不一樣配置的單機容量數據，再計算出集羣的容量，繼而算出模塊的容量，再繼而算出整個產品的容量，在作容量測量用的最多的工具是壓測和全鏈路壓測，這個根據不一樣的情景使用。

對於容量數據首先保證有，再爭取愈來愈準，而後根據代碼、架構、機型改動狀況動態更新。

③抓-災備

災備和成本也是相互矛盾的一對，作多機房災備成本必定高，由於機房之間要保有相互承載用戶的餘量，不作多機房災備成本確定是要低的，但若是某個機房垮了沒法服務，業務就無處可切，就真的垮了，因此咱們要根據業務的級別作合理的災備。

災備意味着作冗餘，合理的災備能夠保障在故障出現時，快速進行業務切換，保障用戶的可用性。通常而言災備分爲熱備和冷備，冷備是指準備好資源平時空放，只有故障時才用一下，形成很大的資源浪費，因此通常能作熱備的就不作冷備。

作熱備的方法有不少，如今不少業務都是面向服務的，最多見的熱備方案其一是搭載負載均衡，經過心跳健康檢查服務自動調度，其二若是是移動、聯通、電信某條鏈路出現故障就經過域名解析進行切換。

最典型的冷備方案就是keepalived，經過vip漂移的方式對某個服務進行冷備，原理就不說了。

災備作好了，能夠大大下降故障出現時的業務壓力，先把服務切了再查故障，心態要輕鬆不少，加之若是可以自動切換（好像能夠叫故障自愈）那就更好了。

④抓-巡檢

巡檢的意義在於發現潛在的問題，將還沒有造成故障的問題提早暴露，提早解決。在方法上，能夠人工巡檢也能夠經過系統實現，巡檢完後發送巡檢報告，將一些核心指標的變化狀況根據業務的屬性進行標記通知。

不管是手動仍是系統巡檢，都要對每一個模塊的核心指標進行梳理，造成每一個模塊的核心指標的鳥瞰screen，一來天天到辦公室首先要巡檢一下業務狀況，二來在遇到故障的時候要迅速看一下各個指標的變化作故障定位。

各模塊的巡檢screen通常要包括QPS、錯誤、時延、外部依賴錯誤、機器指標這幾個大項，便於一眼發現問題所在，快速找到根因，定位故障影響範圍。

二、故障中—目標：快速發現問題、快速止損

若是前面的工做都保質保量的作了，故障依然出現，那就考慮怎麼應對處理吧，故障的處理關鍵有3個環節。

⑤抓-告警

不說告警沒配等特殊狀況，告警應該是故障的第一事件，當oncall人員收到告警，判斷影響後，分發給相應的同窗處理，直到故障恢復。

因此在告警必定要管理好，告警要根據事件的影響程度分級，告警短信和郵件裏儘量攜帶更多的判斷信息，作的好的甚至能夠作一下故障參考預判。

告警的建設上必定要圍繞3個點準、少、快，準是告警的信息準，少是告警的數量少都是收斂後的有效告警，快指的是告警的實效性高速度快。

⑥抓-定位

oncall同窗收到告警簡單的判斷後，會把告警分發給處理人，這個時候就到了故障定位環節。

故障定位依賴於對業務架構細緻的瞭解、依賴於線上的經驗，通常會藉助監控進行排查，這時候在巡檢階段建的核心指標screen就派上用場了，經過screen和核心指標基本能夠作個預判，而後再經過日誌分析或登陸服務器查看詳細日誌進行根因排障。

定位也是有輕重緩急的，首先要找到故障模塊和故障範圍，找到後先根據預案將業務切掉再去排查緣由，減小線上用戶的影響。

⑦抓-預案

預案是指在定位到故障模塊和故障範圍後爲了保障業務的穩定，及時止損所進行的操做，

爲了故障發生後儘快止損減小影響，在平時要考慮好各類故障發生的肯能性，並作好預案是很是重要的，預案也分爲容災預案和降級預案，容災預案基本無損，降級預案可能會影響一些用戶體驗了，可是不影響主體功能，若是什麼預案都沒有隻能生抗了。

三、故障後—目標：消滅同類故障

⑧故障管理

故障管理是整個故障的善後工做，追責任的部分除外，那他的意義就是防止同類故障再次發生。通常會以故障覆盤會的方式約全部相關方進行全過程覆盤，最後造成的文檔叫「故障報告」，我認爲裏面最重要的兩個內容一個是故障緣由（究竟是天災仍是人禍？根因找到了沒有），一個是後續的改進措施。

管理中有句話叫「再好的制度若是不執行等於沒有「，在改進措施的執行上，不少好了傷疤忘了痛的作法家常便飯，改進措施改着改着就沒了，形成了同類故障重複出現，這個過程當中必定要確保造成的改進措施保質保量的完成。