1. 课程导论：混沌工程与容量水位的关系
1.1 混沌工程与容量水位：从故障注入到容量治理
混沌工程（Chaos Engineering）的核心是通过主动注入故障，验证系统在异常条件下的韧性。而容量水位（Capacity Watermark）则是衡量系统资源使用率与承载能力的关键指标。两者看似分属“稳定性验证”与“容量规划”两个领域，但在实际生产环境中，它们之间存在深刻的协同关系：混沌工程为容量水位提供了动态验证手段，容量水位则为混沌工程提供了量化目标。
传统容量规划依赖静态压测与历史峰值估算，但微服务架构下的流量突发、资源争抢、连锁故障等动态行为，往往导致容量水位估算失准。混沌工程通过模拟真实故障场景（如节点宕机、网络延迟、资源耗尽），能够暴露容量水位设计中的盲区，帮助团队建立更精准的容量水位口径。
核心观点： 混沌工程不是容量规划的替代品，而是容量水位策略的“验证引擎”。没有混沌验证的容量水位是“纸面水位”，没有容量目标的混沌实验是“盲目破坏”。
1.2 课程目标与受众
课程目标
本课程旨在帮助学员掌握一套可落地的混沌工程实验优化容量水位口径策略，具体目标包括：
- 理解混沌工程与容量水位的协同模型：建立从故障注入到容量水位校准的闭环方法论。
- 掌握容量水位口径的量化定义：区分“安全水位”“警戒水位”“危险水位”的阈值设定逻辑。
- 学会设计混沌实验验证容量水位：通过故障注入验证水位口径的合理性，并基于实验结果优化阈值。
- 构建持续优化机制：将混沌实验与容量水位监控、告警、自动扩缩容等运维流程集成。
目标受众
| 角色 | 痛点 | 课程价值 |
|---|---|---|
| SRE / 运维工程师 | 容量水位阈值靠经验拍定，缺乏验证手段 | 获得基于混沌实验的阈值校准方法 |
| 混沌工程实践者 | 实验场景与容量治理脱节，结果难以量化 | 学会将实验输出映射到容量水位指标 |
| 架构师 / 技术负责人 | 微服务容量规划缺乏动态验证机制 | 掌握混沌驱动的容量治理体系设计 |
| QA / 测试工程师 | 压测场景单一，无法覆盖真实故障组合 | 扩展测试维度，提升容量验证的覆盖率 |
1.3 课程大纲概览
本课程共分为 8 个模块，从基础概念到实战落地，逐步构建完整的知识体系：
- 课程导论（本章）—— 混沌工程与容量水位的关系、课程目标与受众、大纲概览。
- 容量水位基础概念与口径定义 —— 水位指标分类、阈值设定原则、口径计算模型。
- 混沌工程实验设计原则 —— 稳态假设、实验范围、最小爆炸半径、实验终止条件。
- 容量水位验证实验场景设计 —— 资源耗尽、流量突增、依赖故障、级联失效等场景的注入方法。
- 实验数据采集与水位口径校准 —— 指标采集、基线对比、口径调整策略。
- 自动化实验与持续容量治理 —— 实验编排、流水线集成、自动告警与扩缩容联动。
- 案例实战：电商大促容量水位优化 —— 从压测到混沌实验的完整案例复盘。
- 总结与最佳实践 —— 常见误区、团队协作模式、工具选型建议。
学习建议： 建议学员在阅读第 2 章前，先回顾自己团队当前的容量水位定义方式（如 CPU 使用率 80% 为告警线），带着实际问题进入后续章节，效果更佳。
1.4 混沌工程与容量水位的协同模型
下图展示了混沌工程实验与容量水位策略之间的闭环协同关系：
1.5 为什么需要混沌工程优化容量水位？
在实际生产环境中，容量水位策略常面临以下挑战，而混沌工程恰好提供了针对性的解决方案：
| 容量水位痛点 | 传统做法 | 混沌工程优化方案 |
|---|---|---|
| 阈值设定缺乏验证 | 基于历史峰值 + 经验值 | 通过故障注入验证阈值是否过早/过晚触发 |
| 资源争抢场景被忽略 | 单维度压测（如只压 CPU） | 组合故障注入（CPU + 内存 + 网络延迟） |
| 级联故障下的容量失真 | 独立评估每个服务容量 | 模拟依赖故障，验证整体容量水位 |
| 水位口径僵化 | 固定阈值，不随架构变化调整 | 实验驱动口径持续校准 |
注意： 混沌工程实验本身也会消耗系统资源，实验设计时必须考虑“实验负载”对容量水位的影响，避免实验本身成为故障源。后续章节将详细讨论实验的“最小爆炸半径”控制。
1.6 课程学习路径图
为帮助学员规划学习节奏，下图展示了各模块之间的依赖关系与推荐学习顺序：
建议按模块顺序学习，其中模块 4 和模块 5 可并行推进，最终汇聚到模块 6 的自动化治理实践。模块 7（案例实战）和模块 8（总结）建议在完成前 6 个模块后集中学习。