「無法量測就無法改進」。Google 用內部工具 Outalator 被動接收所有監控告警，並提供註解、分組、分析能力——把零散的告警串成「事件」與「趨勢」。

事後檢討（postmortem）解決「單一重大事件」的深入學習；但有些問題單次衝擊不大、卻頻繁且分散——事後檢討觸及不到。Outalator 補上的就是「跨事件、跨團隊的長期視角」。

它能回答：

• 本團隊每輪 On-Call 收到多少告警？
• 上季 actionable / nonactionable 告警比例？
• 哪個服務製造最多瑣事？

Escalator：所有告警的轉運站#

Google 所有 SRE 告警通知共用一個中央複製系統 Escalator。它追蹤「人是否已 ack」，若超過設定時間沒人接，自動升級到下一目的地（如主 → 副）。

設計上對既有工作流近乎透明——接收寄到 On-Call alias 的郵件複本，不需要使用者或監控系統改行為。

Outalator：在 Escalator 之上的「事件層」#

Outalator 把 Escalator 的「個別告警」抽象成「事件」：

• 多個佇列的告警交織顯示，不必手動切換
• 儲存原始通知並允許註解
• 自動收存所有 email 回覆
• 可標記「重要」註解：其他內容折疊以減少雜訊

合併告警為事件#

單一事件常觸發多個告警（網路故障 → 所有下游 timeout）。

用 Outalator 把多個告警合併為單一 incident：

• 解開「事件 per 日」與「告警 per 日」兩個指標
• 避免重複 debug 與恐慌
• 比一封封寄「這跟另一個是同一件事」的 email 可規模化

標籤（Tags）#

Outalator 本身不區分「假陽性」「測試事件」「真實事件」——以通用標籤處理。看似簡單，卻是 Outalator 最強大的功能之一。

設計巧思：

• 自由格式單字
• 冒號被解釋為語意分隔，自然鼓勵層級命名空間（如 cause:network:switch vs. cause:network:cable）
• 建議的標籤前綴依團隊歷史使用自動學習（如「cause」「action」，某團隊常用「customer」就會推薦）
• 可解析為連結（bug:76543 自動連到 bug tracker）
• 即使打錯字（cause:netwrok）或不太有用（problem-went-away），允許自由標籤比預設清單能蒐集到更真實的資料

分析的層次#

故障追蹤工具的價值不是「重做」，而是讓歷史可被分析。

逐層加深：

1. 基本計數與聚合：每週／月／季事件數、每事件告警數
2. 跨團隊與時間比較：「本週第三次」是好是壞？要看歷史是「每天 5 次」還是「每月 5 次」
3. 語意分析找系統性問題：找出造成最多事件的基礎建設元件——若提升其穩定性就能跨團隊受惠
4. 打破過度敏感的監控：有些「事件」其實是 SLO 內、只是監控太敏感 → 可考慮故意製造一些失敗讓系統不過度承諾

報告與溝通#

• 從介面挑選 outalation → 把主旨、標籤、重要註解打包寄給下一輪 On-Call
• 報告模式：把重要註解就地展開，提供當週低光時刻的快速總覽（多數團隊每週做生產審視）

意外的好處#

Outalator 的副作用之一是跨團隊可見度：

• 看到「Bigtable 似乎是元凶但 Bigtable SRE 沒被告警」→ 手動通知對方
• 事件解決或緩解速度顯著提升

有些團隊甚至設「假的 Escalator 配置」——通知不會打給人，但會出現在 Outalator 裡，可被標記、註解、回顧：

• 紀錄與審計特權帳號使用
• 自動標註週期性非冪等作業（如自動套用 schema 變更）

自建 Outalator 的提示#

多數組織以 Slack、Hipchat、IRC 做內部溝通與儀表板——這些地方都是 Outalator 風格系統的最佳整合點。