1. 课程导论：什么是 Policy as Code (PaC)？为什么需要回滚护栏？课程目标与学习路径
1.1 什么是 Policy as Code (PaC)？
Policy as Code（策略即代码）是一种将组织内的安全、合规、运维与治理规则，以机器可读的声明式或可编程语言进行编码，并通过自动化引擎在软件交付生命周期中持续执行的方法论。PaC 将传统依赖人工审核的“策略文档”转化为可版本控制、可测试、可审计的代码资产。
| 维度 | 传统策略管理 | Policy as Code |
|---|---|---|
| 表达形式 | PDF / Word 文档 | YAML / Rego / HCL / JSON |
| 执行方式 | 人工审核 + 事后检查 | 自动化门禁 + 实时阻断 |
| 版本管理 | 邮件附件 / 共享目录 | Git 仓库 + PR 评审 |
| 可测试性 | 无法自动化测试 | 单元测试 + 集成测试 |
| 反馈周期 | 数小时 ~ 数天 | 毫秒 ~ 秒级 |
核心洞察： PaC 将“策略”从静态文档转变为流水线中的一等公民——可执行、可断言、可追溯。在回滚场景中，PaC 是构建自动化护栏的技术基石。
1.2 为什么需要回滚护栏？
在持续交付流水线中，回滚并非简单的“撤销上一次部署”。缺乏护栏的回滚操作可能引入更严重的风险：
- 数据状态不一致： 数据库 Schema 回退导致数据丢失或外键冲突。
- 依赖版本错配： 回滚应用 A 但未回滚其依赖的服务 B，造成 API 兼容性断裂。
- 安全策略绕过： 回滚到未通过最新安全扫描的旧镜像，重新暴露已知漏洞。
- 配置漂移： 回滚后的环境配置与基础设施即代码（IaC）状态不一致。
- 合规违规： 回滚操作未记录审计日志，违反 SOC2 / PCI-DSS 要求。
回滚护栏是一组在回滚触发前、执行中、完成后自动执行的策略检查点，确保回滚操作本身是安全、合规且可审计的。PaC 为这些护栏提供了统一的策略定义与执行引擎。
常见误区： 不要将回滚护栏等同于“禁止回滚”。护栏的目标是让回滚在受控、可观测的前提下快速执行，而非阻止回滚。
1.3 课程目标与学习路径
本课程旨在帮助 DevOps、SRE 与平台工程团队掌握如何利用 Policy as Code 构建生产级的回滚防护机制，并将其无缝集成到 CI/CD 流水线中。
| 模块 | 核心能力 | 产出物 |
|---|---|---|
| 基础篇（第 1-5 章） | 理解 PaC 原理、回滚风险模型、策略引擎选型 | 回滚策略需求文档 |
| 策略设计篇（第 6-12 章） | 编写 Rego / OPA 策略、设计回滚前置检查与后置验证 | 可复用的回滚策略库 |
| 流水线集成篇（第 13-22 章） | 在 Jenkins / GitLab CI / GitHub Actions 中嵌入 PaC 门禁 | 带护栏的 CI/CD 流水线模板 |
| 进阶与实战篇（第 23-30 章） | 多集群回滚协调、审计链、策略性能优化、故障演练 | 生产级回滚护栏平台 |
1.4 PaC 驱动的回滚护栏架构总览
下图展示了本课程将要构建的核心架构：Policy as Code 引擎作为中央决策点，在回滚流水线的每个关键阶段注入策略检查。
学习建议： 本课程采用“策略先行”的教学路径。建议在学习每章时，先阅读策略代码示例，再理解流水线集成细节。所有示例策略均可在课程配套的 GitHub 仓库中找到。
1.5 本章小结
- Policy as Code 将安全与合规策略转化为可编程、可测试、可版本控制的代码资产。
- 回滚护栏 是防止回滚操作引入二次风险的关键机制，涵盖数据、依赖、安全、配置与合规五个维度。
- 本课程从基础概念到生产实战，逐步构建一套完整的 PaC 驱动回滚防护体系。
- 下一章将深入分析回滚场景中的常见风险模型，并建立策略需求矩阵。