09 · 應用程式現代化
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 25 · 應用程式容器化 | ||||||||
| 25.1 | 鋪好的路到位:base image、chart 與 CI 範本 | — | 2027-05-21 | 規劃中 | 32.2 | SRE · 平台工程 | — | 等待 32.2 |
| 25.2 | 應用達到容器就緒的條件 | — | 2028-02-25 | 規劃中 | 25.1 | 應用程式開發 | — | 等待 25.1 |
| 25.3 | 每個服務一個映像，由 CI 建置並發布 | — | 2028-05-19 | 規劃中 | 25.2 | SRE · 平台工程 | — | 等待 25.2 |
| 25.4 | 尚不能上 K8s 的應用先在現有 VM 上以容器執行 | 2026-10-01 | 2027-09-17 | 規劃中 | — | SRE · 平台工程 | — | — |
| 25.5 | 所有應用移除 sticky session 依賴 | 2026-10-01 | 2028-02-25 | 規劃中 | — | 應用程式開發 | — | — |
| 26 · 應用程式遷移至 Kubernetes | ||||||||
| 26.1 | 依 25.2 的分類擬定遷移波次 | 2027-03-01 | 2028-02-25 | 規劃中 | 25.2, 25.5 | SRE · 平台工程 | — | 等待 25.2, 25.5 |
| 26.2 | 第二階段經 GitOps 部署、以 canary 切換，並退役 VM | 2027-06-19 | 2028-12-10 | 規劃中 | 26.1, 15.6 | SRE · 平台工程 | — | 等待 26.1, 15.6 |
| 26.3 | 其餘波次完成，未遷移者具名列出 | 2027-11-12 | 2030-02-23 | 規劃中 | 26.2 | SRE · 平台工程 | — | 等待 26.2 |
| 26.4 | goods API Phase 1–10 自 middle 遷出，於 11/11 驗證 | 2026-08-13 | 2026-11-11 | 進行中 | — | 平台工程 · 應用程式開發 | — | — |
| 26.5 | 購物車 middle 遷上 Kubernetes | 2026-11-12 | 2028-02-25 | 規劃中 | — | 平台工程 · 應用程式開發 | — | — |
| 26.6 | 追蹤清單／買過清單遷出系統維運部的叢集 | 2026-11-12 | 2027-02-26 | 規劃中 | — | 平台工程 | — | — |
| 26.7 | goods API Phase 11–12 以 canary 切換 | 2026-11-12 | 2027-03-21 | 規劃中 | 26.4, 15.5 | 平台工程 · 應用程式開發 | — | 等待 26.4, 15.5 |
| 26.8 | middle 縮容 P1（11/11 之後） | 2026-11-12 | 2027-03-21 | 規劃中 | 26.4 | 平台工程 | — | 等待 26.4 |
| 26.9 | middle 縮容 P2（6/18 之後） | 2027-06-19 | 2028-05-18 | 規劃中 | 26.5, 26.7, 26.8 | 平台工程 | — | 等待 26.5, 26.7, 26.8 |
| 30 · API 優先的資料存取 | ||||||||
| 30.1 | 跨應用直連完成盤點，每份資料的擁有者明確 | — | 2027-02-26 | 規劃中 | — | SRE | — | — |
| 30.2 | 契約先於程式，破壞性變更由 CI 擋下 | — | 2027-09-10 | 規劃中 | 30.1, 22.1 | SRE · 平台工程 | — | 等待 30.1, 22.1 |
| 30.3 | 鋪好的路:照範本就能開一個 API，呼叫方身分可追，慣例只有一套 | — | 2028-03-10 | 規劃中 | 30.2 | SRE · 平台工程 | — | 等待 30.2 |
| 30.4 | 影響最小的那份資料先切換，直連授權收回 | — | 2028-09-08 | 規劃中 | 30.3 | 應用程式開發 · SRE | — | 等待 30.3 |
| 30.5 | 無法再核發新的直連授權 | — | 2029-01-12 | 規劃中 | 12.2, 30.1 | SRE | — | 等待 12.2, 30.1 |
細節
25.1鋪好的路到位:base image、chart 與 CI 範本2027-05-21規劃中 · 0/4
- base image 由平台維護與更新，而非各團隊各自複製負責人 · TBD複製出去的 base image 就是一份沒人記得要更新的分支,下一個 CVE 得在跟團隊數量一樣多的地方各修一次。
- 涵蓋常見情境的 chart 範本負責人 · TBD
- 每個服務建置一個映像的 CI job 範本負責人 · TBD
- 有一個團隊在無人協助下完整走過一次負責人 · TBD一條需要平台團隊坐在旁邊才走得完的路,不算鋪好。這條是檢驗前面三項是否真的做到的唯一誠實方式。
25.2應用達到容器就緒的條件2028-02-25規劃中 · 0/5
- 設定來自環境，而非寫進映像負責人 · TBD
- 日誌輸出至 stdout負責人 · TBD寫進本機儲存的日誌會隨容器一起消失,這也是應用無法被自由替換的原因之一 — 而自由替換正是排程器要做的事。
- 健康與就緒探針名實相符負責人 · TBD一個在應用還無法服務時就回 OK 的就緒探針,會把一次滾動更新變成一次故障。
- 盤點中 79 個服務逐一辨識本機狀態，尚無法移除者具名列出負責人 · TBD這一步把整個環境分成三類:已無本機狀態、準備上 Kubernetes;仍持有狀態、落腳 25.4;或根本無法容器化、留在項目 09 的路徑上 —— 最後一類必須具名、寫明原因並經 SRE 核准。這份分類是本里程碑的產出,不是它的輸入,26.1 依它排定波次。
- Office Hour 講容器就緒與設定即程式碼負責人 · TBD
25.3每個服務一個映像，由 CI 建置並發布2028-05-19規劃中 · 0/3
- 由 CI 以平台 base image 建置，不在筆電上建負責人 · TBD
- 20.3 產生的稽核事件記錄誰用哪個 revision 建出哪個產出物;這裡就是它指向的那個產出物。
- 簽章與 SBOM 沿用 15.4 的機制，套用於這些映像負責人 · TBD卡片 25 要求附簽章的 SBOM,而 15.4 於 2027-09-24 才交付那套機制 — 晚於本里程碑。在此強制要求會把容器化推到管線重寫之後,顛倒本項目要維持的順序,因此只載明目標,不建立依賴。
25.4尚不能上 K8s 的應用先在現有 VM 上以容器執行2027-09-17規劃中 · 0/4
- 應用在它現在的 VM 上以容器執行負責人 · TBD就是日後要在 Kubernetes 上跑的同一個映像。搬遷時不必重新打包 —— 改變的只是它被排在哪裡。
- 應用一容器化就可以開始，不必等 25.2 的分類全部完成負責人 · TBD
- 明確記錄為停靠點，而非目的地負責人 · TBD每個應用在本機狀態清除後即離開，轉往項目 26。不講明的話，「容器化跑在 VM 上」會安靜地變成所有難搞應用的永久答案 —— 一次遷移就是這樣以「多出一個沒人選擇的平台」收場。
- 發布走流量層分流，而非叢集工具負責人 · TBD就發布而言，不論打包成什麼，它們都是 VM 工作負載，因此由 15.2 承接。
25.5所有應用移除 sticky session 依賴2028-02-25規劃中 · 0/4
- 各應用說明是否把使用者綁在某一個實例上負責人 · TBD
- session 移到共用儲存或改用 token；負載均衡與 gateway 上的 affinity 拿掉負責人 · TBD把使用者綁在某一台的應用無法水平擴展、滾動更新或驅逐時會把使用者登出，也無法依權重切換。
- 驗證：砍掉任一實例，沒有使用者被登出、操作不中斷負責人 · TBD
- Office Hour 講為什麼與怎麼做負責人 · TBD
26.1依 25.2 的分類擬定遷移波次2028-02-25規劃中 · 0/7
- 僅將已無本機狀態的應用納入波次負責人 · TBD
- 仍依賴 sticky session 的應用不納入波次負責人 · TBD前置是 25.5；帶著它進波次，依權重切換時就會把使用者登出。
- 仍持有狀態者留在 25.4 並具名列出負責人 · TBD
- 波次順序依影響範圍排定，最小者優先負責人 · TBD與 2.1 為 IaC 重建訂下的規矩相同 —— 先在可復原的對象上驗證做法，再處理其餘服務所依賴的服務。
- 各波次明訂進入與結束條件，對齊 6/18、11/11 切點負責人 · TBD
- 波次涵蓋盤點中的每一個服務 —— 1796 台主機上的 79 個服務；依業務域的波次順序在此排定負責人 · TBD基準是「現行系統盤點」（架構，快照 2026-09-21）。不在任何波次裡的服務，要不是經 SRE 核准的例外，就是計畫的缺口。
- 各服務由負責人確認能否地端與雲端並行；確認結果決定其波次以哪座叢集為目標負責人 · TBD
26.2第二階段經 GitOps 部署、以 canary 切換，並退役 VM2028-12-10規劃中 · 0/5
- 經 GitOps 部署，不由人執行負責人 · TBD
- 任何流量切換之前先新舊並行負責人 · TBD
- 流量以 canary 切換（15.6）負責人 · TBD
- 由應用團隊自行驗收其切換負責人 · TBD程式碼的改動在 25.2 是他們做的；平台負責搬，並不表示平台有資格判斷它是否運作正常。
- 退役該 VM，而非留著運行 —— 釋出的資源計入項目 03負責人 · TBD
26.3其餘波次完成，未遷移者具名列出2030-02-23規劃中 · 0/3
- 第三階段 —— 原本持有本機狀態的應用 —— 依相同準則完成負責人 · TBD
- 未遷移者列出，並註明屬於三類中的哪一類負責人 · TBD是仍持有本機狀態、停在 25.4,還是根本無法容器化、走項目 09 的路徑。一份只報告搬走了什麼的遷移,藏起來的正是明年還會在那裡的部分。
- 殘餘量以「1796 台／79 個服務中還剩多少」的數字發布，而非任其隱含負責人 · TBD每一個剩下的工作負載，要不是經 SRE 核准的例外（具名並寫明原因），就是仍停在 25.4。其餘都是未完成的遷移，不是殘餘。
26.4goods API Phase 1–10 自 middle 遷出，於 11/11 驗證2026-11-11進行中 · 1/3
- Phase 4、5、10 完成切換負責人 · TBD
- Phase 7、8、9 於 9/30 凍版前切換負責人 · TBD
- 在 Kubernetes 上承接 11/11 高峰負責人 · TBD
26.5購物車 middle 遷上 Kubernetes2028-02-25規劃中 · 0/3
- 與購物車團隊確認目標日負責人 · TBD
- 切流量前確認已無 sticky session 依賴（25.5）負責人 · TBD
- 以 canary 切換並退役 middle 路徑負責人 · TBD
26.6追蹤清單／買過清單遷出系統維運部的叢集2027-02-26規劃中 · 0/2
- UAT 遷至平台叢集負責人 · TBD
- 正式環境遷移並替換舊服務負責人 · TBD
26.7goods API Phase 11–12 以 canary 切換2027-03-21規劃中 · 0/2
- Phase 11、12 以 canary 切換（15.5）負責人 · TBD
- 121 支 goods API 全部由 Kubernetes 服務負責人 · TBD
26.8middle 縮容 P1（11/11 之後）2027-03-21規劃中 · 0/2
- middle VM 依仍在上面的流量縮小負責人 · TBD
- 釋出的機器加入平台叢集負責人 · TBD
26.9middle 縮容 P2（6/18 之後）2028-05-18規劃中 · 0/2
- 第一階段遷完後再縮一次 middle負責人 · TBD
- 剩下的 middle API 具名列出，並註明在哪一階段遷移負責人 · TBD
30.1跨應用直連完成盤點，每份資料的擁有者明確2027-02-26規劃中 · 0/4
- 盤點自資料庫側取得，而非詢問各團隊負責人 · TBD稽核輸出、pg_stat 與 proxy log 說的是這個環境實際在做什麼;問卷說的是各團隊記得它在做什麼。要遷移的是前者。
- 每一筆跨應用讀寫具名列出，並記錄其呼叫方負責人 · TBD
- 這份歸屬對照表是本里程碑的產出,不是它的輸入 — 與 25.2 之於三分類的關係相同。
- 找不到合理擁有者的資料向上呈報，不預設指派負責人 · TBD把一份資料交給碰它最多次的人,紙上有擁有者、實際沒有;它發布的契約也不會有人負責維護。
30.2契約先於程式，破壞性變更由 CI 擋下2027-09-10規劃中 · 0/5
- 把資料表一對一包成 CRUD 的 API,耦合一點沒少,還多了一個網路跳點 — 比直連更糟,因為改一次 schema 現在要連 API 帶呼叫方一起動,而不是只動呼叫方。解耦來自契約的形狀,不是來自「中間隔了一層 HTTP」這件事。
- spec 存放於 git，程式由它生成，而非反向產出負責人 · TBD
- 沒有東西強制執行的契約只是文件,而文件擋不住呼叫方壞掉。
- spec 發布至 Backstage catalog負責人 · TBD呼叫方不必問人就能找到契約。22.1 接好了 catalog 與身分,這正是它要承載的內容之一。
- 逐份資料劃定同步與非同步的界線負責人 · TBD可容忍延遲的讀屬於項目 28 的事件匯流排,分析型的讀屬於項目 27 的 Trino。不劃這條線,API-first 會把批次查詢變成 HTTP,並連帶把資料庫打掛。
30.3鋪好的路:照範本就能開一個 API，呼叫方身分可追，慣例只有一套2028-03-10規劃中 · 0/4
- 涵蓋常見情境的服務範本負責人 · TBD三十個團隊各自發明一套 API,會產生三十種方言 — 共用 schema 被換成了「沒有任何共通約定」。
- 呼叫方身分傳遞至擁有者服務，並進入稽核軌跡負責人 · TBD這是資料庫帳號做不到的事:授權以呼叫方為單位決定,而非以連線為單位;稽核軌跡也記得下是誰提出的請求。
- 分頁、錯誤格式與版本策略在範本中一次定案負責人 · TBD
- 有一個團隊在無人協助下完整走過一份資料負責人 · TBD與 25.1 採用的同一個誠實檢驗 — 一條需要平台團隊坐在旁邊才走得完的路,不算鋪好。
30.4影響最小的那份資料先切換，直連授權收回2028-09-08規劃中 · 0/4
- 依影響範圍挑選一份資料，最小者優先負責人 · TBD2.1 與 26.1 已經在遵守的規矩 — 先在可復原的對象上驗證做法,再處理其餘一切所依賴的資料。
- 由擁有者服務提供;讀方逐一切換，新舊並行負責人 · TBD
- 本里程碑的完成判準是這一條,不是 API 上線。一個跑在仍然開著的直連旁邊的 API,只是多了一個元件,沒有少掉任何耦合。
- 其餘波次明確記錄為跨越至下一個半年負責人 · TBD寫在頁面上,而不是靠少一根 bar 讓人自己推。不講明的話,「我們已經有 API 了」就會變成一個仍然全面直連資料庫的環境的標準答案。
30.5無法再核發新的直連授權2029-01-12規劃中 · 0/4
- 憑證僅由動態密鑰引擎核發，且僅發給該份資料的擁有者服務負責人 · TBD12.2 讓資料庫憑證變成動態核發;這一條是決定誰有資格拿到憑證的政策。
- 此路徑之外無常駐憑證 — 舊授權是被移除，而非只是閒置負責人 · TBD
- 跨應用直連的請求只有一種回答負責人 · TBD就是擁有者服務的契約。在這裡開例外流程,就是讓整個環境回到原點的那套機制。
- 對照 30.1 的歸屬對照表檢查偏移負責人 · TBD沒有單一核發路徑與定期檢查,直連會自己長回來,盤點就得重做一次。