故障复盘

更新时间:

故障复盘规范

故障复盘作为故障体系中的重要一环,整体复盘流程包括故障处理过程、改进分析、故障定责,基于包含标准化的复盘SOP、对应预防action推荐、问责管理机制,全面地回溯线上故障的发生,产出故障复盘报告和改进措施,避免故障重复发生。

复盘遵循以下标准流程:

  • 过程回溯:可使用5-why方法提出多个问题对处理过程进行深挖。如本次故障为什么会发生?为什么没有提前发现?过程中各个团队是如何处理的?处理过程是否有可以优化的空间?

  • 问题剖析:回溯完成过程之后,需要深层次剖析:是否流程机制层面问题?是否质量检验层面问题?是否产品业务层面问题?是否系统设计层面问题?有没有更好的防御机制?如何避免再次发生?

  • 经验总结:剖析出来深层次原因之后,需要切实给出可落地的Action,包括给出短期治标Action,长期治本Action,以及沉淀经验和教训。

  • 定级定责:完成原因和改进方案后,针对本次故障做最终的等级认可和故障责任划分。责任团队分为主要责任团队和次要责任团队,以及测试责任团队。

  • 改进追踪:当完成复盘后,如无法有效的落地执行改进,将导致复盘的成果白费。所以在故障复盘中就需要明确改进方案并限定完成时间。

    • 制定的action需要符合 SMART 原则,即:

      • Specific:即改进项。需要改进、优化的单项、指标是什么?

      • Measurable:即验收标准。指定改验收标准是什么?

      • Attainable:即改进项是否可以达到。避免出现一些假大空、无法落地的改进;

      • Relevant:即要与其他改进具有一定的相关性。即尽可能避免出现孤立的改进;

      • Time-bound:即预期解决时间。这个时间建议最长不要超过三个月,避免改进流于形式;

    • 一个完整的action建议记录以下内容:标题、计划完成时间、负责人(及其团队或协助处理人)、验收方式及验收人、跟踪人、改进措施的类别、具体改进内容描述及验收标准。在改进项完成后可有选择地进行验收,如评审验收、演练验收等。验收完成后由验收负责人完结此改进action的整体工作。

复盘文档一般包含以下内容:

  • 故障简述:故障概述、影响面、处理人等

  • 故障背景:故障发生时的业务链路

  • 故障时间线:着重强调故障引入、故障发生、故障发现、业务响应、恢复执行、故障恢复几个时间点

  • 故障原因分析:建议先一句话总结,再进行具体原因剖析

  • 故障过程分析:可从需求评估、代码发布、故障应急等环节进行分析

  • 后续改进:后续改进措施,明确改进方和责任人

  • 故障等级/责任:参考上述故障等级定义,定义本次故障等级,并明确责任团队和责任人。

故障数据运营

基于基础故障数据,通过不同维度和形式,以线上和线下结合的方式,在报表平台、安全生产报告、安全生产会议等不同场合进行故障数据的披露和运营。目的是利用历史故障数据,度量稳定性现状和能力。故障数据运营的核心是通过故障分量化计算考核,实现整体故障收敛。

故障分整体目标

安全生产故障分目标,经过与各业务团队沟通采用自上而下拆解方式进行设定。比如本财年故障分同比上财年收敛20%-30%。安全生产故障分更深层次拆解由各业务团队内部根据实际情况设定。

故障分计算方案

在设计故障分的计算规则时,建议考虑以下维度数据指标:

故障时长

故障时长=故障恢复时间-故障发生时间

故障发生时间

最接近故障等级定义激活(P4起)的时间点。按照如下顺序:

  1. 针对业务监控:取首次达到故障等级(P4起)的时间为准;

  2. 针对用户上报:取业务开始受影响的时间点;

  3. 若无法评估受影响的时间点则取首次用户上报的时间。

故障恢复时间

故障止血(即:不再发生新增业务/用户影响)的时间点(客户端以测试通过且可实际修复问题版本提交APP审核为恢复时间);

如果有业务监控以监控恢复至正常基线为准,否则以止血时间为准。

注:故障时长及是否降级/减免如有争议,以安全生产值班长判定为准。

收敛比

一般指本财年与上财年对比结果,体现与自身同期收敛效果,为负数代表收敛,负值越大说明收敛效果越好,为正数代表发散,正值越大说明发散越严重,具体计算方法为:

收敛比=(本财年某时段-上财年同时段)/上财年同时段

消耗比

一般指本财年实际消耗故障分,占故障分目标的比例,体现与设定收敛目标的差距,提示达到收敛目标的剩余消耗空间,数值越小越好。

消耗比= 本财年累计消耗故障分/财年故障分目标

制定故障分建议考虑以下原则:

  • 拉齐横向标准:在企业上层拉齐标准,降低各个子部门和业务团队的理解成本。

  • 减少重大故障影响:针对特大故障,设置较大的系数倍数,以凸显特大故障对故障分的影响。

  • 鼓励快速恢复:针对不同P等级故障,差异化设置系数,以体现恢复时长要求。比如同时针对P1P2级重大故障,设置了“5分钟内恢复降一级,10分钟内恢复故障分计80%”的通用标准。

  • 细化责任拆解:设置主次责团队的故障分拆解逻辑,比如主次责团队默认按7:3比例拆分故障分。

  • 故障分统计默认排除:容灾演练&全链路压测符合预期故障、特定打标过不参与故障统计的业务等。