小团队（<10 人）到底该不该做混沌工程？聊聊这笔投入产出账

做运维 3 年，"混沌工程"这个词大概是我在团队周会上被提得最多、但真正落地次数为零的话题。每次有人拍桌子说"我们得搞混沌工程"，另一头就有人回一句"你先把告警误报治干净再来谈这个"。今天想把这个争论摊开，听听大家怎么算这笔账。

【背景：混沌工程在小团队里的尴尬位置】

混沌工程（Chaos Engineering）的核心思想大家都认：主动注入故障，在可控环境验证系统韧性，比被动等生产事故强。Netflix 的 Chaos Monkey、阿里蚂蚁的故障演练平台，听着很性感。但落到 5~10 人的小团队，现实是：

• 没有专职 SRE，故障演练只能兼职做；
• 没有独立的 staging 集群，注入故障等于在"准生产"上动手；
• 业务迭代节奏 2 周一个版本，排不进"本月做混沌工程"的 sprint。

所以大多数小团队的状态是：知道该做，但一直没做，直到生产出了 P0，复盘会上那句"如果提前演练过就不会出"又开始了。

【三种典型立场】

派系 A「不演练 = 裸奔」：生产事故就是"第一次混沌实验"，而且没有回滚脚本、没有预案、没有值班状态，代价是正常演练的 100 倍。你 3 天做一次故障注入，每次 2 小时，成本 6 人时；一次 P0 事故的代价是 3 人 × 2 天 + 客户赔偿 + 团队信心。账很好算。

派系 B「先把地基打好」：小团队最大的风险不是"没做混沌工程"，而是"监控盲区 + 告警噪音 + 回滚脚本过期"。我见过一个 6 人团队，花 2 周搞了 Chaos Mesh 注入，结果发现连最基本的"哪个 Pod 挂了谁不知道"都没解决——liveness 探针没配、日志级别不对、告警规则 80% 是噪音。先治这些，混沌工程是锦上添花。

派系 C「轻量故障演练就够」：不需要 Chaos Mesh、不需要故障注入平台，但每季度做一次"断电演练"（真的关一台机器 / 停一个副本 / 断一条网络）是底线。投入 1 个工程师 × 1 天，产出是一份"系统在当前状态下到底能扛住什么"的事实清单。

【我的倾向：派系 C，但有一条硬指标】

我们 6 人团队，具体做法：

1. 每季度一次"故障日"（Q1 的最后一周周五下午 14:00-17:00），选 2~3 个注入点：
   • 杀掉核心服务 1 个副本（观察自动恢复时间，目标 < 30s）；
   • 把 MySQL 主库的磁盘 IO 打满 60s（dd if=/dev/zero of=/tmp/fill bs=1M count=2048，观察连接池等待和 P99）；
   • 网关层随机 5% 请求注入 500ms 延迟（模拟下游抖动，观察上游超时配置是否合理）。
2. 硬指标：每次演练必须产出一份 1 页纸的"发现清单"，格式固定：注入点 / 预期行为 / 实际行为 / 差距 / 修复 owner / 修复 deadline。没有这份清单的演练不算做。
3. 不做的事：不引入 Chaos Mesh / Litmus 等重型平台（维护成本 > 收益）；不在凌晨做（值班状态和演练状态不同）；不测"全集群挂了"这种超出当前恢复能力的场景（先解决单点，再谈多活）。

上个月 Q3 演练的真实数据：杀副本平均恢复 42s（目标 30s，差 12s，原因是 HPA 扩容冷启动）；DB IO 打满时 P99 从 12ms 飙到 380ms，持续 45s 后恢复——这条被记为"需要加只读副本分流"；网关延迟注入时上游有 2 个调用方超时设了 500ms，刚好卡在注入延迟边界上，这直接暴露了热榜那篇"超时与重试"里说的问题在我们身上的真实版本。

【想听大家的】

1. 你们团队（尤其 5~15 人规模）有没有做过任何形式的故障演练/混沌工程？频率多高？投入几个人时？
2. 派系 B 说的"先治监控/告警/回滚"和派系 A 说的"不演练就是裸奔"，你们实际怎么排优先级的？有没有"先做了 A 发现 B 的问题反而暴露了"或反过来的经历？
3. 轻量演练（手动杀 Pod / 打满 IO / 注入延迟）和平台化混沌工程（Chaos Mesh / Gremlin / Litmus），你们在什么团队规模 / 系统复杂度下觉得"值得上平台"了？那个拐点大概是什么？
4. 演练产出的"发现清单"你们怎么跟踪？有没有发现"演了 3 次同一个问题还在"的情况？怎么解决的？
5. 一个很现实的问题：老板问"混沌工程对业务指标（DAU / 转化率 / GMV）有什么直接贡献"，你怎么答？

欢迎贴具体数字、具体工具、具体踩坑。空谈"该做"的不用来，我只要"怎么做的、花了多少、发现了什么"。