從被動回應到主動預防#

上一章我們建立了充足的生產遙測來看到和解決問題。本章將更進一步——建立工具和技術，讓我們能發現遙測中隱藏的異常和越來越微弱的故障信號，在災難性故障發生之前就加以預防。

案例：Netflix 的離群值偵測#

Netflix 在 2015 年擁有 75 億美元營收和 7,500 萬用戶，需要穩健、可擴展且具韌性的交付基礎設施。Roy Rapoport 描述了管理 Netflix 雲端影片交付服務的挑戰：「在一群應該看起來一樣、行為一樣的牛群中，哪頭牛看起來跟其他的不同？」

離群值偵測（Outlier Detection）#

Netflix 在 2012 年採用了離群值偵測技術，定義為偵測「可能導致嚴重效能降級的異常運行狀態」。

其做法非常簡單：

1. 先計算叢集中節點群組目前的「正常」狀態
2. 識別哪些節點不符合該模式
3. 將不符合的節點從生產環境中移除

Rapoport 表示：「我們可以自動標記行為異常的節點，甚至不需要定義什麼是『正確』的行為。由於我們的設計具備雲端韌性，我們只需直接終止異常的運算節點，然後記錄日誌或通知工程師。」

透過實施 Server Outlier Detection 流程，Netflix 大幅減少了尋找和修復異常伺服器的工作量，提升了服務品質。Rapoport 強調，使用這些技術來維護員工的理智、工作與生活平衡以及服務品質的好處「怎麼強調都不為過」。

使用平均值和標準差偵測潛在問題#

分析生產指標最簡單的統計技術之一，是計算指標的平均值（mean）和標準差（standard deviations）。透過這些數據，我們可以建立篩選器，在指標顯著偏離常態時進行偵測，甚至配置告警以採取矯正措施。

告警疲勞問題#

John Vincent 觀察到：「告警疲勞是我們目前面臨的最大問題……我們需要讓告警更智慧，否則我們都會瘋掉。」當告警不可操作或是誤報時，我們就是在不必要地在半夜叫醒人。

利用高斯分佈設定告警#

當資料呈現高斯分佈（常態分佈）時，我們可以利用標準差來設定告警閾值：

• 1 個標準差包含 68% 的資料
• 2 個標準差包含 95% 的資料
• 3 個標準差包含 99.7% 的資料

例如，我們可以設定當每日未授權登入嘗試次數超過平均值 3 個標準差時觸發告警。在高斯分佈下，預期只有 0.3% 的資料點會觸發此告警。

即使是這種簡單的統計分析也很有價值，因為不需要任何人去定義靜態閾值——在追蹤成千上萬個生產指標時，手動設定閾值是不可行的。

針對非預期結果進行檢測和告警#

Tom Limoncelli（前 Google SRE、The Practice of Cloud System Administration 共同作者）分享了一個關於監控的故事：

在理想世界中，我們會刪除監控系統中的所有告警。然後在每次使用者可見的中斷後，反思什麼指標能預測到這次中斷，並將其加入監控系統。重複這個過程。最終我們就只有預防性告警，而非事後告警。

實踐方法#

分析最近（例如 30 天內）最嚴重的事故，建立一份能實現以下目標的遙測清單：

• 更早偵測和診斷問題
• 更快確認修復已有效實施

例如，如果 NGINX Web 伺服器停止回應，我們會檢視哪些前導指標能更早警告我們：

• 應用程式層級：網頁載入時間增加
• 作業系統層級：伺服器可用記憶體不足、磁碟空間不足
• 資料庫層級：交易時間異常偏長
• 網路層級：負載平衡器後方可運作的伺服器數量下降

對這些指標中的每一個，我們都配置告警系統在偏離平均值到一定程度時通知我們。透過反覆對越來越微弱的故障信號執行此流程，我們能越來越早地在生命週期中發現問題，減少影響客戶的事故。

非高斯分佈的遙測數據問題#

使用平均值和標準差來偵測異常非常有用，但在許多營運資料集上，這些技術可能無法產生預期結果。

Dr. Toufic Boubez 觀察到：「不僅會在凌晨 2 點接到警報電話，還會在 2:37、4:13、5:17 接到。這是因為我們監控的底層資料不是高斯分佈。」

當資料集的分佈不呈現高斯鐘型曲線時，與標準差相關的性質就不適用。例如，監控網站每分鐘的檔案下載次數時，如果我們想偵測異常高的下載量（如超過平均值 3 個標準差），但資料不是常態分佈，就會產生大量誤報。