【.com快译】顾名思义，故障排除是对问题的根本原因进行逻辑、系统的搜索，以找到解决问题的方法。但是结合实际情况，可能很少有人能够将其与逻辑、系统等词语联系起来。你在跟谁开玩笑——忙着猜测可能的原因才是现实，对吧？ 如果你有这种感觉，你注定会浪费大量时间寻找答案。更糟糕的是，也许问题永远得不到解决。 在今天的文章中，我们将尝试找到基于几个基本问??题的解决方案。下半部分内容，我们将分享相关工具、人为因素等问题。 生产中的故障排除 对生产中的特定问题进行故障排除总是会导致一系列后续问题。各种潜在的可能性，往往让这个过程成为一个形而上学的东西： 首先，大家要打消“直接重启才能让它重新工作”的想法。虽然这种方法通常可以快速解决问题，但它也会破坏造成先前问题的重要证据。即使重新启动可以暂时解决问题，请相信我，只要根本原因仍然存在，它迟早会重新出现。 接下来考虑安全相关的内容，包括保证技术调试不影响生产环境。有时我们不得不远程访问环境，这意味着每个操作都需要跳转多次，增加了执行时间周期，同时可能会丢失一些关键信息。 更糟糕的是，一旦我们发布补丁到生产环境并不确定是否有效，相关的测试和应用工作可能需要数小时甚至数天，这进一步增加了修复问题的周期。如果您需要大量使用这些推测性补丁，则可能需要数周时间才能完全解决问题。 ***同样重要的是我们在解决问题的过程中使用的实际工具。其中一些工具可能会对最终用户产生负面影响。例如： 从JVM进行转储可能会导致JVM本身冻结数十秒。 增加日志记录长度可能会导致其他并发问题。 额外分析器的资源消耗可能会使已经很慢的应用程序完全崩溃。 总而言之，从编写脚本到推出补丁再到生产的过程通常需要几天或几周的时间。 由于上述困难，我们主要在不同的环境中实施故障排除措施。 测试开发环境排错 其他环境排错时，可以有效避免生产环境可能出现的各种弊端。但是，您仍然面临一个完全不同的问题，甚至可能更糟：一些难以在生产中重现的性能问题。其他因素也会对故障排除工作产生不利影响： 测试环境使用与生产环境不同的数据源。这意味着无法在测试环境中重现由数据量引起的问题。 对于特定问题，很难重现导致它的使用模式。某些问题可能只在2月29日出现，并且需要两个用户通过WindowsME同时访问相同的特定功能。 应用程序本身并不完全相同。生产部署和配置方案之间可能存在一些差异。这种差异包括不同的操作系统、集群功能、启动参数甚至不同的构建。 这些差异直接导致了“我的机器没问题”式的头痛。 除了环境，其他影响因素也会增加故障排除过程中的不确定性。 成熟的工具和高水平的人能解决问题吗？ 有了正确的工具和严谨成熟的故障排除流程，环境层面的差异将不是问题。然而，在现实中，即使是致力于解决问题的工程师和技术人员，也往往没有任何预定义的流程来完成这项工作。对此有异议吗？你不妨看看下面的Shell代码——你能想出具体的执行顺序吗？ my-precious:~me$sar sar:无法打开输入文件[-1][/var/log/sa/sa06] /usr/bin/sar[-Adgpu][-n{开发|开发者|PPP}][-e时间][-f文件名][-i秒][-s时间] my-precious:~me$mansar my-precious:~me$sar1 15:29:02%usr%nice%sys%idle 15:29:0310297 平均：10297 我的宝贝：~me$sar11000 15:29:06%usr%nice%sys%idle 15:29:0720297 15:29:0810297 ^CAverage:10197 my-precious:~me$mansar my-precious:~me$sar-G13 sar:非法选项--G /usr/bin/sar[-Adgpu][-n{开发|开发者|PPP}][-etime][-ffilename][-isec][-stime] my-precious:~me$asd??askdas?l; -bash:asd??askdas?l:commandnotfound my-precious:~me$ 是不是很像别担心，你绝对不是一个人。事实上，大多数工程师缺乏快速发现常见模式的深入故障排除经验。除非你是天才，否则通常需要数万小时的故障排除才能真正掌握这项技能。 经验的缺乏往往会影响你处理问题所使用的具体信息收集工具，包括但不限于： 收集不同的指标（CPU、内存、IO、网络等）。 分析应用程序日志。 分析GC日志。 捕获和分析线程转储。 捕获并分析堆转储。 有多种此类工具可用，但缺乏经验通常意味着您不知道它们中的哪一种适用于哪种情况，这意味着人们会花费大量时间试图了解它是如何工作的。 解决故障排查挑战 除了投入大量时间练习之外，我们还可以通过以下方法快速解决故障排查挑战。 首先需要强调的是，本文不涉及技术栈本身的分析。相反，我们专注于了解应用程序内部的各个组件，包括它们具体的内存占用，这可以有效地防止最终用户在实际使用中遇到问题。 但是由于数据的差异，我们只能在生产环境中寻找一些可能存在的问题。各种具有前瞻性的问题解决方法往往无法有效完成故障排除中的根源追溯任务。 QA测试 在QA（即质量保证）阶段，我们应该以自动化的方式建立测试机制。这种类型的测试可以进一步减少生产环境中出现的问题数量。 然而，QA的投资往往很难得到明确的回报。毕竟，“性能测试”或“可接受性测试”之类的东西显然没有新功能那么吸引人。为了证明投资回报，我们应该将其与明确的指标联系起来。将生产环境中的性能问题减少三分之一的真正经济效益不仅应该让管理层了解，还应该帮助营销团队完成他们的工作。 生产环境监控 我们必须接受一个事实，生产部署无论如何都可能出错。就连美国宇航局也发生过火箭爆炸事件，所以你必须对这些潜在的问题做好充分的准备。 为了更好的准备生产环境故障排除，我们应该增加生产环境的透明度。出现问题，要有据可依，有针对性地解决。 遗憾的是，监管也需要多种手段。典型的Web应用部署工具至少包括： 日志监控。来自生产堆栈中每个节点的日志聚合使工程团队能够快速搜索信息、可视化日志和标记异常警报。目前最常见的解决方案是ELK栈，其中日志存储在Elasticsearch中，通过Logstash进行分析，通过Kibana进行可视化。 系统监控。在基础架构中聚合和可视化系统级指标既非常有益又实用。我们应该查看CPU、内存、网络和磁盘资源使用情况，以检测系统级问题并及时发出异常警报。 应用程序性能监控和用户体验监控。关注用户交互期间的性能水平与可能对其产生负面影响的可用性问题。最起码在申请失败的时候，应该及时通知大家。另外，如果将它与Plumbr一起使用，您可以在源代码中更具体地查看问题的根源。 总结 排错很头疼却又不得不做。而且很明显，我们不能忽视不同环境下的不同因素，也不能一蹴而就成为技术专家。因此，确保在开发和测试阶段执行应用程序分析，以减少生产环境中的故障??频率。此外，提高生产部署的透明度，以便以更快、更可预测的方式处理问题。只有这样，我们的应用才能更稳健地服务客户。 原标题：排错为什么这么难？ 原作者：IvoMagi
