運(yùn)維工程師面試者第一個(gè)問(wèn)題是：需要值班嗎？筆者自己也曾經(jīng)歷過(guò)月入十萬(wàn)的時(shí)期，在那個(gè)時(shí)候，數(shù)個(gè)系統(tǒng)同時(shí)發(fā)布下一代版本，而老系統(tǒng)還需要過(guò)渡很長(zhǎng)時(shí)間，工作量直接翻倍，大家只能勉強(qiáng)應(yīng)付一線運(yùn)維工作，團(tuán)隊(duì)成員開(kāi)始陸續(xù)離職，而新人又無(wú)法在短時(shí)間內(nèi)上手，整體情況不斷惡化，持續(xù)半年左右才緩過(guò)勁來(lái)。 

下面兩張截圖是我挑選的兩個(gè)團(tuán)隊(duì)一周報(bào)警數(shù)的對(duì)比圖，前者的單日?qǐng)?bào)警量最高是 55348 條，后者單日的報(bào)警量最高為 34 條，兩者相差 1600 倍，而前者才是國(guó)內(nèi)很多互聯(lián)網(wǎng)運(yùn)維團(tuán)隊(duì)的真實(shí)寫(xiě)照。

在管理大規(guī)模集群的情況下，究竟有多少報(bào)警量才是合理的呢？Google SRE 每周只有十條報(bào)警，如果超過(guò)十條，說(shuō)明沒(méi)有把無(wú)效報(bào)警過(guò)濾掉（Google SRE 僅負(fù)責(zé) SLA 要求為 99.99% 的服務(wù)）。筆者所在的團(tuán)隊(duì)要求則是，每周至多兩晚有報(bào)警，單日?qǐng)?bào)警量不能超過(guò) 50 條（比 Google SRE 放水好多?。?/p>

通過(guò)控制單日?qǐng)?bào)警數(shù)量，嚴(yán)格約束夜間報(bào)警天數(shù)，確保最少不低于四人參與值班，筆者所在的團(tuán)隊(duì)，近幾年來(lái)，不僅少有因?yàn)橹蛋鄩毫Χx職的同學(xué)，而且我們每年都能持續(xù)招聘到 985 前 20 名學(xué)校的多個(gè)研究生。那么，怎么做到呢，以下是筆者的一些經(jīng)驗(yàn)分享。

運(yùn)維工程角度看報(bào)警優(yōu)化

報(bào)警值班和報(bào)警升級(jí)

基于值班表，每天安排兩人進(jìn)行值班處理報(bào)警，將值班壓力從全團(tuán)隊(duì)壓縮在兩人范圍內(nèi)，從而讓團(tuán)隊(duì)能夠有足夠的時(shí)間和人力進(jìn)行優(yōu)化工作。同時(shí)，為了避免兩個(gè)值班人員都沒(méi)有響應(yīng)報(bào)警，可以使用報(bào)警升級(jí)功能，如果一個(gè)報(bào)警在 5min 內(nèi)值班人員均未響應(yīng)，或者 15min 內(nèi)未處理完畢，或者有嚴(yán)重故障發(fā)生，都可以將報(bào)警進(jìn)行升級(jí)，通告團(tuán)隊(duì)其他成員協(xié)助處理。

如果公司的監(jiān)控系統(tǒng)暫不支持值班表功能，則通過(guò)人工定期修改報(bào)警接收人的方式進(jìn)行。而對(duì)于監(jiān)控系統(tǒng)不支持報(bào)警升級(jí)的問(wèn)題，通過(guò)自行開(kāi)發(fā)腳本的方式，也能在一定程度上得到解決。也可以將報(bào)警短信發(fā)送至商業(yè)平臺(tái)來(lái)實(shí)現(xiàn)?？傊痪湓?，辦法總比問(wèn)題多。

對(duì)于報(bào)警值班人員，需要隨時(shí)攜帶筆記本以方便處理服務(wù)故障，這個(gè)要求，和報(bào)警數(shù)量多少以及報(bào)警的自動(dòng)化處理程度并無(wú)關(guān)系，僅和服務(wù)重要性有關(guān)。對(duì)于節(jié)假日依然需要值班的同學(xué)，公司或者部門也應(yīng)該盡量以各種方式進(jìn)行補(bǔ)償。

基于重要性不同，分級(jí)應(yīng)對(duì)

一個(gè)問(wèn)題請(qǐng)大家思考一下，如果線上的服務(wù)器全部掉電后以短信方式通知值班人員，那么線上一臺(tái)機(jī)器的根分區(qū)打滿，也通過(guò)短信來(lái)通知是否有必要。

上述的問(wèn)題在日常工作也屢屢發(fā)生，對(duì)于問(wèn)題、異常和故障，我們采取了同樣的處理方式，因此產(chǎn)生了如此多的無(wú)效報(bào)警。

Google SRE 的實(shí)踐則是將監(jiān)控系統(tǒng)的輸出分為三類，報(bào)警，工單和記錄。SRE 的要求是所有的故障級(jí)別的報(bào)警，都必須是接到報(bào)警，有明確的非機(jī)械重復(fù)的事情要做，且必須馬上就得做，才能叫做故障級(jí)別的報(bào)警。其他要么是工單，要么是記錄。

在波音公司裝配多個(gè)發(fā)動(dòng)機(jī)的飛機(jī)上，一個(gè)發(fā)動(dòng)機(jī)熄火的情況只會(huì)產(chǎn)生一個(gè)”提醒“級(jí)別的警示（最高級(jí)別是警報(bào)，接下來(lái)依次是警告，提醒，建議），對(duì)于各種警示，會(huì)有個(gè)檢查清單自動(dòng)彈出在中央屏幕上，以引導(dǎo)飛行員找到解決方案。如果是最高級(jí)別的警報(bào)，則會(huì)以紅色信息，語(yǔ)音警報(bào)，以及飛機(jī)操縱桿的劇烈震動(dòng)來(lái)提示。如果這時(shí)你什么都不做，飛機(jī)將會(huì)墜毀。

故障自愈

重啟作為單機(jī)預(yù)案，在很多業(yè)務(wù)線，可以解決至少 50% 的報(bào)警。沒(méi)有響應(yīng)，重啟試試，請(qǐng)求異常，重啟試試，資源占用異常，重啟試試，各種問(wèn)題，重啟都屢試不爽。

換言之，針對(duì)簡(jiǎn)單場(chǎng)景具有明確處置方案的報(bào)警，自動(dòng)化是一個(gè)比較好的解決方案，能夠?qū)⑷肆拇罅恐貜?fù)的工作中解放出來(lái)。

自動(dòng)化處理報(bào)警的過(guò)程中，需要注意以下問(wèn)題：

• 自動(dòng)化處理比例不能超過(guò)服務(wù)的冗余度（默認(rèn)串行處理最為穩(wěn)妥）
• 不能對(duì)同一個(gè)問(wèn)題在短時(shí)間內(nèi)重復(fù)多次的自動(dòng)化處理（不斷重啟某個(gè)機(jī)器上的特定進(jìn)程）
• 在特定情況下可以在全局范圍內(nèi)快速終止自動(dòng)化處理機(jī)制
• 盡量避免高危操作（如刪除操作，重啟服務(wù)器等操作）
• 每次執(zhí)行操作都需要確保上一個(gè)操作的結(jié)果和效果收集分析完畢（如果一個(gè)服務(wù)重啟需要 10min）

報(bào)警儀表盤，持續(xù)優(yōu)化 TOP-3 的報(bào)警  

如下圖示，全年 TOP-3 的報(bào)警量占比達(dá)到 30%，通過(guò)對(duì) TOP-3 的報(bào)警安排專人進(jìn)行跟進(jìn)優(yōu)化，可以在短時(shí)間大幅降低報(bào)警量。

TOP-3 只是報(bào)警儀表盤數(shù)據(jù)分析的典型場(chǎng)景之一，在 TOP-3 之后，還可以對(duì)報(bào)警特特征進(jìn)行分析，如哪些模塊的報(bào)警最多，哪些機(jī)器的報(bào)警最多，哪個(gè)時(shí)間段的報(bào)警最多，哪種類型的報(bào)警最多，進(jìn)而進(jìn)行細(xì)粒度的優(yōu)化。

同時(shí)，報(bào)警儀表盤還需要提供報(bào)警視圖的功能，能夠基于各種維度展示當(dāng)前有哪些報(bào)警正在發(fā)生，從而便于當(dāng)短時(shí)間內(nèi)收到大量報(bào)警，或者是報(bào)警處理中的狀態(tài)總覽，以及報(bào)警恢復(fù)后的確認(rèn)等。

基于時(shí)間段分而治之

下圖是國(guó)內(nèi)非常典型的一類流量圖，流量峰值在每天晚上，流量低谷在每天凌晨。從冗余度角度來(lái)分析，如果在流量峰值有 20% 的冗余度，那么在流量低谷，冗余度至少為 50%?；谌哂喽鹊淖儞Q，相應(yīng)的監(jiān)控策略的閾值，隨機(jī)也應(yīng)該發(fā)生一系列的變化。

舉例來(lái)說(shuō)，在高峰期，可能一個(gè)服務(wù)故障 20% 的實(shí)例，就必須介入處理的話，那么在低谷期，可能故障 50% 的實(shí)例，也不需要立即處理，依賴于報(bào)警自動(dòng)化處理功能，逐步修復(fù)即可。

在具體的實(shí)踐中，一種比較簡(jiǎn)單的方式就是，在流量低谷期，僅接收故障級(jí)別的報(bào)警，其余報(bào)警轉(zhuǎn)為靜默方式或者是自動(dòng)化處理方式，在流量高峰期來(lái)臨前幾個(gè)小時(shí)，重新恢復(fù)，這樣即使流量低谷期出現(xiàn)一些嚴(yán)重隱患，依然有數(shù)小時(shí)進(jìn)行修復(fù)。這種方式之所以大量流行，是因?yàn)樵摬呗阅軌虼蠓鶞p少凌晨的報(bào)警數(shù)量，讓值班人員能夠正常休息。

報(bào)警周期優(yōu)化，避免瞬報(bào)  

在監(jiān)控趨勢(shì)圖中，會(huì)看到偶發(fā)的一些毛刺或者抖動(dòng)，這些毛刺和抖動(dòng)，就是造成瞬報(bào)的主要原因。這些毛刺和抖動(dòng)，至多定義為異常，而非服務(wù)故障，因此應(yīng)該以非緊急的通知方式進(jìn)行。

以 CPU 瞬報(bào)為例，如果設(shè)置采集周期為 10s，監(jiān)控條件為 CPU 使用率大于 90% 報(bào)警，如果設(shè)置每次滿足條件就報(bào)警，那么就會(huì)產(chǎn)生大量的報(bào)警。如果設(shè)置為連續(xù) 5 次滿足條件報(bào)警，或者連續(xù)的 10 次中有 5 次滿足條件就報(bào)警，則會(huì)大幅減少無(wú)效報(bào)警。對(duì)于重要服務(wù)，一般建議為在 3min 內(nèi)，至少出現(xiàn) 5 次以上異常，再發(fā)送報(bào)警較為合理。

提前預(yù)警，防患于未然

對(duì)于很多有趨勢(shì)規(guī)律的場(chǎng)景，可以通過(guò)提前預(yù)警的方式，降低問(wèn)題的緊迫程度和嚴(yán)重性。下圖是兩臺(tái)機(jī)器一周內(nèi)的磁盤使用率監(jiān)控圖，可以預(yù)見(jiàn)，按照目前的增長(zhǎng)趨勢(shì)，必然會(huì)在某一個(gè)時(shí)間點(diǎn)觸發(fā)磁盤剩余空間 5% 的報(bào)警，可以在剩余空間小于 10% 的時(shí)候，通過(guò)工單或者其他非緊急方式提醒，在工作時(shí)間段內(nèi)，相對(duì)從容的處理完畢即可，畢竟 10% 到 5% 還是需要一個(gè)時(shí)間過(guò)程的。

日常巡檢

提前預(yù)警面向的是有規(guī)律的場(chǎng)景，而日常巡檢，還可以發(fā)現(xiàn)那些沒(méi)有規(guī)律的隱患。以 CPU 使用率為例進(jìn)行說(shuō)明，近期的一個(gè)業(yè)務(wù)上線后，CPU 使用率偶發(fā)突增的情況，但是無(wú)法觸發(fā)報(bào)警條件（例如 3 分鐘內(nèi)有 5 次使用率超過(guò) 70% 報(bào)警），因此無(wú)法通過(guò)報(bào)警感知。放任不管的話，只能是問(wèn)題足夠嚴(yán)重了，才能通過(guò)報(bào)警發(fā)現(xiàn)。這個(gè)時(shí)候，如果每天有例行的巡檢工作，那么這類問(wèn)題就能夠提前發(fā)現(xiàn)，盡快解決，從而避免更加嚴(yán)重的問(wèn)題發(fā)生。

比例為主，絕對(duì)值為輔  

線上機(jī)器的規(guī)格不同，如果從絕對(duì)值角度進(jìn)行監(jiān)控，則無(wú)法適配所有的機(jī)器規(guī)格，勢(shì)必會(huì)產(chǎn)生大量無(wú)意義的報(bào)警。以磁盤剩余空間監(jiān)控為例，線上規(guī)格從 80GB 到 10TB 存在多種規(guī)格，從下圖表格看，比例比絕對(duì)值模式能更好的適配各種規(guī)格的場(chǎng)景（EXT4 文件系統(tǒng)的默認(rèn)預(yù)留空間為 5%，也是基于比例設(shè)置的并可通過(guò) tune2fs 進(jìn)行調(diào)整）

對(duì)于一些特殊場(chǎng)景，同樣以磁盤剩余空間為例進(jìn)行說(shuō)明，例如計(jì)算任務(wù)要求磁盤至少有 100GB 以上空間，以供存放臨時(shí)文件，那這個(gè)時(shí)候，監(jiān)控策略就可以調(diào)整為：磁盤剩余空間小于 5% 報(bào)警或磁盤剩余空間絕對(duì)值小于 100GB 報(bào)警。

Code Review

前人埋坑，后人挖坑。在解決存量問(wèn)題的情況下，不對(duì)增量問(wèn)題進(jìn)行控制，那報(bào)警優(yōu)化，勢(shì)必會(huì)進(jìn)入螺旋式緩慢上升的過(guò)程，這對(duì)于報(bào)警優(yōu)化這類項(xiàng)目來(lái)說(shuō)，無(wú)疑是致命的。通過(guò)對(duì)新增監(jiān)控的 Code Review，可以讓團(tuán)隊(duì)成員快速達(dá)成一致認(rèn)知，從而避免監(jiān)控配置出現(xiàn)千人千面的情況出現(xiàn)。

沉淀標(biāo)準(zhǔn)和最佳實(shí)踐  

僅僅做 Code Review 還遠(yuǎn)遠(yuǎn)不夠，一堆人開(kāi)會(huì)，面對(duì)一行監(jiān)控配置，大眼瞪小眼，對(duì)不對(duì)，為什么不對(duì)，怎么做更好？大家沒(méi)有一個(gè)標(biāo)準(zhǔn)，進(jìn)而會(huì)浪費(fèi)很多時(shí)間來(lái)進(jìn)行不斷的討論。這時(shí)候，如果有一個(gè)標(biāo)準(zhǔn)，告訴大家什么是好，那么就有了評(píng)價(jià)標(biāo)準(zhǔn)，很多事情就比較容易做了。標(biāo)準(zhǔn)本身也是需要迭代和進(jìn)步的，因此大家并不需要擔(dān)心說(shuō)我的標(biāo)準(zhǔn)不夠完美?；跇?biāo)準(zhǔn)，再給出一些最佳的監(jiān)控時(shí)間，那執(zhí)行起來(lái)，就更加容易了。

以機(jī)器監(jiān)控為例進(jìn)行說(shuō)明，機(jī)器監(jiān)控必須覆蓋如下的監(jiān)控指標(biāo)，且閾值設(shè)定也給出了最佳實(shí)踐，具體如下：

• CPU_IDLE < 10
• MEM_USED_PERCENT > 90
• NET_MAX_NIC_INOUT_PERCENT > 80 （網(wǎng)卡入口 / 出口流量最大使用率）
• CPU_SERVER_LOADAVG_5 > 15
• DISK_MAX_PARTITION_USED_PERCENT > 95 （磁盤各個(gè)分區(qū)最大使用率）
• DISK_TOTAL_WRITE_KB（可選項(xiàng)）
• DISK_TOTAL_READ_KB（可選項(xiàng)）
• CPU_WAIT_IO（可選項(xiàng)）
• DISK_TOTAL_IO_UTIL（可選項(xiàng)）
• NET_TCP_CURR_ESTAB（可選項(xiàng)）
• NET_TCP_RETRANS（可選項(xiàng)）

徹底解決問(wèn)題不等于自動(dòng)處理問(wèn)題

舉兩個(gè)例子，大家來(lái)分析一下這個(gè)問(wèn)題是否得到徹底解決：

• 如果一個(gè)模塊經(jīng)常崩掉，那么我們可以通過(guò)添加一個(gè)定時(shí)拉起腳本來(lái)解決該問(wèn)題。那這個(gè)模塊崩掉的問(wèn)題解決了嗎？其實(shí)并沒(méi)有，你增加一個(gè)拉起腳本，只是說(shuō)自己不用上機(jī)器去處理了而已，但是模塊為什么經(jīng)常崩掉這個(gè)問(wèn)題，卻并沒(méi)有人去關(guān)注，更別提徹底解決了。
• 如果一個(gè)機(jī)器經(jīng)常出現(xiàn) CPU_IDLE 報(bào)警，那么我們可以將現(xiàn)在的監(jiān)控策略進(jìn)行調(diào)整，比如說(shuō)，以前 5min 內(nèi)出現(xiàn) 5 次就報(bào)警，現(xiàn)在可以調(diào)整為 10min 內(nèi)出現(xiàn) 20 次再報(bào)警，或者直接刪除這個(gè)報(bào)警策略，或者將報(bào)警短信調(diào)整為報(bào)警郵件，或者各種類似的手段。但這個(gè)機(jī)器為什么出現(xiàn) CPU_IDLE 報(bào)警，卻并沒(méi)有人去關(guān)注，更別提解決了。

通過(guò)上面兩個(gè)例子，大家就理解，自動(dòng)化處理問(wèn)題不等于解決問(wèn)題，掩耳盜鈴也不等于解決問(wèn)題，什么叫做解決問(wèn)題，只有是找到問(wèn)題的根本原因，并消滅之，才能確保徹底解決問(wèn)題，輕易不會(huì)再次發(fā)生。還是上面自動(dòng)拉起的例子，如果仔細(xì)分析后，發(fā)現(xiàn)是內(nèi)存泄露導(dǎo)致的進(jìn)程頻繁崩掉，或者是程序 bug 導(dǎo)致的 coredump，那么解決掉這些問(wèn)題，就能夠徹底避免了。

如何解決團(tuán)隊(duì)內(nèi)部的值班排斥情緒

每個(gè)運(yùn)維團(tuán)隊(duì)早晚都會(huì)面對(duì)團(tuán)隊(duì)高工對(duì)值班工作的排斥，這也是人之常情。辛辛苦苦干了幾年了，還需要值班，老婆孩子各種抱怨，有時(shí)候身體狀況也不允許了，都不容易。不同的團(tuán)隊(duì)，解決方式不同，但有些解決方案，會(huì)讓人覺(jué)得，你自己都不想值班，還天天給我們打雞血說(shuō)值班重要。更嚴(yán)重一些的，會(huì)讓團(tuán)隊(duì)成員感受到不公平，憑什么他可以不值班，下次是不是我們大家也可以找同樣的理由呢。

筆者的團(tuán)隊(duì)是這樣明確說(shuō)明的：

• 保證值班人員數(shù)量不低于四人，如果短時(shí)間內(nèi)低于四人，那么就需要將二線工程師短暫加入一線值班工作中，為期不超過(guò)三個(gè)月。
• 對(duì)于希望退出值班列表的中級(jí)工程師，給三個(gè)月不值班時(shí)間，如果能將目前的報(bào)警短信數(shù)量?jī)?yōu)化 20%-50%，則可以退出值班序列，但如果情況反彈，則需要重回值班工作。
• 團(tuán)隊(duì)達(dá)到一定級(jí)別的工程師，就可以轉(zhuǎn)二線，不參與日常值班工作，僅接收核心報(bào)警，且對(duì)核心報(bào)警的有效性負(fù)責(zé)，若服務(wù)故障核心報(bào)警未發(fā)出，則每次罰款兩百。
• 團(tuán)隊(duì)負(fù)責(zé)人不參與值班工作，但需要對(duì)單日?qǐng)?bào)警數(shù)量負(fù)責(zé)，如果當(dāng)周的日?qǐng)?bào)警數(shù)量大于要求值，則每次罰款兩百元。如果團(tuán)隊(duì)成員數(shù)量低于四人時(shí)，則需要加入值班列表。

寫(xiě)在最后

在團(tuán)隊(duì)的報(bào)警量有了明顯減少后，就需要對(duì)報(bào)警的準(zhǔn)確性和召回率進(jìn)行要求了，從而才能持續(xù)的進(jìn)行報(bào)警優(yōu)化工作。所謂的準(zhǔn)確性，也就是有報(bào)警必有損，而召回率呢，則是有損必有報(bào)警。

最后，祝愿大家都不在因?yàn)橹蛋喙ぷ鞫鄲溃?nbsp;