一次双重根因 Bug 调查中的挫折

最近在调查一个存在双重根因的 Bug 时，因为忽略了其中一个根因而遭遇了一次挫折。

问题

模块中的一项服务依赖一个全局配置，该配置应由脚本在系统启动后设置。如果配置未能正确加载，就会导致服务运行异常。

根因

• 1. 脚本不够健壮。它使用第三方工具查询系统中的一些信息，如果在系统刚启动后立即查询，结果可能并非 100% 准确。
• 2. 脚本无法在下一次重启前执行。可能是脚本加载和执行得太慢，也可能是系统重启得太快，导致脚本被终止。然而，这个根因发现得太晚了。

背景

• 1. 这个问题上报后不久就是一个长假，意味着大家很快都要休假。
• 2. 问题在最后一刻才被上报。
• 3. 紧张的时间安排以及必须在假期前发行软件，意味着要在很大的压力下工作。

结果

• 1. 我没有深入分析这个问题。
• 2. 我过于信任和依赖 AI，没有给自己留出足够的时间进行分析。
• 3. 我尝试了几轮脚本优化，但它们只解决了根因 1。因此，由于根因 2 的存在，我不断收到意外结果。
• 4. 幸运的是，我找到了另一个变通方案，解除了这个 Bug 的阻塞。

时间线

日期	事件
9.29	在验证过程中发现问题。
9.30	假期前的最后一个工作日。上午，我与同事讨论并找到了一个解决方案。中午，我尝试了优化后的脚本 1，但收到了意外结果。这是由根因 2 导致的，但我没有机会再次与同事确认。我也没有深入分析，因此未能发现根因 2。
10.1	我请求尝试优化后的脚本 2。我没有继续跟进这个问题，因为我认为它应该能够 100% 解决问题。
10.2	晚上，我收到了脚本 2 的意外结果，并开始进行分析。
10.3	上午，我收到了脚本 2 的日志，并尝试了后续的脚本 3 和脚本 4，但它们只是进一步强化了针对根因 1 的修复。然而，我仍然没有意识到根因 2 的存在。下午，我尝试了另一个变通方案，暂时搁置未能修复的脚本问题，使用该方案来解除放行阻塞。
10.4	星期日，所有人都休息，包括工厂。
10.5	使用变通方案开始构建。
10.6	假期只剩两天，我选择休息。
10.7	假期只剩一天，我选择休息。
10.8	大家都回到了工作岗位。我终于有机会再次与同事沟通。他认为第一个优化后的脚本应该已经永久解决了问题，因此我重新查看日志，随后发现了根因 2。

总结

我相信，如果有更多时间，我本可以把这件事处理得更好。我从中得到的教训是：

• 冷静、深入地分析每一个问题。
• 一个问题可能有多个根因，而不只是单一根因。