01 · 收斂現有資源
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 01 · OS 管理權限移交 SRE | ||||||||
| 1.1 | 權責邊界確立與特權存取盤點 | 2026-07-13 | 2027-01-31 | 進行中 | — | SRE | — | — |
| 1.2 | SRE 於所有主機取得特權存取 | 2026-08-24 | 2027-03-12 | 進行中 | 1.1 | SRE | — | 等待 1.1 |
| 1.3 | 硬體團隊的 OS 憑證撤除 | — | 2027-04-23 | 規劃中 | 1.2 | 硬體維運 | — | 等待 1.2 |
| 1.4 | OS image 與 PXE 佈建由 SRE 擁有 | — | 2027-05-28 | 規劃中 | 1.1 | SRE | — | 等待 1.1 |
| 02 · 現有服務收斂回 IaC | ||||||||
| 2.1 | 服務盤點與重建順序 | 2026-07-20 | 2026-08-28 | 進行中 | — | SRE | — | 逾期 |
| 2.2 | 首個服務以程式碼重建並完成切換 | 2026-08-31 | 2026-10-09 | 進行中 | 2.1 | SRE | — | 等待 2.1 · 逾期 |
| 2.3 | 其餘服務分波重建 | — | 2027-01-15 | 規劃中 | 2.2 | SRE | — | 等待 2.2 |
| 2.4 | 清掃完成並演練從零重建 | — | 2027-02-26 | 規劃中 | 2.3 | SRE | — | 等待 2.3 |
| 03 · 回收浪費資源 | ||||||||
| 3.1 | 使用率基線與回收計算方式 | 2026-09-01 | 2026-10-16 | 進行中 | — | SRE | — | 逾期 |
| 3.2 | 孤兒 VM、重複環境與閒置預留退役 | — | 2026-12-18 | 規劃中 | 3.1 | SRE | — | 等待 3.1 |
| 3.3 | 服務依實測需求重新佈建 | — | 2027-01-29 | 規劃中 | 2.3, 3.1 | SRE | — | 等待 2.3, 3.1 |
| 3.4 | 回收成果報表化並持續可見 | — | 2027-02-26 | 規劃中 | 3.3 | SRE | — | 等待 3.3 |
| 3.5 | 台中 IDC 退役 | — | 2029-06-01 | 規劃中 | 31.3, 10.4 | SRE | — | 等待 31.3, 10.4 |
| 31 · 災難復原自動化 | ||||||||
| 31.1 | 服務分層、復原目標與復原順序完成記錄 | — | 2027-07-16 | 規劃中 | 2.4 | SRE | — | 等待 2.4 |
| 31.2 | 重建由單一管線依相依順序執行 | — | 2028-01-14 | 規劃中 | 31.1 | SRE · 平台工程 | — | 等待 31.1 |
| 31.3 | 對冷目標完成全環境演練，並計時 | — | 2028-12-01 | 規劃中 | 31.2, 6.3, 8.4, 12.1 | SRE · 平台工程 | — | 等待 31.2, 6.3, 8.4, 12.1 |
| 31.4 | 演練排程化、無人值守，退化即失敗 | — | 2029-04-06 | 規劃中 | 31.3 | SRE | — | 等待 31.3 |
細節
1.1權責邊界確立與特權存取盤點2027-01-31進行中 · 3/3
- 硬體與 OS 分工 RACI，雙方簽核負責人 · Charles韌體、BMC/Redfish 與實體存取留在硬體維運;OS image、PXE、bootloader 以上歸 SRE。
- 主機清單與各主機目前的管理路徑負責人 · Charles
- 特權帳號與金鑰盤點負責人 · Charles各主機的本機帳號、共用 root、authorized_keys 與 sudoers — 作為 1.3 複查的比對基準。
1.2SRE 於所有主機取得特權存取2027-03-12進行中 · 1/4
- 於所有主機建立 SRE 管理路徑負責人 · Charles
- SSH 走 SRE 堡壘路徑，以個人身分取代共用金鑰負責人 · TBD目前為靜態金鑰;目標狀態是動態密鑰引擎(項目 12)核發的短效憑證,因此此處不應假設金鑰的壽命長於一次連線。
- sudo 政策即程式碼，不再有共用 root 密碼負責人 · TBD
1.3硬體團隊的 OS 憑證撤除2027-04-23規劃中 · 0/4
- 自所有主機移除硬體維運的本機帳號與金鑰負責人 · TBD
- 確認 BMC/Redfish 與實體存取仍屬硬體維運負責人 · TBDOut-of-band 邊界正是權責分離成立的原因 — 此任務是保護它,而非移除它。
- OS 存取的 break-glass 程序，封存並留稽核負責人 · TBD
- 複查:SRE 以外不存在任何 OS 憑證負責人 · TBD重跑 1.1 的盤點並比對差異;這份差異就是移交完成的證據。
1.4OS image 與 PXE 佈建由 SRE 擁有2027-05-28規劃中 · 0/4
- 由 SRE 擁有、以程式碼建置的 OS base image負責人 · TBD
- PXE 佈建服務移交 SRE負責人 · TBD
- 修補與 OS 生命週期權責記錄在案，on-call 同步更新負責人 · TBD
- 移交 runbook 發布於本站負責人 · TBD
2.1服務盤點與重建順序2026-08-28進行中 · 3/3
- 早於宣告式框架的服務盤點，含負責人與相依關係負責人 · Charles
- 依風險與影響範圍排定重建順序負責人 · Charles影響範圍最小者優先,讓樣板在可復原的對象上先跑通;其餘服務所依賴的服務排在最後。
- 各服務的切換與回滾準則議定負責人 · Charles「與原服務等價」的定義,以及舊實例從保留待命轉為正式退役的時點。
2.2首個服務以程式碼重建並完成切換2026-10-09進行中 · 1/4
- 在運行中的實例旁，以程式碼重建首個服務負責人 · Charles
- 切換前與原服務做等價驗證負責人 · TBD相同的設定介面、資料與整合,在兩者並行時驗證 — 這正是先建後拆的用意。
- 切換流量並退役舊實例負責人 · TBD
- 將過程萃取為可重複的重建樣板負責人 · TBD首個服務真正的產出是樣板;沒有它,每一波都在重複同樣的摸索。
2.3其餘服務分波重建2027-01-15規劃中 · 0/4
- 第一波重建並切換負責人 · TBD
- 第二波重建並切換負責人 · TBD
- 第三波:其餘服務所依賴的服務，重建並切換負責人 · TBD刻意排在最後 — 影響範圍最大,且此時樣板已在其他服務上驗證過。
- 舊實例確實退役，而非留著運行負責人 · TBD舊實例還在跑的重建等於沒搬;它釋出的資源正是項目 03 要衡量的對象。
2.4清掃完成並演練從零重建2027-02-26規劃中 · 0/4
- 對照 2.1 盤點複查:不再有服務落在 IaC 之外負責人 · TBD
- 於隔離環境演練從零重建負責人 · TBD僅憑程式碼、不接觸運行中的環境,重建具代表性的一部分 — 這才讓清掃成為 DR 能力,而不只是整理。
- 記錄復原時間與演練發現的缺口負責人 · TBD
- 重建 runbook 發布於本站負責人 · TBD
3.1使用率基線與回收計算方式2026-10-16進行中 · 0/4
- 比對 VM 清單與實際回報至 Mimir 的對象;補齊落差，或逐一記錄排除原因負責人 · Charles目前多數 VM 有回報,但並非全部。未進 Mimir 的主機不會出現在基線上,而這些主機正是 3.2 要找的孤兒候選 — 因此這份落差清單是 3.2 的輸入,不只是資料品質的雜務。
- 以完整週期量測每台 VM 與每個磁碟區的使用率，資料取自 Mimir負責人 · Charles要一整週的尖峰,而非瞬時值 — 繼承來的規格通常是靠一個沒人重新量過的尖峰在辯護。
- 議定「回收」的定義負責人 · TBD資源要回到資源池、能被其他工作負載使用才算回收 — 只是把 VM 關機不算。
- 記錄基線，作為後續所有數字的比較基準負責人 · TBD
3.2孤兒 VM、重複環境與閒置預留退役2026-12-18規劃中 · 0/4
- 辨識孤兒 VM(含 3.1 查出未回報 Mimir 的主機)，並給擁有者認領期限負責人 · TBD不因無人回應就直接刪除 — 未認領者先關機,經明訂的隔離期後才移除,讓誤判仍可挽回。
- 重複與過期環境退役負責人 · TBD
- 釋放閒置預留負責人 · TBD
- 檢視孤兒磁碟區、快照與備份保留負責人 · TBD
3.3服務依實測需求重新佈建2027-01-29規劃中 · 0/3
- 重建時依 3.1 的量測值決定規格，而非沿用繼承規格負責人 · TBD
- 規格寫進 IaC 定義，而非手動調整負責人 · TBD手動調整的規格會在下次重建時消失;趁項目 02 的波次做,才能讓新規格成為程式碼。
- 各服務明訂餘裕與擴縮策略負責人 · TBD
3.4回收成果報表化並持續可見2027-02-26規劃中 · 0/3
- 對照 3.1 基線，報告回收的 CPU、記憶體與儲存負責人 · TBD
- 與 3.1 同源,報表與基線才不會各自漂成兩個數字。
- 排定重新檢視，避免規格再度漂回負責人 · TBD若規格下一季又漂回去,這輪清掃就沒有價值;排定的複查才讓回收持久。
3.5台中 IDC 退役2029-06-01規劃中 · 0/4
- 以通過的全環境演練為閘門，而非以日期為閘門負責人 · TBD卡片 03 之所以退掉這個站點,是因為讓服務回來的是重建能力,不是一直開著的硬體。31.3 就是那句話不再只是宣稱的地方。把閘門寫在這裡,是讓這個日期的理由出現在頁面上,而不是只存在於依賴箭頭裡。
- 工作負載與名稱完成搬遷或退役，10.4 先行負責人 · TBDZone B 與 A、C 回答同一批 FQDN。名字還沒改指向就把站點拔掉,會打掉根本不在那個站點的服務。
- 硬體除役，回收量對照 3.1 的基線計算負責人 · TBD退掉一整個站點是項目 03 裡規模最大的一次回收 — 而只有算進與其餘相同的帳裡,它才看得出來是一次回收。
- 記錄兩站點的最終狀態負責人 · TBD
31.1服務分層、復原目標與復原順序完成記錄2027-07-16規劃中 · 0/4
- 依「業務少了它就無法運作」將服務分層負責人 · TBD
- 各層級訂出 RTO 與 RPO，由 2.4 實測的復原時間推得，於業務確認前為暫定值負責人 · TBD這兩個數字目前在整份路線圖裡都不存在。沒有它們,「已復原」就沒有定義,自動化演練也沒有通過或失敗可言。用推導勝過用編的:2.4 已經在記錄復原時間與演練發現的落差。
- 復原順序沿用 2.1 的重建順序，不另行推導負責人 · TBD
- 明確列出目標未涵蓋的範圍負責人 · TBD一個默默涵蓋所有東西的目標,是沒有人做得到的目標。講明排除了什麼,其餘的部分才可信。
31.2重建由單一管線依相依順序執行2028-01-14規劃中 · 0/4
- 單一管線依相依順序重建整個環境負責人 · TBD
- 沒有任何步驟依賴人照著 runbook 操作負責人 · TBDrunbook 是一份假設「寫它的人在場、清醒、而且沒寫錯」的復原計畫 — 而真實事件傾向一次打破這三個假設。
- 秘密與憑證在無人介入下即可供給重建流程負責人 · TBD演練過的復原在真實事件中卡住,最常見的原因就是這個:自動化本身沒問題,但沒有人給得出它需要的那組憑證。
- 演練與真實事件使用同一條管線負責人 · TBD另備一套「真的出事時才用」的程序,等於多一份要維持正確的東西 — 而從沒跑過的那一份,正是真的會被用到的那一份。
31.3對冷目標完成全環境演練，並計時2028-12-01規劃中 · 0/4
- 一次執行，對冷目標重建整個環境負責人 · TBD目前有七次元件級演練 — 8.4、12.1、2.4、27.3、6.3、14.4、28.8 — 而它們從未一起跑過。它們要代表的那個事件,不是其中任何一種。
- 對照 31.1 的目標計時，並記錄結果負責人 · TBD完成判準是量測到的結果,不是「演練有辦」。一次結果從未與目標比對過的演練,是活動,不是測試。
- 落差記錄為待辦工作，而非觀察心得負責人 · TBD
- 不對 14.4、27.3、28.8 建立依賴負責人 · TBD28.8 落在 2029-02-22,晚於本里程碑。為了一個元件等它,第一次全環境演練會晚一季。這裡演練的是屆時存在的環境;後到的元件演練於 31.4 併入排程執行。
31.4演練排程化、無人值守，退化即失敗2029-04-06規劃中 · 0/4
- 演練依排程執行，無人值守負責人 · TBD
- 退化像 build 一樣失敗，並有負責人負責人 · TBD把 6.3 那句話往上提一層 — 沒有人還原過的備份,是一個掛著 cron 的希望;而只演練過一次的復原能力,只是關於某個下午的事實。
- 每次執行的時間與目標比對，趨勢可見負責人 · TBD復原時間會隨環境長大而漂高。第一次超出目標的那次執行,應該是一次失敗,而不是事故當下的一個意外。
- 14.4、27.3、28.8 的元件演練隨其完成併入負責人 · TBD