讓 On-call 沒那麼混亂的可觀測性習慣

好的可觀測性不會讓事故完全消失，但它能明顯降低團隊在事故正發生時，還得花時間問那些最基本問題的機率。

我常把可觀測性看成是一種縮短回應時間的倍增器。如果 traces、logs 與 metrics 結構設計得夠好，同一位工程師就可能在十分鐘內找到問題，而不是花四十分鐘繞圈。

先監測使用者真正走過的路徑

最有價值的遙測資料，應該追蹤真實請求路徑、queue 流程以及依賴呼叫。如果那些資料不能回扣到應用實際行為，只看基礎設施圖表本身通常幫助有限。

對於後端系統，我通常至少希望能把這些層次串在一起看：

• 入口流量或請求速率
• 應用延遲與錯誤率
• 資料庫或快取壓力
• queue 深度與 job 執行時間
• 下游依賴的回應時間

盡早標準化 structured logs

當系統還小時，非結構化 logs 似乎勉強還能用；但隨著服務成長，它們會變得難查、昂貴，而且不同環境之間也很難比對。只要多一點紀律，回報通常會很快出現。

我偏好那些穩定包含 request ID、操作者上下文、部署版本，以及目前執行子系統名稱的 logs。

對真正需要介入的症狀發告警

一個 alert 應該告訴團隊「現在需要介入」，而不是單純表示某張圖動了。如果告警太早、太常，或缺乏上下文，團隊很快就會在心理上把它靜音，即使 pager 仍然在響。

我看過最有效的告警通常有兩個共同點：

• 它們能對應到使用者或操作人員的實際影響
• 它們已經暗示了最應該先檢查的方向

部署脈絡應該在所有地方都看得到

如果正式環境問題在 rollout 後三分鐘開始，那件事應該能在你的遙測工具裡一眼看出來。缺少部署標記會浪費時間，因為工程師只好在事故進行中重新手動拼出發布脈絡。

在以 Kubernetes 為基礎的系統中，我希望 image version、environment、namespace，以及 release event 資訊能同時出現在 dashboard 與 logs 裡。

Dashboard 應該支援推理，而不是只支援觀察

事故期間真正重要的 dashboard，不是最好看的那個，而是能幫一位疲累的工程師一路回答問題，而不必開十二個不同分頁的那個。

這通常代表要把彼此相關的圖表排在一起，並讓依賴關係能在同一個視圖中被看見，而不是按照工具所有權拆開。

真正的成果是更快診斷

很多團隊會把可觀測性工作描述成「提升可見度」。我認為更準確的說法是：它其實是在提升診斷能力。重點不在收集更多訊號，而在於讓下一個困難的正式環境問題更容易被回答。

這才是讓 on-call 在實務上沒那麼混亂的原因。