故障排查：永不过时的技能
故障排查：永不过时的技能
故障排查是一项永不过时的技能，无论在哪个领域，它都是工作中不可或缺的一部分。本文将系统地介绍故障排查的核心方法和技巧，帮助读者提升这一关键能力。
排查故障：永不过时的技能
故障排查可以定义为系统性地找到系统中不期望行为的原因，并予以修复。这一技能往往是在显性学习“这门技能”的过程中通过潜移默化学到的，鲜少把故障排查单独讨论为一门独立的技能。但是，一个有效的故障排查方法中的许多特性都是不依赖于具体领域的。
认识到故障排查的重要性，我们决定尝试找出如何提高自己的排查能力 —— 从而在多个领域提升效率。以下是经过总结的故障排查关键步骤和技巧：
第一步：退一步思考
故障排查需要一种特定的心态。这需要对系统底层结构的兴趣，需要耐心、注重细节和顽强毅力。有时，即使赶时间，慢下来、深思熟虑、冥想式地处理故障排查问题反而更有效。
确保你在调整正确的“琴弦”
在试图修复系统之前，需要确保自己正在调整正确的"琴弦"。例如，在排查 CSS bug 时，可以先设置
- {color: red !important;}
以确保代码在正确的文件中并正在运行。
确定各个流程
理解整个系统是故障排查的关键。需要思考输入、输出是什么？在过程中转化发生了什么？流经系统的不同“东西”是否可以分成几个半独立的子系统？
观察症状
分析症状与预期之间的差异，缩小问题可能影响的子系统范围。同时要认识到，即使是对系统非常熟悉的排查者，也不可能完全理解系统的所有细节。
隔离问题
接下来的步骤是找出该子系统在哪个环节失败了。基本做法是：对系统进行“科学实验”。
- 就问题形成一个假设。这个假设可能是从症状中直观获得的第一印象，也可能是经过长时间观察后的最佳猜测。
- 先排除最简单和最可能出问题的区域。那些该定期检修、曾经出故障过或容易受机械压力影响的部件。
- 如果需要，进行二分查找。
- 找出验证假设的最简单方法。通常，这意味着“切断”认为问题出现之前或之后的系统部分，并在切断点测试其功能。
拆解子系统
如果可能，将正在调试的子系统断开。这样做有三个好处：
- 防止与其他部分之间的奇怪交互
- 避免因自己的错误而牵连整个系统
- 往往能缩短反馈回路
或者不拆解
如果无法（或不愿）完全拆解各个部分，可以在不同位置进行探针测试—— 或称为 “切断并探测”。如果知道或能直觉地感知到在系统正常时某个测试点参数的可接受范围，那么实际测得的值就可以指示出问题所在的位置。
找到合适的“切断点”
在保持系统功能的同时，需要确定最多能在多少个点上“切断”系统去进行测试。例如，火花塞就是子系统之间的一个切断点的例子。
平衡获取信息与尝试修复
解决问题时，需要平衡获取问题信息与尝试修复之间的精力分配。如果直觉正确，直接着手修复会快得多。但如果直觉错了，系统性地收集信息从长远来看更加高效。
了解问题的“赌注”
故障排查问题的风险范围从零（爱好软件项目）到改变人生（医疗诊断），甚至是生死存亡（通用人工智能、核武器）都有所不同，这会影响处理问题的方式。需要评估最糟糕的情况、风险、系统脆弱性以及修复与不修复之间的风险对比。
保持耐心
故障排查往往需要耐心，不要急于求成。
获取关于系统的“信息”
故障排查者永远不可能通晓一切。需要知道对不同信息该用哪个搜索引擎，如何利用高级搜索条件缩小搜索范围，以及如何扩大搜索范围并滤除无关信息。
知道对不同信息该用哪个搜索引擎
有时候需要认识懂得如何操作的人，使用各种手册或库，或使用搜索引擎。在现代社会，大部分时间需要懂得如何使用搜索引擎。不同的搜索引擎适用于不同目的。
知道如何利用高级搜索条件缩小搜索范围
虽然这些技巧并非专门针对故障排查，但如果你不熟悉搜索操作，下面的三篇文章可以作为入门：
- 如何在互联网上找到任何东西（以 Google 为例）
- Google 搜索运算符：完整清单（44 个高级运算符）（Google 专用，更全面，带营销属性）
- 互联网搜索技巧（详尽，学术取向）
知道如何扩大搜索范围并滤除无关信息
大多数系统都会发出各种各样的信息，而且相关性参差不齐。在软件日志中，会有一大堆重复的废话，直到那一行话突然提醒注意。通常，它会包含“error”或“fail”，或提到受影响的子系统。
从系统中获取信息
尽可能从系统中获取信息：更多的输出、更具体的输出、从系统更多的节点采集数据。在软件中，这意味着日志记录，或者在进程运行时附加调试器。在电子设备中，第一步通常是拿出万用表，到各个节点检查系统状态。
直观感受系统的容差
不同材料有不同的容差。某些部件即使遭受一定损伤，也不会破坏系统的整体功能；而其它部分如果遭到同样对待，可能会导致整个系统失效。
与系统保持良好关系
不喜欢自己计算机的人往往使用计算机效率不高；同样，不喜欢与人打交道的人很难从别人那里得到自己想要的，除非他们懂得隐藏自己的情绪。这听起来有些飘渺，但欣赏那台“出问题”的系统的美以及它的复杂性，能使人成为更有成效的故障排查者。
利用现有资源
拥有正确的工具进行测试、拆解、修复和组装系统固然有帮助。但在实际工作中，更重要的是能够随机应变，通过对事物内在结构的理解，找到合适的工具和替换部件，而不是拘泥于标签或先入之见。
缩短反馈周期
为了解决系统问题，需要能够重现该问题。为了获取足够多的信息以可靠地重现错误，往往需要在不同条件下运行系统多次。然后，一旦能够重现问题，还需要再次进行大量测试，每次调整参数，试图找出究竟是哪些条件具体方面触发了错误。
降低噪音干扰
在进行任何干预前，需要尽量减少系统中那些混杂的变量和“杂音”。断开子系统有助于这一点，因为与其他子系统间的相互作用可能会干扰测试结果。
记录过程
写作常被认为是“思考的过程”。以下是利用写作作为故障排查工具的两种方式：
- 像专业人士一样“橡皮鸭调试”：有时只需草拟一篇论坛帖，却不发出去，就能解决问题。
- 留下线索轨迹：建立一个故障排查笔记文件，无论当时的信息看起来多么显而易见或不完整，都能为下次找到问题留下痕迹。
通过投放极为详细的特定信息来观察“黑箱”的反应
尽管“断开子系统”是一个好建议，但有时必须对那些黑箱系统进行故障排查。一种方法是向它们输入非常特定的数据，看其如何响应。如果系统对特定输入条件失败，可以尝试以下两种方法之一：
- 获取导致失败的条件/输入，依次移除其中的一个组成部分，并输入到系统中。如果问题仍然出现，就再移除另一项（可选择恢复前一项），反复操作直至剩下的仅是真正导致问题的因素，或者尽可能接近它。
- 选取一些确认无误、系统正常时的条件/输入，加入一个在故障输入中出现的因素，重复（单独或叠加加入）直到系统失败。
理解问题
也许是某个零件烧坏了。但问题在于为什么它会烧坏？难道零件在周二下午烧坏是正常现象吗？或者，是短路、水浸、散热问题，或者（就像最近的一个案例中）受到附近雷达干扰而造成的失效？
修复问题
一个被理解的问题基本上就已经解决了，除非零件稀缺或安装十分困难。“修复”通常就是指“更换损坏的部件”。对问题以及系统的理解程度决定了需要更换整个系统的多大部分。
故障排查技能能否传授？
自 2024 年 5 月以来，作者断断续续地在写这篇文章。也许作者自欺欺人，但感觉自己的故障排查能力确实有所提升。最大的变化是现在开始主动面对问题。作者开始接手那些平时并不吸引人的故障排查任务——纯粹为了验证理论，无论是否觉得这些问题值得花时间去解决。而且，由于花了大量时间去思考和讨论故障排查，作者觉得自己应该成为当地的某种专家，并且无论这种声誉是否只是自我认同，都希望能当得起它。
如果有经费支持，作者会用科学方法来验证。作者会招募一批人，其中一半会阅读这篇文章，而另一半则阅读一篇长度和风格相当，但不是关于故障排查的文章。然后，两组人会在类似sadservers.com的网站上尝试解决 Linux 服务器的故障排查难题。哪一组会更有效率？如果阅读了这篇文章的人表现更好，这个实验可以在其它领域重复，看故障排查技能的通用性如何。
结论
一旦进入故障排查的心态，大部分事情都会被看作是故障排查问题。用这种系统—问题—解决的视角看待世界，在某些情况下是有效的，但这并不是看待世界的唯一方法，也未必适用于所有情境。意识到自己正在面对故障排查问题，并能有意识地去排查，能节省大量时间。但同样重要的是，也要清楚并非所有问题都需要解决。
故障排查是一项永不过时的技能，无论在哪个领域，它都是工作中不可或缺的一部分。通过系统地学习和实践这些方法，可以显著提升故障排查的能力，从而在多个领域提升工作效率。
本文原文来自cnblogs