故障演练的核心理念：稳态假设、爆炸半径、最小化影响
做故障演练最怕什么？我刚开始带团队搞混沌工程时，最大的困惑就是——到底该从哪里切一刀？
后来跟着 Netflix 的文档啃了两个月，又在自己负责的支付系统上摔了几次跟头，才慢慢摸到门道。说白了，故障演练不是瞎搞破坏，而是有套底层逻辑的。这套逻辑就是三个核心理念：稳态假设、爆炸半径、最小化影响。
今天我们就把这三点掰开揉碎，结合我踩过的坑，一次性说清楚。
1. 稳态假设：先定义“正常”，再谈“故障”
你想想看，要是连系统啥样算健康都没搞清楚，怎么知道故障演练有没有破坏它？所以第一步，得有个稳态假设。
稳态假设，就是系统在正常运行时的可观测行为指标。比如：
- 下单成功率 ≥ 99.5%
- p99 延迟 ≤ 200ms
- 数据库连接数维持在 30～80 之间
- 每分钟日志写入量波动不超过 ±10%
我个人习惯，把这些指标做成一张稳态基线表，每次演练前先跑 10 分钟采集数据，确认系统确实“稳”了再动手。
| 指标 | 正常范围 | 采集方式 |
|---|---|---|
| 下单成功率 | ≥ 99.5% | Prometheus + Grafana |
| API p99 延迟 | ≤ 200ms | APM 打点 |
| MySQL 活跃连接 | 30～80 | SHOW STATUS |
| 错误日志速率 | < 5条/分钟 | ELK 聚合 |
核心要点：稳态假设不是拍脑袋定的，必须来自线上真实数据。我见过一个团队拍了个“延迟200ms”，结果线上实际 p99 是 80ms，演练时一注入延迟，系统刚跑到 110ms 就报警了——假阳性浪费了一天时间。
确立稳态假设之后，故障注入就有了观测锚点。注入故障后，如果这些指标全部还在基线内，那这次演练证明系统是牢靠的；如果某个指标漂移了，说明漏洞找到了。
小技巧：用 prometheus-query 或 gcloud monitoring 做自动化基线校验，比我当初手动盯 Grafana 面板靠谱一百倍。
2. 爆炸半径：要炸一个馒头，别炸整座楼
爆炸半径这个概念，来自 Netflix 的混沌工程原则。它指的是一次故障注入能够影响的最大范围。
为什么重要？我举个例子：
有一次我们要演练 Redis 主从切换。一个同事直接在生产集群上 redis-cli DEBUG SEGFAULT —— 结果整个 Redis 集群挂了，连带影响了 6 个核心服务，线上故障持续了 7 分钟。复盘时他说“我以为只会杀一个节点”。这就是爆炸半径失控了。
所以，控制爆炸半径有三个原则：
- 隔离性：先扔到影子集群、灰度环境，确认安全了再往生产走。
- 范围约束：用
iptables、tc或混沌工程平台的scope参数，只对特定 IP、Pod、服务版本生效。 - 熔断开关：必须预留一层“一键终止”的能力。我习惯在脚本开头写
trap 'cleanup' EXIT，所有注入操作都要能回滚。
| 控制手段 | 说明 | 工具示例 |
|---|---|---|
| 环境隔离 | 先在 staging 执行，再推 prod | K8s namespace / 独立 VPC |
| 资源标签 | 只影响打了 chaos=true label 的容器 | K8s nodeSelector + labels |
| 时间窗口 | 限制演练只能在业务低峰期运行 5 分钟 | cron + timeout |
| 速率限制 | 按比例注入，比如只杀死 10% 的 Pod | LitmusChaos 的 percentage 参数 |
我曾经踩过的坑：有一回在做网络延迟演练，我忘了在 tc qdisc add 后加 timeout 30，结果延迟规则一直没清理。第二天早上线上反馈慢，查了半天才发现是我昨晚留下的“定时炸弹”。从此以后，我所有的注入脚本都强制加 at now + 5 minutes 自动清理。
3. 最小化影响：优先保业务，再谈练技术
故障演练不是破坏生产。它的初衷是验证脆弱点，而不是制造事故。所以“最小化影响”是底线。
怎么做？三步走：
- 观察先行：先在监控上圈出“安全区间”。比如，MySQL 连接池撑到 150 会超时，那我把注入限制在 80～120，绝不碰临界值。
- 灰度渐进：从 1% 流量 → 5% → 20%，每级停留 2 分钟，确认指标无抖动再推进。我习惯用
split 0.01做渐进式注入。 - 兜底预案：演练前准备好回滚脚本和人工确认流程。哪怕自动化再完善，也得有个人盯着屏幕说“停”。
一个简单的数学公式：
影响用户数 = 爆炸半径（实例数）× 每个实例处理的 QPS × 注入持续时间
每次演练前，先算这个数。如果 >1000，我就降级或用更小的实例范围。
三个理念的关系
这三者不是一个串行流程，而是互相制约的三角。用一张图可以讲明白：
这张图反应了一个实战经验：如果你发现爆炸半径太大，先回头审视稳态假设是不是定得太宽松了。反过来，如果最小化影响要求无法满足（比如演练会导致用户报障），那说明你的爆炸半径定义有问题，得砍范围。
实战案例：一次完整的演练准备
我去年负责一个电商核心交易链路的演练，商品详情页依赖缓存、数据库、下游库存服务。按照三个理念，我这么准备：
- 稳态假设：p99 < 200ms，成功率 > 99.8%，缓存命中率 > 85%。采集 5 分钟基线，确认稳定。
- 爆炸半径：只影响商品详情页的
product-detail:v2Pod，一共 4 个实例中的 1 个，同时通过tcpdump确认只有 1 个 Pod 收到延迟策略。 - 最小化影响：先将缓存的读取延迟增加 50ms（只影响 1% 流量），观察 2 分钟。没问题，再升到 100ms，影响 5% 流量。整个过程持续 8 分钟，全程无用户感知。
顺手写了个小脚本片段：
# 只影响指定 deployment 中的一个 replica
kubectl scale deployment product-detail --replicas=4
# 注入网络延迟 100ms，持续 120 秒，只针对 pod-name 包含 "v2-" 的实例
kubectl run chaos-pod --image=alpine -- /bin/sh -c \
"apk add iperf3 tc && \
tc qdisc add dev eth0 root netem delay 100ms && \
sleep 120 && \
tc qdisc del dev eth0 root"注意 sleep 120 后面的自动清理，这就是最小化影响的保障。
演练结束后，我们确认稳态指标全部在基线内，成功证明缓存降级是安全的。后来线上真的有一次缓存故障——因为我们演练过，自动降级脚本一触发，服务无感恢复。
再次提醒：永远不要在演练前告诉业务团队“这次不会有问题”。要承认不确定性，准备好 一键 abort 的权限和人。我经历过一次演练中 ES 集群磁盘写满，当时就是旁边坐着的 DBA 眼疾手快按了终止，才没酿成大祸。
小结
稳态假设、爆炸半径、最小化影响，这三个理念是故障演练的“安全三脚架”。缺一个，演练随时可能变事故。写进你的演练 SOP 里，每次演练前对照检查一遍。