主动扩大信息的接收面，比如问询一下开发或其它相关同学，今天有没有做线上改动，网络组有无重大调整。从中获取到有价值的信息点，对于排查问题至关重要。查看监控，细看某个监控项的变化，追踪日志和调试信息都是扩大信息量的手段。
拓展知识面，闲暇时间多些了解相关联系统，比如架构，部署，逻辑等。一旦故障发生，讨论中也可提供你解决办法的思路，举一反三，推进问题的排查与解决。
收集问题及环境信息，需要收集的信息可能有：
- 问题的已知首次发生时间
- 问题反馈人员所处的环境，例如省、市、ip、ISP、浏览器、手机型号、app 版本等
- 问题是全员的还是部分的。
- 问题发生在哪些服务器上。
- 同期相关的日志、数据信息。
- 同时期的上线、配置变更、运维操作、基础服务变更等记录。
- 同时期基础服务提供商的变更、故障公告等。
五、分析证词，甄别对错
如果是外部提出的问题，比如业务投诉，用户反馈等信息，有时候是可信的，有时候人却是不可信的，举个例子之前有开发反馈效果有问题，有些广告位bias异常，有些正常，让我们帮查查系统的问题，但是最后是代码调用一处动态配置造成的。有些时候反馈的信息，是经过描述者过滤加工过的信息，他的排查和分析有可能把你带偏了，在收集信息同时需要以审视、怀疑的态度，分析每个人的证词。
六、看清问题本质
“当你听到蹄子声响时，应该先想到马，而不是斑马”，看到一件现象或一件事情，要看实质而不只是表面的东西，听到马蹄声时候猜是什么马，是什么人的马，是来干什么的而不是猜它是斑马还是白马还是黑马。排查问题也一样切忌先入为主，有时候你觉得极其简单，看似非常不可能发生的事情，可能就是原因，不要轻易的排除掉某项原因。例比：之前遇到有个mysql连接异常的问题，查了很久，做了很多调优都没有解决，最后发现是网卡跑满了。
七、确定方向，开展定位
排查步骤，可以先“从大到小”，先看比如运营商网络，机房状态等比较宏观的地方是否有问题，逐一排除，逐步缩小问题范围。再“从上到下”，先从现象发生的顶端调用链逐一排查，逐步向下深入。
但也并不是所有问题都从大到小从上到下，宏观问题只有达到一定量级才会引发”质变”，从而引起的注意，在通往质变过程中，你的业务可能已经收到某种影响而表现的很明确，此时需要微观分析，然后再逐渐到宏观来诊断。
八、卷宗记录，破案归档
问题排查解决后，养成事后总结的习惯。好记性不如烂笔头，然而在一片混乱问题分析当中，心平气和地记录下问题与判断确实有点不切实际。但即使如此，我们仍然可以在事情结束后为保留一份分析资料，总结并记录处理过程中的执行步骤以及解决途径，则能帮助自己和团队积累宝贵的处理经验。
对于个人
一次问题的定位解决往往伴随着个人的成长，我们不要放弃这样的机会。在追查过程中了解的知识点是比较零碎的，不系统。事后就需要大家将这些点整体串起来，并且以点带面，将知识点变更知识面。
对于团队
1、是对这次问题的反思，我们应该在流程、代码、工具或者哪些方面做出调整，可以更好的避免同类型问题的出现。
2、是对追查过程的总结，在问题定位的过程中，我们缺少哪些帮助及工具的支持，能否更好的提升排查问题的效率，然后相关人员是否对过程结果存在异议。
长期改进建议
吃一堑长一智出了问题并不可怕，怕的是我们从问题中学不到什么，怕的是类似的问题重现，提高问题定位的效率，有哪些值得去做，比如：
1、建立长效错误码机制，使用具统计、可视意义的数字来简短描述错误含义和范畴，正所谓浓缩就是精华，这一点在错误码屡试不爽。
2、正常程序中打错误日志主要是为了更好地排查问题和解决问题，提供重要线索和指导。但是在实际中打的错误日志内容和格式变化多样，错误提示上可能残缺不全、没有相关背景、不明其义，使得排查解决问题成为非常不方便或者耗时的操作。而实际上只要开发稍加用心，也就会减少排查问题的很多无用功。如何编写有效的错误日志，建立日志标准，也是非常有利于问题分析的。
3、定位问题避免二次损害，当某个看似难以捉摸的难题出现时，本能可能是重启，尽快让系统恢复正常。虽然这样的方式经常能够解决问题而且起效神速，但同时也很可能把情况推向令人难以置信的恶化深渊。问题排查手段包括重新启动不稳定系统、尝试自动记录数据库、文件系统修复等等，这些方式往往确实能搞定难题并让系统重回生产轨道，但同时也没准导致数据恢复努力付之东流，毁掉确定问题根本原因的机会甚至大大延长关键性系统的停机时间。保留现场也非常重要，跟破案现场要要求现场勘察、样本采集、排查、锁定如出一辙，对于难以重现问题，尽量创造条件保留了可以用于故障重现的数据或现场。线上环境复杂多变，虽然这一点并不能马上解决问题起到直接作用，但坚持这种处理思路，为开发和测试创造条件，降低因难以重现的疑难故障的挂起率，最终有助于业务的长期稳定。