复盘报告在it公司中是为了在出现事情后，我们更好的回顾事情的前因后果，定位问题，指定解决措施，并且宣导，让这类事情减少发生的概率。那复盘报告一般怎样写合适呢？下来我们就看看，
一、一般会先还原下故障的基本信息：
1、基础信息
|--------|-------------------------|
| 责任人 | 故障负责人，可 @ 对方 |
| 故障等级 | 【P1】【P2】【P3】【P4】【紧急变更】： |
| 故障状态 | 【编写中】【未复盘】【已定级】 |
| 故障简述 | 故障概述，简要描述问题原因，影响面，修复结果 |
| 发现方式 | 发现方式，如：IM 监控群报警、邮件报警 |
| 故障发现时间 | 发现方式，如：IM 监控群报警、邮件报警 |
| 故障发生时间 | YYYY-MM-DD HH:mm |
| 故障恢复时间 | YYYY-MM-DD HH:mm |
| 故障影响时长 | 服务 xx 分钟不可用 |
在这个里面如何故障定级是一个问题，一般可以参考这个，也可以再加一些公式个性化的项目
出处:《云上稳定性指南》
二、我们要交代处理过程
处理过程推荐按照时间以列表形式，将处理过程时间点，处理内容，阶段性结果描述清楚。
2、1 处理过程
|--------|----|----|----|------------------|
| 关键时间点 | 时间 | 现象 | 动作 | 备注 |
| 【故障开始】 | | | | 相关数据统计链接或 IM 群截图 |
| 【故障发现】 | | | | |
| 【故障处理】 | | | | |
| 【故障恢复】 | | | | |
| 【故障结束】 | | | | |
2、2【影响时间轴 】（具体到分钟级）
（完善时间线及细节，包括报警、监控、干系人提供的信息）
1、【故障日期 2020-06-22】
2、【故障起因】
（做简单原因描述，帮助大家快速进入状态，结论先行，上线了什么需求或者什么其他改动导致了么）
3、【故障发现/报警】
4、【故障定位】
5、【处理】
6、【恢复】
7、【故障处理及时性总结】
发现时间：【x分钟】（发生->发现）
定位时间：【x 分钟】（发现->定位）
止损时间：【3 分钟】（定位->止损）
恢复时间：【6 分钟】（止损->修复）
三、评估好影响范围
这个每家都可以不一样，但可以先有一个基线，各种特性业务自己部门再规定
|-------------|----------|------------------|--------|-------|-----------|------|---------|------|
| 业务量级 （大中小微） | 业务场景 | 功能级别（核心、次核心、非核心） | 可用率下降率 | 影响用户数 | 影响关键性交易笔数 | 资损金额 | 客诉舆情上升率 | 持续时长 |
| | 业务线/业务产品 | | | | | | | |
| | ... | | ... | | | | | |
四、确定发生原因
首先我们会列出是哪个系统的，然后逐步分析确定原因是在什么阶段发生的
4、1【直接原因】
1、xxx做了什么样的变更，导致了什么样的问题
或者系统存在怎样bug，当单量到达阈值导致性能瓶颈，造成雪崩
4、2、【根本原因】
1、产品需求
- 产品设计是否合理
- 产品设计阶段未发现的原因
2、研发阶段
- 设计是否合理，技术设计阶段未发现原因
- 开发自测阶段是否发现
- 联调阶段是否发现
- 是否由于存在历史技术包袱导致
3、测试环节
- 系统测试阶段是否发现
- SIT 回归测试阶段否发现
4、发布流程
- 是否进行灰度发布，灰度发布时长是否足够
- 发布后是否关注线上监控项异常
- 监控项是否缺失，包括链路监控/系统监控/业务监控
5、应急处理
- 问题定位，存量的措施中是否提供确定的操作指南
- 应急时各步骤是否存在优化空间
- 是否可以做到自愈
五、确定责任
确定原因后，我们就应该能确认故障的归属团队和事件级别了
六、故障回归
在之后我们还要做一次故障回顾，看看怎样优化减少再次发生的概率，例如
6、1日常变更中是否遵守了安全原则，技术架构是否合理等等。
- 是否有功能降级
- 是否有容灾备份
- 是否记录完整的日志信息
6、2 好的经验
本次故障中，有哪些是做的好的。
6、3 教训反思
本次故障中，有哪些是做的不够好的
6、4 优化措施：
|----|----|-----|-------|--------|------|--------|
| 序号 | 事项 | 优先级 | 对应责任⼈ | 计划完成时间 | 是否完成 | 实际完成时间 |
| | | | | | | |
能完成复盘报告也是有一个隐含条件的，需要在公司内进行系统定级。
其他关于稳定性更深入的一些信息看过觉得比较好的有这些,但是一些措施是贯穿于设计、测试和众多组件和流程的搭配，还在梳理，组件可用的有一些是云厂商的产品的逻辑还在学一学：
1、云上稳定性指南.pdf
- 安全生产指南的副本.pdf
- 信息系统稳定性保障能力建设指南的副本.pdf
- 滴滴稳定性建设：https://blog.csdn.net/manzhizhen/category_9613558.html
- 哈啰出行高质量故障复盘法："3+5+3"：哈啰出行高质量故障复盘法："3+5+3"（附模板）_TakinTalks稳定性社区_InfoQ写作社区
- 稳定性与高可用保障的工作思路：稳定性与高可用保障的工作思路
- 可用性指标最新盘点，哪个技术团队还没贴墙上：可用性指标最新盘点，哪个技术团队还没贴墙上
- 中国卓越技术团队访谈录·2022第三季.pdf
- 分布式稳定性建设指南.pdf
- TakinTalks稳定性社区