【51CTO.com快译】从定义角度来看,故障排查相当于对问题根源进行一种逻辑性、系统性搜索,旨在找到将其解决的办法。然而,结合实际情况,可能很少有人能够将其与逻辑或者系统这样的字眼联系起来。开什么玩笑——忙着猜测可能原因才是实际情况,对吧?
如果您也有这样的感受,那么您最终一定会在寻找答案中浪费大量时间。更糟糕的是,也许问题始终无法得到解决。在今天的文章中,我们将立足于几项根本问题尝试找到解决思路。而在后半段内容里,我们则将分享相关工具与人为因素等议题。
生产环境中的故障排查
在对生产环境中的特定问题进行故障排查时,总会引发一系列后续麻烦。多种多样的潜在可能性往往令这一过程变成了玄学性质的事物:
首先,大家应当打消“直接重启让其恢复工作”这样的念头。虽然这种方式往往能快速解决问题,但却也会同时破坏产生此前问题的重要证据。而且即使重启能够暂时解决问题,请相信我,只要根本原因仍然存在,那么其早晚还会再次出现。
接下来考虑安全性相关内容,包括确保技术调试不会对生产环境造成影响。有时候我们必须以远程方式进行环境访问,这意味着每项操作都需要跳转多次、增加执行时间周期并可能在此期间丢失部分关键性信息。
更糟糕的是,一旦我们向生产环境中发布了不确定能否奏效的补丁,那么其相关测试与应用工作可能耗时数小时甚至数天,这进一步增加了修复问题的周期。如果需要使用大量这类猜测性补丁,那么也许问题要到数周后才能彻底得到解决。
***同样重要的是,我们在解决问题过程中所使用的实际工具。其中部分工具可能会对最终用户造成负面影响。举例来说:
从JVM进行转储可能导致JVM本身卡住数十秒。
增加日志记录长度可能引发其它并发问题。
附加分析器的资源消耗可能导致本已运行缓慢的应用彻底崩溃。
总而言之,从编写脚本到将补丁投放至生产环境,整个过程往往需要数天或者数周。
正因为存在上述难题,因此我们大多会在不同环境中实施故障排查举措。
在测试与开发环境中进行故障排查
在其它环境中进行故障排查时,大家可以有效避免生产环境内可能出现的种种弊端。然而,大家仍然面对着其它一些完全不同的问题,情况甚至可能更糟:某些在生产环境中出现的性能问题难以重现。其它因素亦会对故障排查工作造成不利影响:
测试环境与生产环境使用的数据源不同。 这