玉山銀行四階段導入Policy as Code，打造具彈性、共創的治理機制

玉山銀行智能金融處（簡稱玉山智金處）在去年將整套AI的開發流程遷移上雲，開發人員開始能在雲端平臺自行宣告並建立資源，不再像以往需要等待平臺團隊、耗時3到5天協助架設環境。上雲後，雖然為開發人員帶來更大的自主性，提升不少開發效率，卻也帶來新的挑戰——治理責任不再集中於平臺團隊，而是擴張到每位開發人員。

這個轉變，讓玉山智金處更加體認到清楚定義邊界的重要性，包括詳細定義命名規範、安全性措施、加密限制等規範。因為當邊界設立明確，開發人員才能在範圍內自由宣告資源。然而，這些規範多半分散在跨團隊的各式文件中，導致負責審核的技術團隊主管或資深工程師，往往需要仰賴記憶、經驗或印象來審視每段程式碼。合規的重擔集中在他們身上，長期下來，也增添了不少人員壓力。

為了解決這項問題，玉山智金處導入了政策即代碼（Policy as Code,PaC），來自動化審核流程。在今年DevOpsDays Taipei活動上，玉山銀行智能金融處副主任工程師、DevOps 團隊成員吳明倫揭露了他們的作法。「當基礎建設走向去中心化，治理就不能再靠記憶與默契。」吳明倫說，這正是他們決定導入PaC的關鍵原因。

PaC適用的三大場景

吳明倫點出，PaC適合用來協助開發團隊落實三類規範，分別是硬限制、軟規範，和業務規則。

硬限制大多泛指組織內部針對基礎設施層設置的限制，包括網路VPC、防火牆設定，或整個組織層級的政策限制等，「這些限制要求開發人員在宣告資源時要遵循特定規則，才能正常使用服務。」吳明倫以過往經驗解釋，曾有開發人員啟動虛擬機後，看似順利完成部署，卻在後續發現系統無法安裝套件。原因是，後端的服務白名單並未開通開發人員選用的作業系統，最終，開發人員只能將整臺機器砍掉重建，「這就是被硬限制擋住。」吳明倫說。

軟性規範指的是組織內部的命名原則或標籤制度，對單一工程師或團隊來說，可能不會帶來直接影響。然而，若組織成員並未遵守這些規範，將大幅增加治理成本。例如，在進行帳單分類或建立自動化維運機制時，若未統一命名，就容易產生管理混亂問題，和執行上的困難。

第三類規範則是業務規則，這些規則是由團隊根據業務需求訂定的標準。以玉山智金處為例，ML團隊可能會要求開發人員須在資料表上標註資料上游，或是在訓練任務中註記對資料中心的負載量。

蒐集初始政策、四階段導入PaC

玉山智金處是如何一步步在組織內導入PaC？第一步，是要先蒐集政策。

吳明倫表示，玉山智金處原先即採用集中化的 CI/CD 流程，協助開發人員將AI模型快速部署為服務，因此，平臺團隊在導入PaC時，只需在既有流程前加上一層檢查機制，「但困難的是，第一批政策要從哪裡來？」

玉山智金處從三個方向著手建立第一批政策。除了透過開源社群取得現成的檢查工具，他們也訪談了內部治理角色，包括上雲管理小組、SRE團隊與平臺團隊等，彙整治理人員在現行開發流程中發現的痛點，並轉化為政策。最後，他們也回頭檢視既有CI/CD流程中的可觀測性數據，從過往部署失敗的案例中歸納常見問題，進一步轉化為政策，希望藉此降低開發人員的出錯機率。

第二步，是以漸進式的方式導入PaC。玉山智金處用四階段慢慢導入PaC。

第一階段是探索期，並不是直接套用規範，而是先建立一套能收集、驗證PaC的機制。具體作法是，在既有的CI/CD流程前加上一層PaC掃描機制，並蒐集一些可建立的政策。到了第二階段，才開始啟動PaC機制。這個階段稱為無感期，當開發人員使用CI/CD過版時，背後其實已經啟用了PaC掃描機制，但開發人員不會收到任何提醒或阻擋的訊息。吳明倫解釋，由於部分政策來自開源社群，未必適用於組織採用的架構，因此，無感期的目的，是要檢視現有蒐集的政策是否適合組織運作。

第三階段，則是進入適應期。在這個階段，若開發人員在過版過程中違反政策，系統會出現提示。但是，系統不會中斷部署流程，「目的是希望讓開發人員開始習慣過版過程中的PaC檢查。」吳明倫說。最後一個階段則是落實期，規範正式上線，平臺能自動協助開發人員進行規範檢查。

建立Suppress機制，創造治理的彈性空間和回饋機制

不過，當PaC機制正式上線後，開發人員就會買單了嗎？當系統發生異常，開發人員需要緊急修正，卻被PaC攔截，平臺團隊就得面臨要堅持執行政策，或是短暫通融的兩難。若選擇前者，可能影響團隊氣氛；選擇後者，雖能維持關係，卻容易不斷累積技術債。甚至，每次緊急情況發生，都可能重演同樣戲碼，長期下來，PaC機制也難以真正落地。

面對這個典型情境，吳明倫強調，建立Suppress機制，是讓PaC可以成功落地的關鍵。他解釋，Suppress是一種能在Terraform或IaC程式中加入的特定格式註解，平臺人員可以填寫略過的政策編號和理由，例如架構限制或緊急修正（Hotfix）。這段註解經過人工核准後，PaC機制在執行特定條件時，便會自動略過對應的檢查，並將相關說明紀錄在過版軟體中。如此一來，組織內就能建立一套較彈性的PaC機制。「我們要保留彈性空間，但不應該由人去開後門，而是透過正規流程、留下紀錄、通過適當的審核機制後，最後由PaC識別。」吳明倫說。

除了提供彈性空間，吳明倫認為，Suppress機制也能創造回饋機制。對開發團隊主管而言，他們能根據Suppress跳過的政策，來進一步檢視團隊既有的技術架構是否適當。對平臺團隊而言，若同時有多個團隊跳過同一條政策，他們也能回頭檢視、調整既有政策。

讓PaC機制可由開發團隊訂定政策

不只要讓PaC機制作為一套管制工具，玉山智金處更期望開放所有開發人員自主制定團隊政策。吳明倫解釋，相較於平臺團隊，開發人員每日與IaC實際互動，更能產出高品質的政策。他提到，當開發團隊擁有自訂政策的空間，就能依照需求延伸出更貼近業務的規範，甚至，跨團隊在合作產出專案時，也能彼此交流團隊專屬規範，又或者，當某條團隊內部的政策解決了跨團隊共通性痛點，也能讓整個組織一同受益。

為了在PaC中加入這套架構，玉山智金處盤點所有PaC工具，最後選擇使用Checkov。吳明倫解釋，玉山智金處有八成以上成員為ML工程師，最熟悉的語言是Python，因此，他們選擇使用能以Python定義政策的PaC工具，來讓所有開發人員都能實踐這套機制。

導入PaC的三大效益

導入PaC後為玉山智金處帶來了三個效益，第一，是減輕審核人員的負擔。吳明倫表示，透過自動化檢查，審核人員只需要專注檢視程式的核心邏輯，而不需要在每次過版時都耗時確認過程是否符合所有組織規範。再來，是提升開發人員經驗。當開發人員在部署時發生問題，可以透過視覺化報表，快速了解自己觸犯哪些規則，進一步解決問題。同時，這套機制也能協助降低開發團隊和平臺團隊之間的溝通成本。對新進的開發人員而言，導入PaC也能降低學習曲線，讓新人更快速熟悉組織內部規範。

最後，吳明倫強調，「治理的關鍵不是限制，而是要讓好規則被實踐。」他提醒，導入PaC，是要讓規則變得說得清、改得動，「並不是單純設定一個規則，而是要設定變化的節奏。」例如設置Suppress機制，來創造彈性空間，同時建立協作和回饋機制，讓治理能持續演進。他也提到，設置PaC時，盡量不要讓規則專屬某一團隊，而是讓規則成為組織的共識。創造社群氛圍，才能讓治理更順暢運作。「重點不是控制，而是打造一個互相理解、協助的環境。」他說。