故障还原

填写故障的基础信息。

责任人 事故负责人，可 @ 对方
故障等级 P0P1P2P3P4
故障状态 编写中未复盘已定级
故障简述 故障概述，简要描述问题原因，影响面，修复结果
发现方式 发现方式，如：IM 监控群报警、邮件报警
故障发现时间 发现方式，如：IM 监控群报警、邮件报警
故障发生时间 YYYY-MM-DD HH:mm
故障恢复时间 YYYY-MM-DD HH:mm
故障影响时长 服务 xx 分钟不可用

业务影响

本次故障对业务影响的范围。

影响业务场景 影响用户数 影响公司收入 客诉情况
业务线/业务产品 影响用户数 影响公司收入 // 可选，描述影响面
… … … …

处理过程

处理过程推荐按照时间以列表形式，将处理过程时间点，处理内容，阶段性结果描述清楚。

关键时间点 时间 动作 备注
【故障开始】 01/17 16:33 故障导致支付成功率下跌 相关数据统计链接或 IM 群截图
【故障发现】 01/17 16:39 故障由监控发现或客诉上报
【故障止血】 01/17 16:42 执行止血方案
【故障恢复】 01/17 16:59 止血方案生效时间
【故障结束】 01/17 17:55 监控恢复正常或客诉解决

故障原因

产品需求

  • 产品设计是否合理
  • 产品设计阶段未发现的原因

研发阶段

  • 设计是否合理，技术设计阶段未发现原因
  • 开发自测阶段是否发现
  • 联调阶段是否发现
  • 是否由于存在历史技术包袱导致

测试环节

  • 系统测试阶段是否发现
  • SIT 回归测试阶段否发现

发布流程

  • 是否进行灰度发布，灰度发布时长是否足够
  • 发布后是否关注线上监控项异常
  • 监控项是否缺失，包括链路监控/系统监控/业务监控

应急处理

  • 问题定位，存量的措施中是否提供确定的操作指南
  • 应急时各步骤是否存在优化空间
  • 是否可以做到自愈

故障总结

在业务的日常变更中，是否遵守了安全原则，技术架构是否合理，等等。

  • 是否有功能降级
  • 是否有容灾备份
  • 是否记录完整的日志信息

    做得好的

    本次故障中，有哪些是做的好的。

做得不好的

本次故障中，有哪些是做的不够好的。

后续改进

复盘后需要进行的后续操作，应指定负责人。

行动 类型 负责人 优先级 预计完成时间

- [ ] 补齐监控项
 发现 P0 01-24

- [ ] 提供熔断能力
 限流 P0 01-24

- [ ] 优化慢 SQL
 程序优化 P0 01-24