玉山银行智能金融处透过四阶段导入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时，尽量不要让规则专属某一团队，而是让规则成为组织的共识。创造社群氛围，才能让治理更顺畅运作。「重点不是控制，而是打造一个互相理解、协助的环境。」他说。