故障不会因为你怕它就不来
系统上线久了，大家反而越来越不敢动它——谁也不知道哪台机器挂了、哪个依赖超时会发生什么。这种「怕」很真实，但它挡不住故障：机器总会坏、网络总会抖、依赖总会抽风。
混沌工程的思路正好反过来：与其天天提心吊胆，不如主动、可控地给系统制造点麻烦，提前看看它在压力下会怎样。
韧性不是系统永远不出问题，而是出了问题之后，系统和团队都能稳稳接住。
本文核心知识点
- 混沌工程用实验主动注入故障找脆弱点。
- 定稳态先定义什么叫系统正常。
- 小步注入从小范围、可回滚的故障开始。
- SLO用可靠性目标约束演练风险。
- 应急演练暴露的问题要排期修复。
混沌工程：用实验找脆弱点
混沌工程不是乱搞破坏，而是一套受控的实验方法：假设系统在某种故障下会表现如何，然后真的注入这种故障，观察它实际的反应，再把发现的脆弱点修掉。
| 步骤 | 做什么 |
|---|---|
| 定假设 | 某个节点挂了，系统还能撑住吗 |
| 小范围 | 先在一台机器、一小部分流量上试 |
| 注入 | 真的制造故障，观察指标变化 |
| 记录 | 哪里退化了、哪里扛住了 |
它的价值在于：把「以为它很稳」变成「亲眼见过它怎么扛」。
先定稳态：什么叫系统正常
做实验之前，得先知道「正常长什么样」。否则故障来了，你根本分不清是预期内的波动还是真的出问题了。
- 核心接口的响应时间和成功率是多少。
- 错误率在什么范围算正常。
- 用户侧能感知到的关键指标。
# 实验开始前先写出稳态
核心接口成功率不低于某个水位线
响应时间在正常区间内
关键流程仍能走完
# 偏离这个稳态，就说明故障真的伤到了系统。稳态定义清楚，注入故障后才能判断：这是可接受的退化，还是必须立刻止损。
注入什么：从小故障开始
新手最容易犯的错，是一上来就拔掉整个机房。正确的做法是从最小、最可控的故障开始，逐步升级。
| 注入类型 | 目的 |
|---|---|
| 单台机器重启 | 看服务能不能自动迁移 |
| 依赖延迟/超时 | 看有没有超时和降级 |
| 小比例流量错误 | 看熔断和限流是否生效 |
每一类故障都要能在几分钟内自动或手动回滚，绝不搞不可控的大爆炸。
SLO：用目标约束风险
SLO（服务等级目标）给系统的可靠性定了一条线：我们承诺一年里有多少比例的时间是正常的。演练时，这条线就是刹车。
# SLO 给演练划底线
演练期间不能跌破承诺的可靠性
一旦指标越线，立即停止并回滚
# SLO 不是考核人，而是给实验一个安全边界。没有 SLO 的混沌演练是玩火；有了 SLO，它才是受控的工程实验。
应急与回滚：演练后做什么
演练不是为了吓人，而是为了把暴露出来的问题补上。每次演练结束后，要把发现的脆弱点列成清单。
- 哪里没有自动恢复，需要补自愈机制。
- 哪里降级策略缺失，遇到依赖超时就雪崩。
- 把修复排进迭代，而不是记在群里就完了。
演练的闭环，是问题被发现、被修复、再用下一次演练验证它真的扛住了。
把韧性练成日常
混沌工程的最终目的，是让「系统在压力下怎样」成为团队天天心里有数的事，而不是出事时才第一次面对。
- 稳态和 SLO 让正常和异常有了共同标准。
- 小步注入让团队对故障不再陌生。
- 演练发现的问题被持续修复，韧性一点点长出来。
当故障演练变成日常，系统的韧性就不再是一句口号，而是一次次实验验证过的事实。