📚 课程目录第3章 IaC变更生命周期

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 校验），下一阶段读取该文件作为输入。这样可以避免因数据格式不一致导致的口径传递错误。