3. 演练场景设计：常见故障场景与选择策略
好，咱们进入演练设计的核心环节——场景设计。说白了，就是决定「今天我们要模拟什么灾难」。
我见过不少团队，一上来就搞「全机房断电」这种大场面。结果呢？演练变成了一场混乱的救火演习，连基础监控都没触发。嗯，这其实是个误区。
我个人习惯，是把故障场景分成三个层级来设计。这样既覆盖全面，又不会一上来就把自己玩死。
3.1 机房级故障：最直接的「物理打击」
机房级故障，就是整个数据中心不可用了。比如电力全断、空调失效、光纤被挖断。这类场景最暴力，也最能检验你的「冷备」能力。
典型场景清单：
- 整机房断电：市电+UPS全挂，柴油发电机未启动
- 网络全断：核心交换机宕机，或上行光缆被挖断
- 制冷失效：机房温度超过45℃，设备自动关机
- 消防误喷：气体灭火系统误触发，设备强制下电
核心验证点：
- DNS/GSLB 能否自动切流到异地机房？
- 数据库主从切换是否在 RPO 时间内完成？
- 应用层会话能否保持或优雅降级？
避坑指南： 我曾经遇到一个客户，机房级演练时发现 DNS 解析缓存 TTL 设了 24 小时。切流后用户死活访问不了新机房。你想想看，这种基础配置问题，不演练根本发现不了。
3.2 区域级故障：更真实的「局部瘫痪」
区域级故障，指的是某个云区域或可用区（AZ）不可用。比如阿里云某地域的某个可用区挂了，或者 AWS 的某个 Region 网络抖动。
这类场景在金融云里特别常见。为什么？因为监管要求「两地三中心」，但很多系统只做了同城双活，跨区域切换根本没验证过。
典型场景清单：
- 单可用区全挂：比如 AZ-A 所有计算实例失联
- 跨区域网络延迟飙升：从 2ms 变成 200ms，触发超时风暴
- 对象存储服务降级：OSS 读写超时，图片/文件加载失败
- 消息队列积压：Kafka 集群部分节点宕机，生产消费失衡
| 故障类型 | 影响范围 | 典型 RTO 目标 | 我建议的演练频率 |
|---|---|---|---|
| 单 AZ 宕机 | 该 AZ 内所有服务 | ≤ 5 分钟 | 每季度 1 次 |
| 跨区域网络故障 | 跨区域调用链路 | ≤ 15 分钟 | 每半年 1 次 |
| 存储服务降级 | 依赖存储的应用 | ≤ 30 分钟 | 每季度 1 次 |
注意： 区域级故障最容易暴露「跨区域数据一致性」问题。我记得有一次演练，主库切到异地后，发现同步延迟了 3 分钟，导致一批交易数据丢失。嗯，这就是 RPO 没达标。
3.3 应用级故障：最频繁的「软故障」
应用级故障，说白了就是代码或配置惹的祸。比如内存泄漏、慢 SQL、配置错误、依赖服务超时。这类故障发生频率最高，但往往被忽视。
为什么？因为大家总觉得「代码是我写的，不会有问题」。你想想看，线上出问题的，十有八九都是这种「软故障」。
典型场景清单：
- 数据库连接池耗尽：应用无法获取连接，请求排队超时
- 缓存雪崩：Redis 大量 key 同时过期，请求穿透到 DB
- 配置中心不可用：Nacos/Etcd 宕机，服务无法获取最新配置
- 慢 SQL 拖垮数据库：一条全表扫描把 CPU 打满
- 第三方接口超时：支付/风控等外部服务响应变慢
核心验证点：
- 熔断降级机制是否生效？
- 限流阈值是否合理？
- 日志链路能否快速定位故障根因？
3.4 场景选择策略：别贪多，要精准
好，场景库建好了。但问题来了：每次演练到底选哪个？
我个人习惯用「风险矩阵法」来选。说白了，就是画个四象限：
- 高概率 + 高影响：必须演练，且要高频（如数据库主从切换）
- 高概率 + 低影响：自动化演练，或纳入混沌工程（如单节点宕机）
- 低概率 + 高影响：定期演练，但要做好预案（如全机房断电）
- 低概率 + 低影响：文档记录即可，不用专门演练
举个例子。我记得去年某支付公司，他们最怕的是「数据库跨区域切换」。虽然概率低，但一旦发生，影响是千万级的。所以他们每季度都做一次这个演练，雷打不动。
我的建议： 刚开始做演练，别选太复杂的场景。先从「单应用故障」入手，比如模拟一个服务超时。等团队熟练了，再逐步升级到「机房级」场景。步子迈大了，容易扯着蛋。
3.5 知识体系：一张图看懂场景设计
下面这张图，是我自己总结的「演练场景设计框架」。你可以把它贴在工位上，每次设计演练时对照着看。
嗯，这张图把三个层级的故障、典型场景、RTO 目标、选择策略都串起来了。你设计演练时，直接对着这个框架选就行。
最后提醒一句： 场景设计不是一次性的。每次演练后，都要根据复盘结果调整场景库。比如这次发现「缓存雪崩」没覆盖到，那下次就把它加进来。场景库是活的，不是死的。
公众号:蓝海资料掘金营，微信deep3321