軟體工程師該如何做好監控 (monitoring)？

很多人可能會覺得，監控與事故處理，不是應該屬於 SRE (Site Reliability Engineer 又稱網站可靠性工程師) 的範疇嗎? 在過去確實是這樣子，但近幾年趨勢的改變下，多數公司也都抱持著開發者要第一線處理事故的做法。

先前 Increment 有做一份調查 (連結)，結果發現包含 Amazon、Dropbox、Meta、Google 還有 Netflix 等公司，現在基本上都是開發者負責監控與輪班處理事故。

這是因為如果跟應用層相關的問題，仍是開發者最了解，如果是進到應用層的問題，SRE 處理不了的話，最終也需要拉開發者來解決問題，所以多數公司仍需要軟體工程師來參與監控、輪班，以及處理的事故。

因此，身為開發者，對於監控、輪班處理事故等主題，仍需要有所掌握，而本篇會先從監控開始談。

監控什麼? 為什麼要監控?

所謂的監控，就是針對系統整體、各部分的持續觀察，藉由搜集不同指標的資料，來判斷系統目前是否有異狀。透過監控，我們能夠提早發現問題，而不是等使用者端回報問題後才發現。這邊提到的發現問題，可能包含系統有故障、系統有潛在的效能問題，或者是系統的使用量到達上限需要進一步擴展。

舉例來說，我們可以透過埋點，持續觀察每天的使用者流量，如果平常每天系統的使用者流量為 1 萬，但某天突然暴增成 100 萬，這種反常的狀況，就代表有可能某些不對勁的事情正在發生 (例如網站正在被 DDoS 攻擊)，而工程師就可以進一步去排查問題。

如果沒有監控，不知道網站流量突然飆高，也就沒辦法第一時間跳下去排查，很可能要等到災情傳出後，才能被動地去回應問題 (例如被 DDoS 後，使用者跟客服說進不去網站，客服再反應給工程團隊，這樣就會慢半拍)。

要監控就需要有指標

想要做好監控，就必須知道要監控什麼。而監控的東西，我們又會稱為指標 (metrics)，如果該觀察的指標沒有觀察，那很可能的導致出問題後不自知。

Google 的 SRE 專書 (連結) 提到，有四個推薦一定要看的指標 (當然，每個系統可能因為有不同的元件，所以需要監控不同的指標，最推薦的做法，是拆解系統的各個部分，然後確保該監控的都有覆蓋到)。

• 延遲度 (效能)：
  • 拆解每一段的耗時 (延遲度)，從前端到後端
• 流量：
  • UV / PV (UV 是看使用者，而 PV 是看頁面)
  • QPS 波動 (QPS 是看請求量)
• 錯誤 (穩定性)：
  • 錯誤率
  • 成功率 (或失敗率)
  • 正常執行時間 (uptime)
• 飽和度 (資源使用率)：
  • CPU 使用率
  • 記憶體使用率
  • 網路頻寬使用率

這邊特別提在看效能指標時，要先注意先行指標。舉例來說，慢查詢、消息堆積可能會導致後面的請求無法被處理，就會引發後續的其他警報被觸發，所以這種先行指標要先注意。

另外，效能指標的監控，推薦要監控百分位數，例如 P50、P90、P95、P99、P99.9。所謂的百分位數，就是指多少比例的請求在這個百分位數當中。舉例來說，頁面加載 P90 的延遲度是 1 秒鐘，表示有 90% 的使用者都在 1 秒鐘內完成加載 (有 10% 的使用者，超過 1 秒才完成加載)。

會推薦這樣看，是因為這能讓我們更清楚整體與極端的狀況。特別在使用者量級大的狀況，百分之一也是很多人，如果不看 P90，只看中位數或平均，很可能會以為效能很好，殊不知其實有不少人在用的時候效能很不好

監控警報需要有等級設定

在做監控時，一般都會加上自動的警報 (alert)，當某些特定的條件發生時，會觸發警報，通知工程團隊要去注意與排查問題。

舉例來說，假如原本某個 API 的請求成功率是 99.99% 以上，團隊設定警報為成功率低於 95% 就會發送警報。這時如果某天突然跌到 80%，那監控系統就會發出警報，讓團隊知道有異常狀況。

然而，在設定警報時，推薦要設定等級。在業界有所謂的服務水準協議 (Service Level Agreement，也就是大家常聽到的 SLA ) 設定，其中「響應時間承諾」也會在 SLA 的規範中。舉例來說，在 SLA 中可能會寫，對於客戶的服務請求的響應，不得超過 12 小時。

一般來說，如果沒有達到 SLA，是會有相對應的罰則或補償。例如 Google Cloud 就有寫出，如果沒有達到，會給 Google Cloud 的免費使用額度 (連結)。

當然，不是所有的問題都該視為均等，例如 API 請求成功率跌到 95%，跟跌到 20%，兩者嚴重性不同，該給予的關注度，以及響應時間也會不同。身為工程師，需要有效辨別什麼該優先響應。

在業界普遍會用分級的方式，來為不同的監控警報分級。舉例來說會用 P0、P1，等以此類推。所謂的 P 是指 Priority，也就是優先順序的意思。一般來說，P0 是最重要的項目 (有些公司會是定義，常態時期最重要的是 P0，而臨時遇到緊急且重要的，會是 P00。只有真的出現 P00 的緊急任務時，才能夠中斷 P0 項目來把人力與資源投入在 P00 事情上。)。 P1 是次重要，然後再來是 P2、P3 以此類推。

又另一種分法是用 SEV，而 SEV 是指 Severity，也就是嚴重性的問題。而 SEV-1 會是最嚴重 (例如客戶的資料丟失)，而 SEV-2 會是次嚴重 (例如某個功能不能用)，而 SEV-3 會是輕微嚴重度，以此類推下去。

依據不同監控指標的優先級，我們也會定義不同的嚮應時間與解決時間：

• 響應時間: 所謂的響應時間，是指當收到監控的警報後，隔了多久才回應收到警報。一般業界會用 Ack 來表示，所謂的 Ack 是 Acknowledge 的簡寫，意思就是指「收到了」。以下表為例，如果是 P0 的監控警報響了，負責值班的團隊就需要在一分鐘內回應說收到了。但假如是 P2 的監控警報響了，那麼晚一點回應收到了也相對不要緊。

• 解決時間: 而解決時間則是當警報開始，到問題實際被解決的時間。實際被解決是指在生產環境中問題不再存在。一般來說，即使是透過臨時的解決方案，只要能先確保線上問題被解決，即使不是縝密的解決方案也沒關係。通常會先確保問題能快速被解決，讓線上的損害不繼續擴大，然後才去重新設計更縝密的解決方案。

備註：下面這張表是參考範例，不同團隊的 SLA 設置可能不同，推薦可以根據自己團隊所在的脈絡來設定。

當監控發出警報時，該如何處理?

前面談到了監控會設置警報，而如果某天警報響了後，該如何處理呢?

首先要響應，一般來說相關的監控系統發出警報時，會有一個可以點的按鍵，點下去會發送 Ack 代表負責的人有收到並著手處理。

在點完 Ack 後，要接著判斷異常是屬於什麼等級的異常，然後實際查詢來判斷是否真的有問題。如果是偽陽性 (false positive)，要去思考是否調整監控的閾值；如果是真的出問題，則著手排查，處理過程如果發現是新上線的問題導致，第一時間要回滾，同時要通告相關人員。

在處理事故的過程，有一個務必要放在腦中的觀念是「時時通報」，讓相關人員都能知道目前處理的最新狀況。解決完問題後，在群組通報相關人員問題已排除，請相關人員協助二次確認。而如果是有一定影響力的事故，在解決完問題後，要開事故檢討會議。

如果你對於監控這主題，想了解更深入，歡迎加入 E+ 成長計畫 (連結)。我們在 E+ 有更深入的版本包含討論如何降低無效噪音、如何避免警報疲乏 (alert fatigue) 與警報風暴 (alert storms)

相關文章

• 軟體工程師該如何值班 (on-call)?