线上问题如何复盘？
昨天知识星球社群里有同学问了一个问题：线上问题如何复盘？从流程、分析和后续措施落地有哪些好的建议？
从质量保障的角度来说，针对线上问题进行复盘可以发现工作中的不足并持续改进，不断提高线上的交付质量。
从团队管理的角度来说，针对线上问题进行复盘也可以发现团队短板并针对性的补齐技术体系，提高团队效率。
那在具体实践中，又该如何来执行和实践呢？这篇文章我想聊聊我的一些实践经验和思考。
如何理解线上问题？
大家都知道，软件系统存在问题是个必然事件。无论是需求&设计环节逻辑不完善还是研发实现或测试遗漏，抑或用户操作问题甚至是网络或者设备兼容，总会存在各种各样的问题。
由于影响因素众多，且穷举的成本和复杂度太高，因此完美无缺没有问题的软件系统只存在于理想中。
关于线上问题，在具体的复盘实践中，一般归类为下面两种：
- 线上问题：生产环境出现了影响用户使用或者影响业务目标达成的问题，但未造成直接损失或影响；
- 线上故障：生产环境出现了影响用户使用或者影响业务目标达成的问题，且造成了直接损失和较大的负面影响；
如何理解这里的直接损失和影响呢？一般有如下几点判断因素：
- 问题在造成影响前是否被观测到并修复；
- 问题从发现到修复的持续时长(故障时长)；
- 问题造成了多少的直接损失(专业点叫做资损)；
- 问题对企业品牌形象带来的负面影响和客诉量；
为什么要开展复盘？
看完了上面的内容，我们再聊聊为什么要开展复盘。
无论是线上问题还是线上故障，其本质都是证明我们交付的软件系统存在不足。区别在于一个未造成直接损失和影响，另一个造成了业务的直接损失和影响。
从质量保障的角度来说，针对线上问题进行复盘可以发现工作中的不足并持续改进，不断提高线上的交付质量。
从团队管理的角度来说，针对线上问题进行复盘也可以发现团队短板并针对性的补齐技术体系，提高团队效率。
从业务目标的角度来说，技术团队作为成本中心，也需要不断提高自身的交付产出质量，来支撑业务目标更好的达成。
当然，上面都是官方的话。在实践中，很多企业的问题复盘，其实就是向下施压+横向甩锅+向上交代。
毕竟，大家混职场都是要恰饭的，有利益诉求，自然有了竞争（此处划掉）。
复盘的核心是什么？
在聊复盘的核心之前，先介绍下问题复盘的大致流程。如下图：
如上图所示，问题复盘的流程大致分为五个环节，当然，真正的问题复盘主要集中在第二到第四环节。可以理解为记录问题是事前，问题复盘是事中，跟进优化是事后。
线上问题复盘的核心是什么呢？我个人认为最核心的因素是找到问题的原因并且确定问题得到有效的解决。
回看本文开始的一段话，复盘是为了找到影响业务目标达成的原因，得到进一步的TODO项，有明确的优化条例并落实到具体的人具体的时间具体的优化效果。
复盘该如何落地实践？
还是基于上图问题复盘的流程，来聊聊如何落地实践。
问题记录：问题记录的核心在于详细的记录问题发生前是什么，发生后出现了什么现象，造成了什么影响。需要较为完善的日志和监控体系作为支撑，这样便于后续分析原因讨论优化方案。
组织复盘：组织问题复盘更多的是一个流程和协作机制上的问题，很类似需求评审或者技术方案评审。
陈述问题：这一环节，需要详尽的介绍问题的前因后果以及造成的影响。要注意的是，最好考虑到如果当时做了什么，可以降低或者避免出现故障或者不良影响以及资损。
讨论优化方案：优化方案需要注意两点：首先是怎么做能解决或避免问题再次发生；其次是是否有潜在的类似因素可以通过更好的方案避免更多类似问题发生。
验证落地效果：这一环节是最容易流于形式的环节，很多公司复盘完方案讨论了就不了了之，这样复盘是没什么效果的。
验证优化方案的落地效果，需要明确的数据度量和监控，来进行对比验证，证明优化是有效果的，效果怎样，是否达到预期，是否发现了潜在的类似问题。这才是问题复盘事后最大的价值所在。
