一個大型的互聯網系統，意味着大用戶量、業務模塊多、服務器多、各種資源佔用多，在拿到一個大型的互聯網應用，運維保障工作應該從哪些方面抓起呢？
首先還是先看運維的目標，追求更高的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、故障後—目標：消滅同類故障
⑧故障管理
故障管理是整個故障的善後工作，追責任的部分除外，那他的意義就是防止同類故障再次發生。一般會以故障覆盤會的方式約所有相關方進行全過程覆盤，最後形成的文檔叫“故障報告”，我認爲裏面最重要的兩個內容一個是故障原因（到底是天災還是人禍？根因找到了沒有），一個是後續的改進措施。
管理中有句話叫“再好的制度如果不執行等於沒有“，在改進措施的執行上，很多好了傷疤忘了痛的做法屢見不鮮，改進措施改着改着就沒了，造成了同類故障重複出現，這個過程中一定要確保形成的改進措施保質保量的完成。