大型系統的運維要從哪些方面抓起——全面質量管理

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

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

再看SLA和成本，兩者并不是獨立的，一般而言高SLA意味著高成本，例如用10臺服務器跑的服務改用100臺服務器跑，服務性能和質量的SLA肯定是有提升的，所以這兩個指標其實是一個對立與統一的平衡，兩個之間此消彼長，共同進步。當SLA和成本產生沖突時，為了服務的穩定性，我們一般的做法也是先穩住服務質量，再考慮優化成本，也可以說用成本先穩定住質量，再慢慢找出用這么多服務器、這么多資源的原因，畢竟如果服務質量沒有了、用戶流失了，一切都是零。

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

上圖將運維的工作從故障生的角度分成了8大塊，每一塊可能對應了很多個系統和制度作為支撐，全部形成了整個運維服務體系，我們日常做的工具和制度就是為了每個業務環節執行的更高效，PS 對于大型系統運維的一個關鍵在于各種標準化，標準化意味著批量操作意味著整齊劃一，現在拆開了說一下這8塊工作。

1、故障前—目標：減少問題流入“故障中”

①抓-變更

故障不是無緣無故的就生發了，很多發生在于變化，變化當中很大的一個又是迭代上線，從每年故障的歷史數據看，有很大一部分故障都是由于上線變更造成的，所以要嚴管變更，控制好質量后再上線。

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

有些變更類故障不是上線后馬上能發現的，比如java程序的full gc，可能上線一天后才能發生，所以這個時候要一些制度作為輔助，比如說重大節日前幾天就不允許上線了，下班時間要找老板審批后走緊急上線等等，加大非正常時間上線的變更成本，讓開發和運維對線上服務慢慢培養起敬畏之心。

②抓-容量

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

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

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

對于容量數據首先保證有，再爭取越來越準，然后根據代碼、架構、機型改動情況動態更新。

③抓-災備

災備和成本也是相互矛盾的一對，做多機房災備成本一定高，因為機房之間要保有相互承載用戶的余量，不做多機房災備成本肯定是要低的，但如果某個機房垮了無法服務，業務就無處可切，就真的垮了，所以我們要根據業務的級別做合理的災備。

災備意味著做冗余，合理的災備可以保障在故障出現時，快速進行業務切換，保障用戶的可用性。一般而言災備分為熱備和冷備，冷備是指準備好資源平時空放，只有故障時才用一下，造成很大的資源浪費，所以一般能做熱備的就不做冷備。

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

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

災備做好了，可以大大降低故障出現時的業務壓力，先把服務切了再查故障，心態要輕松很多，加之如果能夠自動切換（好像可以叫故障自愈）那就更好了。

④抓-巡檢

巡檢的意義在于發現潛在的問題，將尚未形成故障的問題提前暴露，提前解決。在方法上，可以人工巡檢也可以通過系統實現，巡檢完后發送巡檢報告，將一些核心指標的變化情況根據業務的屬性進行標記通知。

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

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

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

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

⑤抓-告警

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

所以在告警一定要管理好，告警要根據事件的影響程度分級，告警短信和郵件里盡可能攜帶更多的判斷信息，做的好的甚至可以做一下故障參考預判。

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

⑥抓-定位

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

故障定位依賴于對業務架構細致的了解、依賴于線上的經驗，一般會借助監控進行排查，這時候在巡檢階段建的核心指標screen就派上用場了，通過screen和核心指標基本可以做個預判，然后再通過日志分析或登錄服務器查看詳細日志進行根因排障。

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

⑦抓-預案

預案是指在定位到故障模塊和故障范圍后為了保障業務的穩定，及時止損所進行的操作，

為了故障發生后盡快止損減少影響，在平時要考慮好各種故障發生的肯能性，并做好預案是非常重要的，預案也分為容災預案和降級預案，容災預案基本無損，降級預案可能會影響一些用戶體驗了，但是不影響主體功能，如果什么預案都沒有只能生抗了。

3、故障后—目標：消滅同類故障

⑧故障管理

故障管理是整個故障的善后工作，追責任的部分除外，那他的意義就是防止同類故障再次發生。一般會以故障復盤會的方式約所有相關方進行全過程復盤，最后形成的文檔叫“故障報告”，我認為里面最重要的兩個內容一個是故障原因（到底是天災還是人禍？根因找到了沒有），一個是后續的改進措施。

管理中有句話叫“再好的制度如果不執行等于沒有“，在改進措施的執行上，很多好了傷疤忘了痛的做法屢見不鮮，改進措施改著改著就沒了，造成了同類故障重復出現，這個過程中一定要確保形成的改進措施保質保量的完成。