故障演练：把事故提前到演练室发生
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 6 · 高可用 · 第 38/49 篇 · 🚧 占位待学
上一篇：《同城双活与异地多活：单元化入门》
下一篇：《场景解剖一：IM 消息系统》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 6 · 单元 6.5
一、本文要解决的问题
高可用架构是不是真的高可用，只有故障知道——但等真实故障来验收，代价太大了。混沌工程的思想是主动、可控地制造故障：预案说了限流会生效，那就真的把流量打超，看看它到底生不生效。
二、知识点清单
- 混沌工程五步法：定义稳态 → 假设（预案）→ 注入故障 → 观测对比 → 放大范围
- 常用注入手段：进程杀（kill -9）、资源压（CPU / 内存 / 磁盘满）、网络乱（延迟 / 丢包 / 分区，tc 命令）、依赖挂（停 DB / Redis）
- 演练分级：观察型（只记录不处理）→ 破坏型（真实切换）→ 突袭型（不预告）
- 预案库的建设：每次真实故障沉淀为预案，演练验证预案，闭环改进
- 演练报告的结构：注入什么 / 预期 / 实际 / 差距 / 改进项
三、动手实验（学习时必须真跑）
- 对示例系统做三次注入：kill MySQL 主（验主从切换）、Redis 加 500ms 延迟（验缓存降级 / 熔断）、打满应用线程池（验隔离舱）
- 每次注入记录：告警触发时间、预案是否生效、用户侧指标（成功率 / RT）变化
- 找出至少一处「预案说了但实际没生效」的差距，修复后复演
四、验收标准（全部通过才进入下一篇）
五、阶段验收（本篇是阶段 6收尾篇）
六、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。