延續電商案例：上線後的觀察#

上一節完成上線。新需求繼續湧入，組織必須兼顧迭代與系統穩定。SRE 在維運期觀察 3 ～ 4 個月後，整理出一份觀測性缺口清單。

維運階段發現的問題#

• 部分服務缺少正確的錯誤訊息與日誌
• 部分服務未在程式中加入量測平均回應時間的指標
• 一個關鍵的支付微服務完全沒有效能指標

觀測性的缺口不會立刻外顯，但會在事故時讓 SRE「無從下手」。例如支付服務間歇性失敗、使用者結帳卡住，但 SRE 沒有可量測的數據可分析。

推動可觀測性導向開發（ODD）#

新一輪 SDLC 啟動時，SRE 先一步把觀測性需求帶進設計：

• 建議在程式中加入指標
• 補齊正確的入出點與錯誤碼
• 修正日誌格式與級別

這就是 可觀測性導向開發（Observability-Driven Development, ODD）：把監控納入設計初期，而非事後加上去。

實作階段#

• 開發拿到含資料流、業務流、服務通訊與指標需求的架構文件
• 採敏捷迭代，建置、單元測試、部署到 dev 環境

測試階段#

• QA 執行常規測試
• SRE 加做混沌與效能測試
• 部署到 production 後 SRE 持續監控

上線後 SRE 抓到某關鍵服務回應時間過長。因為指標已內建在程式中，SRE 與開發能立即觀察並修復；MTTR 因此下降，使用者幾乎沒感覺。

為何 ODD 比事後監控更有效#

• 指標是設計的一部份 → 不會被加在錯誤的位置
• 對應錯誤碼與日誌結構在開發期就統一
• SRE 與開發共同擁有量測語彙，協作更順
• 上線後就能「看到全貌」，而非追著問題補儀表板

把觀測性視為「設計的一部份」而非「上線後的選項」。這個轉變可以為 SRE 省下難以估算的事後補救時間。