如何写复盘报告

复盘报告在it公司中是为了在出现事情后,我们更好的回顾事情的前因后果,定位问题,指定解决措施,并且宣导,让这类事情减少发生的概率。那复盘报告一般怎样写合适呢?下来我们就看看,

一、一般会先还原下故障的基本信息:

1、基础信息

如何写复盘报告_第1张图片 image

在这个里面如何故障定级是一个问题,一般可以参考这个,也可以再加一些公式个性化的项目 如何写复盘报告_第2张图片

出处:《云上稳定性指南》

二、我们要交代处理过程

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

1、 处理过程

关键时间点时间现象动作备注【故障开始】相关数据统计链接或 IM 群截图【故障发现】【故障处理】【故障恢复】【故障结束】

2、【影响时间轴 】(具体到分钟级)

(完善时间线及细节,包括报警、监控、干系人提供的信息)

1、【故障日期 2020-06-22】

2、【故障起因】

(做简单原因描述,帮助大家快速进入状态,结论先行,上线了什么需求或者什么其他改动导致了么) 3、【故障发现/报警】

4、【故障定位】

5、【处理】

6、【恢复】

7、【故障处理及时性总结】

发现时间:【x分钟】(发生->发现) 定位时间:【x 分钟】(发现->定位) 止损时间:【3 分钟】(定位->止损) 恢复时间:【6 分钟】(止损->修复)

三、评估好影响范围

这个每家都可以不一样,但可以先有一个基线,各种特性业务自己部门再规定

如何写复盘报告_第3张图片 image

四、确定发生原因

首先我们会列出是哪个系统的,然后逐步分析确定原因是在什么阶段发生的

1、【直接原因】

1、xxx做了什么样的变更,导致了什么样的问题 或者系统存在怎样bug,当单量到达阈值导致性能瓶颈,造成雪崩

2、【根本原因】

1、产品需求

  • 产品设计是否合理

  • 产品设计阶段未发现的原因 2、研发阶段

  • 设计是否合理,技术设计阶段未发现原因

  • 开发自测阶段是否发现

  • 联调阶段是否发现

  • 是否由于存在历史技术包袱导致 3、测试环节

  • 系统测试阶段是否发现

  • SIT 回归测试阶段否发现 4、发布流程

  • 是否进行灰度发布,灰度发布时长是否足够

  • 发布后是否关注线上监控项异常

  • 监控项是否缺失,包括链路监控/系统监控/业务监控 5、应急处理

  • 问题定位,存量的措施中是否提供确定的操作指南

  • 应急时各步骤是否存在优化空间

  • 是否可以做到自愈

五、确定责任

确定原因后,我们就应该能确认故障的归属团队和事件级别了

六、故障回归

在之后我们还要做一次故障回顾,看看怎样优化减少再次发生的概率,例如 1、日常变更中是否遵守了安全原则,技术架构是否合理等等。

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

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

3、教训反思

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

4、优化措施:

如何写复盘报告_第4张图片 image

能完成复盘报告也是有一个隐含条件的,需要在公司内进行系统定级。 其他关于稳定性更深入的一些信息看过觉得比较好的有这些,但是一些措施是贯穿于设计、测试和众多组件和流程的搭配,还在梳理,组件可用的有一些是云厂商的产品的逻辑还在学一学:

1、云上稳定性指南.pdf

1.安全生产指南的副本.pdf

2.信息系统稳定性保障能力建设指南的副本.pdf

3.滴滴稳定性建设:https://blog.csdn.net/manzhizhen/category_9613558.html

4.哈啰出行高质量故障复盘法:“3+5+3”:https://xie.infoq.cn/article/af67d43b24eee787815dc7ff3

5.稳定性与高可用保障的工作思路:https://mp.weixin.qq.com/s/AWRA2kuT5mvhmYA54NXlgA

6.可用性指标最新盘点,哪个技术团队还没贴墙上:https://mp.weixin.qq.com/s/wGhEp5bLSFE5mq5NxEXx_Q

7.中国卓越技术团队访谈录·2022第三季.pdf

8.分布式稳定性建设指南.pdf

9.TakinTalks稳定性社区

本文由 mdnice 多平台发布

你可能感兴趣的:(后端)