對(duì)于SRE一詞，想必大家已經(jīng)不陌生了蚓庭，滿世界都在講SRE致讥，但是SRE到底是個(gè)什么角色？負(fù)責(zé)哪些工作呢器赞？今天來(lái)給大家解惑一下垢袱。

SRE最早是由Google提出的概念，其大概的意思就是：以標(biāo)準(zhǔn)化港柜、自動(dòng)化请契、可擴(kuò)展驅(qū)動(dòng)維護(hù)，用軟件開(kāi)發(fā)解決運(yùn)維難題夏醉。這個(gè)崗位面世的時(shí)候爽锥，其根本要解決的問(wèn)題就是打破傳統(tǒng)研發(fā)人員快速迭代而引發(fā)的業(yè)務(wù)不穩(wěn)定性，用以保證業(yè)務(wù)維護(hù)側(cè)重的服務(wù)質(zhì)量以及穩(wěn)定性之間的平衡授舟。

不同公司的SRE定位是不同的救恨，可能某些公司的運(yùn)維崗位也是SRE，因此释树，不能以偏概全肠槽，國(guó)內(nèi)的SRE基本是以崗位來(lái)區(qū)分的擎淤，比如，有負(fù)責(zé)網(wǎng)絡(luò)的SRE秸仙，有負(fù)責(zé)DBA的SRE嘴拢，有專門負(fù)責(zé)業(yè)務(wù)的SRE，還有什么安全SRE等等寂纪。就谷歌所提到的SRE的理解來(lái)講席吴，基本都是以服務(wù)質(zhì)量穩(wěn)定為基線的維護(hù)工程師，只是對(duì)于SRE的要求是苛刻的捞蛋，下面是我的個(gè)人理解：

• 第一：技能全面孝冒，比如網(wǎng)絡(luò)、操作系統(tǒng)拟杉、監(jiān)控庄涡、CICD、研發(fā)等搬设，對(duì)于研發(fā)能力穴店，可能不需要你精通，但是你需要具備可以使用一門語(yǔ)言完成某個(gè)功能的設(shè)計(jì)拿穴、開(kāi)發(fā)與迭代泣洞。

• 第二：打破傳統(tǒng)運(yùn)維思想壁壘，以產(chǎn)品角度思維貫穿整個(gè)業(yè)務(wù)架構(gòu)服務(wù)質(zhì)量為前提的溝通協(xié)調(diào)能力默色。

• 第三：始終以軟件工程解決問(wèn)題為方向的規(guī)劃之路球凰。

• 第四：很強(qiáng)的Trouble Shooting與思考、抽象能力该窗，這三個(gè)能力在SRE工作當(dāng)中是至關(guān)重要的弟蚀，是時(shí)間與實(shí)踐積累的最終成果。

綜上所述酗失，國(guó)內(nèi)現(xiàn)在的SRE义钉，大致可以分成倆個(gè)層級(jí)，PasS-SRE和業(yè)務(wù)SRE规肴，前者主要是維護(hù)平臺(tái)基建服務(wù)質(zhì)量為主的SRE捶闸，后者主要是維護(hù)業(yè)務(wù)服務(wù)質(zhì)量穩(wěn)定性為主的SRE，業(yè)務(wù)SRE比較像業(yè)務(wù)運(yùn)維拖刃。

上面的定義只適合大廠删壮，對(duì)于還沒(méi)有傳播SRE文化，SRE的崗位是比較模糊的兑牡，其定位可能就是一個(gè)運(yùn)維開(kāi)發(fā)工程師央碟，要解決的問(wèn)題也是全面的、多元化的均函。在推廣SRE文化以及建設(shè)SRE工作守則的時(shí)候亿虽，需要對(duì)當(dāng)前的業(yè)務(wù)架構(gòu)菱涤、技術(shù)架構(gòu)有全面的了解，并合理的對(duì)基建做好設(shè)計(jì)洛勉、規(guī)劃粘秆、調(diào)整，這樣收毫，SRE文化才會(huì)被更好的推行下去攻走。

下面的都是由網(wǎng)上整理而來(lái)，因?yàn)镾RE的工作范圍是由谷歌最早提出以及實(shí)踐過(guò)的此再，所以昔搂，他的工作范圍就如下所示，萬(wàn)變不離其宗输拇，在這里其實(shí)有一個(gè)很核心的關(guān)鍵點(diǎn)巩趁，那就是基建的穩(wěn)定性決定了SRE的工作效率，因此淳附，我們?cè)诮ㄔO(shè)SRE文化與工作職責(zé)的時(shí)候，也要把基建的一些因素考慮進(jìn)去蠢古。

以下為《SRE谷歌運(yùn)維解密》一書當(dāng)中已經(jīng)提到了關(guān)鍵點(diǎn)：

• 可觀測(cè)性系統(tǒng)

• 故障響應(yīng)

• 測(cè)試與部署

• 容量規(guī)劃

• 自動(dòng)化軟件開(kāi)發(fā)

• 用戶支持

• Oncall

• 制定可交付的SLI/SLO/SLA

• 故障復(fù)盤

可觀測(cè)性系統(tǒng)

在任何有一定規(guī)模的企業(yè)內(nèi)部奴曙，一旦推行起來(lái)整個(gè)SRE的運(yùn)維模式，那么對(duì)于可觀測(cè)性系統(tǒng)的建設(shè)將變得尤為重要草讶，而在整個(gè)可觀測(cè)性系統(tǒng)中洽糟，通常我們會(huì)分為如下三個(gè)方面：

• 指標(biāo)監(jiān)控：即各種指標(biāo)監(jiān)控，比如基礎(chǔ)資源指標(biāo)堕战，服務(wù)性能指標(biāo)坤溃，業(yè)務(wù)的調(diào)用指標(biāo)。

• 日志：各種設(shè)備以及服務(wù)的運(yùn)行日志監(jiān)控嘱丢。

• 調(diào)用鏈：業(yè)務(wù)層面的調(diào)用鏈分析薪介，通常在分布式系統(tǒng)中幫助運(yùn)營(yíng)、開(kāi)發(fā)以及運(yùn)維人員快速識(shí)別整體調(diào)用的瓶頸點(diǎn)

一整套的可觀測(cè)系統(tǒng)越驻，它能確保你洞察系統(tǒng)汁政，跟蹤系統(tǒng)的健康狀態(tài)、可用性以及系統(tǒng)內(nèi)部發(fā)生的事情缀旁。

對(duì)于整個(gè)可觀測(cè)系統(tǒng)的建設(shè)记劈，需要注意如下兩點(diǎn)：

• 確定質(zhì)量標(biāo)準(zhǔn)是什么，并確保系統(tǒng)持續(xù)逼近或保持在質(zhì)量標(biāo)準(zhǔn)極限范圍內(nèi)

• 系統(tǒng)地關(guān)注這項(xiàng)工作—而不應(yīng)該只是隨機(jī)地查看一下系統(tǒng)

在整個(gè)企業(yè)級(jí)可觀測(cè)系統(tǒng)中并巍，我認(rèn)為至少應(yīng)該包括如下幾個(gè)特征：

• 完備指標(biāo)采集：可以對(duì)接企業(yè)內(nèi)大部分的設(shè)備與技術(shù)棧相應(yīng)的監(jiān)控指標(biāo)目木；同時(shí)，支持常見(jiàn)設(shè)備的監(jiān)控指標(biāo)體系懊渡，可以快速接入監(jiān)控設(shè)備和指標(biāo)刽射，避免所有設(shè)備監(jiān)控都是從頭構(gòu)建军拟；對(duì)于日志數(shù)據(jù)的采集支持

• 海量設(shè)備支持：企業(yè)IT系統(tǒng)數(shù)量和規(guī)模越來(lái)越大，因此監(jiān)控系統(tǒng)比以前需要監(jiān)控海量設(shè)備監(jiān)控柄冲。

• 監(jiān)控?cái)?shù)據(jù)存儲(chǔ)和分析：監(jiān)控?cái)?shù)據(jù)是運(yùn)維分析吻谋、運(yùn)維自動(dòng)化和智能化的基礎(chǔ)，因此海量監(jiān)控?cái)?shù)據(jù)存儲(chǔ)以及基于監(jiān)控?cái)?shù)據(jù)的可視化分析是一個(gè)監(jiān)控系統(tǒng)的基本能力现横。

可觀測(cè)系統(tǒng)是整個(gè)運(yùn)維體系的基礎(chǔ)漓拾，它需要提供整個(gè)運(yùn)維體系的數(shù)據(jù)化支持。

因此戒祠，一個(gè)企業(yè)級(jí)的可觀測(cè)性系統(tǒng)應(yīng)該是平臺(tái)化的骇两。一方面可以通過(guò)配置或者開(kāi)發(fā)實(shí)現(xiàn)更多 運(yùn)維指標(biāo)的接入；另一方面姜盈，亦可對(duì)接更多的專業(yè)運(yùn)維工具低千，整合并打通多元的運(yùn)維數(shù)據(jù)，為更多運(yùn)維場(chǎng)景提供數(shù)據(jù)服務(wù)馏颂。從整體上示血，可觀測(cè)性系統(tǒng)為企業(yè)運(yùn)維提供了一個(gè)數(shù)據(jù)基礎(chǔ)，讓我們對(duì)事故響應(yīng)以及容量預(yù)測(cè)等方面更多使用數(shù)據(jù)而非憑借以往經(jīng)驗(yàn)和拍腦袋做出決策救拉。

故障響應(yīng)

如果有什么東西出了故障难审，該如何提醒大家并做出回應(yīng)？工具可以幫助解決這個(gè)問(wèn)題亿絮，因?yàn)樗梢远x提醒人類的規(guī)則告喊。

故障響應(yīng)是建立在使用可觀測(cè)性系統(tǒng)構(gòu)建的數(shù)據(jù)之上，并借助反饋循環(huán)派昧，來(lái)幫助我們加強(qiáng)對(duì)服務(wù)的監(jiān)控黔姜。

故障響應(yīng)通常包含如下幾個(gè)動(dòng)作:

• 關(guān)注: 不論是主動(dòng)發(fā)現(xiàn)瓶頸點(diǎn)或異常點(diǎn)，還是通過(guò)可觀測(cè)性系統(tǒng)被動(dòng)暴露瓶頸點(diǎn)蒂萎，我們都應(yīng)該進(jìn)行主動(dòng)關(guān)注

• 交流: 及時(shí)將觀察到風(fēng)險(xiǎn)點(diǎn)通知到相關(guān)方秆吵，并告知影響面以及相關(guān)的補(bǔ)救措施

• 恢復(fù): 三方達(dá)成一致后，根據(jù)補(bǔ)救措施進(jìn)行修復(fù)相關(guān)風(fēng)險(xiǎn)點(diǎn)和異常點(diǎn)

需要注意的是五慈，如果在前期整個(gè)可觀測(cè)性系統(tǒng)能夠做好帮毁，通常故障應(yīng)當(dāng)始于一個(gè)簡(jiǎn)單的告警信息或一個(gè)報(bào)障電話，因此豺撑，通常情況下烈疚，可觀測(cè)系統(tǒng)做的足夠好僅能起到追溯和排查的作用，但是無(wú)法起到及時(shí)發(fā)現(xiàn)的作用聪轿，此時(shí)就需要依賴于各個(gè)觀測(cè)數(shù)據(jù)進(jìn)行計(jì)算和評(píng)估告警爷肝，以及時(shí)將相關(guān)的告警通知到相關(guān)人，以暴露風(fēng)險(xiǎn)點(diǎn)。

告警只是整個(gè)故障響應(yīng)的第一個(gè)環(huán)節(jié)灯抛，解決的是故障如何發(fā)現(xiàn)的問(wèn)題金赦，而大多數(shù)的故障響應(yīng)工作都是關(guān)于定義處理策略和提供培訓(xùn)的，以便人們?cè)谑盏骄瘓?bào)時(shí)知道該怎么做对嚼，通常這部分更多的是過(guò)去歷史經(jīng)驗(yàn)和運(yùn)維經(jīng)歷的總結(jié)和沉淀夹抗，包括經(jīng)驗(yàn)的一些抽象和工具化沉淀，以保證故障響應(yīng)的效率和普遍化(即不依賴人為經(jīng)驗(yàn))纵竖。

而對(duì)于整個(gè)告警系統(tǒng)來(lái)說(shuō)漠烧，需要確保的是告警的有效性，否則靡砌，整個(gè)報(bào)警系統(tǒng)很有可能淪落為垃圾數(shù)據(jù)制造機(jī)已脓，告警有效性意味著需要滿足如下兩個(gè)需求：

• 告警及時(shí)性: 系統(tǒng)有問(wèn)題需要及時(shí)通過(guò)告警信息告知運(yùn)維處理人員及時(shí)處理告警;

• 告警準(zhǔn)確性: 只要有告警信息系統(tǒng)必然出現(xiàn)問(wèn)題(對(duì)于很多企業(yè)可能存在大量的無(wú)用告警，比如磁盤問(wèn)題通殃，mem等相關(guān)問(wèn)題度液，當(dāng)然這里涉及到了自動(dòng)化、業(yè)務(wù)形態(tài)画舌、告警閾值的問(wèn)題);

在整個(gè)運(yùn)維過(guò)程中堕担，我們經(jīng)常會(huì)發(fā)現(xiàn)有大量的無(wú)關(guān)緊要的告警信息，讓運(yùn)維人員的注意力迷失在告警海洋當(dāng)中曲聂，而通常非運(yùn)維領(lǐng)域的領(lǐng)導(dǎo)會(huì)關(guān)注整個(gè)告警的響應(yīng)程度照宝，因此，抑制和消除無(wú)效的告警句葵，讓運(yùn)維人員不被告警風(fēng)暴所吞沒(méi)，也是告警管理中重點(diǎn)建設(shè)的內(nèi)容兢仰。

通常情況乍丈，在我們的各個(gè)可觀測(cè)系統(tǒng)構(gòu)建完成后，可以通過(guò)整合到監(jiān)控平臺(tái)中的各種監(jiān)控?cái)?shù)據(jù)把将，應(yīng)用趨勢(shì)預(yù)測(cè)轻专、短周期檢測(cè)、間歇性恢復(fù)察蹲、基線判斷请垛、重復(fù)壓縮等算法和手段實(shí)現(xiàn)告警壓縮收斂，強(qiáng)化告警的有效性洽议。

img

同時(shí)宗收，面向一線的運(yùn)維人員，我們需要根據(jù)同一個(gè)系統(tǒng)或設(shè)備的多個(gè)監(jiān)控指標(biāo)進(jìn)行綜合性建模和分析亚兄，匯總成一個(gè)健康度的分值混稽，給予一線運(yùn)維人員系統(tǒng)的基于健康度的系統(tǒng)分層評(píng)價(jià)體系，真實(shí)、直觀反映系統(tǒng)運(yùn)行狀態(tài)匈勋，實(shí)現(xiàn)問(wèn)題快速定位礼旅。

比如，通過(guò)基礎(chǔ)資源的多個(gè)指標(biāo)進(jìn)行綜合加權(quán)計(jì)算來(lái)整體評(píng)估該資源的利用率洽洁；通過(guò)一個(gè)應(yīng)用關(guān)聯(lián)的全部資源的資源利用率以及應(yīng)用的運(yùn)維架構(gòu)整體建模分析來(lái)計(jì)算一個(gè)分值來(lái)整體評(píng)估該應(yīng)用的健康程度痘系。

這個(gè)過(guò)程如果做得成熟一些，可以根據(jù)內(nèi)部已有的解決方案和告警進(jìn)行閉環(huán)打通饿自，一個(gè)簡(jiǎn)單的場(chǎng)景就是汰翠，當(dāng)磁盤滿時(shí)，告警會(huì)首先觸發(fā)一次標(biāo)準(zhǔn)化的磁盤巡檢璃俗，并進(jìn)行相關(guān)的可丟棄數(shù)據(jù)的刪除奴璃，如果依然無(wú)法解決該報(bào)警，下次可直接關(guān)聯(lián)到一線運(yùn)維進(jìn)行人工干預(yù)城豁，之后進(jìn)行標(biāo)準(zhǔn)化經(jīng)驗(yàn)總結(jié)苟穆。

測(cè)試與部署

測(cè)試與部署對(duì)于整個(gè)穩(wěn)定性和可靠性的主要出于一個(gè)預(yù)防的作用，預(yù)防是指嘗試限制發(fā)生的事故數(shù)量唱星，并確保在發(fā)布新代碼時(shí)基礎(chǔ)架構(gòu)和服務(wù)能夠保持穩(wěn)定雳旅。

作為一個(gè)長(zhǎng)期從事運(yùn)維工作的人，可能內(nèi)心中最為恐懼的莫過(guò)于新應(yīng)用版本發(fā)布间聊。因?yàn)槌擞布途W(wǎng)絡(luò)設(shè)備損壞這個(gè)屬于天災(zāi)級(jí)別的概率事件外攒盈，新應(yīng)用版本發(fā)布的第二天通常是停機(jī)與事故的高危期。所以哎榴，對(duì)于一些量級(jí)較大的產(chǎn)品通常會(huì)在節(jié)假日以及重要活動(dòng)前夕進(jìn)行封網(wǎng)操作型豁，以避免新版本上線而導(dǎo)致的業(yè)務(wù)bug出現(xiàn)。

而測(cè)試是在成本和風(fēng)險(xiǎn)之間找到適當(dāng)?shù)钠胶饣顒?dòng)尚蝌。如果過(guò)于冒險(xiǎn)迎变，你們可能就會(huì)疲于應(yīng)付系統(tǒng)失敗飘言；反過(guò)來(lái)說(shuō)衣形，如果你太保守，你就不能足夠快地發(fā)布新東西姿鸿，讓企業(yè)在市場(chǎng)上生存下來(lái)谆吴。

在錯(cuò)誤預(yù)算比較多（即在一段時(shí)間內(nèi)故障導(dǎo)致系統(tǒng)停機(jī)時(shí)長(zhǎng)較少）的情況下，可以適當(dāng)減少測(cè)試資源并放寬系統(tǒng)上線的測(cè)試和條件苛预，讓業(yè)務(wù)可以有更多的功能上線句狼，以保持業(yè)務(wù)的敏態(tài)；在錯(cuò)誤預(yù)算比較少（即在一段時(shí)間內(nèi)故障導(dǎo)致系統(tǒng)停機(jī)時(shí)長(zhǎng)較多）的情況下热某，則要增加測(cè)試資源并收緊系統(tǒng)上線的測(cè)試鲜锚，讓系統(tǒng)的潛在風(fēng)險(xiǎn)得到更多有效的釋放突诬，避免系統(tǒng)停機(jī)保持系統(tǒng)的穩(wěn)態(tài)。這種敏態(tài)與穩(wěn)態(tài)之間的平衡芜繁，需要整個(gè)運(yùn)維與開(kāi)發(fā)團(tuán)隊(duì)來(lái)共同承擔(dān)旺隙。

除了測(cè)試外，應(yīng)用發(fā)布也是一項(xiàng)運(yùn)維團(tuán)隊(duì)通常要承擔(dān)的責(zé)任骏令。SRE其中的一個(gè)原則是將一切可以重復(fù)性勞動(dòng)代碼化和工具化蔬捷；此外，應(yīng)用發(fā)布的復(fù)雜程度往往與系統(tǒng)的復(fù)雜程度成正比榔袋。因此在應(yīng)用系統(tǒng)上規(guī)模企業(yè)周拐，往往已經(jīng)著手基于自動(dòng)化框架構(gòu)建自動(dòng)化的應(yīng)用發(fā)布過(guò)程。

img

通過(guò)自動(dòng)化發(fā)布工具凰兑，我們可以構(gòu)建流水線實(shí)現(xiàn)部署的過(guò)程中所有的操作（如編譯打包妥粟、測(cè)試發(fā)布、生產(chǎn)準(zhǔn)備吏够、告警屏蔽勾给、服務(wù)停止、數(shù)據(jù)庫(kù)執(zhí)行锅知、應(yīng)用部署播急、服務(wù)重啟等）全部自動(dòng)化。

容量規(guī)劃

容量規(guī)劃是關(guān)于預(yù)測(cè)未來(lái)和發(fā)現(xiàn)系統(tǒng)極限的售睹，容量規(guī)劃也是為了確保系統(tǒng)可以隨著時(shí)間的推移得到完善和增強(qiáng)桩警。

規(guī)劃的主要目標(biāo)是管理風(fēng)險(xiǎn)和期望，對(duì)于容量規(guī)劃昌妹，涉及到將容量擴(kuò)展到整個(gè)業(yè)務(wù)捶枢；所關(guān)注的期望是人們?cè)诳吹綐I(yè)務(wù)增長(zhǎng)時(shí)期望服務(wù)如何響應(yīng)。風(fēng)險(xiǎn)是在額外的基礎(chǔ)設(shè)施上花費(fèi)時(shí)間和金錢來(lái)處理這個(gè)問(wèn)題飞崖。

容量規(guī)劃首先是對(duì)未來(lái)預(yù)測(cè)性的分析與判斷烂叔，其預(yù)測(cè)的基礎(chǔ)正是海量的運(yùn)維數(shù)據(jù)。因此蚜厉，容量規(guī)劃除了有相應(yīng)的架構(gòu)和規(guī)劃團(tuán)隊(duì)外，一個(gè)全面的運(yùn)維數(shù)據(jù)中心是實(shí)現(xiàn)系統(tǒng)容量規(guī)劃的必須設(shè)施畜眨。

容量趨勢(shì)預(yù)警和分析將綜合地從各種運(yùn)維監(jiān)控昼牛、流程管理等數(shù)據(jù)源中收集、整理康聂、清洗并結(jié)構(gòu)化地存儲(chǔ)各種運(yùn)維數(shù)據(jù)贰健，將這些來(lái)自于各種工具的運(yùn)維數(shù)據(jù)打通融合并且構(gòu)建各種數(shù)據(jù)主題。

應(yīng)用這些數(shù)據(jù)主題的數(shù)據(jù)用于幫助運(yùn)維人員對(duì)問(wèn)題進(jìn)行評(píng)估恬汁，包括：

• 當(dāng)前的容量是多少

• 何時(shí)達(dá)到容量極限

• 應(yīng)該如何更改容量

• 執(zhí)行容量規(guī)劃

運(yùn)維平臺(tái)除了可以提供必要的數(shù)據(jù)支持外伶椿，還需要提供必要的數(shù)據(jù)可視化支持能力。運(yùn)維數(shù)據(jù)可視化提供了一些必要的能力保障運(yùn)維人員可以更好地利用其中的運(yùn)維數(shù)據(jù)評(píng)估容量。

首先脊另，運(yùn)維平臺(tái)需要有極強(qiáng)的數(shù)據(jù)檢索能力导狡。運(yùn)維平臺(tái)存儲(chǔ)著海量的運(yùn)維數(shù)據(jù)，運(yùn)維人員為了嘗試建立和驗(yàn)證一個(gè)探索性場(chǎng)景的時(shí)候偎痛，往往多次反復(fù)檢索和查詢特定數(shù)據(jù)旱捧。如果運(yùn)維數(shù)據(jù)分析平臺(tái)的數(shù)據(jù)查詢很慢或者查詢角度很少的情況下，運(yùn)維人員建立場(chǎng)景的時(shí)間就會(huì)拖得很長(zhǎng)甚至進(jìn)行不下去踩麦。因此枚赡，運(yùn)維人員可通過(guò)平臺(tái)可以實(shí)現(xiàn)關(guān)鍵字、統(tǒng)計(jì)函數(shù)谓谦、單條件贫橙、多條件、模糊多維度查找功能反粥，以及實(shí)現(xiàn)海量數(shù)據(jù)秒級(jí)查詢卢肃，才能更有效幫助運(yùn)維人員更便捷分析數(shù)據(jù)。

其二星压，平臺(tái)需要強(qiáng)大的數(shù)據(jù)可視化能力践剂。人們常說(shuō)“千言萬(wàn)語(yǔ)不及一圖”，運(yùn)維人員經(jīng)常會(huì)通過(guò)各系統(tǒng)的運(yùn)維數(shù)據(jù)進(jìn)行統(tǒng)計(jì)分析并生成各類實(shí)時(shí)報(bào)表娜膘，對(duì)各類運(yùn)維數(shù)據(jù)（如應(yīng)用日志逊脯、交易日志、系統(tǒng)日志）進(jìn)行多維度竣贪、多角度深入分析军洼、預(yù)測(cè)及可視化展現(xiàn)，將他們分析的預(yù)測(cè)結(jié)果和經(jīng)驗(yàn)向他人表達(dá)和推廣演怎。

自動(dòng)化工具開(kāi)發(fā)

SRE不僅涉及運(yùn)營(yíng)匕争，還涉及軟件開(kāi)發(fā)，當(dāng)然這部分指的是和運(yùn)維以及SRE領(lǐng)域相關(guān)的工具和平臺(tái)開(kāi)發(fā)爷耀。在Google的SRE體系中甘桑，SRE工程師將花費(fèi)大約一半的時(shí)間來(lái)開(kāi)發(fā)新的工具和服務(wù)，這些工具的一部分用于自動(dòng)化一些手動(dòng)任務(wù)歹叮，而其他部分用于來(lái)不斷填補(bǔ)和修復(fù)整個(gè)SRE體系內(nèi)部的其他系統(tǒng)跑杭。

通過(guò)編寫代碼把自己和其他人從重復(fù)的工作中解放出來(lái)，如果我們不需要人類來(lái)完成任務(wù)咆耿，那么就編寫代碼德谅，這樣人類就不需要參與其中了。

SRE從內(nèi)心上鄙視重復(fù)性的工作萨螺，將從原有的人工加被動(dòng)響應(yīng)窄做，轉(zhuǎn)變?yōu)楦咝Ю⑶⒏鼮樽詣?dòng)化的運(yùn)維體系。

自動(dòng)化運(yùn)維框架：

img

自動(dòng)化運(yùn)維工具的優(yōu)勢(shì)和必要性:

• 提高效率: 由程序自動(dòng)化操作椭盏，有效地降低運(yùn)維人力資源的投入组砚，也讓運(yùn)維人員的精力得以釋放并投向更為重要的領(lǐng)域。

• 操作的標(biāo)準(zhǔn)化: 將原來(lái)許多復(fù)雜庸汗、易錯(cuò)的手工操作實(shí)現(xiàn)統(tǒng)一運(yùn)維操作入口惫确，實(shí)現(xiàn)運(yùn)維操作白屏化，提升運(yùn)維操作的可管理性蚯舱；

  同時(shí)改化，減少由于運(yùn)維人員情緒帶來(lái)手工誤操作，避免“從刪庫(kù)到跑路”這樣的悲劇的發(fā)生枉昏。

• 運(yùn)維經(jīng)驗(yàn)?zāi)芰Φ膫鞒? 運(yùn)維自動(dòng)化工具將原來(lái)許多運(yùn)維團(tuán)隊(duì)積累的經(jīng)驗(yàn)以代碼方式總結(jié)為各種運(yùn)維工具陈肛，實(shí)現(xiàn)自動(dòng)化和白屏化的運(yùn)維操作。運(yùn)維團(tuán)隊(duì)的后來(lái)者兄裂，可以有效地繼承句旱、重復(fù)使用并優(yōu)化它們。這種代碼化的工作傳承晰奖，將個(gè)人能力轉(zhuǎn)變?yōu)閳F(tuán)隊(duì)能力谈撒，并減少人員流動(dòng)帶來(lái)對(duì)工作的影響。

構(gòu)建自動(dòng)化運(yùn)維體系就必須以運(yùn)維場(chǎng)景為基礎(chǔ)匾南，這些運(yùn)維場(chǎng)景是在本企業(yè)內(nèi)反復(fù)迭代和打造啃匿，是企業(yè)中最常用的運(yùn)維場(chǎng)景。

比如常見(jiàn)的運(yùn)維場(chǎng)景：軟件安裝部署蛆楞、應(yīng)用發(fā)布交付溯乒、資產(chǎn)管理、告警自動(dòng)處理豹爹、故障分析裆悄、資源申請(qǐng)、自動(dòng)化巡檢等等臂聋。因此光稼，整個(gè)自動(dòng)化運(yùn)維體系建設(shè)時(shí)也應(yīng)支持多種不同類型的自動(dòng)化作業(yè)配置能力，通過(guò)簡(jiǎn)單的腳本開(kāi)發(fā)孩等、場(chǎng)景配置和可視化定制流程實(shí)現(xiàn)更多運(yùn)維場(chǎng)景的實(shí)現(xiàn)艾君。

用戶支持

用戶體驗(yàn)這一層要說(shuō)的是，作為SRE來(lái)講瞎访，從用戶的角度來(lái)保證業(yè)務(wù)的穩(wěn)定性和可用性才是最終目標(biāo)腻贰。這個(gè)才傳統(tǒng)意義上的運(yùn)維人員是不會(huì)關(guān)注這一點(diǎn)的吁恍，因?yàn)榇蠹彝ǔＶ粫?huì)考慮到我底層運(yùn)維的系統(tǒng)或底層資源是否穩(wěn)定扒秸，但實(shí)際上整個(gè)業(yè)務(wù)的穩(wěn)定才是SRE需要關(guān)心的問(wèn)題播演，而業(yè)務(wù)的穩(wěn)定性和可用性通常需要站在用戶的角度來(lái)模擬和衡量整體的可用性和可靠性。

在前面提到的所有SRE相關(guān)的工作范疇伴奥，無(wú)論是監(jiān)控写烤、事故響應(yīng)、回顧拾徙、測(cè)試與發(fā)布洲炊、容量規(guī)劃以及構(gòu)建自動(dòng)化工具，無(wú)非都是為了提供更好的系統(tǒng)用戶業(yè)務(wù)體驗(yàn)而服務(wù)的尼啡。因此暂衡，我們?cè)谶\(yùn)維的過(guò)程中無(wú)不需要注意關(guān)注系統(tǒng)的用戶體驗(yàn)。

而在實(shí)際運(yùn)維工作中崖瞭，我們往往可以通過(guò)應(yīng)用日志狂巢、監(jiān)控?cái)?shù)據(jù)、業(yè)務(wù)探測(cè)等業(yè)務(wù)相關(guān)的用戶體驗(yàn)信息书聚。在運(yùn)維數(shù)據(jù)平臺(tái)中唧领，通過(guò)這些用戶體驗(yàn)監(jiān)測(cè)數(shù)據(jù)之間的關(guān)聯(lián)和串聯(lián)，重現(xiàn)用戶的最終業(yè)務(wù)調(diào)用鏈路以及各應(yīng)用環(huán)節(jié)對(duì)性能數(shù)據(jù)的關(guān)系雌续。最終形成從業(yè)務(wù)用戶體驗(yàn)數(shù)據(jù)入手斩个，逐步實(shí)現(xiàn)系統(tǒng)運(yùn)行狀態(tài)數(shù)據(jù)、設(shè)備運(yùn)行狀態(tài)數(shù)據(jù)鏈路的打通驯杜，讓運(yùn)維體系實(shí)現(xiàn)以最終用戶體驗(yàn)為中心的目標(biāo)受啥。

這些用戶體驗(yàn)的信息，對(duì)于運(yùn)維團(tuán)隊(duì)掌握客戶整體的用戶體驗(yàn)情況艇肴、系統(tǒng)可用性的監(jiān)測(cè)以及系統(tǒng)針對(duì)性的優(yōu)化提供著無(wú)可替代的作用腔呜。

其實(shí)，SRE運(yùn)維體系更為強(qiáng)調(diào)以用戶的體驗(yàn)為核心再悼，以自動(dòng)化和運(yùn)維數(shù)據(jù)為手段核畴，實(shí)現(xiàn)應(yīng)用業(yè)務(wù)連續(xù)性保障，從這個(gè)點(diǎn)出發(fā)冲九，我們會(huì)發(fā)現(xiàn)和以往的傳統(tǒng)運(yùn)維還是有很大的區(qū)別的谤草，我們不再僅僅是單純的安裝和部署工程師，我們需要通過(guò)一系列的技術(shù)手段來(lái)不斷保障上層業(yè)務(wù)的穩(wěn)定性和可靠性莺奸。

Oncall

Oncall 簡(jiǎn)單來(lái)說(shuō)就是要保證線上服務(wù)的正常運(yùn)行丑孩。典型的工作流程是：收到告警，檢查告警發(fā)出的原因灭贷，確認(rèn)線上服務(wù)是否有問(wèn)題温学，定位到問(wèn)題，解決問(wèn)題甚疟。

收到告警并不總意味著真正的問(wèn)題仗岖，也有可能告警設(shè)置的不合理逃延。告警和監(jiān)控面板并不是一個(gè)靜態(tài)的配置，它應(yīng)該是每天都在變化的轧拄，時(shí)刻在調(diào)整的揽祥。如果發(fā)現(xiàn)沒(méi)有標(biāo)志真正線上問(wèn)題的告警發(fā)了出來(lái)，就應(yīng)該修改告警規(guī)則檩电。如果發(fā)現(xiàn)當(dāng)前的監(jiān)控?zé)o法快速定位問(wèn)題李丰，應(yīng)該調(diào)整監(jiān)控面板琅轧，添加或者刪除監(jiān)控指標(biāo)。業(yè)務(wù)在發(fā)展，請(qǐng)求量在變化夺鲜，某些閾值也需要不斷地調(diào)整蓬痒。

定位問(wèn)題沒(méi)有一概而論的方法了恤左，需要根據(jù)看到的實(shí)時(shí)監(jiān)控?cái)?shù)據(jù)蔓肯，結(jié)合自己的經(jīng)驗(yàn)，然后做推測(cè)丽柿，然后使用工具驗(yàn)證自己的推測(cè)恢准，然后確定問(wèn)題的根因。

但是解決問(wèn)題是可以有方法論的甫题，叫做 SOP馁筐，標(biāo)準(zhǔn)操作流程。即：如果出現(xiàn)了這種現(xiàn)象坠非，那么執(zhí)行那種操作敏沉，就可以恢復(fù)業(yè)務(wù)。SOP 文檔應(yīng)該提前制定炎码，并且驗(yàn)證其有效性盟迟。

需要注意的是上述定位問(wèn)題、解決問(wèn)題并沒(méi)有順序關(guān)系潦闲。一個(gè)經(jīng)常犯的錯(cuò)誤是攒菠，在出現(xiàn)故障的時(shí)候，花了很長(zhǎng)時(shí)間定位到故障的根因歉闰，然后再修復(fù)辖众。這樣花的時(shí)間一般會(huì)比較長(zhǎng)。正確的做法是先根據(jù)現(xiàn)象看現(xiàn)有的 SOP 能否恢復(fù)業(yè)務(wù)和敬。比如說(shuō)當(dāng)前錯(cuò)誤只發(fā)生在某一個(gè)節(jié)點(diǎn)上凹炸，那么就直接下線這個(gè)節(jié)點(diǎn)，具體的原因后面再排查昼弟∑∷恢復(fù)當(dāng)前的故障永遠(yuǎn)是第一要?jiǎng)?wù)。但是恢復(fù)操作也要經(jīng)過(guò)測(cè)試，比如猜測(cè)可以通過(guò)重啟解決問(wèn)題的話变骡，可以先重啟一臺(tái)做測(cè)試救欧，而不是一次性將所有服務(wù)重啟。大部分情況是需要臨場(chǎng)分析的锣光，是一個(gè)緊張又刺激的過(guò)程。

故障到底多久恢復(fù)算好铝耻？出現(xiàn)多少故障是可以容忍的誊爹？怎么檢測(cè)服務(wù)的穩(wěn)定性到底如何？我們使用 SLI/SLO 來(lái)衡量這些問(wèn)題瓢捉。

制定可交付的SLI/SLO/SLA

SLO 和 SLA 是大家常見(jiàn)的兩個(gè)名詞：服務(wù)等級(jí)目標(biāo)和服務(wù)等級(jí)協(xié)議频丘。

云計(jì)算時(shí)代，各大云服務(wù)提供商都發(fā)布有自己服務(wù)的 SLA 條款泡态，比如 Amazon 的 EC2 和 S3 服務(wù)都有相應(yīng)的 SLA 條款搂漠。這些大公司的 SLA 看上去如此的高大上，一般是怎么定義出來(lái)的呢某弦？

說(shuō) SLA 不能不提 SLO桐汤，這個(gè)是眾所周知的，但是還有一個(gè)概念知道的人就不多了靶壮，那就是 SLI（Service Level Indicator）怔毛，定義一個(gè)可執(zhí)行的 SLA，好的 SLO 和 SLI 是必不可少的腾降。

另外必須要提到的是拣度，SLI/SLO/SLA主要是為服務(wù)指定的，如果沒(méi)有服務(wù)作為依托關(guān)系螃壤，那這些概念也就失去了原有的意義抗果。

下面是一個(gè) SLA 在制定過(guò)程中需要考慮到的一些問(wèn)題：

例如：設(shè)計(jì)一個(gè)可用率的時(shí)候，并不是說(shuō)達(dá)到了”4個(gè)9“為標(biāo)準(zhǔn)就足夠了奸晴，因?yàn)槲覀冃枰紤]如下問(wèn)題：

1. 如何定義這個(gè)可用率冤馏？比如我們以可用率 > 99.9% 為目標(biāo)，有一個(gè)服務(wù)部署了 5 個(gè) 區(qū)域, 那么有一個(gè) 區(qū)域 掛了寄啼，其余的 區(qū)域 是可用的宿接，那么可用率被破壞了嗎？這個(gè)可用率是每一個(gè) 區(qū)域 的還是所有的 區(qū)域 一起計(jì)算的辕录？

2. 可用率計(jì)算的最小單位是什么睦霎？如果 1min 內(nèi)有 50s 沒(méi)有達(dá)到可用率，那么這一分鐘算是 down 還是 up走诞？

3. 可用率的周期是怎么計(jì)算的副女？按照一個(gè)月還是一個(gè)周？一個(gè)周是最近的 7 天還是計(jì)算一個(gè)自然周蚣旱？

4. 如何設(shè)計(jì)與規(guī)劃 SLI 和 SLO 監(jiān)控碑幅？

5. 如果錯(cuò)誤預(yù)算即將用完戴陡，有什么處理措施？比如減少發(fā)布以及配置變更沟涨？

Service

什么是服務(wù)恤批？

簡(jiǎn)單說(shuō)就是一切提供給客戶的有用功能都可以稱為服務(wù)。

服務(wù)一般會(huì)由服務(wù)提供者提供裹赴，提供這個(gè)有用功能的組織被稱為服務(wù)提供者喜庞，通常是人加上軟件，軟件的運(yùn)行需要計(jì)算資源棋返，為了能對(duì)外提供有用的功能軟件可能會(huì)有對(duì)其他軟件系統(tǒng)的依賴延都。

客戶是使用服務(wù)提供者提供的服務(wù)的人或公司。

SLI

SLI 是經(jīng)過(guò)仔細(xì)定義的測(cè)量指標(biāo)睛竣，它根據(jù)不同系統(tǒng)特點(diǎn)確定要測(cè)量什么晰房，SLI 的確定是一個(gè)非常復(fù)雜的過(guò)程。

SLI 的確定需要回答以下幾個(gè)問(wèn)題：

1. 要測(cè)量的指標(biāo)是什么射沟？

2. 測(cè)量時(shí)的系統(tǒng)狀態(tài)殊者？

3. 如何匯總處理測(cè)量的指標(biāo)？

4. 測(cè)量指標(biāo)能否準(zhǔn)確描述服務(wù)質(zhì)量验夯？

5. 測(cè)量指標(biāo)的可靠度 (trustworthy)幽污？

6. 常見(jiàn)的測(cè)量指標(biāo)有以下幾個(gè)方面：

• 性能

  • 響應(yīng)時(shí)間 (latency)

  • 吞吐量 (throughput)

  • 請(qǐng)求量 (qps)

  • 實(shí)效性 (freshness)

• 可用性

  • 運(yùn)行時(shí)間 (uptime)

  • 故障時(shí)間 / 頻率

  • 可靠性

• 質(zhì)量

  • 準(zhǔn)確性 (accuracy)

  • 正確性 (correctness)

  • 完整性 (completeness)

  • 覆蓋率 (coverage)

  • 相關(guān)性 (relevance)

• 內(nèi)部指標(biāo)

  • 隊(duì)列長(zhǎng)度 (queue length)

  • 內(nèi)存占用 (RAM usage)

• 因素人

  • 響應(yīng)時(shí)間 (time to response)

  • 修復(fù)時(shí)間 (time to fix)

  • 修復(fù)率 (fraction fixed)

下面通過(guò)一個(gè)例子來(lái)說(shuō)明一下：hotmail 的 downtime SLI

• 錯(cuò)誤率 (error rate) 計(jì)算的是服務(wù)返回給用戶的 error 總數(shù)

• 如果錯(cuò)誤率大于 X%，就算是服務(wù) down 了簿姨，開(kāi)始計(jì)算 downtime

• 如果錯(cuò)誤率持續(xù)超過(guò) Y 分鐘距误，這個(gè) downtime 就會(huì)被計(jì)算在內(nèi)

• 間斷性的小于 Y 分鐘的 downtime 是不被計(jì)算在內(nèi)的。

2. 測(cè)量時(shí)的系統(tǒng)狀態(tài)扁位，在什么情況下測(cè)量會(huì)嚴(yán)重影響測(cè)量的結(jié)果

• 測(cè)量異常 (badly-formed) 請(qǐng)求准潭，還是失敗 (fail) 請(qǐng)求還是超時(shí)請(qǐng)求 (timeout)

• 測(cè)量時(shí)的系統(tǒng)負(fù)載（是否最大負(fù)載）

• 測(cè)量的發(fā)起位置，服務(wù)器端還是客戶端

• 測(cè)量的時(shí)間窗口（僅工作日域仇、還是一周 7 天刑然、是否包括計(jì)劃內(nèi)的維護(hù)時(shí)間段）

3. 如何匯總處理測(cè)量的指標(biāo)？

• 計(jì)算的時(shí)間區(qū)間是什么：是一個(gè)滾動(dòng)時(shí)間窗口暇务，還是簡(jiǎn)單的按照月份計(jì)算

• 使用平均值還是百分位值泼掠，比如：某服務(wù) X 的 ticket 處理響應(yīng)時(shí)間 SLI 的

• 測(cè)量指標(biāo)：統(tǒng)計(jì)所有成功解決請(qǐng)求，從用戶創(chuàng)建 ticket 到問(wèn)題被解決的時(shí)間

• 怎么測(cè)量：用 ticket 自帶的時(shí)間戳垦细，統(tǒng)計(jì)所有用戶創(chuàng)建的 ticket

• 什么情況下的測(cè)量：只包括工作時(shí)間择镇，不包含法定假日

• 用于 SLI 的數(shù)據(jù)指標(biāo)：以一周為滑動(dòng)窗口，95% 分位的解決時(shí)間

4. 測(cè)量指標(biāo)能否準(zhǔn)確描述服務(wù)質(zhì)量括改？

• 性能：時(shí)效性腻豌、是否有偏差

• 準(zhǔn)確性：精度、覆蓋率、數(shù)據(jù)穩(wěn)定性

• 完整性：數(shù)據(jù)丟失吝梅、無(wú)效數(shù)據(jù)虱疏、異常 (outlier) 數(shù)據(jù)

5. 測(cè)量指標(biāo)的可靠度

• 是否服務(wù)提供者和客戶都認(rèn)可

• 是否可被獨(dú)立驗(yàn)證，比如三方機(jī)構(gòu)

• 客戶端還是服務(wù)器端測(cè)量苏携，取樣間隔

• 錯(cuò)誤請(qǐng)求是如何計(jì)算的

SLO

SLO (服務(wù)等級(jí)目標(biāo)) 指定了服務(wù)所提供功能的一種期望狀態(tài)做瞪。SLO 里面應(yīng)該包含什么呢？所有能夠描述服務(wù)應(yīng)該提供什么樣功能的信息右冻。

服務(wù)提供者用它來(lái)指定系統(tǒng)的預(yù)期狀態(tài)装蓬；開(kāi)發(fā)人員編寫代碼來(lái)實(shí)現(xiàn)；客戶依賴于 SLO 進(jìn)行商業(yè)判斷国旷。SLO 里沒(méi)有提到，如果目標(biāo)達(dá)不到會(huì)怎么樣茫死。

SLO 是用 SLI 來(lái)描述的跪但，一般描述為： 比如以下 SLO：

• 每分鐘平均 qps > 100k/s

• 99% 訪問(wèn)延遲 < 500ms

• 99% 每分鐘帶寬 > 200MB/s

設(shè)置 SLO 時(shí)的幾個(gè)最佳實(shí)踐：

• 指定計(jì)算的時(shí)間窗口

• 使用一致的時(shí)間窗口 (XX 小時(shí)滾動(dòng)窗口、季度滾動(dòng)窗口)

• 要有一個(gè)免責(zé)條款峦萎，比如：95% 的時(shí)間要能夠達(dá)到 SLO

• 如果 Service 是第一次設(shè)置 SLO屡久，可以遵循以下原則

• 測(cè)量系統(tǒng)當(dāng)前狀態(tài)

  • 設(shè)置預(yù)期 (expectations)，而不是保證 (guarantees)

  • 初期的 SLO 不適合作為服務(wù)質(zhì)量的強(qiáng)化工具

• 改進(jìn) SLO

  • 設(shè)置更低的響應(yīng)時(shí)間爱榔、更改的吞吐量等

• 保持一定的安全緩沖

  • 內(nèi)部用的 SLO 要高于對(duì)外宣稱的 SLO

• 不要超額完成

  • 定期的 downtime 來(lái)使 SLO 不超額完成

設(shè)置 SLO 時(shí)的目標(biāo)依賴于系統(tǒng)的不同狀態(tài) (conditions)被环，根據(jù)不同狀態(tài)設(shè)置不同的 SLO：**總 SLO = service1.SLO1 weight1 + service2.SLO2 weight2 + …

為什么要有 SLO，設(shè)置 SLO 的好處是什么呢详幽？

• 對(duì)于客戶而言筛欢，是可預(yù)期的服務(wù)質(zhì)量，可以簡(jiǎn)化客戶端的系統(tǒng)設(shè)計(jì)

• 對(duì)于服務(wù)提供者而言

  • 可預(yù)期的服務(wù)質(zhì)量

  • 更好的取舍成本 / 收益

  • 更好的風(fēng)險(xiǎn)控制 (當(dāng)資源受限的時(shí)候)

  • 故障時(shí)更快的反應(yīng)唇聘，采取正確措施

  • SLO 設(shè)好了版姑，怎么保證能夠達(dá)到目標(biāo)呢？

  • 需要一個(gè)控制系統(tǒng)來(lái)：

監(jiān)控 / 測(cè)量 SLIs 對(duì)比檢測(cè)到的 SLIs 值是否達(dá)到目標(biāo) 如果需要迟郎，修正目標(biāo)或者修正系統(tǒng)以滿足目標(biāo)需要 實(shí)施目標(biāo)的修改或者系統(tǒng)的修改 該控制系統(tǒng)需要重復(fù)的執(zhí)行以上動(dòng)作剥险，以形成一個(gè)標(biāo)準(zhǔn)的反饋環(huán)路，不斷的衡量和改進(jìn) SLO / 服務(wù)本身宪肖。

我們討論了目標(biāo)以及目標(biāo)是怎么測(cè)量的表制，還討論了控制機(jī)制來(lái)達(dá)到設(shè)置的目標(biāo)，但是如果因?yàn)槟承┰蚩厍O(shè)置的目標(biāo)達(dá)不到該怎么辦呢么介？

也許是因?yàn)榇罅康男略鲐?fù)載；也許是因?yàn)榈讓右蕾嚥荒苓_(dá)到標(biāo)稱的 SLO 而影響上次服務(wù)的 SLO蜕衡。這就需要 SLA 出場(chǎng)了夭拌。

SLA

SLA 是一個(gè)涉及 2 方的合約，雙方必須都要同意并遵守這個(gè)合約。當(dāng)需要對(duì)外提供服務(wù)時(shí)鸽扁，SLA 是非常重要的一個(gè)服務(wù)質(zhì)量信號(hào)蒜绽，需要產(chǎn)品和法務(wù)部門的同時(shí)介入。

SLA 用一個(gè)簡(jiǎn)單的公式來(lái)描述就是：SLA = SLO + 后果

• SLO 不能滿足的一系列動(dòng)作桶现，可以是部分不能達(dá)到

  • 比如：達(dá)到響應(yīng)時(shí)間 SLO + 未達(dá)到可用性 SLO

• 對(duì)動(dòng)作的具體實(shí)施

  • 需要一個(gè)通用的貨幣來(lái)獎(jiǎng)勵(lì) / 懲罰躲雅，比如：績(jī)效得分等

SLA 是一個(gè)很好的工具，可以用來(lái)幫助合理配置資源骡和。一個(gè)有明確 SLA 的服務(wù)最理想的運(yùn)行狀態(tài)是：增加額外資源來(lái)改進(jìn)系統(tǒng)所帶來(lái)的收益小于把該資源投給其他服務(wù)所帶來(lái)的收益相赁。

一個(gè)簡(jiǎn)單的例子就是某服務(wù)可用性從 99.9% 提高到 99.99% 所需要的資源和帶來(lái)的收益之比，是決定該服務(wù)是否應(yīng)該提供 4 個(gè) 9 的重要依據(jù)慰于。

故障復(fù)盤

故障復(fù)盤就是對(duì)于過(guò)去的一些服務(wù)異常和服務(wù)中斷情況進(jìn)行回顧和總結(jié)钮科，以確保相同問(wèn)題下次不會(huì)再出現(xiàn)。為了讓大家團(tuán)結(jié)協(xié)作婆赠，我們希望建立一種無(wú)指責(zé)绵脯、透明的事后文化。個(gè)人不應(yīng)該害怕事故休里，而是確信如果事故發(fā)生蛆挫，團(tuán)隊(duì)將會(huì)響應(yīng)和改進(jìn)系統(tǒng)。

備注: 其實(shí)在國(guó)內(nèi)的SRE文化中妙黍，一般只有對(duì)大型悴侵，對(duì)業(yè)務(wù)有重大影響的事故才會(huì)進(jìn)行復(fù)盤，但實(shí)際上如果在時(shí)間和經(jīng)歷允許的情況下拭嫁，對(duì)于一般的普通事故也應(yīng)該在小范圍進(jìn)行復(fù)盤可免，正所謂大的故障都是從不斷的小問(wèn)題一點(diǎn)一點(diǎn)積累的。另外做粤，其實(shí)對(duì)于運(yùn)維相關(guān)的個(gè)人而言巴元，我們也應(yīng)當(dāng)及時(shí)的進(jìn)行小故障復(fù)盤，以不斷加強(qiáng)個(gè)人的故障處理和修復(fù)能力驮宴。

我認(rèn)為SRE的一個(gè)關(guān)鍵共識(shí)正是承認(rèn)了系統(tǒng)的不完美性逮刨，追求永不停機(jī)的系統(tǒng)是不現(xiàn)實(shí)的《略螅基于不完美系統(tǒng)修己，我們無(wú)可避免要面對(duì)和經(jīng)歷系統(tǒng)故障與失敗。

所以我們重要的并非找到為這個(gè)故障責(zé)任的這個(gè)人或者那個(gè)人迎罗，而是更應(yīng)該刨根問(wèn)底地復(fù)盤這個(gè)故障和失敗的根本原因是什么睬愤，以及如何避免再次出現(xiàn)相同的故障。系統(tǒng)可靠性是整個(gè)團(tuán)隊(duì)共同奮斗的方向纹安，從失敗中快速恢復(fù)并吸取教訓(xùn)尤辱，每個(gè)人放心地提出問(wèn)題砂豌，應(yīng)對(duì)停機(jī)，并努力改進(jìn)系統(tǒng)光督。

備注: 通常很多企業(yè)內(nèi)部在故障復(fù)盤過(guò)程中阳距，相關(guān)人員可能將故障和失敗的根因追溯 不經(jīng)意間 當(dāng)做了故障定責(zé)和一系列的懲罰措施，通過(guò)一些懲戒措施來(lái)強(qiáng)行約定故障的發(fā)生结借，這種方式往往是非常不可取的筐摘，試想每個(gè)人都不想出現(xiàn)事故，要么是認(rèn)知之外船老，要么是規(guī)則缺陷咖熟，永遠(yuǎn)沒(méi)有一個(gè)人明知會(huì)有故障而偏偏去制造故障的。

需要牢記的是: 故障是我們可以從中學(xué)習(xí)的東西柳畔，而不是讓人害怕和羞恥的事情馍管！

在日常運(yùn)維過(guò)程中，出現(xiàn)故障等事故對(duì)于我們而言其實(shí)是一個(gè)很好的復(fù)盤學(xué)習(xí)機(jī)會(huì)薪韩。通過(guò)歷史監(jiān)控?cái)?shù)據(jù)确沸，分析事故其中的根本原因，制定后續(xù)應(yīng)對(duì)策略躬存，并且通過(guò)運(yùn)維平臺(tái)將這些應(yīng)對(duì)策略編輯成標(biāo)準(zhǔn)化张惹、可重用舀锨、自動(dòng)化的運(yùn)維應(yīng)用場(chǎng)景岭洲，為后續(xù)相同問(wèn)題的處理提供標(biāo)準(zhǔn)且快捷的解決方案。這正是事后回顧這個(gè)過(guò)程最真實(shí)的價(jià)值體現(xiàn)坎匿。

故障復(fù)盤的唯一目的是減少故障的發(fā)生盾剩。有幾個(gè)我目前認(rèn)為不錯(cuò)的做法。

故障復(fù)盤需要有文檔記錄替蔬，包括故障發(fā)生的過(guò)程告私，時(shí)間線的記錄，操作的記錄承桥，故障恢復(fù)的方法驻粟，故障根因的分析，為什么故障會(huì)發(fā)生的分析凶异。文檔應(yīng)該隱去所有當(dāng)事人的姓名對(duì)公司的所有人公開(kāi)蜀撑。很多公司對(duì)故障文檔設(shè)置查看權(quán)限，我覺(jué)得沒(méi)什么道理剩彬。有些公司的故障復(fù)盤甚至對(duì)外也是公開(kāi)的酷麦。

故障在復(fù)盤的時(shí)候應(yīng)該將當(dāng)事人的名字用代碼替代，可以營(yíng)造更好的討論氛圍喉恋。

不應(yīng)該要求所有的故障復(fù)盤都產(chǎn)生 Action沃饶。之前一家的公司的故障復(fù)盤上母廷，因?yàn)楸仨毥o領(lǐng)導(dǎo)一個(gè)“交待”，所以每次都會(huì)產(chǎn)生一些措施來(lái)預(yù)防相同的故障再次發(fā)生糊肤，比如增加審批流程之類的琴昆。這很扯，讓級(jí)別很高的領(lǐng)導(dǎo)審批他自己也看不懂的操作轩褐，只能讓領(lǐng)導(dǎo)更痛苦椎咧，也讓操作流程變得又臭又長(zhǎng)，最后所有人都會(huì)忘記這里為什么會(huì)有一個(gè)審批把介，但是又沒(méi)有人敢刪掉勤讽。你刪掉，出了事情你負(fù)責(zé)拗踢。

Blame Free 文化脚牍？之前我認(rèn)為是好的。但是后來(lái)發(fā)現(xiàn)巢墅，有些不按照流程操作導(dǎo)致的問(wèn)題確實(shí)多少應(yīng)該 Blame 一下诸狭，比如下線服務(wù)的時(shí)候沒(méi)有檢查還沒(méi)有 tcp 連接就直接下線了，或者操作的時(shí)候沒(méi)有做 canary 就全部操作了君纫，這種不理智的行為導(dǎo)致的故障驯遇。但是條條框框又不應(yīng)該太多，不然活都沒(méi)法干了蓄髓。

引用來(lái)源：：

https://silenceper.com/blog/202009/how-to-use-keda/

https://bgbiao.top/post/sre運(yùn)維體系

在基于DevOps思想對(duì)自動(dòng)化運(yùn)維改革的大道上叉庐，一直砥礪前行，從未停歇会喝。

道阻且長(zhǎng)陡叠，行則將至，行而不輟肢执，未來(lái)可期枉阵。

歡迎搜索 k8stech 關(guān)注公眾號(hào)，定時(shí)更新運(yùn)維開(kāi)發(fā)预茄、SRE兴溜、云原生等文章。