1. 课程导论：什么是IaC成本异常、为什么需要Runbook、课程目标与受众
1.1 什么是IaC成本异常
基础设施即代码（IaC）通过模板化声明（Terraform、CloudFormation、Pulumi）管理云资源。当这些声明与实际云账单之间出现非预期的、可量化的偏差时，即构成IaC成本异常。它不是单纯的“费用超支”，而是代码驱动的资源状态与财务预期之间的失配。
| 异常类型 | 典型表现 | 根因示例 |
|---|---|---|
| 资源规格漂移 | 实例类型从 t3.medium 被手动升级为 m5.xlarge | 控制台手动变更未同步回 IaC 仓库 |
| 闲置/僵尸资源 | 未关联负载的 Load Balancer、未挂载的 EBS 卷 | 销毁流程未清理 IaC 定义外的残留资源 |
| 配置膨胀 | 非生产环境使用了生产级冗余（多 AZ、自动扩缩） | 环境变量或模块参数未按环境差异化 |
| 计费模型错配 | 按需实例运行 24/7，但工作负载为批处理型 | IaC 中未启用 Spot 或预留实例策略 |
| 标签缺失 | 资源无成本归属标签，无法分摊到业务线 | IaC 模板未强制标签规范 |
关键认知： IaC 成本异常的本质是 “代码承诺”与“实际账单”之间的审计缺口。传统成本告警只能告诉你“花了多少钱”，而 IaC 成本异常分析要回答“哪段代码导致了这笔钱”。
1.2 为什么需要Runbook
面对成本异常，大多数团队的反应是：登录云控制台 → 查看账单 → 猜测原因 → 手动修改资源 → 祈祷不再复发。这种临时救火模式存在三个致命缺陷：
- 不可重复：每次排查路径依赖个人经验，人员变动后知识流失。
- 不可审计：手动操作无变更记录，无法追溯“谁、何时、为何”修改了资源。
- 不可扩展：当环境数量从 5 个增长到 50 个时，人工排查完全失效。
Runbook（处置手册） 将异常发现、根因定位、修复执行、验证闭环这四个阶段固化为可执行的标准化流程。它让成本异常处置从“艺术”变为“工程”。
Runbook 的核心价值： 将平均修复时间（MTTR）从小时级压缩到分钟级，同时确保每次修复都符合变更管理规范。
1.3 课程目标
本课程旨在培养学员构建 IaC 成本异常 Runbook 处置体系 的实战能力。完成课程后，学员将能够：
- 识别：基于 Terraform/CloudFormation 状态文件与云账单数据，自动化识别 5 类以上成本异常模式。
- 设计：使用 Python/Go 编写可复用的诊断与修复脚本，封装为标准化 Runbook 模块。
- 集成：将 Runbook 嵌入 CI/CD 流水线（GitHub Actions/GitLab CI）与事件管理平台（PagerDuty/Opsgenie）。
- 治理：通过 IaC 策略即代码（OPA/Sentinel）从源头预防成本异常复发。
| 模块 | 核心产出 | 工具链 |
|---|---|---|
| 检测与诊断 | 成本异常检测脚本 + 告警规则 | infracost, tfsec, AWS Cost Explorer API |
| 修复与自动化 | Runbook 自动化修复流水线 | Python, Terraform, GitHub Actions |
| 预防与治理 | 策略即代码规则集 | OPA, Sentinel, Checkov |
1.4 目标受众
本课程面向以下三类角色，每类角色将获得差异化的能力提升：
前置要求： 学员需具备基础的 IaC 使用经验（至少使用过 Terraform 或 CloudFormation 管理过 3 个以上资源），了解云计费基本概念（按需、预留、Spot）。
1.5 课程核心概念关系
下图展示了本课程的核心概念体系及其逻辑关系：
课程定位： 这不是一门纯理论课，也不是纯工具操作课。它是一套 “检测 → 诊断 → 修复 → 预防” 的工程化方法论，结合真实云环境中的 Terraform 代码与账单数据，让你在课程结束时拥有一个可直接投入生产的 Runbook 处置框架。