一般来说，只要系统架构设计得比较合理，大部分情况下系统都能正常运行，出现系统崩溃等故障问题是小概率事件。也就是说，业务开发是大部分软件工程中的重头戏，所以有人开玩笑说：“面试造火箭，入职拧螺丝。”
一般来说，我们进行排查分析的目的主要有：
- 解决问题和故障
- 排查系统风险隐患
我们按照问题的复杂程度，可以分为两类：
- 常规问题
- 疑难杂症
常规的问题一般在开发过程中就被发现和解决了，所以线上问题一般会比较复杂，出现在大家都没有考虑到的地方。按照我们的多年解决经验，这些复杂问题的排查方式可以分为两种途径：
- 逻辑严密的系统性排查；
- 以猜测来驱动，凭历史经验进行排查。
如果您倾向于选择后一种方式，那么可能会浪费大量的时间，效果得看运气。更糟糕的是，因为基本靠蒙，所以这个过程是完全不可预测的，如果时间很紧张，就会在团队内部造成压力，甚至升级为甩锅和互相指责。
系统出现性能问题或者故障，究竟是不是 JVM 的问题，得从各个层面依次进行排查。
为什么问题排查这么困难？
生产环境中进行故障排查的困难
在生产环境中针对特定问题进行故障排除时，往往会有诸多限制，从而导致排查的过程变得痛苦。
1. 影响到客户的时间越短越好
面对客户的抱怨，解决问题最快的办法可能是：“只要重启机器就能让系统恢复正常”。
用最快的方法来避免对用户产生影响是很自然的需求。
但重启可能会破坏故障现场，那样就很难排查问题的根本原因了。
如果重新启动实例，则无法再采集实际发生的情况，导致我们并没有从这次故障中学习，从而获得收益。
即使重启解决了目前的问题，但问题原因本身仍然存在，一直是一个定时炸弹，还可能会接二连三地发生。
2. 安全方面的限制
接下来是安全性相关的限制，这些限制导致生产环境是独立和隔离的，一般来说，开发人员可能没有权限访问生产环境。如果没有权限访问生产环境，那就只能进行远程故障排除，并涉及到所有与之相关的问题：
- 每个要执行的操作都需要多人参与或审核，这不仅增加了执行单个操作所需的时间，而且沟通交流过程中可能会丢失一些信息。
特别是将临时补丁程序发布到生产环境时，“希望它能生效”，但这种试错的情况却可能导致越来越糟糕。
因为测试和发布流程可能又要消耗几小时甚至几天，进一步增加了解决问题实际消耗的时间。
如果还需要分多次上线这种“不一定生效的补丁程序”，则很可能会消耗几个星期才能解决问题。
3. 工具引发的问题
还有很重要的一点是需要使用的工具：安装使用的某些工具在特点场景下可能会使情况变得更糟。
