相信无论在哪行哪业，总会有“线上问题”，比如购买电子产品，使用有问题进行维权等等，每行每业都有内部的处理手段及问题复盘手段，那在互联网，或者说在移动端，该如何复盘呢？
关于复盘，JB看法是，无论大事小事，只要是有意义，复盘这个事情都值得去做~
最粗暴的方式，举例子：
某app，在A日晚上，某同学在后台配置参数，结果在E日，出现大量用户反馈称该app出现某严重功能问题，最终定位是因为A日配置参数错误导致问题发生，解决方案是重新配置正确的参数即可解决；
这个事情，从上面文字上看，有3个疑问：
1）为什么配置几天后才暴露问题？
2）为什么配置后不进行验证上是否正常？
3）为什么配置错误内容后就会出现问题？
收到的回复是：
1）因为这个参数是活动配置参数，定的就是在E天才开放给用户；
2）验证比较麻烦，而且配置同学不懂怎么验证；
3）配置的内容不符合代码规范，当时明确要求配置的同学要按照文档来配置的；
到了这步，也许有同学会说，哦，然后就没然后了~
但实际，这背后有潜在的问题：
1）查看埋点数据，发现A日配置参数了，从当天就已经有出现异常的埋点信息，只是数量比较少，而且没有用户反馈，当到E日开放，用户量暴增，才把问题暴露；
这是否就变成了，线上监控预警不到位，出现问题没有及时通知对应负责人？还是通知了，负责人因预警邮件太多没有看到？麻痹性疏忽？
方案：如果是没有通知，配置通知；如果是因为预警邮件过多而疏忽，重新梳理预警邮件，减少不必要的预警；如果没有埋点日志，新增并形成预警链路闭环。
2）是否有工具提供验证？工具是否灵活好用？
方案：提供校验工具，小白式教学使用，越简单越好；
3）这问题主要围绕2方面，文档的约束力是很低的，客户端代码健壮性及容错率、配置平台的异常提示，发现是明显错误，从源头上不允许发布；
上面这个例子是很普遍的例子，却隐藏了背后的问题，上面也提供一些解决方案~
但，这只是复盘内容的一环；
复盘应包含以下几部分：
1）问题回顾， 收到首条问题反馈时间+量级、问题引入具体时间、本地解决时间、线上用户解决时间；
2）问题影响范围；
3）问题出现原因&解决方案；
4）后续改进计划，正如例子所述，了解问题原因及背景，哪个环节出问题，是否有深挖可能等；
小结：
问题的解决方案有很多种，但哪个才是问题的本质~
感兴趣的同学可以看看下面的截图~
