06 · 統一可觀測性與監控平台
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 17 · 遙測收集基礎設施 | ||||||||
| 17.1 | Alloy 成為唯一收集器，部署於所有來源 | 2026-09-01 | 2026-12-18 | 進行中 | — | SRE · 平台工程 | — | — |
| 17.2 | 所有來源皆有回報，或具名列為例外 | — | 2027-07-16 | 規劃中 | 3.1, 17.1 | SRE · 平台工程 | — | 等待 3.1, 17.1 |
| 17.3 | 管線容量與保留期依實際流量設定 | — | 2027-11-19 | 規劃中 | 17.2 | SRE · 平台工程 | — | 等待 17.2 |
| 18 · 統一監控平台 | ||||||||
| 18.1 | 與服務負責人議定 SLI 與 SLO — 自零開始 | — | 2027-11-19 | 規劃中 | 17.2 | SRE · 平台工程 | — | 等待 17.2 |
| 18.2 | 告警可行動，並對應 SLO | — | 2028-03-10 | 規劃中 | 18.1 | SRE · 平台工程 | — | 等待 18.1 |
| 18.3 | 儀表板即程式碼，而非點出來的 | — | 2028-03-10 | 規劃中 | 14.2, 18.1 | SRE · 平台工程 | — | 等待 14.2, 18.1 |
| 19 · ELK 與 Pinpoint 遷移至 Grafana LGTM | ||||||||
| 19.1 | 應用改以 OpenTelemetry 一次性 instrument | — | 2027-09-10 | 規劃中 | 17.1 | 應用程式開發 | — | 等待 17.1 |
| 19.2 | 新舊並行，逐服務驗證等價 | — | 2028-05-19 | 規劃中 | 18.3, 19.1 | SRE · 平台工程 | — | 等待 18.3, 19.1 |
| 19.3 | Elasticsearch 與 Pinpoint 叢集除役 | — | 2028-11-17 | 規劃中 | 19.2 | SRE · 平台工程 | — | 等待 19.2 |
細節
17.1Alloy 成為唯一收集器，部署於所有來源2026-12-18進行中 · 1/4
- 後端已經存在。剩下的是讓整個環境把資料送過去,而這正是本項目其餘部分要做的事。
- VM 以 systemd、Kubernetes 以 DaemonSet 部署 Alloy負責人 · TBD
- 被 Alloy 取代的 agent 確實移除，而非並存負責人 · TBDAlloy 取代 Prometheus agent、Promtail 與 OTel Collector。留著其中一個,就會有兩個標籤集不同的收集器,而一個自相矛盾的指標比一個缺失的指標更糟。
- 每一筆寫入都標記租戶身分負責人 · TBDX-Scope-OrgID 是租戶之間互不可讀的依據,也是分租戶成本得以呈現的基礎;它必須在收集當下標記,事後補不回來。
17.2所有來源皆有回報，或具名列為例外2027-07-16規劃中 · 0/4
- 3.1 查出未回報 Mimir 的主機補齊，或具名記錄排除原因負責人 · TBD3.1 在建立基線時順帶產出那份清單;這裡是它從一則資料品質註記變成真正被關閉的地方。
- 日誌與追蹤的覆蓋率以與指標相同的方式量測負責人 · TBD指標的覆蓋率看得見,是因為已經有東西在數它。日誌與追蹤在建立同樣的量測之前沒有對應物,所以它們的缺口是看不見,而不是不存在。
- 覆蓋率以可追蹤的數字發布負責人 · TBD
- 完全沒有回報的來源視為待處理事項，而非預設狀態負責人 · TBD監控盲點通常在事故當中被發現 — 那是最糟的時機,也是最糟的發現方式。
17.3管線容量與保留期依實際流量設定2027-11-19規劃中 · 0/4
- 逐訊號量測實際 ingest 流量，而非估算負責人 · TBD
- 實際停掉一個後端以驗證 WAL 緩衝負責人 · TBD沒有人測試過的緩衝,只是設定檔裡的一句宣稱。要測它的理由是:後端故障的當下,正好也是沒有人看得到任何東西的時候。
- 設計已經寫得很詳細;還不知道的是,當某個站點連不上時它會怎麼表現。
18.1與服務負責人議定 SLI 與 SLO — 自零開始2027-11-19規劃中 · 0/4
- 優先訂定 SLO 的服務依使用者影響選擇，而非依容易程度負責人 · TBD
- SLI 依使用者實際感受定義負責人 · TBDCPU 使用率不是 SLI。它容易量測,但它不是團隊以外任何人會察覺到的東西。
- 各 SLO 由負責人書面議定，並附錯誤預算負責人 · TBD
- 錯誤預算用罄時的處置，事先議定負責人 · TBD沒有議定後果的 SLO 只是一張儀表板。後果才是整個機制 — 而且必須在需要它之前議定,因為違反之後的對話就會變成究責。
18.2告警可行動，並對應 SLO2028-03-10規劃中 · 0/4
- 盤點既有告警，刪除無人處理的那些負責人 · TBD一個一直響、一直被忽略的告警,是在訓練人忽略告警;刪掉它是提升安全性,不是降低覆蓋率。
- 告警依症狀與 SLO 消耗速率產生，而非依成因負責人 · TBD以成因為基礎的告警,會為使用者根本沒感覺的狀況發出通知,卻對沒人預料到的故障保持沉默。
- 每個告警都附 runbook 連結與具名負責人負責人 · TBD
- 告警數量前後量測比較負責人 · TBD
18.3儀表板即程式碼，而非點出來的2028-03-10規劃中 · 0/4
- 儀表板於 Git 宣告，由 ArgoCD 收斂負責人 · TBD14.2 讓平台元件改為收斂而非手動套用;儀表板就是其中一個元件。
- UI 上的手動修改予以回報，而非默默保留負責人 · TBD沒有人重建得出來的儀表板,會隨著做它的人一起消失 — 而那通常正是上一次事故中最有用的那一張。
- 將 3.4 的使用率儀表板納入同一套管理負責人 · TBD
- 僅憑 repository 即可在空的 Grafana 重建儀表板負責人 · TBD
19.1應用改以 OpenTelemetry 一次性 instrument2027-09-10規劃中 · 0/4
- 逐應用以 OTel SDK 取代 Pinpoint agent負責人 · TBD
- 結構化日誌帶上 trace id負責人 · TBD就是這一個改動,讓一行日誌能跳到它的追蹤;也是它把三個各自獨立的訊號,變成一幅畫面而不是三個分頁。
- 提供共用函式庫或起始範本，避免各團隊各自重解一次負責人 · TBD
- 與應用團隊議定順序負責人 · TBD這件事屬於應用團隊,不屬於 SRE — 15.3 與項目 26 也是。三個項目同時向同一批人要時間,是這份 roadmap 上最大的協調面,而順序該由他們決定。
19.2新舊並行，逐服務驗證等價2028-05-19規劃中 · 0/4
- 各服務先於新舊兩套並行，之後才關閉任何一邊負責人 · TBD
- 等價的定義是:上個月的事故能在新平台上查得出來負責人 · TBD把儀表板並排比對不算等價 — 它們可以長得一模一樣,卻答不出唯一重要的那個問題。重跑一次真實的調查才是驗證。
- 儀表板與告警以程式碼遷移，而非手動重建負責人 · TBD
- 逐服務簽收，由日後實際使用的團隊確認負責人 · TBD
19.3Elasticsearch 與 Pinpoint 叢集除役2028-11-17規劃中 · 0/4
- 叢集先停止服務，經明訂隔離期後才移除負責人 · TBD把 3.2 對孤兒 VM 的規矩套用到這裡 — 停止服務會讓還在使用的人浮出來,而此時要放回去仍然做得到。
- 刪除任何日誌資料前先確認保留義務負責人 · TBD舊叢集可能一直默默滿足著某項保留要求,而新平台設計時沒有人重述過它。先刪掉,一個合規問題就會變成一個合規缺失。
- 釋出的運算與儲存資源交予項目 03 計算負責人 · TBD項目 03 的里程碑期限為 2026-12-18,遠早於此,因此不建立依賴 — 那條邊會指向未來。但釋出的資源是真實的,仍應計入它們的帳。
- Grafana 成為唯一的查詢去處負責人 · TBD