线上问题排查经验

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

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

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

2、作好通报

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

通常通报能够在几种场景下进行：

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

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

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

1、收集问题及环境信息

      信息越丰富，意味着问题的脉络更清晰，并且若是不在第一现场尽量多的收集这些信息，就有可能由于现场的破坏而致使线索再也采集不到。

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

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

           问题是全员的仍是部分的

           问题发生在哪些服务器上

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

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

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

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

      这里我经常使用的思路有：

           经过变动记录来咨询相关人员，大量问题其实都是上线、变动等引发的，因此排查下同时期有过业务相关的变动操做人员，每每就能够把不少问题排除在这道线上了。

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

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

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

4、总结

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

 一个是我的的总结。一次问题的定位解决每每伴随着我的的成长，咱们不要放弃这样的机会。在追查过程当中了解的知识点是比较零碎的，不系统。过后就须要你们将这些点总体串起来，而且以点带面，将知识点变动知识面。

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

      一是对此次问题的反思，咱们应该在流程、代码、工具或者哪些方面作出调整，能够更好的避免同类型问题的出现。

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

最后，也但愿用抛砖引玉的方式，带出你们的思考与总结。