线上问题排查经验

长期从事后端研发工作，不可避免的会遭遇到许多线上服务的问题，结合我自己的一些经验，整理下排查的过程及思路，供大家参考。

一、定位优先级及紧急程度

根据功能及影响范围，确定优先级及紧急程度；决定是否需要向上通报，协调其他资源介入。

二、做好通报

在问题发生的时候，研发同学经常一心问题的排查上，心无旁骛。这个认真程度是非常赞同的，在排场时间过长的情况下，就有可能造成业务相关方及问题发布者长时间没有收到反馈。本着“提升用户体验”的理念，我们要将这些同学当成用户来看待，要做到有进度、有通报。

一般通报可以在几种场景下进行：

1. 首先，接到问题的第一时间表示跟进。
2. 视优先级及紧急程度，告知业务相关方，方便他们了解情况，做出相应调整。
3. 视优先级及紧急程度，告知上级，方便做出更上层的决策及协调更多资源。
4. 有较大进展的时候，进行周知，方便相关人员了解进展。
5. 如果问题定位时间较长。重大问题可以采用定时通告的方式；次要问题可以进行排期后周知相关人员。
6. 如果有必要进行回滚，回滚前后都通告下相关人员，方便他们了解情况，确定影响，做出调整。
7. 问题有结论后，进行通告，并给出后续解决方案。
8. 问题最终排期解决后，进行通告。

这些通告的目的是同步信息，方便相关方做出对应措施。

三、问题排查的思路及方法

 一、收集问题及环境信息

      信息越丰富，意味着问题的脉络更清晰，而且如果不在第一现场尽可能多的收集这些信息，就有可能因为现场的破坏而导致线索再也采集不到。

      需要收集的信息可能有：
     
           问题的已知首次发生时间

           问题反馈人员所处的环境，例如省、市、ip、ISP、浏览器、手机型号、app 版本等

           问题是全员的还是部分的

           问题发生在哪些服务器上

           同期相关的日志、数据信息

           同时期的上线、配置变更、运维操作、基础服务变更等记录

           同时期基础服务提供商的变更、故障公告等

 二、汇总信息并从多条排查线去进行分析

      这里我常用的思路有：

           通过变更记录来咨询相关人员，大量问题其实都是上线、变更等引起的，所以排查下同时期有过业务相关的变更操作人员，往往就可以把很多问题排除在这道线上了。

           通过日志、数据等，把一些已知问题筛选出来。

           通过影响人群、问题点等信息尝试找出复现方法。一般来说，能有方法稳定复现的问题，就比较容易排查到了。

           到这一步的问题，基本上都属于一些疑难杂症了，就没有一些特别通用的方法了。需要开阔思路，找找规律，将平时没关注到的技术、业务点再了解的更细致，更深入一些，或者求助于团队的帮助一起来解决。

四、总结

 这里的总结包括两个部分。

 一个是个人的总结。一次问题的定位解决往往伴随着个人的成长，我们不要放弃这样的机会。在追查过程中了解的知识点是比较零碎的，不系统。事后就需要大家将这些点整体串起来，并且以点带面，将知识点变更知识面。

 二是团队的总结，这个总结又分两个部分

      一是对这次问题的反思，我们应该在流程、代码、工具或者哪些方面做出调整，可以更好的避免同类型问题的出现。

      二是对追查过程的总结，在问题定位的过程中，我们缺少哪些帮助及工具的支持，能否更好的提升排查问题的效率，然后相关人员是否对过程结果存在异议。

最后，也希望用抛砖引玉的方式，带出大家的思考与总结。