二、了解案情，评估大小
先评估出这个问题的影响范围，是全网，某些地区，还是某条链路不可用的问题，还是很多业务线都出现问题，评估出案情的大小，到底是普通的民事案件，还是刑事案件。
三、理清线索，整理分析
理清手头已得到的信息或线索，比如监控上有网络报警，有用户反馈无法访问，有开发人员反馈服务器有问题，同时间段有做变更等等，尽量不要漏掉这些看似无关紧要的线索，把这些线索先整理下来，后面一并分析。
推理的过程，就是根据已知线索，通过合理的想象、推断得出一个唯一的结果。线索是整个推理过程的起点，线索给出的好不好、是否有错误，直接会影响推理的质量，因此是最基础、也是最重要的一环。线索的梳理，最常犯错误就是信息不足，主观臆断。
其中整理分析过程中，很重要的一点：尽可能搞清楚问题的前因后果！
不要一下子就扎到服务器前面，你需要先搞明白对这台服务器有多少已知的情况，还有故障的具体情况。不然你很可能就是在无的放矢。
必须搞清楚的问题有：
- 故障的表现是什么？无响应？报错？
- 故障是什么时候发现的？
- 故障是否可重现？
- 有没有出现的规律（比如每小时出现一次）
- 最后一次对整个平台进行更新的内容是什么（代码、服务器等）？
- 故障影响的特定用户群是什么样的(已登录的, 退出的, 某个地域的…)?
- 基础架构（物理的、逻辑的）的文档是否能找到?
- 是否有监控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic… 什么都可以）
- 是否有日志可以查看?. （比如Loggly、Airbrake、 Graylog…）
另外也可以进一步从应用层、数据库层、网络层进行检查：
应用层：
- 应用最近是否有上线？
- 软硬件环境最近是否有变更？
- 应用日志是否有异常？
- 重启是否有效？
数据库：
- 数据库系统级配置最近是否有变更？
- telnet端口是否畅通？
- tnsping监听是否正常（连通性、延迟）
- 数据库是否有异常的等待？
- 远程、本地SQL执行是否正常？
网络：
- 网络最近是否有变更?
- ping是否正常？
- traceroute -l 是否正常？
- 网络是否有丢包、延迟？
尽可能地获取到更多的已知有效信息，汇总信息并从多条排查线去进行分析，这里推荐思路有：
- 通过变更记录来咨询相关人员，大量问题其实都是上线、变更等引起的，所以排查下同时期有过业务相关的变更操作人员，往往就可以把很多问题排除在这道线上了。
- 通过日志、数据等，把一些已知问题筛选出来。
- 通过影响人群、问题点等信息尝试找出复现方法。一般来说，能有方法稳定复现的问题，就比较容易排查到了。
- 到这一步的问题，基本上都属于一些疑难杂症了，就没有一些特别通用的方法了。需要开阔思路，找找规律，将平时没关注到的技术、业务点再了解的更细致，更深入一些，或者求助于团队的帮助一起来解决。
需要注意一点：通过分析日志时，业务日志除了要关注系统异常与业务异常之外，还要关注服务执行耗时情况，耗时过长的服务调用如果没有熔断等机制，很容易导致应用性能下降或服务不可用，服务不可用很容易导致雪崩。如果没办法直接从日志中发现异常，那就只能看看应用到底在干嘛了（可分析应用在异常时期的线程内存堆栈信息）。
这一步原则很简单：找出系统正在执行“什么”，询问系统“为什么”执行这些操作，以及系统的资源都被用在了“哪里”可以帮助你了解系统为什么出错。
四、扩大你的信息量