1.?行為準(zhǔn)則

文章來源地址http://www.zghlxwxcb.cn/news/detail-760361.html

2.?On-Call工程師

2.1.?On-Call工程師是應(yīng)對(duì)計(jì)劃外工作的第一道防線，無論是生產(chǎn)環(huán)境問題還是臨時(shí)支持請(qǐng)求

2.2.?將深度工作與運(yùn)維工作分開，可以讓團(tuán)隊(duì)中的大多數(shù)人專注于開發(fā)任務(wù)

2.3.?On-Call工程師只需專注于不可預(yù)知的運(yùn)維難題和支持任務(wù)

3.?On-Call的工作方式

3.1.?On-Call的開發(fā)人員根據(jù)時(shí)間表進(jìn)行輪換

3.1.1.?每名合格的開發(fā)人員都會(huì)參與到輪換工作中

3.2.?On-Call人員的大部分時(shí)間用來處理臨時(shí)性的支持請(qǐng)求

3.2.1.?bug報(bào)告、關(guān)于他們團(tuán)隊(duì)的軟件如何運(yùn)行以及使用的問題

3.3.?大概每名On-Call人員最終都會(huì)遇到一起運(yùn)維事故（生產(chǎn)軟件的關(guān)鍵問題）

3.3.1.?事故是由自動(dòng)監(jiān)控系統(tǒng)發(fā)出的警報(bào)或由支持工程師觀察到問題并報(bào)告給值班人員的

3.3.2.?On-Call的開發(fā)人員必須對(duì)事故分流、緩解癥狀和最終解決

3.4.?所有的On-Call輪換的工作都應(yīng)該以交接開始和結(jié)束

4.?On-Call技能包

4.1.?隨時(shí)響應(yīng)

4.1.1.?較大的公司有“跟隨太陽(yáng)”的On-Call輪換機(jī)制，隨著時(shí)間的推移，輪換到不同時(shí)區(qū)的開發(fā)人員

4.1.2.?“隨時(shí)響應(yīng)”并不意味著立即放下你正在做的事情來解決最新的問題

4.1.3.?對(duì)于許多請(qǐng)求，完全可以先承認(rèn)你已經(jīng)收到了詢問，并回答你應(yīng)該在什么時(shí)候能看一下這個(gè)問題

4.2.?保持專注

4.3.?確定工作優(yōu)先級(jí)

4.3.1.?首先處理優(yōu)先級(jí)最高的任務(wù)

4.3.2.?隨著任務(wù)的完成或受阻，你可以依次從最高優(yōu)先級(jí)到最低優(yōu)先級(jí)展開工作

4.3.3.?如果你無法判斷一個(gè)請(qǐng)求的緊急程度，請(qǐng)?jiān)儐栐撜?qǐng)求的影響是什么

4.3.4.?P1：嚴(yán)重影響(critical impact)——服務(wù)在生產(chǎn)環(huán)境中無法使用

4.3.5.?P2：高影響(high impact)——服務(wù)的使用受到嚴(yán)重?fù)p害

4.3.6.?P3：中等影響(medium impact)——服務(wù)的使用部分受損

4.3.7.?P4：低影響(low impact)——服務(wù)完全可用

4.3.8.?服務(wù)水平指標(biāo)(SLI)如錯(cuò)誤率、請(qǐng)求延遲和每秒請(qǐng)求數(shù)，是了解一個(gè)應(yīng)用程序是否健康的最簡(jiǎn)單的方法之一

4.3.9.?服務(wù)水平目標(biāo)(service level objective，SLO)為健康的應(yīng)用程序行為定義了SLI的目標(biāo)

4.3.10.?如果錯(cuò)誤率是某個(gè)應(yīng)用程序的SLI，SLO可能是請(qǐng)求錯(cuò)誤率低于0.001%的

4.3.11.?服務(wù)水平協(xié)議(service level agreement，SLA)是關(guān)于越過SLO范圍時(shí)將會(huì)發(fā)生什么的協(xié)議

4.3.12.?了解你的應(yīng)用程序的SLI、SLO和SLA，SLI將為你指出最重要的指標(biāo)，SLO和SLA將幫助你確定事故的優(yōu)先次序

4.4.?清晰的溝通

4.4.1.?用簡(jiǎn)潔的句子進(jìn)行溝通

4.4.2.?回應(yīng)請(qǐng)求要迅速

4.4.2.1.?回應(yīng)不一定代表解決方案

4.4.3.?定期發(fā)布狀態(tài)更新

4.4.3.1.?每次更新時(shí)，提供一個(gè)新的時(shí)間預(yù)估

4.5.?跟蹤你的工作

4.5.1.?記錄下你在工作中所做的事情

4.5.2.?聊天是一種很好的溝通方式，但聊天記錄在以后很難被閱讀，所以要確保在任務(wù)票或文檔中總結(jié)一切

4.5.3.?關(guān)閉已解決的問題，這樣懸而未決的任務(wù)票就不會(huì)在On-Call的看板上留下痕跡，也不會(huì)使On-Call支持的系統(tǒng)指標(biāo)出現(xiàn)偏差

4.5.3.1.?如果請(qǐng)求者沒有回應(yīng)，就說你將在24小時(shí)內(nèi)因缺乏回應(yīng)而關(guān)閉該任務(wù)票，然后真的這樣做

4.5.4.?始終在你的筆記中包含時(shí)間戳

5.?事故處理

5.1.?事故處理是On-Call人員最重要的職責(zé)

5.1.1.?第一個(gè)目標(biāo)是減輕問題的影響并恢復(fù)服務(wù)

5.1.2.?第二個(gè)目標(biāo)是捕捉信息，以便以后分析問題是如何發(fā)生以及為什么發(fā)生的

5.1.3.?第三個(gè)目標(biāo)是確定事故的原因，證明它是罪魁禍?zhǔn)?，并解決根本問題

5.2.?提供支持

5.2.1.?大多數(shù)請(qǐng)求是bug報(bào)告、關(guān)于業(yè)務(wù)邏輯的問題，或關(guān)于如何使用你的軟件的技術(shù)問題

5.2.2.?支持請(qǐng)求遵循一個(gè)相當(dāng)標(biāo)準(zhǔn)的流程

5.3.?5個(gè)階段

5.3.1.?分流(triage)

5.3.1.1.?工程師必須找到問題，確定其嚴(yán)重性，并確定誰能修復(fù)它

5.3.1.2.?確認(rèn)問題并了解其影響，以便對(duì)其進(jìn)行適當(dāng)?shù)膬?yōu)先排序

5.3.1.3.?分流不是證明你能自己解決問題的時(shí)候，最寶貴的是爭(zhēng)取時(shí)間

5.3.1.4.?分流也不是排除故障的時(shí)候

5.3.1.4.1.?把故障排除留給提出應(yīng)急方案和解決方案的階段

5.3.2.?協(xié)同(coordination)

5.3.2.1.?團(tuán)隊(duì)（以及潛在的用戶）必須得到這個(gè)問題的通知

5.3.2.2.?大型事故設(shè)有專門的“作戰(zhàn)室”來幫助溝通，“作戰(zhàn)室”是用于協(xié)調(diào)事故響應(yīng)的虛擬或物理空間

5.3.2.3.?所有相關(guān)方都加入作戰(zhàn)室，以協(xié)同響應(yīng)

5.3.2.4.?即使你是一個(gè)人在工作，也要交流你的工作

5.3.2.4.1.?有人可能會(huì)稍后加入并發(fā)現(xiàn)你記錄的日志大有所益，詳細(xì)的記錄將有助于事后重建時(shí)間線

5.3.3.?應(yīng)急方案(mitigation)

5.3.3.1.?工程師必須盡快讓事情穩(wěn)定下來

5.3.3.2.?緩解并不是長(zhǎng)期的修復(fù)，你只是在試圖“止血”

5.3.3.3.?應(yīng)急方案的階段目標(biāo)是降低問題的影響

5.3.3.3.1.?應(yīng)急方案并不是要徹底地解決這個(gè)問題，而是要降低其嚴(yán)重性

5.3.3.4.?修復(fù)一個(gè)問題可能需要很多時(shí)間，而應(yīng)急方案通常可以很快完成

5.3.3.5.?事故的應(yīng)急方案通常是將軟件版本回滾到“最后已知良好”的版本，或?qū)⒘髁繌膯栴}上轉(zhuǎn)移開

5.3.3.6.?迅速寫下你發(fā)現(xiàn)的任何不足，可以使你在排除故障時(shí)處理得更游刃有余，在后續(xù)行動(dòng)的階段新建任務(wù)票以解決這些不足

5.3.4.?解決方案(resolution)

5.3.4.1.?在問題得到緩解后，工程師有一些時(shí)間來喘口氣、深入思考，并為解決問題而努力

5.3.4.2.?一旦完成了應(yīng)急方案，事故就不再是緊急事故了

5.3.4.3.?使用科學(xué)方法來排除技術(shù)問題的故障

5.3.4.4.?測(cè)試并不是治療

5.3.5.?后續(xù)行動(dòng)(follow-up)

5.3.5.1.?對(duì)事故的根本原因：為什么會(huì)發(fā)生，進(jìn)行調(diào)查

5.3.5.2.?目的是從事故中學(xué)習(xí)，防止它再次發(fā)生

5.3.5.3.?要寫一份事后總結(jié)的文檔，并進(jìn)行評(píng)審，同時(shí)開啟新任務(wù)以防止其再次發(fā)生

5.3.5.3.1.?描述了事故的前因后果、故障、影響、檢測(cè)、響應(yīng)、恢復(fù)、時(shí)間表、根本原因、經(jīng)驗(yàn)教訓(xùn)和所需的糾正措施

5.3.5.3.2.?任何回顧總結(jié)文檔的關(guān)鍵部分是根本原因分析(root-cause analysis，RCA)

5.3.5.4.?根本原因分析是利用5個(gè)“Why”進(jìn)行的

5.3.5.4.1.?“5W”只是口口相傳的經(jīng)驗(yàn)，大多數(shù)問題要經(jīng)過5次反復(fù)才能找到根本原因

5.3.5.4.2.?根本原因分析是一個(gè)流行但具有誤導(dǎo)性的術(shù)語

5.3.5.4.2.1.?事故很少是由單一的問題引起的

5.3.5.4.2.2.?在實(shí)踐中，這5個(gè)“Why”可能會(huì)引向許多不同的原因

5.3.5.4.2.3.?只要把一切都記錄下來

5.3.5.5.?良好的事后總結(jié)會(huì)還將“解決問題”與評(píng)審會(huì)議分開

5.3.5.6.?事后總結(jié)會(huì)結(jié)束后，后續(xù)任務(wù)必須被完成

5.3.5.7.?舊的回顧總結(jié)文檔是很好的學(xué)習(xí)資料

6.?不要逞英雄

6.1.?跳入“救火”模式成為一種條件反射

6.2.?依賴“救火隊(duì)員”是不健康的

6.3.?長(zhǎng)時(shí)間和高風(fēng)險(xiǎn)將導(dǎo)致倦怠?！熬然稹惫こ處熞矔?huì)在編程或設(shè)計(jì)工作中“步履蹣跚”，因?yàn)樗麄儾粩嗟乇淮驍?/h2>

6.4.?“救火隊(duì)員”的英雄主義也會(huì)導(dǎo)致那種修復(fù)嚴(yán)重的潛在問題的工作被置于次要地位，因?yàn)椤熬然痍?duì)員”總在旁邊修修補(bǔ)補(bǔ)

到了這里，關(guān)于讀程序員的README筆記12_On-Call的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！