邱繼平 (山姆大叔)
架構師
我是邱繼平(山姆大叔)，Microsoft MVP（DevOps） ，現任架構師，專注於企業 DevOps 治理、平台工程與雲端原生架構。
近年持續推動 Azure DevOps、Kubernetes、API Gateway 與多雲平台治理，致力於將組織中隱性的交付知識轉化為可理解、可治理、可追蹤的工作流程。目前負責以 Azure DevOps 為平台核心，推動 Azure、Kong API Gateway 與多叢集 Kubernetes 平台的治理與自動化。
除了實務導入外，也長期投入技術社群分享，兩屆iThome 鐵人賽優選作者，並曾擔任最佳團隊獎團長。《我要招架一切【痛點】：從工程師到開發團隊的 Azure DevOps 冒險指南》作者，曾於 Hello World Dev Conference、DevOpsDays Taipei 等技術研討會分享企業 DevOps 實踐。
我相信，真正的 DevOps 不只是導入工具，而是讓每一位參與者都能理解整個工作流，並讓治理成為組織持續演進的能力。
不填表，也能被治理：理解自助服務如何長成黃金路徑
在推動 Pipeline as Code 的過程中，我原本只想解決一個看似單純的問題：當應用程式從 DEV、SIT 進入 UAT 與 PROD，散落在各個 Kustomize Overlay 中的大量 `secret.yaml`，究竟要如何被整理、建立、填值與部署？
真正困難的並不是 Secret 應該放在 Azure DevOps Library，還是 Azure Key Vault，而是每一次交付都必須在開發者、持密者與雲端基礎設施管理者之間反覆換手。開發者先整理需求，基礎設施人員再將需求翻譯成 Portal 操作、CLI 指令或 IaC；持密者接手後，還可能因 Secret Key、環境或資源位置不一致而產生新的摩擦。當單一領域在一個環境就可能出現數十份 `secret.yaml` 時，這種依賴人工理解與轉譯的流程，很快就無法承受規模。
我沒有完整的平臺團隊，也不可能為此先導入 Backstage。於是，我選擇使用開發者每天最熟悉的 Azure DevOps Repos、Pull Request 與 Pipeline 作為平臺入口，並以 Bicep 主模板封裝 Azure Key Vault、Secret Container、IAM、Tag 與資源配置的複雜度，讓開發者只需要填寫如同結構化表單的 `bicepparam`。
這份參數檔不再是一張需要由另一個人重新解讀的申請單，而是一份可以版本控制、審查、自動驗證並直接執行的宣告式換手契約。Pull Request Pipeline 透過 Azure Validate 與 What-if 提供審查證據，合併後則自動建立資源。開發者可以使用熟悉的 Git 與 Pull Request 流程提出需求，審核者也不必依靠記憶逐項找錯，而能根據自動化結果判斷是否放行。
不同環境則以 IAM 與 Service Connection 切分權限。開發者可以在 DEV、SIT 親自操作與填入 Secret Value；在 UAT、PROD 則只能查看 Secret Key 與 Metadata，無法取得真正的 Value，由持密者完成填值。這項設計讓 IAM 不只是限制存取的安全護欄，也成為一條學習路徑：開發者先在低風險環境理解持密者的操作視角，未來才能更精確地描述需求與協助跨角色合作。
然而，第一版上線後並不完美。我們陸續遇到 `bicepparam` 檔名與 Key Vault 名稱不一致、資源進入錯誤環境、分支未基於最新 Main、必要 Tag 遺漏，以及重複宣告 Secret 可能影響既有 Value 等問題。這些錯誤沒有停留在「提醒使用者下次注意」，而是被逐步轉換成新的 Pipeline 檢查、Azure Policy 與審查證據。
使用者也回饋，大量 Secret 若需要逐筆填入，開發者與持密者都將承受新的操作負擔。因此，平臺又長出了共用的取框與填密工具：先依照 Key Vault 中既有的 Secret Key 產出不含 Value 的 JSON 或 YAML 框架，再由具備適當 IAM 權限的使用者批次填入。工具後續也因特殊字元與 JSON 跳脫問題，增加偵測機制及 YAML 格式，並持續更新 README、ADR 與 Changelog。
這些護欄與工具並不是在第一版架構中一次規畫完成，而是在「投入使用、發現問題、接收回饋、補強護欄、再次投入使用」的循環中逐漸形成。我們也透過早期合作團隊，在規模仍小、錯誤仍容易控制時，快速驗證流程並修正產品。
一個月內，近百座 Azure Key Vault 透過這條路徑被建立。過去需要由基礎設施人員逐筆接收表單、重新理解需求並轉換成雲端操作的工作，逐漸成為開發團隊可以自助使用，同時維持透明度、可稽核性與可追蹤性的平臺能力。
我原本以為這只是 CD 範本、自動化流程與幾項工具的組合，後來才理解，它已經具備 Self-service、Golden Path 與 Platform as a Product 的特徵。這場分享將透過這段從換手問題、MVP、真實錯誤到護欄演進的實作歷程，探討如何不先建立新的 Portal，而是在既有的開發者工具中，讓一項基礎設施能力逐漸產品化，並成長為組織可以重複使用的黃金路徑。
聽完這場分享，聽眾將可以：
- 1. 理解如何從價值流中的等待、翻譯與跨角色換手問題，辨識適合被產品化的平臺能力，而不只是將既有人工流程直接自動化。
- 了解如何利用既有的 Repository、Pull Request、Pipeline 與 IaC，建立不依賴新 Portal 的 Self-service 入口，並將參數檔轉化為開發者與平臺之間可審查、可執行的宣告式契約。
- 學習如何組合 Azure Validate、What-if、Pipeline Check、Azure Policy、IAM 與 Service Connection，在降低人工審查負擔的同時，維持安全性、透明度、可稽核性與可追蹤性。
- 重新思考 IAM 的用途：除了最小權限與環境隔離，也能透過 DEV、SIT 的安全試錯空間，建立開發者理解其他角色工作視角的學習路徑。
- 帶走一套讓 Golden Path 持續演進的方法：從早期使用者的真實錯誤與操作回饋中，判斷問題應由文件、工具、Pipeline、Policy 或 IAM 哪一層承接，並將一次性的經驗轉換成下一位使用者可以重複使用的產品能力。