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

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

1、基础信息

在这个里面如何故障定级是一个问题，一般可以参考这个，也可以再加一些公式个性化的项目

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

二、我们要交代处理过程

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

1、 处理过程

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

2、【影响时间轴 】（具体到分钟级）

（完善时间线及细节，包括报警、监控、干系人提供的信息）

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

2、【故障起因】

（做简单原因描述，帮助大家快速进入状态，结论先行，上线了什么需求或者什么其他改动导致了么）

3、【故障发现/报警】

4、【故障定位】

5、【处理】

6、【恢复】

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

发现时间：【x分钟】（发生->发现）

定位时间：【x 分钟】（发现->定位）

止损时间：【3 分钟】（定位->止损）

恢复时间：【6 分钟】（止损->修复）

三、评估好影响范围

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

四、确定发生原因

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

1、【直接原因】

1、xxx做了什么样的变更，导致了什么样的问题

或者系统存在怎样bug，当单量到达阈值导致性能瓶颈，造成雪崩

2、【根本原因】

1、产品需求

• 产品设计是否合理
  
• 产品设计阶段未发现的原因
  2、研发阶段
  
• 设计是否合理，技术设计阶段未发现原因
  
• 开发自测阶段是否发现
  
• 联调阶段是否发现
  
• 是否由于存在历史技术包袱导致
  3、测试环节
  
• 系统测试阶段是否发现
  
• SIT 回归测试阶段否发现
  4、发布流程
  
• 是否进行灰度发布，灰度发布时长是否足够
  
• 发布后是否关注线上监控项异常
  
• 监控项是否缺失，包括链路监控/系统监控/业务监控
  5、应急处理
  
• 问题定位，存量的措施中是否提供确定的操作指南
  
• 应急时各步骤是否存在优化空间
  
• 是否可以做到自愈
  

五、确定责任

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

六、故障回归

在之后我们还要做一次故障回顾，看看怎样优化减少再次发生的概率，例如

1、日常变更中是否遵守了安全原则，技术架构是否合理等等。

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

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

3、教训反思

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

4、优化措施：

能完成复盘报告也是有一个隐含条件的，需要在公司内进行系统定级。

其他关于稳定性更深入的一些信息看过觉得比较好的有这些,但是一些措施是贯穿于设计、测试和众多组件和流程的搭配，还在梳理，组件可用的有一些是云厂商的产品的逻辑还在学一学：

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稳定性社区