02 · 底層基礎設施即程式碼(IaC)
此主題 roadmap 項目的里程碑
截至 2026-10-22 · 今天
甘特圖
里程碑
| # | 里程碑 | 開始日 | 目標日 | 狀態 | 等待 | 團隊 | Epic | 推導 |
|---|---|---|---|---|---|---|---|---|
| 04 · 宣告式基礎設施框架 | ||||||||
| 4.1 | 雲端資源納入 Terraform 管理 | 2026-07-06 | 2026-10-30 | 進行中 | — | SRE | — | — |
| 4.2 | 虛擬機納入 Terraform 管理 — KVM 與 Harvester | — | 2027-01-15 | 規劃中 | 4.1 | SRE | — | 等待 4.1 |
| 4.3 | 資料庫基礎設施納入 Terraform 管理 | — | 2027-02-26 | 規劃中 | 4.1 | SRE | — | 等待 4.1 |
| 4.4 | 組態管理納入 Ansible 標準 | 2026-07-06 | 2026-11-20 | 進行中 | 4.1 | SRE | — | 等待 4.1 |
| 05 · 實體機基礎設施即程式碼 | ||||||||
| 5.1 | Netbox 成為硬體真實來源 | 2026-08-03 | 2026-10-23 | 進行中 | — | 硬體維運 | — | — |
| 5.2 | 帶外電源與開機控制自動化 | — | 2027-01-01 | 規劃中 | 5.1 | SRE | — | 等待 5.1 |
| 5.3 | iPXE 無人值守 OS 佈建 | — | 2027-02-12 | 規劃中 | 4.1, 5.2 | SRE | — | 等待 4.1, 5.2 |
| 5.4 | 從上架到叢集成員，全程無人登入 | — | 2027-02-26 | 規劃中 | 5.3 | SRE | — | 等待 5.3 |
| 06 · 資料庫基礎設施即程式碼(Database IaC 與 DBaaS) | ||||||||
| 6.1 | OpenMetadata 目錄涵蓋資料庫資產 | — | 2026-12-18 | 規劃中 | — | SRE | — | — |
| 6.2 | schema migration 程式碼化 | — | 2027-01-15 | 規劃中 | — | SRE | — | — |
| 6.3 | 複寫、備份與生命週期納入 GitOps | — | 2027-07-16 | 規劃中 | 4.3 | SRE | — | 等待 4.3 |
| 6.4 | 資料庫從申請到交付，不需工單 | — | 2027-11-19 | 規劃中 | 6.1, 6.3 | SRE | — | 等待 6.1, 6.3 |
| 07 · 網路基礎設施即程式碼 | ||||||||
| 7.1 | Netbox 承載網路的預期狀態 | — | 2027-01-01 | 規劃中 | 5.1 | 網路 | — | 等待 5.1 |
| 7.2 | 設定由程式碼產生並通過驗證 | — | 2027-02-26 | 規劃中 | 7.1 | 網路 | — | 等待 7.1 |
| 7.3 | 設備變更只能經由 Git | — | 2027-09-10 | 規劃中 | 7.2 | 網路 | — | 等待 7.2 |
| 7.4 | 預設拒絕的分段，以及自助式網路申請 | — | 2028-01-14 | 規劃中 | 7.3, 22.2 | 網路 | — | 等待 7.3, 22.2 |
細節
4.1雲端資源納入 Terraform 管理2026-10-30進行中 · 2/4
- Repository 結構、遠端 state 與鎖定機制議定負責人 · CharlesState 才是這套框架真正的介面 — 它放在哪、誰能寫、一次執行如何上鎖,決定了兩個人能不能同時工作。
- 模組與命名慣例形成文件負責人 · Charles
- 既有雲端帳號以 import 納管，而非重建負責人 · TBD先對現況執行 terraform import — 程式碼要能描述既有資產,才有資格改動它。
- plan 與 apply 一律經 CI，不做本機 apply負責人 · TBD本機 apply 會留下別人重現不了的 state;經由 CI 才能讓框架成為唯一路徑,而不是選項之一。
4.2虛擬機納入 Terraform 管理 — KVM 與 Harvester2027-01-15規劃中 · 0/4
- 接上 Harvester provider，虛擬機以程式碼宣告負責人 · TBD
- KVM 主機納入同一套框架負責人 · TBD涵蓋尚未遷移至 Harvester 的虛擬機(項目 09),讓它們在等待期間不再是手工建置。
- VM 映像與範本與程式碼一起版本化負責人 · TBD
- 記錄與項目 05 的分界:實體層在下，虛擬機在此負責人 · TBD05 負責 Netbox、帶外控制與 iPXE,也就是虛擬機底下的那層。是分層,不是依機器種類切割。
4.3資料庫基礎設施納入 Terraform 管理2027-02-26規劃中 · 0/3
- 實例、參數組與備份排程以程式碼宣告負責人 · TBD
- 既有資料庫 import 進 state負責人 · TBD
- 記錄與項目 06 的分界:基礎設施在此，自助服務在彼負責人 · TBD項目 06 是在此里程碑佈建的成果之上,建立 Backstage 申請流程與 schema migration,而非重新佈建。
4.4組態管理納入 Ansible 標準2026-11-20進行中 · 0/4
- 既有 playbook 盤點並收攏至單一 repository負責人 · Charles它們已經在跑。這裡要做的不是導入 Ansible,而是終結目前好幾套互不相干的執行方式。
- role 與 inventory 慣例形成文件負責人 · TBD
- inventory 由 Terraform state 產生，而非手工維護負責人 · TBD這是項目 04 兩半之間的交接點 — 佈建宣告有什麼,組態就從那裡讀,而不是另外維護一份會逐漸走樣的清單。
- playbook 經 CI 執行;主機狀態可僅由程式碼重現負責人 · TBD與 4.1 的「不做本機 apply」同一條規矩 — 手動跑過的 playbook 會留下沒有人重建得出來的主機。
5.1Netbox 成為硬體真實來源2026-10-23進行中 · 1/4
- 每個機櫃、機箱與伺服器登錄序號、MAC、機櫃位置與 BMC 位址負責人 · TBD
- Netbox 成為變更發生的地方，而非事後同步的副本負責人 · TBD事後才更新的清冊,是第二個需要有人維持誠實的系統。硬體團隊改 Netbox,其他一切從那裡讀。
- 自動化經 API 讀取 Netbox，路徑上不再有試算表負責人 · TBD
- 落差檢查:Netbox 的記載與 BMC 實際回報的比對負責人 · TBD沒有人稽核的清冊會悄悄變成虛構。這項檢查才讓它是真實來源,而不只是宣稱。
5.2帶外電源與開機控制自動化2027-01-01規劃中 · 0/4
- BMC 僅能自隔離的管理網路連通負責人 · TBD
- 電源與開機順序以程式控制，而非網頁主控台負責人 · TBDBMC 協定(IPMI、Redfish 或廠商介面)是選定佈建工具時一併決定的驅動選項,這條里程碑不需要先為它定案。
- BMC 憑證依身分核發，不使用共用帳號負責人 · TBD待項目 12 有里程碑後改由 Vault 核發;在那之前這只是明訂的目標,不是圖上畫得出來的依賴。
- 人的存取仍屬硬體維運(1.3);自動化使用自己的身分負責人 · TBD1.3 保護的正是 out-of-band 邊界 — 自動化進到那個網路,不能反而成為繞過它的路。
5.3iPXE 無人值守 OS 佈建2027-02-12規劃中 · 0/4
- iPXE 開機鏈由管理網路提供負責人 · TBD
- Harvester 節點映像以產出物形式建置並版本化負責人 · TBD
- 佈建由 IaC 管線驅動，而非人工主控台負責人 · TBD4.1 建立的 state 後端與 CI 路徑,才讓這件事可重現,而不是一支要靠人記得去跑的腳本。
- 記錄與 1.4 的分界負責人 · TBD1.4 移轉 OS image 與 PXE 的權責,5.3 讓那個佈建變成無人值守。一個是歸屬、一個是自動化,不是同一件事被寫兩次。
5.4從上架到叢集成員，全程無人登入2027-02-26規劃中 · 0/3
- 一台新伺服器自上架到成為叢集成員，全程無互動登入負責人 · TBD卡片最後那句承諾,實際跑一次。任何仍需要動手的地方就是缺口,而這一次執行就是用來找出它們的。
- 記錄該次執行:耗時，以及仍需人工的每一個步驟負責人 · TBD
- 缺口補上，或明列為已知例外負責人 · TBD
6.1OpenMetadata 目錄涵蓋資料庫資產2026-12-18規劃中 · 0/4
- 部署 OpenMetadata，自每個資料庫實例擷取中繼資料負責人 · TBD
- 每項資產都有具名的擁有者負責人 · TBD沒有擁有者的目錄只是一份清單。有了擁有者,關於某張表的疑問才有人可以問。
- 擷取 schema 與資料血統，並排程更新負責人 · TBD只擷取一次的血統會悄悄失真;排程更新才讓它描述的是今天的資產,而不是上一季的。
- 記錄與 Backstage 的分界負責人 · TBDOpenMetadata 回答「有什麼、是誰的」;Backstage 是「我要一個」的地方。兩套系統各司一職,而不是對同一件事各自宣稱。
6.2schema migration 程式碼化2027-01-15規劃中 · 0/4
- migration 與服務程式碼在同一 repo 版本化負責人 · TBD
- 單一上線路徑:dev、staging、production，不接受手動套用的 SQL負責人 · TBD在正式環境手動改過的 schema,是重建重現不出來的資料庫 — 與項目 02 對服務的要求同一條規矩。
- 每個 migration 明訂回滾方式，否則只允許 expand-only負責人 · TBD
- migration 狀態在目錄中可見負責人 · TBD
6.3複寫、備份與生命週期納入 GitOps2027-07-16規劃中 · 0/4
- 複寫拓撲以宣告定義，而非手動設定負責人 · TBD
- 備份排程與保留期以程式碼定義負責人 · TBD
- 還原經實際演練，而非假設有效負責人 · TBD沒有人還原過的備份,只是一個掛著排程的期望。
- 實例生命週期(建立、調整、退役)由 repository 驅動負責人 · TBD
6.4資料庫從申請到交付，不需工單2027-11-19規劃中 · 0/4
- 開發者經自助流程申請，並取得已佈建完成的實例負責人 · TBD
- 預設值、配額與擁有者中繼資料自動套用，不需另外要求負責人 · TBD
- 新實例自動出現在目錄中負責人 · TBD佈建了卻沒有登錄資產,就是在製造下一批孤兒 — 正是項目 03 之後要去找的那些。
- 實際跑完一次完整申請並記錄耗時負責人 · TBD
7.1Netbox 承載網路的預期狀態2027-01-01規劃中 · 0/4
- VLAN、網段、介面與防火牆物件登錄於 Netbox負責人 · TBD
- 記錄的是預期狀態，而非設備目前恰好是什麼樣子負責人 · TBD只是照抄設備的清冊,永遠只會跟設備一致。記錄「預期」,兩者的差異才有意義。
- 既有設備設定匯入一次，之後由 Netbox 擁有負責人 · TBD
- Netbox 與設備之間的落差要被回報，而非默默同步掉負責人 · TBD默默覆蓋任何一邊,都會把真正該被看見的分歧藏起來。
7.2設定由程式碼產生並通過驗證2027-02-26規劃中 · 0/3
- 設備設定由 Netbox 與 Git 中的政策產生負責人 · TBD
- 產生的設定在離線狀態下通過廠商語法與站點規則驗證負責人 · TBD
- 每次變更在推送前先產出可審閱的差異負責人 · TBD這條里程碑刻意停在不寫入設備。一個剛做好就被信任去改交換器的產生器,正是網路斷線的典型起點。
7.3設備變更只能經由 Git2027-09-10規劃中 · 0/4
- 由管線推送產生的設定;交換器與防火牆不再有手動輸入的變更負責人 · TBD
- 主控台與設備本機帳號縮減為 break-glass 用途負責人 · TBD這條規矩要成立,另一條路就得關上。留著它,「不手動改」就只是個請求,而不是性質。
- 排程偵測飄移，並以變更流程處理，而非手動修掉負責人 · TBD
- 回滾就是 revert，而且已經演練過負責人 · TBD
7.4預設拒絕的分段，以及自助式網路申請2028-01-14規劃中 · 0/4
- 分段政策以程式碼表達，並以預設拒絕套用負責人 · TBD政策本身由零信任主題制定;這裡是它落到實體設備上的地方。
- 例外是 Git 中具名且有理由的條目，而非永久的破口負責人 · TBD
- 開發者的網路需求是自助動作，而非工單負責人 · TBD由同一個 backend 服務,申請與手動變更才不會分岔。表單在 Backstage — 實現網路申請的樣板是 22.2,本里程碑現已相依於它。
- 實際跑完一次完整申請負責人 · TBD