1. 课程导论：什么是GameDay、为什么需要故障注入、容量水位口径的定义与重要性
1.1 什么是GameDay
GameDay 是一种有计划的、受控的、面向生产或类生产环境的故障演练实践。它并非随意的“破坏测试”，而是一套结构化的韧性验证流程：团队预先定义故障场景、设定观测指标、执行注入、记录系统行为，并在事后进行复盘与改进。
GameDay 的核心目标不是“搞垮系统”，而是通过主动暴露薄弱环节，验证监控、告警、自动伸缩、限流降级等容量与韧性机制的实际生效边界。
关键特征：
- 计划性：有明确的开始时间、持续时间、影响范围与回滚方案。
- 可观测性：演练全程依赖 Grafana、Prometheus 等工具实时追踪指标变化。
- 可复盘性：每次 GameDay 产出故障报告，直接驱动容量水位口径的校准。
1.2 为什么需要故障注入
在传统容量规划中，团队往往依赖峰值流量推算或压测报告来设定资源水位。但生产环境的故障模式远比线性压测复杂：
- 级联效应：一个实例的 CPU 毛刺可能引发整个集群的雪崩，压测通常无法触发这种连锁反应。
- 依赖盲区：数据库连接池耗尽、缓存穿透、DNS 解析延迟等“软故障”在常规压测中难以复现。
- 容量口径失真：没有故障注入验证的“水位线”往往是乐观估计，实际承载能力可能远低于预期。
实践建议：故障注入应覆盖 CPU 过载、内存泄漏、网络延迟/丢包、磁盘 I/O 饱和、下游依赖中断 五大基础场景。每次注入后，观察 Grafana 中对应的容量指标是否在预期水位内触发告警或自动伸缩。
1.3 容量水位口径的定义与重要性
容量水位口径是指衡量系统资源使用状态与剩余承载能力的标准化指标定义与阈值体系。它回答三个核心问题：
- 当前用了多少？（例如：CPU 使用率 70%、内存占用 12GB）
- 还能承受多少？（例如：剩余连接数 200、磁盘 IOPS 余量 5000）
- 达到多少必须干预？（例如：CPU > 85% 触发扩容、延迟 > 500ms 触发降级）
| 资源维度 | 常见错误口径 | 优化后口径（GameDay 验证） |
|---|---|---|
| CPU | 整体使用率 < 80% | 单核使用率 < 75% + 突发容忍 30s |
| 内存 | 已用 / 总量 < 85% | 堆内存 GC 频率 < 5次/min + 剩余堆 > 512MB |
| 网络 | 带宽利用率 < 70% | TCP 重传率 < 0.5% + 连接建立延迟 < 50ms |
| 磁盘 I/O | 磁盘使用率 < 80% | IOPS 余量 > 30% + 平均等待时间 < 10ms |
常见误区：很多团队将“容量水位”等同于“资源使用率百分比”，忽略了延迟、错误率、饱和度三个黄金信号。GameDay 故障注入的核心价值之一，就是暴露这些被百分比掩盖的真实瓶颈。
1.4 GameDay 与容量水位口径的联动关系
GameDay 不是一次性的“破坏活动”，而是容量水位口径持续校准的验证引擎。其联动逻辑如下：
- 假设 → 注入 → 验证：先设定容量水位阈值（假设），通过故障注入制造压力，观察系统是否在预期水位触发保护动作。
- 偏差 → 复盘 → 调整：如果系统在远低于警戒水位时就出现性能恶化，说明口径过于乐观，需要下调安全阈值。
- 持续迭代：每次 GameDay 的产出直接更新 Grafana 告警规则、HPA 参数和容量规划模型。
课程核心主张：没有经过 GameDay 验证的容量水位口径，本质上只是“猜测”。本课程将教会你如何通过故障注入与 Grafana 联动，把容量水位从“经验值”升级为“可验证的工程标准”。