架构词典: 复盘

每次事故发生后，都需要去做复盘。

复盘应该有四个章节，第一个章节简要地描述这次事故的影响范围，影响程度。最好补上能够直接反映影响程度的图表截图，避免因为几个月后这些图表被废弃或者精度降低，无法真实表述当时的情况。

第二个章节，应该按照时间顺序，精确地描述事故期间究竟发生了哪些事情，包括前期的诱因(比如之前的一次上线)，触发事故的最后一根稻草，客户的反馈，排查动作，恢复服务的动作，事后的数据修复动作。时间的精度应该至少精确到分，必要时可以到秒甚至更小的单位。

第三个章节，应该按照逻辑推理的角度描述这次事故发生的原因，并且补上相关的证据(比如日志，Full GC 记录等等)，确保阅读者阅读完毕后能够直接推理出事故必然发生。除了事故根因，这个章节还应该回顾定位过程、修复过程的一些逻辑。

最后一个章节是提升，这也是复盘中最有价值的部分。提升的部分应该分为至少四个部分，首先是根因的修复，这部分比较简单。第二部分是定位过程的提升项，是否可以通过新增工具，或者增减日志来加速定位的流程。第三部分是监控，是否存在客户比我们先发现问题的情况，我们如何第一时间知道问题发生，监控如何更好地指向真实的问题，是否存在可以提升的部分。第四部分是架构提升，某些问题是否可以通过架构的修改来得到根本解决，比如引入分布式事务，就可以减少事务完成一半的 bug；消除服务状态就可以避免单点故障等等。提升项必须要做到可落地，要么是 BUG 的改变，要么是文档的改变，要么是举行一次培训或考试，避免出现下次不要做某某错误操作的表述，这类的表述等于什么都不做。

最后是复盘的通用原则

1. 复盘应该对事不对人，不是追究责任人，而是找出提升项

2. 人都是不可靠的，提升项要多通过修改系统来实现，而不是对人增加规则。对人增加规则反而让人更容易犯错。

3. 复盘要尽快，超过 2 天很可能就遗忘得差不多了。

4. 除了需要保密的事故，复盘的结果应该对组员公开，组员入职后应该学习本组曾经发生的事故。

5. 提升项应该有负责人，有 deadline，PMO 部门要跟踪提升项的执行情况。