线上故障复盘规范

一、背景

规范故障复盘流程、复盘内容、判定原则，明确复盘意义

二、参考资料

2.1 名词定义

• MTBF：Mean Time Between Failure，平均故障时间间隔
• MTTR：Mean Time To Repair， 故障平均修复时间，包括MTTI、MTTK、MTTF、MTTV

• • MTTI (Mean Time To ldentify,平均故障发现时间)，也就是从故障实际发生，到我们真正开始响应的时间。这个过程可能是用户或客服反馈、舆情监控或者是监控告警等渠道触发的。
  • MTTK (Mean Time To Know，平均故障认知时间)，更通俗一点，可以理解为我们常说的平均故障定位时间。这个定位指的是root cause，也就是根因被定位出来为止。
  • MTTF (Mean Time To Fix，平均故障解决时间)，也就是从知道了根因在哪里，到我们采取措施恢复业务为止。这里采取的手段就很多了，比如常见的限流、降级、熔断，甚至是重启。
  • MTTV (Mean Time To Verify,平均故障修复验证时间)，就是故障解决后，我们通过用户反馈、监控指标观察等手段，来确认业务是否真正恢复所用的时间。

三、复盘意义

故障是系统运行的常态，正常才是特殊状态！

因此，无论作为什么角色，一定要以平常心对待故障，我们的目标是鼓励改进，而不是处罚出错

四、判定原则

这里并不是要判定承担故障的责任方，而是由谁来承担主要的改进职责，是为了培养大家对于系统稳定性的责任心！

4.1 健壮性原则

这个原则要求每个部件自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等。

例如，在 B 依赖 A 的状态下，被依赖方 A 出现问题，但是能够快速恢复，而依赖方 B 无法快速恢复，导致故障蔓延。这时，承担主要责任的是依赖方 B，而不是被依赖方 A

另外，核心应用对非核心应用的依赖必须要有降级和限流手段。如果因为非核心应用的故障或者瞬时高并发访问，导致核心应用故障，这种情况下，主要的改进责任在核心应用，非核心应用只需要配合改造

4.2 第三方默认无责

这一条是上一条的延伸，如果使用到了第三方的服务，如公有云的各类服务，包括 IaaS、PaaS、CDN 以及视频等等，我们的原则就是默认第三方无责。

涉及第三方服务的情况，在判定改进责任时会分为两部分，对内谁的服务受影响谁改进，并对外推进第三方改进，但是稳定性一定要做到相对自我可控，而不是完全依赖外部

注意，本条不适用于强依赖关系，例如前台数据实时依赖于中台服务，除非服务本身状态接收一定程度的不同步

4.3 分段判定原则

这个原则主要应用在情况比较复杂的场景：当发生衍生故障，或者故障蔓延的原因与触发原因不同时，我们需要将一次故障分段判断。

五、复盘内容

需要明确一点，引起故障的根因并不是只有一个！

不同角度对故障有不同的看法，例如网络抖动：开发认为是网络原因，让运维去处理即可；而运维认为网终不可控，需要开发自身保证高可用等

因此，在复盘时应包括以下问题：

• 故障原因有哪些
• 如何做才能确保下次不会再出现类似故障
• 当时如果做了什么，可以用更短的时间恢复业务

在整个复盘会议上必须紧扣以上问题展开，除此之外绝不允许出现互相指责和埋怨等情况，若出现会议主持者需要及时控制并打断！

六、复盘流程

1. 技术主导整个会议生命周期
2. 确定参与人员，发送会议邀请
3. 复盘故障内容，根据判定原则确定改进责任方及验收时间
4. 验收改进方案
5. 向相关部门公示报告，防止类似故障发生

附录

I 复盘报告样本

• 问题描述

• • 过程描述：简单描述故障过程的表现
  • 故障时长：MTTR时长
  • 导致结果：描述具体影响点
  • 影响范围：B/C端的具体数据

• 事件背景：描述相关事件的背景
• 事件回放：MTTR纬度描述完整过程
• 原因分析：MTTK定位出来的具体根因（直接+根本原因）
• 解决方案：MTBF纬度，包括故障改进（临时+最终方案）、故障预防