01運(yùn)維的初心
可用性是運(yùn)維的基礎(chǔ)，當(dāng)服務(wù)不可用時，運(yùn)維做的任何工作都是0。
運(yùn)維可用性能力的三個階段
1、救火階段
2、防火階段
3、放火階段
救火階段
核心模塊的MTTR(故障恢復(fù)時間)不要超過20分鐘，這聽起來很簡單，但在可用性的初級階段，一般處于這個階段的運(yùn)維人員，處理故障流程是：收到告警，連接vpn，定位故障，故障修復(fù)，整個流程中，占用時間較長的是定位故障，這取決于對服務(wù)間調(diào)用關(guān)系的理解以及運(yùn)維經(jīng)驗(yàn)是否足夠多，在這個階段比較依賴于個人能力。
防火階段
當(dāng)處于防火階段時，運(yùn)維人員需要更多精力去做預(yù)案管理、服務(wù)高可用能力、災(zāi)備、告警自動化處理、服務(wù)降級等事情，處于這個階段的故障處理流程，一般會在定位故障前，就能發(fā)現(xiàn)是哪個服務(wù)、哪個模塊、哪個機(jī)房發(fā)生了問題，通過預(yù)案、切流等手段先將服務(wù)恢復(fù)或降級，在這個階段MTTR時間要遠(yuǎn)遠(yuǎn)小于第一階段，因?yàn)榉?wù)已經(jīng)提前做了止損操作。
放火階段
運(yùn)維要做的是盡可能的保證線上服務(wù)的穩(wěn)定性，為什么要自己把自己的服務(wù)搞死？
一個系統(tǒng)很長時間保持穩(wěn)定，一定隱藏了著災(zāi)難性的故障（黑天鵝事件），穩(wěn)定了很多年的服務(wù)，運(yùn)維、開發(fā)人員無處理經(jīng)驗(yàn)，會導(dǎo)致大問題。
放火的前提：至少已經(jīng)度過救火階段且部分故障已經(jīng)有明確的操作方法和規(guī)范，保證運(yùn)維的工作已經(jīng)足夠游刃有余。
如何做：前期人工制造故障，進(jìn)行故障演練。針對線上的服務(wù)進(jìn)行故障演練，通過故障演練可及時發(fā)現(xiàn)故障造成影響、故障處理流程是否符合預(yù)期。
誤區(qū)：藍(lán)軍負(fù)責(zé)制造故障，紅軍負(fù)責(zé)修復(fù)故障。相互之間不可以溝通。否則變成了小孩子過家家，毫無意義。
故障演練流程：切走大部分流量->制造故障->人員介入處理->故障恢復(fù)->流量恢復(fù)->復(fù)盤
長期：通過平臺的方式，在不提前通知的情況下，通過平臺在線上不定期制造故障（例如netflix的Chaos Monkey系統(tǒng)）。
故障處理的誤區(qū)：
我們總是在聚焦在防火階段，不希望我們的系統(tǒng)出現(xiàn)故障這本身沒有問題，但是沒有任何一個系統(tǒng)可以做到100%可用，我們的系統(tǒng)一定存在某些不穩(wěn)定因素，當(dāng)這些因素積累到一定程度爆發(fā)出來時，我們的工程師們是否記得如何處理故障？
如果一個極其穩(wěn)定的系統(tǒng)發(fā)生大故障，損失可能是災(zāi)難性的。所以防火做好了之后要自己經(jīng)常去放一些小火。通過主動的制造故障，發(fā)現(xiàn)未知的問題和隱患，進(jìn)而更加的保障系統(tǒng)的穩(wěn)定性，甚至從軟件設(shè)計之初就考慮到服務(wù)可用性。
通過不斷的制造故障，使得系統(tǒng)具備反脆弱性。
02持續(xù)提高可用性
以可用性為目的，我們可以滲透到大量的有價值的工作中。
例如：
線下（開發(fā)環(huán)境、測試環(huán)境、預(yù)發(fā)布環(huán)境）
發(fā)布（灰度發(fā)布、分級發(fā)布）
快速止損
解決變更帶來的可用性隱患
從廣義上來說，任何故障都來源于【變更】，變更不僅僅包含代碼的變更、環(huán)境的變更同時也包含網(wǎng)絡(luò)的變更、硬盤由正常變更為異常、系統(tǒng)在執(zhí)行過程中某個指標(biāo)由于積累到一定程度導(dǎo)致的故障等等。我們需要做的是這些變更在發(fā)生時如何快速搞定。
例如平時需要定位問題的時候，很久都定位不出來，最終花了很久才發(fā)現(xiàn)是一個很不相關(guān)的指標(biāo)發(fā)生異常才引發(fā)出來。有經(jīng)驗(yàn)的人可能憑直覺就能猜到可能是哪個地方發(fā)生故障。
靠猜來排查故障會帶來兩個問題：
沒有經(jīng)驗(yàn)的人無法快速查到問題。
運(yùn)氣成分占比較大，可能猜到也可能猜不到，猜不到的時候MTTR時間就不可控。
如何解決靠猜來查故障？
系統(tǒng)實(shí)時狀態(tài)運(yùn)行圖：通過運(yùn)維數(shù)據(jù)可視化、操作標(biāo)準(zhǔn)化，將系統(tǒng)指標(biāo)、線上配置指標(biāo)、產(chǎn)品對應(yīng)的指標(biāo)通過屏幕進(jìn)行展示。使得所有變更一目了然，歷史指標(biāo)數(shù)據(jù)可查。（例如grafana+prometheus）
03運(yùn)維的目的
運(yùn)維工具、自動化、平臺化都是手段，但不是目的。
我們的目的是在一個產(chǎn)品漫長的生命周期中不斷為產(chǎn)品加強(qiáng)或者發(fā)揮出產(chǎn)品的價值，從而提升運(yùn)維人員對于這個產(chǎn)品的價值。
運(yùn)維人員如果跟別人的印象只是很辛苦，那并不是運(yùn)維的價值所在，我們要想辦法發(fā)現(xiàn)辛苦的源頭是什么？是流程不合理？還是運(yùn)維效率低下？我們應(yīng)該要功勞而不是靠苦勞博同情。
如何才能體現(xiàn)自己的價值？
日常匯報中不要寫做了什么，而要說做了這樣的事情，為團(tuán)隊產(chǎn)生了什么樣的價值和收益，這件事繼續(xù)做下去空間是什么，怎樣做才是極致的狀態(tài)。
技術(shù)指標(biāo)不等于業(yè)績指標(biāo)
qps、load等等都是技術(shù)指標(biāo)。需要想辦法轉(zhuǎn)換成產(chǎn)品核心指標(biāo)（收入、PV、品牌影響力）例如（基于這樣的優(yōu)化，我們整個集群可以承載的產(chǎn)品的數(shù)量可以達(dá)到什么水平，對應(yīng)投入的資源成本會發(fā)生哪些變化）。
可用性是運(yùn)維人的臉面，也是這個職位存在的意義，在保證可用性的前提下，不斷為產(chǎn)品創(chuàng)造價值。才稱得上是一位合格的互聯(lián)網(wǎng)運(yùn)維工程師。
