故障演练与稳定性建设
线上故障无法完全避免，能控制的是“发现多快、止血多快、同一个坑重复踩过几次”。稳定性建设就是这三件事的工程化：可观测的监控告警、可执行的预案，以及把预案在接近真实的环境里演练一遍。本章讲故障分级与响应流程、常见演练项目与复盘要点。
稳定性体系三根支柱
监控告警 → 知道出事了、知道哪里出事（指标、日志、链路追踪）
预案与演练 → 知道该怎么办，而且演练过（限流、降级、切流、回滚）
复盘改进 → 同类问题不再发生（根因分析 + 改进项闭环）
三者缺一不可：只有监控没有预案，故障时只能现场想对策；只有预案没有演练，真出事时脚本可能早已失效。
监控告警要点
| 层次 | 关键指标 | 作用 |
|---|---|---|
| 业务 | 下单成功率、支付成功率、GMV 曲线 | 最先发现“程序正常但业务异常” |
| 应用 | QPS、错误率、P99、线程池与连接池水位 | 定位自身瓶颈 |
| 中间件 | 缓存命中率与延迟、消息堆积、数据库慢查询 | 定位下游瓶颈 |
| 主机 | CPU、内存、磁盘、网络、文件句柄数 | 定位资源问题 |
| 链路 | TraceID 串联各跳耗时 | 跨服务定位慢在哪一跳 |
告警设计的原则是告警必须可行动：同一现象只保留一条主告警，其余作为关联信息；阈值告警与同比、环比突变告警结合，避免大促期间出现告警风暴。
故障分级与响应
| 级别 | 判定标准 | 响应要求 | 参与角色 |
|---|---|---|---|
| P0 | 核心链路不可用、有资损风险、大面积影响 | 立即拉起，全员响应 | 值班 + 负责人 + 相关方 |
| P1 | 核心功能受损但有绕行方案 | 15 分钟内响应 | 值班 + 模块负责人 |
| P2 | 非核心功能异常、少量用户受影响 | 工作时间处理 | 模块负责人 |
| P3 | 体验问题、潜在隐患 | 排期修复 | 需求方 |
响应流程固定为四步：发现 → 止血 → 定位 → 修复。其中止血优先于定位：能回滚就先回滚、能降级就先降级，不要在故障进行中做根因分析，那是复盘阶段的事。
发现：告警或用户反馈
↓ 3 分钟内确认影响面：哪个功能、多少用户、是否在扩大
止血：回滚版本 / 关闭开关 / 限流降级 / 切流，先恢复核心链路
↓ 记录每个动作的时间点，复盘时要用
定位：对比监控曲线、查 Trace 与日志、核对最近的变更记录
↓
修复：小流量验证后逐步放量，同步更新故障记录
常见演练项目
| 演练项 | 做法 | 验证目标 |
|---|---|---|
| 杀进程 | 随机 kill 应用实例或关键 worker | 负载均衡摘除、重启自愈、发布无损 |
| 网络延迟与丢包 | 用 tc 注入延迟和丢包 | 超时设置是否合理、重试是否放大流量 |
| 依赖超时 | 让下游接口延迟返回 | 熔断降级是否生效、线程池是否被占满 |
| 数据库主从切换 | 主动切换主库或模拟主库不可写 | 切换耗时、应用重连、数据一致性 |
| 缓存宕机 | 停掉缓存实例或清空缓存 | 缓存击穿保护、本地缓存与限流是否兜住 |
| 磁盘写满 | 模拟日志目录写满 | 服务是否仍能服务核心读写链路 |
| 消息堆积 | 停止消费者一段时间后恢复 | 堆积告警、消费速率、重复消费是否出错 |
演练脚本要固化下来，可重复执行：
# 示例：注入 200ms 网络延迟，验证下游超时与熔断配置（需 root 权限）
tc qdisc add dev eth0 root netem delay 200ms
# 演练结束后务必移除，否则会变成持续故障
tc qdisc del dev eth0 root netem
混沌工程工具做的事就是把这类“注入 → 观察 → 恢复”流程自动化、可控化并限定爆炸半径；工具本身不产生稳定性，没有监控与预案的演练只是制造故障。
演练纪律
- 先在生产之外的类生产环境演练；核心链路演练必须在低峰期并提前报备。
- 每次演练设定明确的成功判据（例如“实例被摘除时间小于 30 秒”），否则无法判断是否通过。
- 演练必须有一键终止手段和观察人，避免演练本身变成事故。
- 演练发现的问题要和故障一样走复盘与改进闭环。
复盘要点
| 要素 | 内容 | 常见错误 |
|---|---|---|
| 时间线 | 精确到分钟：何时开始、何时发现、何时止血、何时恢复 | 只写大概时间，无法衡量改进效果 |
| 影响面 | 受影响用户数、订单数、资损金额 | 用“部分用户”含糊带过 |
| 根因 | 直接原因与根本原因：为什么会发生、为什么没更早发现 | 停留在“某人操作失误” |
| 改进项 | 每条都有人、有截止时间、有验证方式 | 写成“加强监控”这类空话 |
复盘的目的是修正系统而不是追责个人，但改进项必须闭环：没有验收的改进项等于没做，下一轮演练或复盘时要逐条核对。
小结：稳定性靠监控告警、预案演练、复盘闭环三者支撑；故障响应遵循“先止血后定位”，常见演练覆盖进程、网络、依赖、数据库、缓存与消息六类；每一次演练与故障都必须产出包含时间线、根因与可验收改进项的复盘记录。