设想以下情形:您和团队夜以继日地工作,以完成软件产品的下一个主要版本。您以不错的节奏创建新功能。只要质量检查报告了错误,团队就会进行修复。单元测试全部为绿色。应用程序通过一套更全面的测试后,就可以发布了。然而,出错了! 只要进入生产环境,应用程序就会崩溃。出现了什么问题?

事实证明,测试环境并不像您曾经认为的那样接近于生产环境。在没有任何记录的情况下对环境进行了基础设施更改。结果是,环境逐渐偏离。

作为技术行业的专业人员,我们相当一部分时间都用在故障排除上。当然,我们也花时间去修复这些问题,但是当您不知道何处出现问题时,将无法进行修复。正如任何一个在调试程序前花费数小时的软件开发人员会告诉您的那样,通常真正困难的部分是找到错误。只要知道了发生的问题,修复可能就非常轻松了。

因此,作为软件开发人员或 IT 工作人员,通常了解更快地排除故障是最佳投资之一。

我们来讨论一下如何更快地找到问题并快速修复。

根本原因分析:含义和需要关注的原因

根本原因分析(RCA)是一种可以用来排除问题的特定技术。利用这种技术,您可以使用一组特定的步骤分析手头的问题,以确定问题的主要原因。RCA 基于如下原则:只关注问题的症状而忽略问题根源毫无意义。

通过使用 RCA,您将能够了解发生的问题。通常,您不能仅仅通过观察症状就有了全面了解。但确定发生的问题只是第一步,然后您需要进一步发现发生的原因。有了这些知识,就应该将其付诸实践,制定计划或策略以降低再次发生的几率。

了解了“含义”和“原因”之后,下面是四个可以帮助使用 RCA 减少问题的提示。

使用橡皮鸭方法
是的,我是认真的,就是橡皮鸭方法。这不是我编造的。此方法还称为橡皮鸭调试,可能有更多的名称。此方法包括向一只橡皮鸭解释您的问题。没有橡皮鸭,怎么办? 别担心! 您可以使用手头的任何无生命物体。或者您甚至可以和人交谈!

那么,橡皮鸭方法到底是什么呢? 此方法是根据向别人解释某事后观察到的效果,您迫使自己整理想法。我们的思维过程常常杂乱无章。当我们面临着不得不向别人解释的情形时,除了整理之外,我们别无选择。Jeff Atwood 是热门问答站点 Stack Overflow 的联合创始人,他谈到,软件开发人员好多次告诉他,在站点上写新问题,在此过程中自己找出答案,但从来没有实际提交问题!

橡皮鸭方法是否足以排除任何问题? 当然不能。可能能够排除问题,但通常这只是更广泛策略的第一步。

您是否担心人们会觉得您和无生命物体说话有点奇怪? 问题是,橡皮鸭的想法有点像个笑话。这是一个愚蠢而难忘的形象,不应该太当真。重要的是,您强迫自己以有序的方式表达自己的想法,尽可能清楚地解释手头的问题。

您可以使用以下方法:
1.写一个 Stack Overflow 问题。或者您可以假装您正在写一个 Stack Overflow 问题,但却写在记事本中。
2.提交详细的错误报告。反正总得有人做,为什么不一石二鸟呢?
3.走到同事的隔间/办公室和他们聊几分钟。当然,只要他们同意就行。没有必要的事情,不要打扰同事。


收集大量日志数据(并有效地进行搜索)

如果您已经成功地以一种明显的方式解释了问题,但仍然找不到问题的根源,那么必须进一步深入。现在需要做的是收集有关问题的数据,并从中提取洞察。

在这里,日志记录和监控可以派上用场,比如崩溃日志、应用程序和服务器日志等等。您必须收集问题发生的证据,但如果可能的话,也要找出问题的持续时间和频率。

但您不能就此止步。收集大量数据非常重要,但如果您不能足够快地找到所需的具体数据,那么所有这些数据就不会有太大用处。陷入“大海捞针”的境地既不有趣也没有特别的成效。

这就是为什么您必须使用工具帮助您搜索和分析实时收集的所有日志数据,并将其转化为有价值的洞察,以便更快地诊断和解决问题。


利用“五问法”技巧
当您收集了信息后,需要通过确定起因来加以使用。这里的“起因”指的是当前问题的直接原因。您不应该做的是确定一个起因,然后停止。您必须进一步深入。最著名的技巧之一就是“五问法”技巧。

此技巧就是反复问“为什么?”直到找到问题的根源。我们看一个简单示例:

问题:网站显示错误 500。
1.为什么? 因为 Web 框架的路由组件出现故障。
2.为什么? 因为它需要另一个组件,而这个组件本身出现了故障。
3.为什么? 因为 Web 框架的这个组件需要 intl 扩展,但该扩展不起作用。
4.为什么? 因为它在服务器软件更新后意外停用了。

如您所见,第 5 项只是进行了说明。用更少的步骤就可以找到根本问题。或者您可能需要更多步骤。

“五问法”技巧远非完美。这种技巧饱受批评,肯定有其局限性。但可以鼓励工程师不断寻找问题的根本原因,而不是在接近解决方案的首个迹象时停止。


让他人审查
在我的软件开发人员职业生涯中,我开始喜欢的一种做法是代码审查。让另一位不带偏见的人员检查您的代码,就能发现许多您以前无法发现的问题,真是不可思议。随着时间的推移,完全寄期望于让其他人员检查您的代码使您更加意识到这一点。您开始投入更多的注意力。

因此,在这一点上,我是否建议进行代码审查呢? 是的,但这不是唯一方法。我建议您在工程师做的几乎每一项任务中都采用类似审查的过程。或者更好的是结对。进行结对编程、结对服务器配置、对等调试和面向客户的对等支持。简而言之:结对解决问题。

科学还是艺术?

故障排除仍处于艺术多于科学的阶段。但这不应该阻止您采用技巧和工具提高效率

因此,请使用这些技巧执行 RCA:
1.使用橡皮鸭方法
2.收集大量的日志数据,并使用适当的工具进行搜索和分析
3.利用“五问法”技巧
4.让他人审查

现在可以抓住您的橡皮鸭,开始分析问题的根本原因了。

了解有关 Amazon OpenSearch Service 定价的更多信息

访问定价页面
准备好开始构建了吗?
开始使用 Amazon OpenSearch Service
还有更多问题?
联系我们