02.技术复盘专项模版

01.为什么需要复盘

⼀件事情做完后⽆论成功与否，坐下来把当时预先的想法、中间出现的问题、为什么没达成⽬标等因素整理⼀遍，在下次做同样的事时，⾃然就能吸取上次的经验教训。这就是复盘。

复盘不是⽤于追责，⽽是为了发现和解决问题、积累经验、优化流程，避免再次出现同样问题。

02.事故清晰的描述

对事故的具体表现表述清楚，⽐如正常情况下逻辑是什么，出现问题后表现是什么，可以⽤截图⽅式说明。

03.事故的影响数据

1. 数据⼝径要准确，要说明影响数据的计算公式。
2. 定级是根据受影响功能使用量、受影响⽤户数、资损三个维度来定级，若事故对这三个维度都有影响，那需要把相关数据都统计，以影响最⼤的纬度定级。

04.事故回放的记录

1. 事故时间线不要漏了关键节点，处理⼈、采取对应的⾏动和原因。
2. 时间线需要完整，包含事前、事中、事后的动作。

05.事故的原因分析

1. 直接原因，是直接导致事故发⽣的原因，常⻅的是代码逻辑问题、分⽀合并、并发等。
2. 深层原因，是挖掘为什么会出现这个事情深层次原因，也要从事前、事中、事后⻆度分析。

挖掘的⽅法可以在原有问题上在问为什么，⽐如为什么事故持续时间这么⻓？为什么代码逻辑有问题？为什么这个问题没有被发现。

深层原因才是我们要复盘解决的问题，能够避免相同问题再出现。

06.事故的解决方案

止损方案：详细描述止损方案

解决方案：详细描述解决方案，决定什么时候解决。要有一个把控进度的能力。

07.复盘的后续改善

改善措施⼀定要写切实可落地的，和原因分析得出的结论要相对应，并且要有完成时间和跟进⼈。

08.复盘的相关原则

事事总结：敬畏错误，原则上，所有线上问题（含pre发现的严重问题），都有必要复盘，形成wiki

强调意识：违规线上操作或者严重的主观意识问题，升格处理；难以规避的技术问题，特别是由于业务快速发展⽽不得不承担的线上⻛险，酌情降级

流程和技术设计：流程+技术设计类问题，重点关注：遇到基础库导致的线上bug、设计或沟通不到位、代码合并、常犯模块（>2次）、其他明显质量意识或机制，导致的线上问题/测试暴露被投诉的案例

举⼀反三：凡是犯某个具体错误的，都需要承担⼼梳理上下游类似问题/某个技术点更完 整学习，进⾏组⾥分享的责任；把问题，当成学习机会