【背景】 10 年 SRE，过去三年在两家不同公司都推过混沌工程（Chaos Engineering）。一次在金融客户环境做网络延迟注入（模拟跨机房 RTT 从 2ms 升到 50ms），一次在电商大促前做 pod 驱逐演练。两次都差点没批下来。
第一次，安全团队第一反应是："你往生产网络里注延迟，和 DDoS 有什么区别？" 第二次，业务方的反应是："大促前 3 天你拔我 pod？出了问题谁背锅？"
最后两次都做了，但方式完全不同：一次是凌晨 3 点、低峰窗口、只对一个非核心 zone 做了 10 分钟延迟注入；另一次是提前两周、只驱逐了一个灰度 zone 的一个 pod、全程有 on-call 兜底。
【常见分歧】 我观察到团队里通常有三派：
1.「必须做」派：认为不测就不知道哪里会炸，宁可被业务骂一周，也好过线上真炸一次。 2.「坚决不做」派：认为生产环境不是试验田，混沌工程的风险不可控，出了事故责任说不清。 3.「折中」派：只在 staging 做，但承认 staging 和生产有差异（资源争抢、网络拓扑、内核参数、连接池预热状态都不一样），效果打了折扣。
还有一种更微妙的分歧：做不做可以讨论，但「谁有权拍板执行」这件事，很多团队其实没有明确机制。是 SRE 自己决定？是业务 owner 签字？是安全团队审批？是 CTO 一句话？我见过最极端的——一个 200 人规模的团队，混沌演练的审批链居然要走到 VP 层，结果一年只做了两次，而且都是最保守的"杀一个 pod"，形同虚设。
【我的倾向】 我倾向于「生产环境可以做，但必须满足三个前提」：
- 有明确的「爆炸半径」上限——只影响 N 个 pod / 一个 zone / 一个非核心服务，且这个上限写进 runbook，不是口头约定。比如："单次演练不得影响超过总流量 5% 的请求，不得触及支付、风控、账务链路。"
- 有「一键回滚」的硬机制——不是靠人反应速度，而是脚本化的 kill switch。注入脚本自带 TTL（比如 300 秒自动恢复），同时有一个独立的、不依赖注入脚本的"紧急停止"通道（比如直接 iptables -F + 重启 sidecar）。
- 执行前必须走一次「桌面推演」——把最坏情况写下来，业务方签字确认"我接受这个最坏情况"。不是走形式，是真的把"如果延迟注入导致 5% 请求超时、触发熔断、上游雪崩"这条链路推演完，让业务方看到自己会承受什么。
打个比方：混沌工程就像给飞机做试飞——你不是在机场跑道上随便拉个乘客试，但你也不能永远只在地面模拟，因为地面上的风洞测不出高空湍流。关键是：试飞有高度限制、有应急迫降方案、有乘客知情同意。三个条件缺一个，我就不签字。
【想听大家】
- 你们团队有没有在生产环境跑过混沌工程？具体做了什么（网络延迟、pod 驱逐、DNS 故障、磁盘满、时钟偏移……）？用的什么工具（Chaos Mesh、LitmusChaos、自研脚本……）？
- 审批流程是怎样的？谁最终拍板？有没有被拒过？被拒的理由是什么？
- 你们的「红线清单」是什么？哪些故障类型绝对不允许注入？（比如：时钟回拨？全链路超时？DB 主从切换？）
- 有没有「做了之后反而发现更不敢做了」的经历？比如第一次演练就发现了真正的架构缺陷，但修起来代价太大，团队反而开始回避？
欢迎拍砖，尤其欢迎「坚决不做」派的朋友讲讲你们的顾虑——我真心觉得你们的担心可能是对的，只是还没找到折中点。