平台基礎設施策略路線圖
2026 年 8 月 – 2030 年 2 月 · 平台工程
我們依層次建設平台:從 IaC、CI/CD 到安全政策的端到端宣告式自動化、涵蓋全系統的統一可觀測性,以及位於兩者之上、為開發者提供的抽象化自助服務。Backstage 成為唯一、零阻力的入口;其下的一切皆為程式碼。三者之下,我們先收斂既有資產:OS 管理權移交 SRE、所有舊服務在 IaC 下重建,並回收其浪費的資源。最上層是應用程式本身:容器化、搬上 Kubernetes,並透過契約而非彼此的資料表來存取對方的資料。與之並行的是資料平台:三地各自一套相同的資料倉儲、彼此鏡像,由同一套排程器驅動以維持端到端的血緣,並提供單一的自助查詢入口。
01 · 收斂現有資源
將 OS 層管理權限自硬體維運團隊移交 SRE,以韌體、BMC、實體存取為硬體層邊界。硬體管理者保留 out-of-band 存取,但不持有任何 OS 憑證,與 Google、AWS、Meta 的權責分離設計一致。特權 OS 存取改由動態密鑰引擎短效核發並留存稽核軌跡。硬體團隊負責上架、韌體與 out-of-band 管理(BMC);SRE 負責 OS image、佈建(PXE)與 bootloader 以上的一切。
所有早於宣告式框架的服務,以先建後拆方式收斂回 IaC:從程式碼在既有服務旁重建、切換流量、再下線原環境。全數完成即證明整套 IaC 能從零重建公司全部服務,同時取得災難復原能力。
以每次重建為 right-size 時點:清除孤兒 VM、重複環境與閒置預留,依實測需求而非沿襲規格重新配置。回收的 CPU、記憶體、儲存以使用率基準線追蹤,讓成效可見。退掉一整個站點是規模最大的一次回收。當整套資產能僅憑程式碼重建——由 02 的從零重建演練證明——台中 IDC 就以退役取代續存:讓服務回來的是重建能力,而不是那批一直開著的硬體。
這個環境的復原故事，目前是七次從未一起跑過的元件級演練:還原一台 Harvester VM、解封一次 Vault、救回一套資料庫、把叢集 reconcile 到空叢集、復原一次資料倉儲、切斷一個站點 —— 每一次都是隔離進行，每一次都沒有碼錶。而它們要代表的那個事件，不是其中任何一種。本項目把 02 已經證明的重建，變成由單一管線依相依順序執行的東西;把「復原完成」用各服務層級的復原目標定義清楚;並在碼錶計時下對冷目標演練整個環境。接著把這個演練排進時程，讓它像 build 一樣會失敗 —— 因為只演練過一次的復原能力，只是關於某個下午的事實。本項目要的不是一個熱待命站點:03 之所以退掉台中，正是因為讓服務回來的是重建能力而不是一直開著的硬體;而本項目讓那次退役能以證據為閘門，而不是以信心為閘門。
02 · 底層基礎設施即程式碼(IaC)
將核心平台後端標準化於 Terraform 負責佈建,並以 Ansible 管理組態,以確定性方式管理多雲、DNS 與裸機資源。
以程式碼運行實體機群:Netbox 作為硬體 inventory(序號、MAC、機架位置、BMC 位址),由硬體團隊維護、自動化讀取;out-of-band 管理走隔離網段,BMC 憑證由 Vault 核發;無人值守的 OS 佈建(Harvester 節點以 iPXE)由 IaC 管線驅動,伺服器從上架到加入叢集不需任何人登入。
將資料庫實例佈建、預設組態與 schema 遷移程式碼化並納入自動化管線。開發者透過 Backstage 申請資料庫資源,平台後端則以 GitOps 在幕後處理複寫、備份排程與完整生命週期管理。
以 Git 中的宣告式政策管理防火牆規則、VLAN 與路由,Netbox 作為 source of truth,自動化 backend 負責產生、驗證並推送設備設定,交換器與防火牆不再有手動變更。同一個 backend 服務 Backstage,開發者的網路需求成為自助動作,而非給網路團隊的工單。安全政策(預設拒絕、分段)由 04 制定,在此執行。
03 · 核心基礎設施與私有雲
以後端 IaC 供應器架構、部署並強化 Harvester 超融合基礎設施,建立具韌性的生產級私有雲運算基礎。
規劃並執行將既有 KVM 虛擬機遷移至 Harvester HCI 平台,包含工作負載盤點、分階段切換與驗證,待工作負載穩定後汰除舊有 Hypervisor 主機。
重新設計核心 DNS 拓撲以提升容錯能力、簡化內部網域路由,並完全透過自動化程式碼管線管理公有/私有區域組態。
在 routed（L3）伺服器 fabric 上建立新的 Kubernetes 叢集，MetalLB 採 BGP 模式；在兩個叢集並行期間分波將現有服務搬遷過去，最後一波切換完成後淘汰舊叢集。與 fabric 工作平行啟動；最終切換需等所有伺服器機櫃都切到 L3。
04 · 零信任安全與自動化治理
為資料庫、SSH 目標系統與雲端供應商 API 金鑰實作具嚴格短效 TTL 週期的自動化動態帳號,消除靜態憑證。人員修改正式環境 Oracle 資料改經 Superset 使用這些憑證 —— 每人一組一小時有效的帳號、讀寫分開、寫入權限由具名的擁有者核准、每一段 SQL 都留下紀錄 —— 取代目前只要能登入就能寫入正式環境的內部工具（設計）。
採用 NetBird 作為自建、以 WireGuard 為基礎的 overlay 網路,連接站點、伺服器與人員:每個 peer 帶有來自 SSO 的身分,連線點對點,可達性由政策群組與裝置狀態決定,而非所處網段。這些流量目前不在任何 overlay 上,因此這是這些路徑第一次帶有身分、而不只是位址 —— 並沒有東西要遷移。Tailscale 不受影響,維持它自己狹窄的職責:承載站點間的 DNS 轉送,這也是它既不被併入、也不被移除的原因。NetBird 成為唯一的入口:多數服務接上之後即直接連線,少數需要留下連線紀錄的服務則置於 Warpgate 之後,而 Warpgate 本身也僅能經由 NetBird 抵達,連線由 Vault 核發的 SSH 憑證承載 —— 使 01 的 OS 移交只留一道受稽核的門。
05 · 進階 CI/CD 與 GitOps 引擎
以 ArgoCD 作為 GitOps 引擎,收斂叢集與其上運行的平台元件,由程式碼合併或 Backstage 目錄動作觸發,而非由人執行。Jenkins 退場會把它目前做的事拆成兩半 —— GitLab CI 負責建置與測試,ArgoCD 負責部署 —— 發布工具仍然啟動 CI,但部署不再是任何人手動觸發的動作。叢集本身仍由 Terraform 佈建;叢集裡跑的東西由 ArgoCD 掌管。
全面翻修建置與部署管線,實作穩健的漸進式交付(金絲雀/藍綠部署)、自動回滾策略、平行化測試執行,以及嚴格的產物簽章以確保供應鏈安全。
以 Google Artifact Registry 取代目前單節點、沒有備援的 Nexus OSS，成為所有套件與映像的唯一來源 —— Go、Python、npm、Maven、Docker 與 Ubuntu Apt。每種格式各有一個放自家發布內容的 repository，以及一個快取上游的 remote repository，讓地端與雲端的建置從同一個地方解析出同一份相依套件，25 所發布的映像也有了明確的落腳處。存取一律經 Google IAM：pipeline 走 workload identity federation，人員走 SSO，不留靜態金鑰（12）。保留策略依循上版約定：版本 tag 永不清除，commit tag 保留最新 N 版、部署中者不清。歷史套件一併遷移，Nexus 以唯讀方式並行，直到所有 pipeline 都切換後退場 —— 唯一的例外是保留一台最小化的 Nexus 給 NuGet，因為 Artifact Registry 不支援。詳見設計。
06 · 統一可觀測性與監控平台
建置或擴展高吞吐量管線,集中處理指標、分散式追蹤與結構化日誌。
以 Grafana LGTM 堆疊作為監控平台 —— Mimir、Loki 與 Tempo 統一由 Grafana 呈現,均已部署並有架構文件 —— 並讓它成為人們真正使用的工具:服務水準指標依使用者實際感受定義,服務水準目標與各服務負責人議定,並一併訂下錯誤預算用罄時的處置;告警由這些目標而非成因產生;所有儀表板以程式碼宣告,可被重建,而不會隨著做它的人一起消失。
淘汰兩個既有的可觀測性孤島:記錄日誌的 ELK 與做 APM 的 Pinpoint,將其工作負載遷移到 Grafana LGTM 堆疊:日誌進 Loki、追蹤與服務地圖進 Tempo、指標進 Mimir,由 Alloy 以 OpenTelemetry 收集,應用程式只需儀器化一次。逐服務新舊平行運行、以程式碼遷移儀表板與告警、驗證一致後,下線 Elasticsearch 與 Pinpoint 叢集並回收其運算與儲存資源。最終在 Grafana 單一介面以 trace id 關聯日誌、指標與追蹤。
07 · 軟體供應鏈安全與稽核
建立端到端的建置稽核機制,完整記錄建置者、建置時間與來源版本,並將建置溯源、相依清單與管線日誌寫入不可竄改、可搜尋的稽核軌跡,以支援合規與事件鑑識。
以 DefectDojo 作為安全弱點的唯一記錄系統:管線中的每個掃描器(SAST、相依套件/SCA、容器映像、密鑰、DAST)與基礎設施掃描結果都匯入其中,弱點去重後綁定產品與引入它的建置,依嚴重度指派負責人與 SLA,追蹤至關閉。05 的發布閘門讀取它:有逾期未修重大弱點的建置不得上線。儀表板讓資安與管理層看到跨產品的單一風險視圖,而非各工具各自的報表。
08 · 開發者體驗與抽象化自助服務
部署 Backstage 作為零阻力的單一介面,把底層基礎設施(Terraform、Ansible、GitOps)藏在直覺的表單與軟體範本之後。目錄把下層能佈建的東西——Kubernetes 叢集與 namespace、Harvester 虛擬機、資料庫、網路變更——變成自助動作:開發者填表,負責的 backend 自動佈建資源,預設值、配額與擁有者中繼資料一併套用。
持續演進並擴展「Cogwork」桌面應用程式,處理複雜的本地操作自動化、開發者手動覆寫,以及日常在地化工程工作流程。
建立標準化、合規且高度可見的變更管理追蹤流程,安全地記錄、審查與稽核系統發布。
09 · 應用程式現代化
讓每個應用程式具備容器就緒條件:設定來自環境、不留本機狀態、健康與就緒探針、日誌輸出至 stdout,每個服務在 CI 中以平台 base image 建置單一映像,附簽章 SBOM 發布至 registry。平台提供鋪好的路(base image、Helm chart 範本、CI job 範本),程式碼的修改由應用程式團隊負責。
將已容器化的應用程式從手工建置的 VM 分波搬上 L3 模式的 Kubernetes 叢集:經 GitOps 部署、新舊並行、切換流量、退役該 VM。目標是全部系統 —— 2026-09-21 盤點中1796 台主機上的 79 個服務，尚未遷移的部分以這份基準用數字報告。工作負載分三類,而非兩類。已無本機狀態的應用來到這裡。已容器化但仍持有本機狀態的 —— sticky session、日誌寫在本機 —— 先在現有 VM 上以容器形式執行,直到那些狀態被清除;跑的是日後要在這裡執行的同一個映像。根本無法容器化的 —— 有狀態的設備、授權軟體 —— 則維持 VM,走 KVM 遷移至 Harvester 那條路，但每一個都必須具名、寫明原因並經 SRE 核准；未經核准者一律屬於本項目的範圍。每一波都為 03 釋出資源,也是 02 的重建確實可行的證明。
應用程式直接存取不屬於自己的資料庫。如此一來 schema 成了事實上的對外 API —— 改一個欄位就得全公司協調;一組資料庫帳號等同於表層級的授權,而稽核軌跡記下的是連線、不是呼叫方;耦合則完全隱形:沒有任何地方回答得了「這張表壞掉會影響誰」。它同時讓連線數隨應用實例數成長 —— 而 26 正要讓實例數變成彈性的 —— 並擋住 06 的複製調整與 27 的站點獨立,因為兩者都無法搬動一份不知道誰在讀的資料。每一份資料只有一個擁有它的服務,其餘一律走它的契約:spec 放在 git 中、程式由它生成,破壞性變更在 CI 擋下。契約依呼叫方的需要設計,而非依資料表的樣子 —— 把 schema 一對一包成 CRUD 的 API,耦合一點沒少,只多了一個跳點。平台提供鋪好的路 —— 服務範本、呼叫方身分、統一的分頁與錯誤慣例 —— 應用團隊則負責自己程式碼的改動。遷移逐份資料進行,新舊並行後切換;一份資料的完成判準是直連授權被收回,而非 API 上線。並非所有存取都變成同步呼叫:可容忍延遲的讀走 28,分析型的讀走 27,兩者都不該是打在 OLTP 資料庫上的 HTTP 呼叫。這個項目要的不是在共用資料庫前面擺一個資料 gateway —— 那只是把 schema 藏到 HTTP 後面,並讓所有變更排在同一個團隊後面。
10 · 資料平台
在三個彼此獨立的位置運行相同形態的資料平台 —— IDC 以 MinIO，GCP Taiwan 與 GCP US 以 GCS —— 每一站有自己的 Trino 叢集，就近讀取物件儲存。每一站以自己持有的資料回答查詢，WAN 中斷或單站故障只影響該站；每一站都是完整的平台，而非同一套的分片。三個 Phase 對齊 Kubernetes 的切點：地端在 2026 雙 11 前、US 在 2027 618 前、asia-east1 在 2027 雙 11 前。Phase 1 完成後，地端的 StarRocks 以一年時間遷入資料平台並退場。資料管線由同一套排程器驅動，DAG 就是依賴圖，血緣由單一來源推導。排程器先提供類似 BigQuery 排程查詢的入口 —— 給 SQL、排程與目標表即可 —— 讓既有作業原樣搬進來，再逐一重建成 DAG。應用層的定時任務維持原狀。分析者只有一個入口：Superset 負責儀表板與臨時探索，Cube.js 作為語意層，讓指標只定義一次。身分經 Zitadel SSO 一路傳遞至 Trino，每次查詢都以提問者本人的身分執行，存取由針對該身分評估的 Rego 政策決定。
以 HTTP 發布一則業務事件,讓它成為查得到的 Iceberg 資料表,而且發布者的身分一路帶到底:事件先對已註冊的 schema 驗證,以該身分寫入 Kafka,落地為 Iceberg,再由 Trino 讀取。一個 topic 的所有事實——schema、誰可以發布、誰可以讀取——都寫在 git 裡的同一份檔案,schema、存取規則與落地資料表都由它產生,而不是手改。授權只有一個執行點,也就是 broker,因此沒有第二處需要同步。同一套平台也負責把事件送到三站:topic 在 IDC、GCP Taiwan、GCP US 之間鏡像,各站各自落地一份,複製為非同步,站點在查詢時保持獨立,資料則逐步收斂一致。延遲與健康納入平台監控(見 18)——而且是在第一條邊開始載流量之前就到位,不是之後。