调试仅生产错误的过程是什么？

Question

我先说我对这个话题一无所知，我甚至不知道这个问题是否有客观答案。如果它最终“不”，我将删除或投票关闭帖子。

这是场景：我刚刚写了一个小小的Web服务。它适用于我的机器。它适用于我的团队负责人的机器。据我所知，它可以在除生产服务器之外的每台机器上运行。生产服务器在发生故障时吐出的例外来自第三方JAR文件，并且信息很少。我在网上搜索了几个小时，但没有提出任何有用的东西。

那么追踪仅在生产机器上发生的问题的程序是什么？是否有标准方法，或者可能是一个类别/系列工具？

启发这个问题的错误已经得到修复，但这更多是因为好运而不是一个可靠的调试方法。我问这个问题以供将来参考。

编辑：
到目前为止，答案似乎总结为一个词：记录。记录的一个问题是它需要预先考虑。如果现有系统中出现日志不佳的情况，或者客户端担心敏感数据并且首先不想在系统中使用大量日志记录系统，该怎么办？

  

一些相关问题：
  Test accounts and products in a production system
  Running test on Production Code/Server

Answer 1

除了日志记录，这是非常宝贵的，以下是我自己和我的同事多年来使用的一些其他技术...回到我们无法访问的客户端计算机上的16位窗口。 （我是否与自己约会？）当然，并非一切都可以/将会有效。

• 分析您看到的所有行为。
• 如果可能的话，重现它，重现它。
• 桌面检查，浏览您怀疑的代码。
• 与团队成员以及对代码很少或根本不熟悉的人员进行橡皮擦。你必须向某人解释的东西越多，你发现某些东西的机会就越大。
• 不要感到沮丧。休息5-10分钟。快速步行穿过建筑物/街道/无论如何。那个时候不要考虑这个问题。
• 倾听你的直觉。

Answer 2

这是最困难的调试方案之一。答案取决于生产系统的细节。它是一个你完全控制它的系统吗？或者它是否安装在客户端的计算机上，您需要通过多次电话呼叫才能访问日志文件或修改配置参数？

我相信大多数人会同意最有效的调试方法是使用日志记录。您需要主动操作并添加尽可能多的日志记录信息。但是，您必须能够启用和禁用按需记录。生产系统中的大量调试日志可能会破坏性能。出于同样的原因，您需要只能启用日志记录的特定部分。创建记录打印输出的逻辑组，并仅启用您认为可以为您提供最相关信息的组。

Answer 3

我会从小的，易于检查生产和测试之间的差异开始。通过实际测试消除权限，防火墙，不同版本等明显的东西。有一次我偷工减料并说哦，那不可能是，它就是。

然后，我按可能性和成本优先考虑更昂贵的测试。要有创意。想想可能导致您看到的行为的非常奇怪的事情。

Answer 4

通常来说，“调试”[即附加到流程并检查执行]是不可行的 - 出于多种原因，其中最重要的是数据敏感性[例如，开发人员很少有资格\清除检查我们操作的数据] < / p>

因此，这通常归结为从次要来源和工件推断执行。然后归结为......

• 日志记录，
• 日志记录，
• 日志记录，

目前编写的绝大多数软件属于Java或.Net阵营，因此分别利用log4j和log4net。

还有一个防止出色的Ops配置指南和验证过程有助于。请记住，负责硬件和环境的人员很少了解他们托管的应用程序的配置要求。

Answer 5

我使用了可配置的日志记录系统（如Log4J）来查看生产运行中发生的情况，这假设开发人员已在日志中放置了有用的调试信息。

但请注意，日志记录可能会暴露一些明智的私有数据，应尽可能对其进行编码和/或跳过。

Answer 6

除日志记录外，其他技术还包括保存请求数据，然后您可以将这些请求数据输入到您自己的“相同”系统中。这可以简单到将您收到的每个HTTP请求保存到文件中以供以后分析。现在您可能会记录大部分此类信息（尤其是GET的URL），您只需要添加标题和请求主体即可。

为错误消息添加更多细节也很方便。例如，当您从例程中获得异常时，可以将该调用中使用的参数添加到异常错误中。或者，至少，全球状态信息（谁登录，他们在哪个高级模块，他们正在调用什么高级功能等）。

Answer 7

一些建议：

• 准备好bug可能是由多种原因引起的，所以尽量不要让你的思维缩小到只搜寻一个原因。
• 使用未处理的错误处理程序，它会跟踪错误并汇总类似的错误（greylog，ELMAH）。
• 考虑使用迷你转储文件进行事后调试。
• 有快速和肮脏方法的固定时间框架，然后采用系统方法。
• 与您的同事一起尝试代码审核缺陷模块。新观点可能会有所帮助。
• 使用您的版本控制系统（GIT，SVN）进行划分和征服。
• 注意修复，因为大约4％的修复程序最终会引入新的错误。
• 不要让生产中快速修复错误的压力使您省略标准质量控制程序（例如代码审查）。
• 修复后确保您已经编写了自动化测试，以防错误一段时间后再发生。