软件在生产环境中崩溃，无法访问调试器。在短期和长期做什么？

Question

这是一个采访问题：

软件在生产环境中崩溃，无法访问调试器。您将采取哪些措施来解决短期问题？长期？你会怎么做才能防止它发生？你会用什么工具？

我的想法：

短期：

• 跟踪由OS生成的程序的日志文件，这可能会生成一些有关崩溃的信号。
• 通过添加一些打印，缩小到程序崩溃的文件。
• 在可能的位置添加try-catch。
• 找出原因。

长期：

• 检查整个程序设计思路，算法/数据结构用法，确保正确使用它们。
• 使用导致崩溃的不同案例对其进行测试以找出基本原因
• 工具：GDB，Valgrind家族，gprof

有更好的想法或解决方案吗？

Answer 1

短期  1.首先要做的就是找出解决问题的方法并尝试重现它。如果可以这样做，现在可以在调试环境中对其进行跟踪。  2.如果它不可重现，您需要查看在第一步中收集的所有信息（包括任何日志记录），看看是否可以看到可能的问题。  3.如果未找到问题，则需要添加日志记录以及大量日志记录。这是“DEBUG”日志记录设置派上用场的地方。它可能会减慢系统速度，甚至可能掩盖问题（这会告诉你一些问题的本质）。  4.使用新的日志记录信息，您可以返回第一步。重复此操作直到问题解决！

从长远来看，最明显的事情是确保您有足够的日志记录，即使必须打开和关闭，以捕获问题。除此之外，您还需要尝试加强测试工作。

当您追踪问题时，值得注意问题的类型（竞争条件，可扩展性，数据库访问等）。这为您提供了应用更多自动化和手动测试的区域。

Answer 2

你有一些很好的初步想法，这是我的评论：

1. 将记录添加到您的代码中 - 您将从中获取非常少的信息 关于你的代码的操作系统。
2. 如果您调用的方法可以抛出异常，则应该捕获它们。不要让它们冒泡到最终用户！
3. 现在运行valgrind，而不是以后
4. 设置模拟生产环境的测试环境。从简单开始，增加复杂性，直到您能够重现您的问题。你有一个测试环境，对吗？

Answer 3

您应该做的第一件事是 确定问题的严重性 。这将有助于制定您的短期战略。您需要与软件中的主要利益相关者（例如客户）进行一些简短的讨论，或让项目经理执行此操作并向您报告。

在当下的热度中，这通常有点被忽视，而短暂的匆忙修复几乎总是意味着浪费大量时间而不是真正理解需要做什么。

在此之后，您的实际战略，无论是长期还是短期，都取决于您使用的技术及其部署方式。

短期

在尝试解决问题，获取日志文件，截取屏幕截图，记下内存/ CPU使用率等系统信息，归档任何可能有用的临时数据之前，获取有关崩溃的一些初步信息绝对至关重要。

短期行动应该是让系统快速恢复运行。短期解决方案的一些常见方法：

• 尝试将其关闭再打开......说真的，90％的时间都是这样 将在短期内再次投产，至少直到 这个bug再次显现出来。
• 恢复到之前的制作 发布，最好是已知可以正常工作的最新版本 可靠。
• 在另一台计算机上运行第二个实例并进行故障转移 问题再次发生。这有额外的好处，日志和 在上次崩溃发生后保留系统状态。

长期

从长远来看，您需要正确分析您在失败时收集的信息。尽可能尝试尽可能地重现问题。将代码还原为正在部署的版本（您确实使用版本控制工具吗？），检查高级别因素以及低级别配置因素。例如坠毁时谁在使用系统？他们能告诉你他们做了什么吗？

在此阶段，调试和日志记录可能很有用，以及所有常用的开发人员工具，如功能测试和内存分析工具。崩溃可能来自许多来源，从内存保护错误到资源的意外状态。你应该编制一份候选问题列表，并在你确信它们不是导致崩溃的原因时将它们交叉。

Answer 4

除了日志记录之外，您还可以启用mdmp文件（windows）或核心转储（linux）的创建，然后再进行检查;这种方法的一个缺点是核心转储可能非常大。 mdmp和核心转储包含崩溃发生时应用程序的上下文。