Observability Maturity Framework¶
概念概覽
雙維度評估框架¶
核心知識¶
雙維度評估框架¶
現況能力分數（Current State Score）與行動優先順序（Action Priority）是兩個獨立維度，不能混用： - 修復成本低 ≠ 缺口不嚴重 - 裝了 Tempo/Loki/Grafana ≠ 觀測鏈路閉環
核心判斷標準：鏈路是否端到端閉環——OTEL endpoint 是否到叢集、middleware 是否把 trace_id 注入 log、log 是否有 structured fields 可供 LogQL 查詢。
兩層式行動路線圖¶
Layer 1（today fixes，低成本高槓桿）：
- game-server middleware 順序修正
- logging 補 trace_id/user_id
- admin 補 tracing middleware
- Infra OTEL endpoint 從 localhost 改到 tempo.monitoring:4318
- Promtail JSON pipeline_stages 讓 request_id/trace_id 可 LogQL 查詢
Layer 2（成熟度項目，現在不做但不能把未來做死）： - incident lookup 工具 - replay artifacts - synthetic trace CI gate - 現在要確保 structured log schema 設計好，否則之後補工具需要重構 log format
驗收標準量化¶
- 任一玩家回報：15 分鐘內從 user_id 收斂到具體 pod + trace
- critical 故障：10 分鐘內自動告警到真實 on-call
經驗教訓¶
-
不要用修復成本來低估缺口嚴重性——trace transport 只是改一行 config，但讓 dev tracing 完全不可靠
-
Layer 2 項目現在不做，但現在要避免把未來做死：先設計好介面和資料欄位 schema
-
battle-validator 在從 Noop 變成真實 gRPC client 之前，不要列入第一波 tracing 優先項
常見陷阱¶
-
系統裝了觀測元件但 OTEL endpoint 仍是 localhost，整條鏈路形同虛設
-
忘記在 Grafana query 加 environment filter 時，共用 Tempo 會看到混合多環境資料
最佳實踐¶
-
驗收標準要量化（分鐘數 + 具體動作），而非模糊的「可觀測性提升」
-
多環境 tracing 共用同一 Tempo + environment label 隔離，比部署三套 Tempo 更省維護成本
-
診斷時先確認 OTEL endpoint 是否到叢集，這是最大單點阻塞
相關概念¶
- Alertmanager ExternalSecret
- EKS Node Group Migration Runbook
- Go Middleware Chain Ordering
- OpenTelemetry Trace Pipeline
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Game Item Exemption Resource Architecture — 共享：
game-backend/ 獨特：architecture-pattern,item-system
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-24 | 6295486a-8e60-49c7-a5da-f375c806641a | 建立「現況評分 vs 行動優先順序」雙維度框架，並量化 Go 遊戲後端從 60 分到 95 分的具體缺口與兩層式行動路線圖 |