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

【问题标题】：What is the procedure for debugging a production-only error?调试仅生产错误的过程是什么？
【发布时间】：2010-06-10 14:39:12
【问题描述】：

让我先声明一下，我对这个话题太无知了，我什至不知道这个问题是否有客观的答案。如果结果是“不是”，我会删除或投票关闭帖子。

以下是场景：我刚刚编写了一个小 Web 服务。它适用于我的机器。它适用于我的团队负责人的机器。据我所知，它在除生产服务器之外的每台机器上都有效。生产服务器在失败时吐出的异常源自第三方 JAR 文件，并且信息不足。我在网上搜索了几个小时，但没有找到任何有用的东西。

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

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

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

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

【问题讨论】：

标签： debugging production-environment

【解决方案1】：

除了非常宝贵的日志记录之外，还有我自己和我的同事多年来使用的其他一些技术……回到我们无法访问的客户端计算机上的 16 位窗口。（我和自己约会了吗？）当然，并非所有事情都能/将会奏效。

分析您看到的所有行为。
复制，如果可能的话，复制它。
桌面检查，检查您怀疑的代码。
与团队成员以及对代码知之甚少或不熟悉的人一起避而不谈。您需要向某人解释的次数越多，您发现某事的机会就越大。
不要沮丧。休息5-10分钟。快速穿过建筑物/街道/随便什么。暂时不要考虑这个问题。
倾听你的直觉。

【讨论】：

【解决方案2】：

这是最困难的调试场景之一。答案将取决于生产系统的细节。它是一个您可以完全控制的系统吗？还是它安装在客户端的机器上，您需要通过无数次电话才能访问日志文件或修改配置参数？

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

【讨论】：

【解决方案3】：

我将从易于检查生产和测试之间的细微差别开始。通过实际测试消除明显的东西，如权限、防火墙、不同版本等。有一次我偷工减料说哦，这不可能，是的。

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

【讨论】：

很好地展示了“那不可能”或“那是不可能的！”。当卢克提到这一点时，我们都知道发生了什么......

【解决方案4】：

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

因此，这通常归结为从辅助资源和工件推断执行。然后归结为...

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

现在编写的大部分软件都属于 Java 或 .Net 阵营，因此请分别利用 log4j 和 log4net。

还有一个以 Ops 为中心的防暴配置指南和验证流程也会有所帮助。请记住，负责硬件和环境的人员很少了解他们托管的应用程序的配置要求。

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

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

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

【讨论】：

【解决方案7】：

一些建议：

准备好错误可能是由多种原因引起的，因此尽量不要只寻找一个原因。
使用未处理的错误处理程序，它将跟踪错误并汇总类似的缺陷（greylog、ELMAH）。
考虑使用小型转储文件进行事后调试。
为快速而肮脏的方法设置固定时间框架，然后采用系统方法。
与您的一位同事一起尝试代码审查缺陷模块。新鲜的观点可能会有所帮助。
使用您的版本控制系统（GIT、SVN）分而治之。
小心修复，因为大约 4% 的修复最终会引入新错误。
不要让快速修复生产中的错误的压力让您忽略标准质量控制程序（例如代码审查）。
修复后请确保您已编写自动化测试，以防错误在一段时间后再次出现。

【讨论】：