從小時到分鐘：平臺工程的演進與實踐

引言

在現代軟體開發中，平臺工程（Platform Engineering）已成為組織規模擴張與效能提升的關鍵驅動力。面對數千用戶的規模需求，Kasan數位團隊透過平臺工程的演進，成功解決了工具重複、標準化缺失與開發者參與度低等挑戰。本文探討其技術實踐與核心原則，並分析如何透過CNCF生態系與技術治理，實現可擴展的基礎設施管理。

主要內容

技術定義與核心概念

平臺工程的核心在於透過技術抽象，降低使用者的複雜性負擔，使其專注於業務價值。其關鍵特徵包括：

• 自服務堆疊（Self-Service Stack）：開發者透過YAML描述基礎設施需求，無需具備基礎設施開發技能。
• 標準化與治理：建立基於CNCF與Kubernetes的技術委員會，推動基礎設施provisioning的標準化。
• 可擴展性：透過平臺orchestrator支援不同成熟度的使用者，並根據組織階段調整目標。

關鍵技術與實踐

3S引擎的開發

Kasan團隊以Terraform為底層開發3S引擎，提供自服務堆疊，支援觀測性、安全性、憑證管理與防火牆規則。此引擎的設計目標是讓開發者能以簡化流程配置資源，但其限制為僅支援Internet連線，導致部分域無法使用。

SRP/MRP產品調整

為解決3S引擎的限制，團隊重構SRP（單區域）與MRP（多區域）產品，新增內部網路連線功能。透過Platform Score（PFC API）實現網路與安全資源的自主配置，取代原有需提交支援請求的流程。同時引入provisioning API與secret management API，簡化產品使用流程。

開發者門戶的建立

開發者門戶的建立提升了使用者體驗與功能反饋機制，使開發者能更直覺地與平臺互動，並快速響應需求變更。

技術挑戰與解決方案

遷移困難與成本

SRP/MRP的網路重構導致無法平滑遷移自3S引擎，原有用戶需重新部署，成本高昂。此外，新用戶對SRP/MRP的價值認知不足，因功能與3S相似，未見顯著改進。

技術選擇與迭代

團隊回歸3S引擎，保留原有功能並回補SRP/MRP的特性，降低開發成本。透過回溯更新，提升3S引擎的技術深度與功能組合，使其更符合實際需求。

組織與規模考量

平臺工程需與組織成熟度對齊，避免過度設計或功能不足。Kasan團隊透過專屬交付經理與季度規劃，優化跨團隊協作與資源分配。同時，技術治理的建立確保了基礎設施的可擴展性與一致性。

總結

平臺工程的核心在於降低使用者負擔、適應組織成熟度，並透過工具（如orchestrator）實現可擴展性與靈活性。關鍵教訓包括：

• 交付管理：建立專屬交付經理與季度規劃，優化跨團隊協作。
• 靈活性與適應性：接受失敗並持續迭代，適應快速變化的技術環境。
• 用戶中心思維：平臺工程需降低用戶複雜度，避免將技術負擔轉嫁給用戶。
• 變革管理：預見抵觸情緒，及早識別並制定應對策略。

透過CNCF生態系的整合與技術治理，Kasan團隊成功實現了從小時到分鐘的平臺工程演進，為組織規模擴張與效能提升提供了可參考的實踐模型。