企业官网建设流程全解析

1. 先把问题摊开：为什么企业最终都会走到 Policy-as-Code 这条路上

做基础设施或者平台工程的同行大概都有类似的经历：安全团队发来一份 PDF，里面写着"所有对象存储不得开启公共读写"；三个月后再查，仍然有几十个桶开着公共读。不是没人管，而是这份规则从诞生的那一刻起就只存在于文档里，它没有牙齿。Policy-as-Code 要解决的就是这件事——把原本写在制度文件、审批工单、老员工脑子里的判定逻辑，抽出来变成可版本管理、可自动执行、可测试的代码资产。它服务三类人：平台与 DevOps 团队用它做准入控制，安全合规团队用它把制度翻译成机器语言，业务研发则通过它获得即时反馈，而不是等到上线后被告警追着跑。

我在几个不同规模的团队里推过这套东西，最大的感受是：Policy-as-Code 从来不是技术问题，而是"策略资产如何被治理"的问题。工具选错可以换，流程设计错了会反复返工，规范缺失则半年后策略库变成一团没人敢动的意大利面。所以这篇内容按流程、规范、工具链三条线拆，尽量把每一步的判断依据和踩过的坑都摆出来，你拿去可以直接对照改造。

2. 需求拆解与方案选型：先想清楚判定点在哪里

2.1 传统策略管理到底断在哪几个环节

把策略停留在文档阶段的团队，通常会在四个地方同时失血。第一是不可执行，规则写得再清楚，落地依然依赖人去看、人去点，检查频率取决于谁有空。第二是不可测试，你没法验证一条新规则会不会把正常业务误伤，只能等它上线后炸出来。第三是不可追溯，半年后有人问"为什么这个资源被拦了"，翻遍工单也找不到当初是谁、基于什么理由加的规则。第四是不可复用，同一套镜像规范，容器平台写一遍、CI 流水线写一遍、云平台合规检查再写一遍，三份逻辑慢慢就漂移成了三个版本。

这四条里最要命的是第四条。我在一个项目里见过同一个"禁止 latest 标签"的检查存在三份实现，其中一份把latest写成了Lastest，一直没生效，也没人发现。策略一旦复制粘贴，就等于放弃了单一事实来源。Policy-as-Code 的第一个价值不是"自动化"，而是"收敛"——把所有判定逻辑收拢到一个仓库、一套语言、一份测试里。

2.2 用生活化的方式理解 Policy-as-Code

可以把它类比成小区门禁的演进。最早的形态是保安凭记忆放行，谁脸熟谁进，这就是人肉策略；后来变成一张纸质名单贴在门口，保安对着看，这是文档化策略，但名单更新要打印、要送过来，永远滞后；再后来是门禁卡加闸机固件，卡里的权限位就是代码，闸机是执行引擎，刷卡那一刻完成判定，这就是 Policy-as-Code。

这个类比里有一个关键点容易被忽略：闸机固件是声明式的——它只描述"什么卡在什么时间段可以进哪个门"，不描述"先抬左手再抬右手"的操作流程。策略代码也应该是声明式的，输入是一份资源描述，输出是一个允许或拒绝的判定，中间不掺杂任何副作用。一旦你在策略里写了发通知、调接口、改数据库这类动作，它就不再是策略，而是业务流程了，后面会讲这为什么是个大坑。

2.3 判定点分布决定了架构形态

选型之前必须先回答一个问题：你的策略要在哪些位置执行？常见的有四个判定点，各自的输入形态和技术要求完全不同。

大部分企业的第一站是前两个，因为收益最直接、改造成本最低。运行时的策略判定虽然听起来最酷，但它和业务代码耦合太深，出问题影响面大，我一般建议放到二期，等前两个判定点的流程跑顺了再谈。

2.4 四类方案怎么选，别被"通用"两个字骗了

市面上能叫得上策略引擎的东西可以分成四类，各有各的舒适区。

通用策略引擎（以 OPA 和它的 Rego 语言为代表）优势是判定点覆盖广，同一套语言能同时服务 IaC 扫描、容器准入、API 鉴权，缺点是 Rego 的学习曲线确实陡，团队里得有人愿意啃。平台内置的准入控制（比如容器编排平台自带的准入 webhook 机制）上手快、和平台贴合度高，但换一个平台就得重写，跨平台一致性差。静态扫描类规则（各类 IaC 扫描器）开箱即用、规则库丰富，问题在于自定义能力有限，遇到企业特有的合规要求就抓瞎。自研脚本看着最灵活，实际上是最贵的——没有统一的输入契约、没有测试框架、没有决策日志，半年后就变成只有作者本人敢改的黑盒。

我的判断标准很朴素：如果你的策略需要跨三个以上判定点复用，选通用引擎；如果只在一个平台内做准入，用平台原生机制更省事；如果只是想要一份合规基线报告，扫描器足够。别为了"架构统一"硬上通用引擎，然后发现团队没人会写 Rego，最后所有策略都堆在一个人身上，这比不做还危险。

3. 流程设计：策略从提出到退役要走完的每一道关

3.1 策略资产盘点：先分清哪些能交给机器

落地第一步不是装工具，是坐下来盘一遍现有的制度文件、安全基线、历史事故复盘、审计发现，把它们逐条拆成"可机器判定"和"需人工判定"两类。这一步的产出质量直接决定后面所有工作的天花板。

可机器判定的典型特征：有明确的对象、有明确的属性、有明确的比较关系。比如"存储桶不得对公网开放读写""容器镜像必须来自内部受信任的仓库""数据库实例必须开启备份且保留期不少于 7 天"，这些都是对象 + 属性 + 阈值的结构，机器一秒能判完。人工判定的典型特征：涉及上下文权衡、涉及架构合理性、涉及业务影响评估。比如"这个服务的拆分粒度是否合理""这个接口的设计是否过度暴露内部信息"，这类东西硬写成策略只会制造大量误报，把团队对策略系统的信任度消耗干净。

我见过一个团队试图把"代码是否有足够的注释"写成策略，规则是注释行占比不低于 15%。结果工程师开始写// 这是一行注释这种垃圾注释来凑数，策略通过了，代码质量反而更差。这就是把人工判定硬塞给机器的典型失败案例。

盘点的产出建议是张表，每行一条策略，字段包括：原始出处、判定对象、判定条件、可自动化程度、拟执行的判定点、初定严重级别。这张表就是后面策略仓库的雏形，别小看它，很多团队跳过这一步直接开始写代码，写到第三十条策略时发现前后逻辑打架，回头重来。

3.2 三级分级：不是所有违规都该阻断流水线

策略分级是整个流程里最容易拍脑袋、也最容易出事的环节。全设成阻断，业务团队三天两头被卡，怨气冲天；全设成告警，等于没设。我推荐三级，并且在设计阶段就把每一级的处置动作写死。

设计上的关键取舍是P0 的数量必须严格控制。经验值是不超过策略总数的 10%。P0 一旦泛滥，团队会集体想办法绕过整个系统，那时候你失去的不是几条规则，而是整个策略体系的权威性。我通常的做法是新策略一律先以 P2 上线跑两周，观察误报率，误报率低于 2% 再升 P1，跑满一个月稳定后才考虑 P0。

3.3 生命周期流程：八道关卡和各自的产出物

一条策略从提出到退役，我会设计成八个阶段，每个阶段都有明确的产出物和责任人，缺一环流程就会漏。

提出：任何角色都可以提，但必须填写理由（对应哪条制度、哪个事故、哪个审计项）。产出是一份策略提案，包含意图描述和期望的判定点。编写：策略工程师把它翻译成代码，同时写测试用例。产出是策略文件加测试文件，两者必须在同一个合并请求里。评审：至少两人，一个懂策略语言，一个懂业务场景。产出是评审记录。测试：在隔离环境用真实样本集跑一遍，统计命中数和误报数。产出是测试报告，误报率超标直接打回。灰度：以观察模式在部分项目上线，只记录不阻断。产出是两周的命中数据。全量：正式启用，同步更新文档和培训材料。监控：持续跟踪命中趋势和豁免申请量。退役：策略过期或被替代时，必须有明确的退役动作，包括清理豁免记录、归档决策日志。

这套流程听着重，实际跑起来一个策略从提案到全量大概两到三周。我试过压缩到三天全量上线，结果第二天就误伤了三个核心服务，因为某个字段在旧版本资源里是可选字段，策略假设它一定存在。灰度期存在的意义就是把这类的"假设错误"提前暴露出来。

3.4 三方分工：平台、安全、业务各管一段

组织分工不清是 Policy-as-Code 落地失败的第二大原因（第一大是分级失控）。比较顺的分工是这样的：平台团队负责引擎部署、流水线集成、策略执行的可观测性，是工具链的所有者；安全与合规团队负责策略内容的正确性，也就是"这条规则该不该有、阈值定多少"，是策略意图的所有者；业务研发负责在自己的仓库里接入、消费策略反馈、提交豁免申请，是策略的使用者。

有争议的点通常在"谁来写策略代码"。我的建议是平台团队提供模板和脚手架，安全团队写业务逻辑，实在写不动的部分由平台团队代笔但必须让安全团队逐行确认。千万别让平台团队独自把策略写完，他们对合规要求的理解往往差一层，写出来的规则看着对、实际漏判，而且安全团队因为没有参与感，后面推新规则时会非常被动。

4. 规范制定：让策略库半年后还能看、还能改

4.1 目录结构与命名：先定骨架再填肉

策略仓库的目录结构我一般按"判定点优先、领域其次"来组织，因为执行的时候是按判定点调用的，按领域分会导致流水线配置里到处是路径拼接。

policies/ ├── common/ # 跨判定点复用的库函数 │ ├── labels.rego │ └── network.rego ├── terraform/ # 基础设施代码判定点 │ ├── storage/ │ │ ├── deny_public_bucket.rego │ │ └── deny_public_bucket_test.rego │ └── database/ ├── kubernetes/ # 容器准入判定点 │ ├── workload/ │ └── network/ ├── metadata/ # 每条策略的元数据 │ └── policy_index.yaml └── exemptions/ # 豁免记录 └── exemptions.yaml

命名规范建议用"动作 + 对象 + 条件"三段式，全部小写下划线连接，比如deny_public_bucket、require_resource_limit、warn_missing_owner_label。动作只用三个动词：deny（阻断）、require（要求存在）、warn（告警）。这个约束看着吹毛求疵，实际上非常有用——半年后新人看文件名就知道这条策略干什么，不用点进去读逻辑。

要避免的是那种check1.rego、new_rule_final_v2.rego的命名，这种文件一旦超过二十个，整个仓库就废了。我在一个接手项目里见过test.rego和test2.rego并存，里面逻辑几乎一样但阈值差了一倍，没人知道哪个在生效。

4.2 元数据规范：每条策略必须自带说明书

策略代码只描述"怎么判"，元数据描述"为什么这么判、判错了找谁、怎么修"。这两部分必须绑在一起，否则策略库会迅速退化成无法维护的黑箱。

id: K8S-WORKLOAD-007 name: require_resource_limit severity: P1 owner: platform-team rationale: 缺少资源限额的工作负载在节点资源紧张时会挤占其他服务，历史上引发过两次集群级雪崩。 remediation: 在容器 spec 中添加 resources.limits 的 cpu 与 memory 字段，建议参考该服务近 7 天实际用量的 P95 值。 references: - 内部容量管理规范 第 3.2 节 - 事故复盘编号 INC-2023-0417 enforcement: mode: deny since: 2024-03-01 exemptions_allowed: true max_exemption_days: 90

这里有几个字段是必须的。rationale要写清楚业务影响，不要写"为了安全"这种废话；remediation必须给到可操作的程度，光说"请补充资源限额"等于没说，得告诉人家参考什么值来定；references把策略和制度、事故挂上钩，这是后面应对审计的关键证据链。

max_exemption_days是我强烈建议加的字段。没有期限的豁免等于永久豁免，我在一个项目里做过统计，超过 70% 的豁免记录在一年后依然存在，其中一半对应的服务早就下线了，豁免却还挂在那里。

4.3 豁免与例外管理：把"口头放行"变成可审计的代码

豁免管理是策略体系里最考验设计的地方。工程师被一条策略卡住了，最自然的反应是找人说一声"这次先放过"。这个口子一旦开在聊天工具里，整个策略体系就崩了。

正确的做法是把豁免本身也代码化。在仓库里维护一份豁免清单，每条包含策略 ID、目标资源标识、申请理由、审批人、生效时间、到期时间。流水线在判定时先跑策略，命中后查豁免清单，如果存在有效豁免则降级为告警，同时把"已豁免"这个状态写进决策日志。

exemptions: - policy_id: K8S-WORKLOAD-007 target: "namespace/prod-payment" reason: "遗留服务，资源画像采集中，预计下个迭代补齐限额" approver: "合规负责人代称" created: 2024-05-10 expires: 2024-08-10 ticket: "变更单号占位"

这套机制的好处是把"人情"转成了"数据"：豁免总量可以统计、到期可以自动提醒、超期可以自动失效。我在实践里加了个规则——豁免申请超过十条的团队，负责人会收到一份汇总，因为豁免密度本身就是个信号，说明要么策略阈值定错了，要么这个团队的基础设施欠账太多。

4.4 策略代码本身的写法约束

策略语言（尤其是 Rego）写得不好，可读性会断崖式下跌。我总结了几条硬约束，写进团队规范里。

一是单条策略只判一件事。把"存储桶不能公网可写、必须加密、必须有生命周期"三件事写在一个文件里，出问题时你根本定位不到是哪条命中。二是禁止在策略里做网络调用和状态变更，策略必须是无副作用的纯函数，输入确定则输出确定，否则测试和缓存全废。三是公共逻辑抽到 common 库里，比如标签校验、网络段判断这些高频逻辑，抽出来之后各条策略只引一行。四是每条策略必须配测试，测试文件与策略文件同名加_test后缀，覆盖率要求我一般定在 80%，剩下的 20% 留给"实在不好构造的极端输入"。

第五条约束容易被忽视：策略里不允许出现硬编码的账号标识、路径、命名空间。这些和环境强相关的值必须通过外部配置注入。我接手过一个策略库，里面硬编码了十几个命名空间名字，换环境之后全线报错，排查了半天才发现是这里的问题。

5. 工具链搭建：从本地编写到线上执行的闭环

5.1 引擎选型：声明式才是关键，不是语法

选引擎的时候，团队最容易被"支持多少种语言"这类宣传带偏。真正该看的是三件事：判定输入是不是结构化的数据、策略是不是声明式的纯函数、引擎是不是嵌入式的（能作为库被调用，也能作为独立服务被调用）。

声明式这一点值得展开说。用命令式的 if-else 脚本写策略，代码长这样："如果没有限额，就报错；如果命名空间在白名单里，就跳过；如果今天是周五，就……"。这种代码的复杂度随规则数量线性增长，最后没人敢改。声明式的写法是描述"什么样的输入算违规"，引擎负责匹配，规则之间天然解耦，加一条新规则不影响已有的。这个差别就像 SQL 和手写循环的区别，后者你永远不敢在别人的代码上动刀。

嵌入式能力也很重要。策略引擎如果只能作为独立服务部署，那每次判定都是一次网络往返，容器准入这种毫秒级场景直接歇菜。支持嵌入调用的引擎可以让宿主程序把策略加载进内存，判定在本地完成，延迟可以压到微秒级。

5.2 三层门禁：把反馈尽量往前推

工具链集成的核心原则是：能在本地发现的错误，绝不留到流水线；能在合并请求阶段发现的，绝不留到部署阶段。按这个原则设计三层门禁。

第一层是本地开发环境。给工程师提供命令行工具和编辑器插件，保存文件时就能看到策略判定结果。这层的价值在于缩短反馈循环，一次 FS 扫描 200 毫秒和一分钟差的不是时间，是耐心。同时配一个 pre-commit 钩子，提交前自动跑一遍策略自测，防止把错误的策略代码提上来。

第二层是合并请求阶段。流水线里跑三件事：策略代码自身的语法校验与单元测试、用真实资源样本跑一遍判定统计误报、把判定结果以评论形式贴回合并请求。第三件事很多人不做，但它的价值极高——工程师在合并请求里就能看到"你这次改动会触发 3 条 P1、12 条 P2"，比事后收到告警邮件有效得多。

第三层是部署前门禁。这一层是最后一道闸，必须是阻断式的。基础设施代码在 plan 之后、apply 之前插入判定，容器工作负载在提交到编排平台时由准入机制拦截。这一层的设计要点是失败信息必须包含修复指引，不能只吐一句policy violated。我见过最差的实现是只返回策略 ID，工程师得自己去仓库里查这个 ID 对应什么规则，一查就是五分钟，一天触发十次谁都烦。

5.3 流水线配置示例

以一个基础设施代码仓库为例，合并请求阶段的流水线大致长这样：

stages: - validate - policy_test - policy_scan - report policy_lint: stage: validate script: - policy-cli fmt --check ./policies - policy-cli check ./policies policy_unit_test: stage: policy_test script: - policy-cli test ./policies --coverage --min-coverage 80 artifacts: paths: - coverage.json policy_scan: stage: policy_scan script: # 先生成基础设施变更的计划文件 - iac-cli plan -out=tfplan.binary - iac-cli show -json tfplan.binary > plan.json # 用计划文件作为策略输入执行判定 - policy-cli eval --data ./policies --input plan.json --format json > result.json artifacts: paths: - result.json policy_report: stage: report script: - policy-cli report --input result.json --format markdown > comment.md - comment-cli post --file comment.md when: always

几个细节值得说。--format json输出结构化结果是为了后续统计，别用人类可读格式直接管道传递，解析起来很痛苦。判定步骤加了when: always是为了让它在前面失败时也能产出报告，否则工程师只能看到一个红色的叉，不知道具体哪条策略挂了。计划文件和判定输入之间要落盘保存，这样出问题时能拿着同一份输入复现，不然"本地没问题线上有问题"的扯皮能耗掉一整天。

5.4 决策日志与可观测性：没有日志等于没有策略

策略系统必须记录每一次判定的完整上下文：什么时间、哪个判定点、哪条策略、输入的关键字段、判定结果、耗时、是否命中豁免。这些数据是后续所有优化的基础。

日志的用途至少有三个。一是误报分析，统计每条策略的命中数和人工确认的误报数，误报率高的策略立刻回炉调整阈值。二是豁免治理，看哪些策略被豁免最多，豁免集中的地方往往是阈值定得过于严格。三是性能排障，策略判定的耗时分布要能看到 P99，容器准入场景下 P99 超过 10 毫秒就该查一查是不是某条策略写了低效的循环。

要提醒一句：决策日志里可能包含资源名称、标签这类信息，落盘前要考虑脱敏和保留期。保留期我一般设 90 天，够做趋势分析，也不会让存储无限膨胀。日志本身别写进业务数据库，单独一个时序存储更合适，查询模式完全不一样。

6. 实操走一遍：从零写一条策略并让它上线

6.1 需求确认与输入契约设计

假设要落地两条容器相关的策略：禁止容器以特权模式运行、禁止镜像使用浮动标签。先别急着写代码，先把输入契约定下来——策略的输入是什么形态的对象。

这里有个容易踩的坑。不同来源的资源对象结构差异很大，从编排平台 API 拿到的对象和从 YAML 文件读到的对象，字段层级可能不一样，可选项的默认值处理也不一样。我建议在策略仓库里先放一组标准输入样本，每条策略的测试都基于这些样本，保证判定逻辑面对的是统一的形态。

样本要覆盖四类情况：完全合规的、明确违规的、字段缺失的、字段存在但值为空的。第四类最容易被忽略，也是线上误报的主要来源。比如securityContext存在但里面没有privileged字段，这种情况该判合规还是违规？我的处理是判合规，同时出一条 P2 提示补全字段，因为大多数平台的默认值是false，符合预期的安全姿态。

6.2 策略代码与单元测试

判定"禁止特权模式"的逻辑，核心是遍历容器的securityContext.privileged字段，只要有一个容器为true就拒绝。判定"禁止浮动标签"的逻辑，是检查image字段是否以:latest结尾或者根本没有标签部分。

package kubernetes.workload import future.keywords.in # 收集所有容器的 securityContext containers[container] { some container in input.spec.containers } containers[container] { some container in input.spec.initContainers } # P0：禁止特权容器 deny[msg] { some container in containers container.securityContext.privileged == true msg := sprintf( "容器 %s 以特权模式运行，违反 K8S-WORKLOAD-001。修复方式：移除 securityContext.privileged 或显式设为 false。", [container.name] ) } # P1：禁止浮动镜像标签 deny[msg] { some container in containers endswith(container.image, ":latest") msg := sprintf( "容器 %s 使用浮动标签 latest，违反 K8S-WORKLOAD-002。修复方式：固定为具体版本或镜像摘要。", [container.name] ) } deny[msg] { some container in containers not contains(container.image, ":") msg := sprintf( "容器 %s 未指定镜像版本，违反 K8S-WORKLOAD-002。修复方式：固定为具体版本或镜像摘要。", [container.name] ) }

配套的测试要覆盖刚才说的四类样本，而且测试用例的名字要写清楚意图，不要用test1、test2。

package kubernetes.workload test_privileged_container_is_denied { deny[_] with input as { "spec": {"containers": [{ "name": "app", "image": "registry.local/app:1.2.3", "securityContext": {"privileged": true} }]} } } test_non_privileged_container_is_allowed { count(deny) == 0 with input as { "spec": {"containers": [{ "name": "app", "image": "registry.local/app:1.2.3", "securityContext": {"privileged": false} }]} } } test_missing_security_context_is_allowed { count(deny) == 0 with input as { "spec": {"containers": [{ "name": "app", "image": "registry.local/app:1.2.3" }]} } } test_latest_tag_is_denied { deny[_] with input as { "spec": {"containers": [{ "name": "app", "image": "registry.local/app:latest" }]} } } test_image_without_tag_is_denied { deny[_] with input as { "spec": {"containers": [{ "name": "app", "image": "registry.local/app" }]} } }

写完跑一遍，覆盖率不够就把缺失的分支补上。这一步花的时间通常在半小时到一小时，但它换来的是后面两周灰度的安心，非常划算。

6.3 接入准入控制与灰度策略

代码写完不代表能上线。第一版的接入模式我建议设成audit——只记录判定结果，不实际拦截。准入机制的配置里通常会有一个enforcementAction之类的开关，设成 dry-run 或者 audit 模式。

灰度期的观察指标我一般看三个：命中总量、命中资源的分布、以及误报确认数。命中总量突然飙高往往意味着有人在批量部署，这时候去打扰他们效果不好，等一波过去再说。命中资源的分布要看是不是集中在某几个团队，如果是，先私下沟通让他们清理，别在全量上线那天一次性炸出一堆失败。误报确认数是最关键的，两周内如果误报超过命中数的 5%，说明策略逻辑有问题，必须打回重写。

灰度转正式的那一步，我习惯挑业务低峰期，比如周三凌晨或者周末。不是为了迷信，而是给回滚留出足够的时间窗口。回滚方案必须提前演练一遍：把enforcementAction改回 audit 是分钟级操作，但如果策略本身导致准入服务崩溃，那就得把整个 webhook 从配置里摘掉，这个操作要提前写好脚本并验证过。

6.4 文档与培训：别指望大家自己去看仓库

策略上线的同时必须出一份面向业务的说明，内容就三块：这条策略要干什么、被拦住了怎么修、修不了怎么申请豁免。文档放哪儿不重要，重要的是入口要好找——我一般挂在内部开发者门户的策略目录页，同时在流水线失败信息里直接附上链接。

培训这件事不用搞大场面。我做过的效果最好的形式是十五分钟的小范围演示：现场挑一个真实被拦住的合并请求，演示一遍从看报错到改配置到通过的全过程。工程师看到"原来这么快就能修好"，抵触情绪会小很多。反过来，如果第一次被拦就折腾了半天还没搞清楚原因，后面他会想尽一切办法绕开你的系统。

7. 常见问题与排查技巧实录

7.1 典型故障速查表

下面这张表是我这几年攒下来的，基本覆盖了上线后八成的问题。

7.2 几个只有踩过才知道的坑

策略的输入不是你以为的那个对象。我遇到过一次，本地用 YAML 文件测试全部通过，上线后全部误报。原因是准入阶段拿到的对象经过了平台的默认值填充和字段转换，某些在 YAML 里不存在的字段被塞了默认值，而策略假设它不存在。解决方式是永远用真实链路抓下来的对象做测试样本，别用自己手写的 YAML。我现在会在灰度环境开一个采样开关，把前一百个真实对象脱敏后存进测试样本库。

策略之间的隐式依赖比显式依赖更可怕。有两条策略，一条要求必须有某个标签，另一条要求标签的值必须在枚举范围内。单测都过，一起跑的时候，资源没有这个标签，第一条报"缺标签"，第二条报"标签值非法"，同一个问题报两次，工程师一脸懵。处理方式是在策略设计阶段就画出依赖关系，能合并的合并，不能合并的让后置策略先判断前置条件是否满足。

豁免清单会成为新的技术债。前面提过，豁免必须有期限。我再补一条：豁免到期前七天要自动提醒申请人，到期后自动失效并在下一次判定时重新拦截。没有这个自动化的团队，豁免清单会在一年内膨胀成第二个策略库，而且没人敢清理。

别把策略当成唯一的防线。策略是准入控制，它只能拦住"不合规的新增"，管不了"已经存在的历史欠账"。存量资源的治理要靠定期扫描加专项清理，两条腿走路。我见过团队把策略做得非常完善，结果一统计，违规存量还有几千个，因为策略只管新增，老资源一直躺在那里。所以配套的存量扫描任务必须一起规划，扫描结果按团队分发，设定清理期限。

策略语言的性能陷阱。声明式语言写起来舒服，但嵌套遍历写多了性能会掉得很难看。一个典型的反例是在策略里对每个容器去遍历一遍全部命名空间列表做匹配，复杂度直接上到乘积级。优化的方向是把不变的数据放到 data 层而不是 input 层，引擎会对 data 做索引，input 则每次判定都要重新遍历。

7.3 一个关于推进节奏的个人经验

最后说点非技术的。Policy-as-Code 这类基础设施性质的改造，技术只占三成，剩下七成是推进节奏。我的经验是先做一条，做透，做出可见收益，再铺开。挑一条业务痛感最强的策略——通常是"禁止公网可写的存储"或者"禁止明文密钥入库"这类——把它从提案到全量完整走一遍，中间所有的流程文档、模板、脚手架都在这一条上打磨出来。

这条跑通之后，后面新增策略的成本会降到原来的三分之一，因为流程、模板、评审机制都已经就位。更关键的是，你有了一个可以拿去讲的故事：某次审计发现的问题，我们用一条策略在两周内彻底堵住了，而且以后不会再犯。这个故事比任何架构图都更能说服人。

反过来，如果一上来就规划三十条策略、五个判定点、全套工具链，大概率是三个月后交付了一个半成品，业务方觉得被折腾了一圈什么也没得到，后面再想推就难了。我见过太多这样的项目死在"宏大开局"上。策略这件事，慢就是快。