混沌工程

【背景】 做了 3 年 SRE，复盘过不下 20 次线上故障，我有个越来越强的体感：复盘报告写得再漂亮，如果没变成代码 / 配置 / 告警，下次同类故障大概率还会来。 举两个我亲历的例子： - 一次 Redis 大 key 把带宽打满，复盘

【背景】 10 年 SRE，过去三年在两家不同公司都推过混沌工程（Chaos Engineering）。一次在金融客户环境做网络延迟注入（模拟跨机房 RTT 从 2ms 升到 50ms），一次在电商大促前做 pod 驱逐演练。两次都差点没批

【背景】 做了 10 年测试开发，最近 18 个月跟着研发一起复盘了 7 起线上性能事故：连接池打满、P99 抖动 30 倍、慢 SQL 执行计划漂移、Kafka 慢消费者重启跳消息、TCP 建连静默失败……几乎每一起都有一个共同点——st

«作者视角：15 年网络工程，长期盯系统稳定性与可观测性。这篇文章不教你「怎么排查网络」，而是讲一个更被低估的能力——在你自己机器上把「网络坏了」这件事精确地造出来，用来验证你的超时、熔断、降级、重连逻辑是不是真的按设计工作。全文给可复现的

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