基础设施即代码（Infrastructure as Code，简称IaC）已经从可选的最佳实践变成了云原生团队的基础能力。Kubernetes 的 YAML 清单、Terraform 的 HCL 模块、Ansible 的 Playbook，这些文件和业务代码一样被提交到 Git 仓库，通过流水线应用到集群。但随之而来的问题是：基础设施代码的变更影响面远比业务代码大，一次错误的 SecurityContext 配置可能让整个命名空间暴露在风险中，一个写错的 replicas 字段可能导致线上容量骤减。治理与评审，就是为了让这类变更在一个受控、可追溯的轨道上进行。本文将从仓库结构、策略规则、评审流程三个层面展开讨论，给出可以直接落地的方案。
为什么IaC治理不能照搬业务代码的评审模式
很多团队在引入 IaC 的初期，直接把业务代码的 Code Review 流程搬过来：提 PR、找人审、合并、发布。这套流程对业务代码是够用的，因为业务逻辑的错误通常在测试阶段就能暴露。但基础设施代码有一个本质区别：它的执行效果往往不可逆，或者回滚成本极高。
举个例子，Terraform 执行 terraform apply 之后，如果 state 文件中记录的资源已经销毁重建，单纯地 git revert 并不能恢复数据。Kubernetes 中误删了一个带 finalizer 的 CRD，可能连带影响所有关联资源。这意味着 IaC 评审的重点不是代码风格，而是变更的影响半径、权限边界和失败后的恢复路径。
因此，IaC 治理体系至少要回答三个问题：谁有权改什么、改动的合法依据是什么、出问题后如何快速止损。这三个问题分别对应权限模型、策略规则和回滚机制，下面逐一展开。
分层仓库结构与权限模型设计
治理的第一步是把代码组织好。常见的做法是将基础设施代码分为三层：基础层（网络、集群节点池、存储）、平台层（命名空间、RBAC、Ingress、监控组件）和应用层（Deployment、Service、ConfigMap）。分层的好处是变更频率和风险等级天然分离，基础层一个月可能改一次，应用层一天可能改十次，评审规则自然应该不同。
在仓库形态上有 Monorepo 和 Polyrepo 两种选择。中小团队推荐 Monorepo 配合 CODEOWNERS 机制，路径即权限边界：
# .github/CODEOWNERS 示例 # 基础层变更必须由平台组核心成员评审 /infra/base/ @platform-core # 平台层由平台组任意成员评审 /infra/platform/ @platform-team # 应用层由应用所属团队自行评审 /apps/team-a/ @team-a-leads
CODEOWNERS 把「谁有权改什么」从口头约定变成了强制的代码规则，任何触碰对应目录的 PR 都会自动要求指定团队评审，绕不过去。对于权限更敏感的场景，比如生产集群的 kubeconfig、云厂商的 AK/SK，应该完全排除在代码仓库之外，改用 Vault 或云厂商的密钥管理服务，仓库里只保留引用占位符。
分支保护也是权限模型的一环。基础层可以要求两名评审人加线性历史，应用层一名评审人即可。关键是规则要和风险等级匹配，一刀切地要求所有目录双人评审，只会让开发者想办法绕过流程。
策略即代码：让机器先审一遍
人的评审容易被疲劳和人情稀释，策略即代码（Policy as Code）可以把硬性规则交给机器执行。核心思路是：用代码定义「什么样的配置是合法的」，在 CI 阶段自动校验，违规直接阻塞流水线。
目前生态中最通用的是 OPA（Open Policy Agent）配合 Rego 语言。以 Kubernetes 清单为例，要求所有容器禁止以 root 身份运行、必须设置资源限制，策略可以写成这样：
package kubernetes.admission
deny[msg] {
container := input.spec.template.spec.containers[_]
not container.securityContext.runAsNonRoot
msg := sprintf("容器 %s 未设置 runAsNonRoot", [container.name])
}
deny[msg] {
container := input.spec.template.spec.containers[_]
not container.resources.limits
msg := sprintf("容器 %s 缺少资源限制", [container.name])
}
在 CI 中用 Conftest 对清单文件批量校验：
# 对 manifests 目录下所有 YAML 执行策略校验 conftest test manifests/ --policy policy/
Terraform 场景下也有对应工具。tfsec 专注于安全扫描，能识别安全组过度开放、磁盘未加密等常见问题；Checkov 则覆盖更广的合规规则集，支持自定义策略。建议把这两类工具都接入流水线，安全类规则设为阻塞级别，风格类规则只输出警告。
策略规则本身也应该走代码评审。把策略文件放在独立目录，策略的每次收紧或放宽都是一次显式的 PR 讨论，留下完整的决策记录。这比评审时口头争论「到底要不要禁用 latest 镜像标签」要有效得多。
把评审流程做成可执行的规范
机器审硬规则，人审软决策。人的评审需要一份明确的 Checklist，避免每个评审人凭感觉发挥。一份实用的 IaC 评审清单至少包含这些条目：变更影响哪些环境、是否有对应的回滚方案、资源配额是否会产生成本变化、是否引入新的外部依赖、密钥是否被硬编码。
PR 的呈现方式也很关键。要求变更者在 PR 描述中填写变更目的、影响范围、验证方式三段式说明，评审效率会显著提升。对于 Terraform 变更，强制在 PR 中粘贴 terraform plan 的输出摘要，让评审人直接看到资源的增删改计划，而不是靠脑内推演。可以借助 Atlantis 或 terraform-ci 这类工具，在 PR 评论里自动触发 plan 并回贴结果。
# PR 模板示例 .github/pull_request_template.md 摘要 # 变更目的：为什么做这次修改 # 影响范围：涉及的环境、集群、命名空间 # 回滚方案：出问题时如何恢复 # 验证方式：如何在预发环境验证
最后要建立评审的度量与反馈机制。统计 PR 从提交到合并的时长、策略拦截的违规次数、回滚频率，这些数据能告诉你治理规则是否过严或过松。规则太严，开发者会想方设法申请例外；太松，则形同虚设。治理不是一次性的制度设计，而是随着团队规模和系统复杂度持续迭代的工程实践。
总结来看，IaC 治理的核心是把「约定」沉淀为「代码」：仓库结构约定职责边界，CODEOWNERS 约定权限，OPA 策略约定合法性，PR 模板约定评审质量。当这些环节彼此咬合，基础设施变更的每一次落地都有据可查、有人负责、有路可退，这才算真正实现了基础设施即代码的价值。