一、背景
规范故障复盘流程、复盘内容、判定原则,明确复盘意义
二、参考资料
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 分段判定原则
这个原则主要应用在情况比较复杂的场景:当发生衍生故障,或者故障蔓延的原因与触发原因不同时,我们需要将一次故障分段判断。
五、复盘内容
需要明确一点,引起故障的根因并不是只有一个!
不同角度对故障有不同的看法,例如网络抖动:开发认为是网络原因,让运维去处理即可;而运维认为网终不可控,需要开发自身保证高可用等
因此,在复盘时应包括以下问题:
- 故障原因有哪些
- 如何做才能确保下次不会再出现类似故障
- 当时如果做了什么,可以用更短的时间恢复业务
在整个复盘会议上必须紧扣以上问题展开,除此之外绝不允许出现互相指责和埋怨等情况,若出现会议主持者需要及时控制并打断!
六、复盘流程
- 技术主导整个会议生命周期
- 确定参与人员,发送会议邀请
- 复盘故障内容,根据判定原则确定改进责任方及验收时间
- 验收改进方案
- 向相关部门公示报告,防止类似故障发生
附录
I 复盘报告样本
- 问题描述
-
- 过程描述:简单描述故障过程的表现
- 故障时长:MTTR时长
- 导致结果:描述具体影响点
- 影响范围:B/C端的具体数据
- 事件背景:描述相关事件的背景
- 事件回放:MTTR纬度描述完整过程
- 原因分析:MTTK定位出来的具体根因(直接+根本原因)
- 解决方案:MTBF纬度,包括故障改进(临时+最终方案)、故障预防