4. GameDay 演练设计：PDCA 循环与场景分类
GameDay 演练不是一次性的“破坏实验”，而是一个持续改进的闭环过程。本章围绕 PDCA 循环（计划-执行-检查-改进）构建演练框架，并按基础设施、中间件、应用层三个维度对演练场景进行分类，帮助团队建立可重复、可度量的容量水位验证机制。
4.1 GameDay 的 PDCA 循环
PDCA 循环将一次 GameDay 拆解为四个阶段，每个阶段都有明确的交付物和检查点。下表总结了各阶段的核心活动与产出物：
| 阶段 | 核心活动 | 关键产出物 | 参与角色 |
|---|---|---|---|
| P（计划） | 确定演练目标、选择场景、定义爆炸半径、准备观测工具 | 演练方案文档、回滚预案、监控看板 | SRE、开发、运维、PM |
| D（执行） | 注入故障、执行演练、记录时间线、触发告警 | 执行日志、告警记录、故障注入快照 | 混沌工程师、值班SRE |
| C（检查） | 分析指标水位、评估影响范围、对比预期与结果 | 容量水位报告、故障复盘文档 | SRE、架构师、QA |
| A（改进） | 修复缺陷、优化限流/降级策略、更新演练库 | 改进工单、自动化测试用例、演练场景库 | 全团队 |
实践要点： 在 P 阶段必须明确“爆炸半径”——即故障影响的最大范围（如仅影响某台实例、某个可用区或整个集群）。爆炸半径应逐次扩大，避免首次演练就造成大面积生产影响。
下图展示了 PDCA 循环在 GameDay 中的流转关系，以及每个阶段对应的关键动作：
4.2 演练场景分类
根据故障注入的层次，GameDay 场景可分为三大类：基础设施层、中间件层和应用层。每一层关注不同的容量水位指标和故障模式。
4.2.1 基础设施层场景
基础设施层演练关注计算、网络、存储等底层资源的容量水位。典型场景包括：
- CPU 打满：通过 stress-ng 或混沌平台对指定节点注入 CPU 负载，观察 HPA 弹性伸缩、Pod 驱逐与调度行为。
- 内存压力：模拟 OOM 场景，验证 cgroup 限制、swap 策略和节点自愈能力。
- 网络延迟/丢包：使用 tc 命令注入网络抖动，检验服务间超时重试、熔断降级策略。
- 磁盘 IO 打满：通过 fio 或 dd 制造磁盘瓶颈，验证日志轮转、监控采集是否受影响。
容量水位口径： 基础设施层重点关注 资源饱和度（CPU 使用率 > 80%、内存使用率 > 85%、磁盘 IOPS 接近上限）和 弹性伸缩延迟（从触发扩容到 Pod Ready 的时间）。
4.2.2 中间件层场景
中间件层演练覆盖消息队列、数据库、缓存、网关等核心组件的容量水位。下表列出了常见中间件及其演练场景：
| 中间件类型 | 演练场景 | 容量水位指标 | 预期行为 |
|---|---|---|---|
| Kafka | 生产者/消费者延迟、Broker 宕机 | 消息堆积量、消费 Lag、吞吐量 | 消费者自动重平衡、限流降级 |
| MySQL | 慢查询注入、连接池耗尽、主从延迟 | QPS、连接数、复制延迟秒数 | 读写分离切换、连接池回收 |
| Redis | 缓存击穿、大 Key 删除、内存打满 | 命中率、内存使用率、OPS | 本地缓存兜底、逐出策略生效 |
| Nginx/Gateway | 连接数打满、限流触发、后端超时 | 活跃连接数、5xx 比例、响应延迟 P99 | 熔断返回降级响应、限流排队 |
4.2.3 应用层场景
应用层演练聚焦业务逻辑、接口依赖和线程池水位。典型场景包括：
- 接口超时/异常：对下游依赖注入延迟或错误响应，验证熔断器（Hystrix/Sentinel）降级逻辑。
- 线程池耗尽：模拟突发请求占满 Tomcat/Dubbo 线程池，观察请求排队与拒绝策略。
- 业务逻辑异常：注入特定业务错误码，验证事务回滚、补偿机制和告警准确性。
- 数据一致性：模拟分布式事务参与者超时，验证 Saga/TCC 模式的最终一致性。
注意： 应用层演练必须提前梳理 核心链路 和 非核心链路。优先对非核心链路注入故障，确认降级策略生效后再逐步扩展到核心链路。切勿在未验证降级逻辑的情况下直接对核心链路注入故障。
下图展示了三层演练场景的覆盖范围及其与容量水位指标的对应关系：
4.3 场景选择策略
在实际 GameDay 中，不应一次性覆盖所有场景。推荐按以下优先级选择：
- 历史故障复现：优先选择过去 3 个月内发生过生产故障的场景，验证修复措施是否有效。
- 容量水位瓶颈：根据监控数据，选择当前水位接近阈值的组件进行压力测试。
- 新架构/新组件：对近期上线的服务或中间件进行首次演练，验证其弹性能力。
- 合规与审计要求：满足 SLA 承诺或监管要求的场景（如多可用区容灾）。
建议： 每个 GameDay 周期（通常 2-4 周）选择 3-5 个场景，其中至少包含 1 个基础设施层、2 个中间件层和 2 个应用层场景。场景之间应设置 15-30 分钟的恢复间隔，避免故障叠加导致系统雪崩。
4.4 演练检查清单
在进入 D 阶段之前，使用以下清单确认准备就绪：
- 监控覆盖：所有演练涉及组件的核心指标已接入告警和看板。
- 回滚预案：每个场景都有明确的停止条件和回滚操作步骤。
- 通知机制：演练开始前已通知相关团队和值班人员。
- 数据备份：涉及数据库或持久化存储的场景已确认备份有效。
- 爆炸半径确认：故障注入范围已通过配置或白名单严格限制。
- 演练时间窗口：选择业务低峰期，并预留 2 倍于预期演练时间的缓冲期。