掌握這些監控報警優化技巧，百萬年薪不在話下！

運維工程師面試者第一個問題是：須要值班嗎？筆者本身也曾經歷過月入十萬的時期，在那個時候，數個系統同時發佈下一代版本，而老系統還須要過渡很長時間，工做量直接翻倍。

圖片來自 Pexels

你們只能勉強應付一線運維工做，團隊成員開始陸續離職，而新人又沒法在短期內上手，總體狀況不斷惡化，持續半年左右才緩過勁來。

下面兩張截圖是我挑選的兩個團隊一週報警數的對比圖，前者的單日報警量最高是 55348 條，後者單日的報警量最高爲 34 條，二者相差 1600 倍，而前者纔是國內不少互聯網運維團隊的真實寫照。

在管理大規模集羣的狀況下，究竟有多少報警量纔是合理的呢？

Google SRE 每週十條故障報警

Google SRE 每週只有十條報警，若是超過十條，說明沒有把無效報警過濾掉（Google SRE 僅負責 SLA 要求爲 99.99% 的服務）。

筆者所在的團隊要求則是，每週至多兩晚有報警，單日報警量不能超過 50 條（比 Google SRE 放水好多啊）。

經過控制單日報警數量，嚴格約束夜間報警天數，確保最少不低於四人蔘與值班。

筆者所在的團隊，近幾年來，不只少有由於值班壓力而離職的同窗，並且咱們每一年都能持續招聘到 985 前 20 名學校的多個研究生。

那麼，怎麼作到呢，如下是筆者的一些經驗分享。

運維工程角度看報警優化

①報警值班和報警升級

基於值班表，天天安排兩人進行值班處理報警，將值班壓力從全團隊壓縮在兩人範圍內，從而讓團隊可以有足夠的時間和人力進行優化工做。

同時，爲了不兩個值班人員都沒有響應報警，可使用報警升級功能，若是一個報警在 5min 內值班人員均未響應，或者 15min 內未處理完畢，或者有嚴重故障發生，均可以將報警進行升級，通告團隊其餘成員協助處理。

若是公司的監控系統暫不支持值班表功能，則經過人工按期修改報警接收人的方式進行。

而對於監控系統不支持報警升級的問題，經過自行開發腳本的方式，也能在必定程度上獲得解決。

也能夠將報警短信發送至商業平臺來實現。總之一句話，辦法總比問題多。

對於報警值班人員，須要隨時攜帶筆記本以方便處理服務故障，這個要求，和報警數量多少以及報警的自動化處理程度並沒有關係，僅和服務重要性有關。

對於節假日依然須要值班的同窗，公司或者部門也應該儘可能以各類方式進行補償。

②基於重要性不一樣，分級應對

一個問題請你們思考一下，若是線上的服務器所有掉電後以短信方式通知值班人員，那麼線上一臺機器的根分區打滿，也經過短信來通知是否有必要。

上述的問題在平常工做也屢屢發生，對於問題、異常和故障，咱們採起了一樣的處理方式，所以產生了如此多的無效報警。

Google SRE 的實踐則是將監控系統的輸出分爲三類，報警、工單和記錄。

SRE 的要求是全部的故障級別的報警，都必須是接到報警，有明確的非機械重複的事情要作，且必須立刻就得作，才能叫作故障級別的報警。其餘要麼是工單，要麼是記錄。

在波音公司裝配多個發動機的飛機上，一個發動機熄火的狀況只會產生一個」提醒「級別的警示（最高級別是警報，接下來依次是警告、提醒、建議），對於各類警示，會有個檢查清單自動彈出在中央屏幕上，以引導飛行員找到解決方案。

若是是最高級別的警報，則會以紅色信息，語音警報，以及飛機操縱桿的劇烈震動來提示。若是這時你什麼都不作，飛機將會墜毀。

③故障自愈

重啓做爲單機預案，在不少業務線，能夠解決至少 50% 的報警。沒有響應，重啓試試，請求異常，重啓試試，資源佔用異常，重啓試試，各類問題，重啓都屢試不爽。

換言之，針對簡單場景具備明確處置方案的報警，自動化是一個比較好的解決方案，可以將人力從大量重複的工做中解放出來。

自動化處理報警的過程當中，須要注意如下問題：

• 自動化處理比例不能超過服務的冗餘度（默認串行處理最爲穩妥）。

• 不能對同一個問題在短期內重複屢次地自動化處理（不斷重啓某個機器上的特定進程）。

• 在特定狀況下能夠在全局範圍內快速終止自動化處理機制。

• 儘可能避免高危操做（如刪除操做、重啓服務器等操做）。

• 每次執行操做都須要確保上一個操做的結果和效果收集分析完畢（若是一個服務重啓須要 10min）。

④報警儀表盤，持續優化 TOP-3 的報警

以下圖示，整年 TOP-3 的報警量佔比達到 30%，經過對 TOP-3 的報警安排專人進行跟進優化，能夠在短期大幅下降報警量。

TOP-3 只是報警儀表盤數據分析的典型場景之一，在 TOP-3 以後，還能夠對報警特徵進行分析。

如哪些模塊的報警最多，哪些機器的報警最多，哪一個時間段的報警最多，哪一種類型的報警最多，進而進行細粒度的優化。
同時，報警儀表盤還須要提供報警視圖的功能，可以基於各類維度展現當前有哪些報警正在發生，從而便於當短期內收到大量報警，或者是報警處理中的狀態總覽，以及報警恢復後的確認等。

⑤基於時間段分而治之

下圖是國內很是典型的一類流量圖，流量峯值在天天晚上，流量低谷在天天凌晨。

從冗餘度角度來分析，若是在流量峯值有 20% 的冗餘度，那麼在流量低谷，冗餘度至少爲 50%。
基於冗餘度的變換，相應的監控策略的閾值，隨機也應該發生一系列的變化。
舉例來講，在高峯期，可能一個服務故障 20% 的實例，就必須介入處理的話，那麼在低谷期，可能故障 50% 的實例，也不須要當即處理，依賴於報警自動化處理功能，逐步修復便可。
在具體的實踐中，一種比較簡單的方式就是，在流量低谷期，僅接收故障級別的報警，其他報警轉爲靜默方式或者是自動化處理方式，在流量高峯期來臨前幾個小時，從新恢復，這樣即便流量低谷期出現一些嚴重隱患，依然有數小時進行修復。
這種方式之因此大量流行，是由於該策略可以大幅減小凌晨的報警數量，讓值班人員可以正常休息。

⑥報警週期優化，避免瞬報
在監控趨勢圖中，會看到偶發的一些毛刺或者抖動，這些毛刺和抖動，就是形成瞬報的主要緣由。
這些毛刺和抖動，至多定義爲異常，而非服務故障，所以應該以非緊急的通知方式進行。
以 CPU 瞬報爲例，若是設置採集週期爲 10s，監控條件爲 CPU 使用率大於 90% 報警，若是設置每次知足條件就報警，那麼就會產生大量的報警。
若是設置爲連續 5 次知足條件報警，或者連續的 10 次中有 5 次知足條件就報警，則會大幅減小無效報警。

對於重要服務，通常建議爲在 3min 內，至少出現 5 次以上異常，再發送報警較爲合理。

⑦提早預警，防患於未然
對於不少有趨勢規律的場景，能夠經過提早預警的方式，下降問題的緊迫程度和嚴重性。
下圖是兩臺機器一週內的磁盤使用率監控圖，能夠預見，按照目前的增加趨勢，必然會在某一個時間點觸發磁盤剩餘空間 5% 的報警。

能夠在剩餘空間小於 10% 的時候，經過工單或者其餘非緊急方式提醒，在工做時間段內，相對從容的處理完畢便可，畢竟 10% 到 5% 仍是須要一個時間過程的。

⑧平常巡檢
提早預警面向的是有規律的場景，而平常巡檢，還能夠發現那些沒有規律的隱患。
以 CPU 使用率爲例進行說明，近期的一個業務上線後，CPU 使用率出現偶發突增的狀況，可是沒法觸發報警條件（例如 3 分鐘內有 5 次使用率超過 70% 報警），所以沒法經過報警感知。
聽任無論的話，只能是問題足夠嚴重了，才能經過報警發現。
這個時候，若是天天有例行的巡檢工做，那麼這類問題就可以提早發現，儘快解決，從而避免更加嚴重的問題發生。

⑨比例爲主，絕對值爲輔
線上機器的規格不一樣，若是從絕對值角度進行監控，則沒法適配全部的機器規格，勢必會產生大量無心義的報警。

以磁盤剩餘空間監控爲例，線上規格從 80GB 到 10TB 存在多種規格，從下圖表格看，比例比絕對值模式能更好的適配各類規格的場景（EXT4 文件系統的默認預留空間爲 5%，也是基於比例設置的並可經過 tune2fs 進行調整）。

對於一些特殊場景，一樣以磁盤剩餘空間爲例進行說明，例如計算任務要求磁盤至少有 100GB 以上空間，以供存放臨時文件。

那這個時候，監控策略就能夠調整爲：磁盤剩餘空間小於 5% 報警且磁盤剩餘空間絕對值小於 100GB 報警。
⑩Code Review
前人埋坑，後人挖坑。在解決存量問題的狀況下，不對增量問題進行控制，那報警優化，勢必會進入螺旋式緩慢上升的過程，這對於報警優化這類項目來講，無疑是致命的。
經過對新增監控的 Code Review，可讓團隊成員快速達成一致認知，從而避免監控配置出現千人千面的狀況出現。
⑪ 沉澱標準和優秀實踐
僅僅作 Code Review 還遠遠不夠，一堆人開會，面對一行監控配置，大眼瞪小眼，對不對，爲何不對，怎麼作更好？你們沒有一個標準，進而會浪費不少時間來進行不斷的討論。
這時候，若是有一個標準，告訴你們什麼是好，那麼有了評價標準，不少事情就比較容易作了。
標準自己也是須要迭代和進步的，所以你們並不須要擔憂說個人標準不夠完美。
基於標準，再給出一些最佳的監控時間，那執行起來，就更加容易了。 以機器監控爲例進行說明，機器監控必須覆蓋以下的監控指標，且閾值設定也給出了優秀實踐。

具體以下：

• CPU_IDLE < 10

• MEM_USED_PERCENT > 90

• NET_MAX_NIC_INOUT_PERCENT > 80 （網卡入口/出口流量最大使用率）

• CPU_SERVER_LOADAVG_5 > 15 

• DISK_MAX_PARTITION_USED_PERCENT > 95 （磁盤各個分區最大使用率）

• DISK_TOTAL_WRITE_KB（可選項）

• DISK_TOTAL_READ_KB（可選項）

• CPU_WAIT_IO（可選項）

• DISK_TOTAL_IO_UTIL（可選項）

• NET_TCP_CURR_ESTAB（可選項）

• NET_TCP_RETRANS（可選項）

⑫完全解決問題不等於自動處理問題

舉兩個例子，你們來分析一下這個問題是否獲得完全解決：
若是一個模塊常常崩掉，那麼咱們能夠經過添加一個定時拉起腳原本解決該問題。
那這個模塊崩掉的問題解決了嗎？其實並無，你增長一個拉起腳本，只是說本身不用上機器去處理了而已，可是模塊爲何常常崩掉這個問題，卻並無人去關注，更別提完全解決了。
若是一個機器常常出現 CPU_IDLE 報警，那麼咱們能夠將如今的監控策略進行調整。
好比說，之前 5min 內出現 5 次就報警，如今能夠調整爲 10min 內出現 20 次再報警，或者直接刪除這個報警策略，或者將報警短信調整爲報警郵件，或者各類相似的手段。
但這個機器爲何出現 CPU_IDLE 報警，卻並無人去關注，更別提解決了。
經過上面兩個例子，你們就理解，自動化處理問題不等於解決問題，掩耳盜鈴也不等於解決問題，什麼叫作解決問題，只有是找到問題的根本緣由，並消滅之，才能確保完全解決問題，輕易不會再次發生。
仍是上面自動拉起的例子，若是仔細分析後，發現是內存泄露致使的進程頻繁崩掉，或者是程序 Bug 致使的 Coredump，那麼解決掉這些問題，就可以完全避免了。

如何解決團隊內部的值班排斥情緒

每一個運維團隊遲早都會面對團隊高工對值班工做的排斥，這也是人之常情。
辛辛苦苦幹了幾年了，還須要值班，老婆孩子各類抱怨，有時候身體情況也不容許了，都不容易。
不一樣的團隊，解決方式不一樣，但有些解決方案，會讓人以爲，你本身都不想值班，還每天給咱們打雞血說值班重要。
更嚴重一些的，會讓團隊成員感覺到不公平，憑什麼他能夠不值班，下次是否是咱們你們也能夠找一樣的理由呢。
筆者的團隊是這樣明確說明的： 保證值班人員數量不低於四人，若是短期內低於四人，那麼就須要將二線工程師短暫加入一線值班工做中，爲期不超過三個月。

對於但願退出值班列表的中級工程師，給三個月不值班時間，若是能將目前的報警短信數量優化 20%-50%，則能夠退出值班序列，但若是狀況反彈，則須要重回值班工做。
團隊達到必定級別的工程師，就能夠轉二線，不參與平常值班工做，僅接收核心報警，且對核心報警的有效性負責，若服務故障核心報警未發出，則每次罰款兩百。

團隊負責人不參與值班工做，但須要對單日報警數量負責，若是當週的日報警數量大於要求值，則每次罰款兩百元。若是團隊成員數量低於四人時，則須要加入值班列表。

寫在最後

在團隊的報警量有了明顯減小後，就須要對報警的準確性和召回率進行要求了，從而才能持續的進行報警優化工做。
所謂的準確性，也就是有報警必有損，而召回率呢，則是有損必有報警。
最後，祝願你們都不在由於值班工做而苦惱！