IaC 可靠性基础：生命周期、故障模式与评审输入输出

基础设施即代码（IaC）的可靠性并非仅靠工具或语法检查就能保障，它贯穿于代码从定义到退役的完整生命周期。SRE 与平台工程师需要理解 IaC 在每个阶段可能出现的故障模式，并建立结构化的可靠性评审机制。本章将拆解 IaC 生命周期的三个核心阶段，梳理常见故障模式，并明确可靠性评审的输入与输出。

2.1 IaC 生命周期：定义、部署、运行

IaC 的可靠性管理可以抽象为三个连续且循环的阶段：定义（代码编写与版本控制）、部署（执行与状态同步）、运行（持续观测与漂移修复）。每个阶段都有其独特的可靠性关注点。

2.1.1 定义阶段：可靠性的源头

定义阶段是 IaC 可靠性的起点。代码的结构化程度、参数化设计、模块复用性直接决定了后续阶段的故障概率。此阶段的关键活动包括：

• 模块化与抽象： 将通用资源（如 VPC、安全组）封装为可复用模块，减少重复代码引入的配置错误。
• 参数化与默认值： 通过变量和局部值暴露可配置项，并为关键参数设置安全的默认值。
• 版本控制与分支策略： 所有 IaC 代码必须纳入 Git，并采用合理的分支策略（如 Trunk-based 或 GitFlow）以支持并行开发与回滚。
• 静态分析与预检查： 在代码提交前执行 terraform validate、tflint、checkov 等工具，拦截语法错误和安全配置问题。

2.1.2 部署阶段：状态同步的可靠性

部署阶段是 IaC 从声明到现实的转换过程。可靠性风险主要来自状态管理、执行顺序和并发控制。核心关注点包括：

• 状态文件（State）的完整性： 状态文件是 IaC 的核心资产，必须使用远程后端（如 S3 + DynamoDB、Terraform Cloud）并启用状态锁定，防止并发写入导致的状态损坏。
• 执行计划的审核： 每次 plan 输出必须经过人工或自动化审核，确认变更范围符合预期，避免意外的资源销毁或替换。
• 幂等性与原子性： 同一份代码多次执行应产生相同结果；部署失败时应支持回滚或重试，不留下中间状态。

2.1.3 运行阶段：持续观测与漂移管理

运行阶段是 IaC 可靠性最容易忽视的环节。基础设施在运行中可能因手动操作、外部 API 变更、资源老化等原因偏离代码定义的期望状态，即发生配置漂移。

• 漂移检测： 定期执行 terraform plan 或使用专门的漂移检测工具（如 Terragrunt、Atlantis），对比实际状态与代码定义。
• 自动修复策略： 对于非关键漂移，可通过 CI/CD 流水线自动执行 apply 恢复；对于关键资源，应触发告警并人工介入。
• 审计与合规： 记录所有 IaC 变更历史，确保基础设施变更可追溯、可审计。

2.2 常见故障模式

基于 IaC 生命周期的三个阶段，可以归纳出以下高频故障模式。理解这些模式是设计可靠性评审检查项的基础。

2.3 可靠性评审的输入与输出

IaC 可靠性评审不是一次性的代码审查，而是贯穿生命周期的持续活动。评审的输入和输出需要明确界定，以确保每次评审都有可操作的结论。

2.3.1 评审输入

可靠性评审需要以下材料作为输入，缺少任何一项都可能导致评审不完整：

• IaC 代码仓库： 包含所有模块、配置文件和版本标签的完整代码库。
• 执行计划（Plan）输出： 最近一次 plan 的详细输出，展示即将发生的变更。
• 状态文件快照： 当前远程状态文件的版本摘要，用于对比实际资源状态。
• 运行指标与告警记录： 过去一段时间内的漂移检测结果、部署成功率、告警事件列表。
• 依赖清单： 所有 Provider、模块、外部数据源的版本和来源。
• 变更请求（CR）上下文： 本次变更的业务目的、预期影响范围、回滚方案。

2.3.2 评审输出

评审完成后，必须输出以下可追溯、可执行的成果：