3. IaC 变更生命周期:计划阶段、实施阶段、验证阶段、回滚阶段、变更口径的建立
IaC 变更并非一次性操作,而是一个包含多个阶段的闭环过程。每个阶段都对应特定的 SLI 口径与校准动作。本章将拆解变更生命周期的四个核心阶段,并说明如何在每个阶段建立与维护变更口径。
3.1 变更生命周期全景
一个完整的 IaC 变更生命周期包含以下四个阶段,每个阶段都有明确的输入、输出与口径管理目标:
| 阶段 | 核心活动 | 口径管理目标 | 典型 SLI 示例 |
|---|---|---|---|
| 计划阶段 | 变更方案设计、资源影响评估、口径基线确定 | 建立变更前的口径基线,识别口径漂移风险 | 计划变更资源数、影响范围覆盖率 |
| 实施阶段 | 执行 IaC 代码、资源创建/更新/删除 | 实时监控口径偏差,确保变更按预期执行 | 执行成功率、资源创建延迟、口径偏差率 |
| 验证阶段 | 变更后状态校验、口径一致性检查 | 验证变更后口径与预期口径的一致性 | 口径匹配率、验证通过率、口径漂移量 |
| 回滚阶段 | 变更撤销、状态恢复、口径回退 | 确保口径回退到变更前基线,避免残留漂移 | 回滚成功率、口径恢复时间、残留漂移率 |
3.2 计划阶段:口径基线的建立
计划阶段是变更口径管理的起点。在此阶段,SRE 团队需要完成以下关键动作:
- 确定变更范围:明确本次变更涉及的资源类型、数量与依赖关系。
- 建立口径基线:从可观测性平台导出当前资源的 SLI 口径快照,作为变更前的基准。
- 识别漂移风险:分析变更可能引发的口径漂移点,制定预防措施。
口径基线建立示例(Terraform + Prometheus):
# 在计划阶段导出当前口径基线
# 使用 Terraform plan 输出与 Prometheus 指标对比
# 1. 导出 Terraform 计划中的资源清单
terraform plan -out=plan.tfplan
terraform show -json plan.tfplan > plan.json
# 2. 从 Prometheus 查询当前资源口径
# 查询示例:当前 EC2 实例数
curl -G 'http://prometheus:9090/api/v1/query' \
--data-urlencode 'query=count(aws_ec2_instance_state{state="running"})'
# 3. 对比计划资源数与实际资源数,建立基线差异报告
python3 compare_baseline.py --plan plan.json --prometheus prometheus.json
3.3 实施阶段:实时口径监控
实施阶段是口径漂移的高发期。IaC 执行过程中,网络延迟、API 限流、资源冲突等因素都可能导致实际创建的资源与预期口径不一致。
实施阶段的监控要点:
| 监控维度 | 监控指标 | 告警阈值 | 漂移类型 |
|---|---|---|---|
| 资源数量 | 实际创建数 vs 计划创建数 | 偏差 > 0 | 数量漂移 |
| 资源配置 | 实际参数 vs 模板参数 | 任意参数不匹配 | 配置漂移 |
| 依赖状态 | 依赖资源就绪状态 | 超时 > 30s | 依赖漂移 |
| 执行延迟 | 资源创建耗时 vs 预期耗时 | 延迟 > 2x 基线 | 性能漂移 |
最佳实践:在实施阶段启用 变更前快照对比 机制。每次执行 terraform apply 或 kubectl apply 前,自动生成当前资源口径快照,与计划阶段基线进行实时比对。一旦发现偏差超过阈值,立即暂停变更并触发告警。
3.4 验证阶段:口径一致性校验
验证阶段的核心目标是确认变更后的实际状态与预期口径完全一致。验证动作应在变更完成后立即执行,并形成正式的验证报告。
验证阶段的标准流程:
- 自动触发验证:变更完成后,CI/CD 管道自动触发口径校验任务。
- 多维度对比:对比 IaC 模板、实际资源状态、可观测性指标三个维度的口径数据。
- 漂移量化:计算口径漂移量,生成漂移报告。
- 决策判定:根据漂移量阈值判定验证通过或触发回滚。
口径一致性校验脚本示例:
#!/bin/bash
# verify_drift.sh - 验证变更后口径一致性
# 定义预期口径(来自 Terraform state)
EXPECTED_COUNT=$(terraform state list | grep -c "aws_instance")
# 定义实际口径(来自 AWS API)
ACTUAL_COUNT=$(aws ec2 describe-instances \
--filters "Name=tag:Environment,Values=production" \
--query "Reservations[].Instances[].[InstanceId]" \
--output text | wc -l)
# 计算漂移量
DRIFT=$((ACTUAL_COUNT - EXPECTED_COUNT))
echo "预期资源数: $EXPECTED_COUNT"
echo "实际资源数: $ACTUAL_COUNT"
echo "漂移量: $DRIFT"
# 判定阈值(允许 ±1 的浮动)
if [ $DRIFT -gt 1 ] || [ $DRIFT -lt -1 ]; then
echo "口径漂移超出阈值,触发回滚"
exit 1
else
echo "口径一致性验证通过"
exit 0
fi
3.5 回滚阶段:口径基线恢复
当验证阶段发现口径漂移超出可接受范围时,必须启动回滚流程。回滚阶段的口径管理目标是:将系统状态恢复到变更前的口径基线,且不产生残留漂移。
回滚阶段的关键动作:
- 执行回滚操作:使用 IaC 工具的回滚能力(如 terraform destroy、kubectl rollout undo)撤销变更。
- 口径恢复校验:回滚完成后,再次执行口径一致性校验,确保与变更前基线完全一致。
- 残留漂移清理:如果回滚操作本身产生了残留资源(如未删除的临时资源),需手动或自动清理。
常见陷阱:回滚操作本身也可能引入新的口径漂移。例如,terraform destroy 可能因依赖关系未能删除所有资源,导致残留漂移。建议在回滚后执行 两次校验:第一次校验回滚是否成功,第二次校验口径是否与基线一致。
3.6 变更口径的建立方法
变更口径的建立是贯穿整个生命周期的系统性工作。以下是建立变更口径的标准方法:
| 步骤 | 动作 | 产出物 | 工具/方法 |
|---|---|---|---|
| 1 | 定义口径维度 | 口径维度清单 | 资源类型、数量、配置、依赖、标签 |
| 2 | 建立口径基线 | 基线快照文件 | Terraform state + Prometheus 快照 |
| 3 | 设定漂移阈值 | 阈值规则表 | 数量 ±1、配置 100% 匹配、延迟 < 2x |
| 4 | 嵌入 CI/CD 管道 | 自动化校验任务 | GitLab CI / Jenkins Pipeline |
| 5 | 持续校准 | 口径漂移报告 | 定期对比基线 vs 实际状态 |
3.7 阶段间口径传递机制
变更口径需要在四个阶段之间正确传递,避免信息丢失或口径不一致。以下是阶段间传递的关键数据:
| 传递方向 | 传递数据 | 传递方式 | 校验点 |
|---|---|---|---|
| 计划 → 实施 | 口径基线快照、变更计划清单 | CI/CD 管道环境变量 / 制品仓库 | 实施前校验基线是否完整 |
| 实施 → 验证 | 执行日志、实际资源状态 | 可观测性平台 API / 日志存储 | 验证前校验执行是否完成 |
| 验证 → 回滚 | 漂移报告、回滚指令 | 告警系统 / 自动化回滚脚本 | 回滚前校验漂移是否可恢复 |
| 回滚 → 计划 | 回滚后基线快照、残留漂移报告 | 状态存储 / 数据库 | 重新计划前校验基线已恢复 |
工程化建议:使用 口径传递契约 来规范阶段间的数据交换。每个阶段输出一个标准格式的口径快照文件(如 JSON Schema 校验),下一阶段读取该文件作为输入。这样可以避免因数据格式不一致导致的口径传递错误。