可觀測性與事故處理
讓系統的內部狀態透過外部訊號顯現，並在出問題時有方法止血與復原
讓系統的內部狀態透過外部訊號顯現，並在出問題時有方法止血與復原
Monitoring 與 Observability
| Monitoring | Observability |
|---|---|
| 監看已知問題與預設指標 | 從輸出推論未知的內部狀態 |
| 「CPU 是否過高？」 | 「為什麼某類請求突然變慢？」 |
| Dashboard、threshold、alert | 可探索的 log、metrics、trace 與 context |
三種主要訊號
- Log：某個時間點發生了什麼事件
- Metrics：一段時間內的數值與趨勢
- Trace：一個請求跨模組與服務的完整路徑
- Profile：CPU、memory、I/O 的實際消耗位置
- Business event：使用者與領域流程是否正常
Log 要留下什麼？
- Timestamp、severity、service、environment、version
- Request／trace／correlation ID
- 操作、結果、錯誤類型與必要 context
- 結構化欄位，避免只能搜尋自然語句
- 不記錄 password、token、個資與不必要 payload
Metrics 與常見指標
- Rate：請求、事件、工作量
- Error：失敗數量與比例
- Duration：latency 與分位數
- Saturation：CPU、memory、queue、connection pool
- Golden Signals、RED、USE method
- Counter、gauge、histogram 與 label cardinality
Distributed Trace
一個 request / trace
├─ API span
├─ service span
├─ database span
└─ external API span用 trace ID 串起跨服務延遲、錯誤與依賴關係。
SLI、SLO 與 SLA
- SLI：實際量測的服務指標
- SLO：團隊希望達成的可靠度目標
- SLA：對外承諾與可能的責任
- Error budget：允許失敗的空間
- SLO 應從使用者可感受的結果出發
Dashboard 與 Alert
- Dashboard 用來看狀態、趨勢與關聯
- Alert 應指向需要採取行動的異常
- Symptom-based alert 通常比單一資源閾值更接近使用者影響
- 避免 alert fatigue、重複通知與沒有 owner 的警報
- 每個 alert 應連到 runbook 與必要 context
Incident 的基本流程
偵測 → 宣告 incident → 分級與指揮
→ 止血／降低影響 → 定位與復原
→ 驗證服務恢復 → 對內外溝通
→ Postmortem 與改善追蹤Incident Command
- Incident Commander：控制全局與優先順序
- Operations：執行診斷與修復
- Communications：同步利害關係人與時間線
- Scribe：記錄事件、操作、證據與決策
- 明確 owner，避免所有人同時修改 production
Triage、Mitigation 與 Root Cause
- Triage：先判斷影響、範圍與緊急程度
- Mitigation：先恢復服務，不一定已找出根因
- Root cause analysis：理解條件如何一起造成事故
- Rollback、disable feature、scale、failover、rate limit
- 每次操作都要觀察結果，避免越修越壞
Postmortem
- 事故時間線、影響範圍與偵測方式
- 技術條件、組織條件與防線為何失效
- 哪些事情做得有效，哪些資訊當時缺少
- Action item 要有 owner、期限與可驗證結果
- Blameless 不代表沒有責任，而是不停在指責個人
看到 Agent 診斷問題時
要分辨它引用的是 log、metric、trace、設定還是推測，
並要求時間範圍、版本、查詢條件與支持證據。