转载

故障排查工作为何总是如此艰难?

【51CTO.com快译】从定义角度来看，故障排查相当于对问题根源进行一种逻辑性、系统性搜索，旨在找到将其解决的办法。然而，结合实际情况，可能很少有人能够将其与逻辑或者系统这样的字眼联系起来。开什么玩笑——忙着猜测可能原因才是实际情况，对吧?

如果您也有这样的感受，那么您最终一定会在寻找答案中浪费大量时间。更糟糕的是，也许问题始终无法得到解决。

在今天的文章中，我们将立足于几项根本问题尝试找到解决思路。而在后半段内容里，我们则将分享相关工具与人为因素等议题。

故障排查工作为何总是如此艰难?

生产环境中的故障排查

在对生产环境中的特定问题进行故障排查时，总会引发一系列后续麻烦。多种多样的潜在可能性往往令这一过程变成了玄学性质的事物：

首先，大家应当打消“直接重启让其恢复工作”这样的念头。虽然这种方式往往能快速解决问题，但却也会同时破坏产生此前问题的重要证据。而且即使重启能够暂时解决问题，请相信我，只要根本原因仍然存在，那么其早晚还会再次出现。

接下来考虑安全性相关内容，包括确保技术调试不会对生产环境造成影响。有时候我们必须以远程方式进行环境访问，这意味着每项操作都需要跳转多次、增加执行时间周期并可能在此期间丢失部分关键性信息。

更糟糕的是，一旦我们向生产环境中发布了不确定能否奏效的补丁，那么其相关测试与应用工作可能耗时数小时甚至数天，这进一步增加了修复问题的周期。如果需要使用大量这类猜测性补丁，那么也许问题要到数周后才能彻底得到解决。

最后同样重要的是，我们在解决问题过程中所使用的实际工具。其中部分工具可能会对最终用户造成负面影响。举例来说：

从JVM进行转储可能导致JVM本身卡住数十秒。

增加日志记录长度可能引发其它并发问题。

附加分析器的资源消耗可能导致本已运行缓慢的应用彻底崩溃。

总而言之，从编写脚本到将补丁投放至生产环境，整个过程往往需要数天或者数周。

正因为存在上述难题，因此我们大多会在不同环境中实施故障排查举措。

在测试与开发环境中进行故障排查

在其它环境中进行故障排查时，大家可以有效避免生产环境内可能出现的种种弊端。然而，大家仍然面对着其它一些完全不同的问题，情况甚至可能更糟：某些在生产环境中出现的性能问题难以重现。其它因素亦会对故障排查工作造成不利影响：

测试环境与生产环境使用的数据源不同。这意味着由数据量引发的问题无法在测试环境内重现。

很难针对特定问题重现将其引发的使用模式。某些问题可能只会出现在2月29日，且要求两位用户通过Windows ME同时访问同一特定功能。

应用本身并不完全相同。生产部署与配置方案间可能存在些许差别。这种差异包括不同操作系统、集群化功能、启动参数甚至是不同build。

这些差别直接引发了“在我的机器上没问题”这类令人头痛的状况。

除了环境之外，其它一些影响因素也会增加故障排查流程中的不确定性。

成熟的工具与高水平人员能否解决问题?

如果配合正确的工具以及严格而成熟的故障排查流程，那么环境层面的差异将不再是问题。然而，在现实当中即使是专门负责解决问题的工程技术人员，往往也不具备任何预定义流程完成这项工作。对此抱有异议?大家不妨看看以下Shell代码——您能弄清其具体执行顺序吗?

my-precious:~ me$ sar

sar: failed to open input file [-1][/var/log/sa/sa06]

/usr/bin/sar [-Adgpu] [-n { DEV | EDEV | PPP }] [-e time] [-f filename] [-i sec] [-s time]

my-precious:~ me$ man sar

my-precious:~ me$ sar 1

15:29:02 %usr %nice %sys %idle

15:29:03 1 0 2 97

Average: 1 0 2 97

my-precious:~ me$ sar 1 1000

15:29:06 %usr %nice %sys %idle

15:29:07 2 0 2 97

15:29:08 1 0 2 97

^CAverage: 1 0 1 97

my-precious:~ me$ man sar

my-precious:~ me$ sar -G 1 3

sar: illegal option -- G

/usr/bin/sar [-Adgpu] [-n { DEV | EDEV | PPP }] [-e time] [-f filename] [-i sec] [-s time]

my-precious:~ me$ asdöäaskdasäl;

-bash: asdöäaskdasäl: command not found

my-precious:~ me$

是不是看起来很眼熟，别担心，您绝对不是一个人。事实上，大多数工程师都缺少深层故障排查经验，因此无法快速发现其中的共通性模式。除非您是天才，否则一般需要经过上万小时的故障排查工作才能真正掌握这方面技能。

经验的匮乏往往影响到您用于处理问题的具体信息收集工具，其中包括但不限于：

收集不同指标(CPU、内存、IO、网络等)。

分析应用日志。

分析GC日志。

捕获并分析线程转储。

捕获并分析堆转储。

可资利用的此类工具多种多样，然而经验的缺乏往往导致您不了解其中哪些工具适用于哪些情况，这意味着大家需要耗费大量时间尝试其实际效果。

解决故障排查难题

除了投入大量时间进行实践外，我们还可以通过以下方式快速解决故障排查难题。

首先需要强调，本文并不涉及对技术堆栈本身的分析。相反，我们关注的是对应用程序内各组件的了解，包括其具体内存占用量，这能够有效防止最终用户在实际使用时遭遇问题。

然而，数据的差异导致我们只能发现一部分生产环境中可能出现的问题。各类前瞻性问题解决手段往往无法有效完成故障排查中的根源追溯任务。

QA测试

在QA(即质量保证)阶段，我们应当以自动化方式建立测试机制。这类测试能够进一步降低生产环境中出现的问题数量。

然而，QA中的投入往往很难获得明确的回报。毕竟与新型功能相比，“性能测试”或者“可接受度测试”之类的东西显然没什么吸引力。为了证明投资回报，我们应当将其与明确的指标加以联系。在生产环境中将性能问题减少至三分之一能够带来怎样的实际经济收益，这样的结论不仅能够让管理层下定决心，亦足以帮助营销团队开展工作。

生产环境监控

我们必须接受一项事实，即无论如何生产部署都有可能出现问题。即使是美国宇航局也遭遇过火箭爆炸事故，因此大家最好为这些潜在问题作好充分准备。

为了更好地筹备生产环境故障排查工作，我们应当提升生产环境的透明度。当问题出现时，大家最好已经掌握全部证据并进行针对性解决。

遗憾的是，监管工作同样需要通过多种方式才能实现。典型Web应用的部署工具就至少包括：

日志监控。从生产堆栈中的各节点处进行日志汇总，保证工程团队能够快速搜索信息、进行日志可视化并标记异常警报。目前最为常见的解决方案为ELK堆栈，其中日志存储于Elasticsearch中，由Logstash负责分析，并由Kibana进行可视化处理。

系统监控。对基础设施内的系统级指标进行聚合与可视化既能够带来显著收益，又切实可行。我们应着眼于CPU、内存、网络及磁盘资源使用量，从而及时发现系统级问题并对异常状况进行警报。

应用性能监控与用户体验监控。关注用户交互过程中的性能水平与可能造成负面影响的可用性问题。至少，大家应当在应用发生故障时及时得到提醒。另外，如果配合使用Plumbr，则能够更为具体地查看源代码中的问题根源。

总结

故障排查是件让人头痛但又不得不做的工作。而且很明显，我们无法忽视不同环境中的差异性因素，也不可能一夜之间成为技术专家。因此，请确保在开发与测试阶段进行应用分析，减少生产环境中出现故障的频率。另外，提升生产性部署透明度，从而以更快、更可预见的方式处理问题。只有这样，我们的应用才能够以更为稳健的方式为客户服务。

原文标题：Why Is Troubleshooting So Hard?

原文作者：Ivo Magi

【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】

【责任编辑：周雪 TEL：（010）68476606】

原文 http://network.51cto.com/art/201611/523458.htm

正文到此结束