变更审批与 PR Review 流程

核心问题：基础设施变更风险极高——怎样通过流程和工具保证每次变更都经过审查、测试和审批？

IaC 变更的四眼原则

没有人应该能够独自把未经审查的基础设施变更推到生产。最小审批流程：

GitHub CODEOWNERS

CODEOWNERS 文件定义哪些人必须审批哪些文件的变更：

# .github/CODEOWNERS
# 所有 Terraform 变更必须经过 SRE 团队审批
infra/**/*.tf                @myorg/sre-team
# 生产环境变更额外需要 SRE Lead 审批
infra/environments/production/  @myorg/sre-team @myorg/sre-lead
# K8s RBAC 变更必须经过安全团队
k8s/**/rbac*.yaml             @myorg/security-team
# Helm Charts 变更必须经过应用团队 Lead
charts/**                     @myorg/platform-team
# ArgoCD Application 配置必须经过平台团队
clusters/**                   @myorg/platform-team @myorg/sre-team

PR Review 清单

# IaC PR Review Checklist
## Terraform 变更
- [ ] 有无 `-/+` 替换（删除重建）操作？是否知晓影响？
- [ ] 有无意外 `-`（删除）操作？
- [ ] state 变更是否符合预期？
- [ ] 安全组规则是否遵循最小权限？
- [ ] 是否有新的 IAM 权限授予？最小权限原则？
- [ ] 资源名称、标签是否符合命名规范？
- [ ] Checkov/tfsec 扫描是否通过？
- [ ] 变更影响范围：是 production 还是 staging？
## Kubernetes 变更
- [ ] 镜像 tag 是否具体版本（非 latest）？
- [ ] 是否设置了 resources requests/limits？
- [ ] 是否配置了 readiness/liveness 探针？
- [ ] PodDisruptionBudget 是否考虑了可用性？
- [ ] 是否有敏感信息明文写入？
- [ ] RBAC 变更是否必要，权限是否最小？
## 通用
- [ ] 是否有对应的测试或验证步骤？
- [ ] 是否更新了相关文档/CHANGELOG？
- [ ] 部署后怎样验证变更生效？
- [ ] 如果变更失败，回滚步骤是什么？

Atlantis：PR 驱动的 Terraform 工作流

Atlantis 把 Terraform plan/apply 的触发权交给 PR 评论：

# atlantis.yaml
version: 3
automerge: false
projects:
- name: prod-vpc
dir: infra/environments/production/vpc
terraform_version: v1.6.0
autoplan:
when_modified: ["*.tf", "../../../modules/vpc/**/*.tf"]
enabled: true
apply_requirements:
- approved          # 需要 CODEOWNERS 批准
- mergeable         # PR 无冲突
- undiverged        # 与 main 没有分叉
- name: prod-eks
dir: infra/environments/production/eks
depends_on: [prod-vpc]
apply_requirements:
- approved
- mergeable

# PR 中评论 atlantis 命令
atlantis plan          # 触发 plan
atlantis plan -p prod-vpc  # 只 plan 指定 project
atlantis apply         # 触发 apply（需要已批准）
atlantis unlock        # 解锁当前 PR 的状态

变更风险等级矩阵

变更冻结（Change Freeze）

生产发布前后、节假日期间，设置自动拒绝生产变更：

# Atlantis 项目级冻结策略
projects:
- name: prod-all
apply_requirements:
- approved
- mergeable
- custom:
name: no-change-freeze
command: |
# 检查当前是否在变更冻结窗口
current_hour=$(date -u +%H)
day_of_week=$(date -u +%u)
# 工作日 UTC 8:00-18:00 才能 apply
if [ "$day_of_week" -gt 5 ] || [ "$current_hour" -lt 8 ] || [ "$current_hour" -ge 18 ]; then
echo "变更冻结：仅工作日 UTC 8:00-18:00 允许生产变更"
exit 1
fi

完整 IaC 安全防线

代码提交阶段：
✅ pre-commit hooks：terraform fmt / validate / tfsec
✅ CODEOWNERS 自动分配 reviewer
PR 阶段（CI Gates）：
✅ terraform fmt -check（格式检查）
✅ terraform validate（语法检查）
✅ tfsec / checkov（安全扫描）
✅ terraform plan（变更预览，自动评论到 PR）
✅ OPA/Conftest（策略检查）
审批阶段：
✅ CODEOWNERS 必须审批
✅ 变更风险评估
✅ 变更时间窗口检查
Apply 阶段：
✅ Atlantis apply（仅审批通过后可触发）
✅ terraform apply -input=false（非交互模式）
运行时防线：
✅ Gatekeeper Constraints（阻止不合规资源进集群）
✅ AWS Config Rules（云资源合规持续检查）
✅ Falco（运行时威胁检测）
---
## 本书总结
恭喜！你已完成《基础设施即代码实战指南》全部 12 章。
| 阶段 | 掌握的技能 |
|------|-----------|
| **Ansible（Ch02–03）** | 批量管理服务器配置，Role 复用，多环境管理，密钥安全 |
| **Terraform（Ch04–05）** | 声明式云资源管理，模块化，多账号，CI/CD 集成 |
| **Kubernetes（Ch06–07）** | Pod/Deployment/Service，存储，自动扩缩容 |
| **Helm（Ch08）** | 应用打包，版本管理，私有仓库 |
| **GitOps（Ch09）** | ArgoCD，声明式部署，漂移检测 |
| **可观测性（Ch10）** | Prometheus + Grafana 监控栈，告警 |
| **多集群（Ch11）** | RBAC，Namespace 隔离，环境晋级 |
| **安全合规（Ch12）** | 静态扫描，策略执行，变更审批 |
## 推荐下一步
- **[DevOps 实战指南](../../devops-guide/README.md)**——复习 Linux 服务器运维基础
- **[网络工程实战指南](../../networking-guide/README.md)**——深入理解 VPC/子网/安全组背后的网络原理
- **参加 CKA 认证**（Certified Kubernetes Administrator）——系统检验 Kubernetes 知识
> **从这里再出发**：
> - 把本书的 Ansible Playbook 应用到你的真实服务器
> - 用 Terraform 把下一个项目的 AWS 资源代码化
> - 把最重要的生产应用迁移到 Kubernetes + GitOps

全书完。 掌握 IaC 不是一蹴而就，每一步都值得动手实践。