调试纯生产错误的过程是什么?

除了非常宝贵的日志记录之外,以下是我和同事多年来使用的一些其他技术。。。回到我们无法访问的客户机上的16位windows(我和自己约会了吗?)当然,不是每件事都能/都能成功。

• 复制,如果可能的话,复制它。
• 案头检查,检查你怀疑的代码。
• 与团队成员和对代码不太熟悉或不熟悉的人打交道。你越是需要向某人解释某事,你就越有机会发现某事。
• 别灰心。休息5-10分钟。快走过去穿过大楼/街道/随便什么。那时候不要考虑这个问题。

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

我将从小的,易于检查的生产和测试之间的差异开始。通过实际测试消除明显的东西,如权限、防火墙、不同版本等。有一次我抄近路说 哦,不可能 是的。

一般来说,“调试”[即连接到进程并检查执行]是不可行的,原因很多,其中最重要的一个原因是数据敏感性[例如开发人员很少有资格检查我们操作的数据]

所以这通常归结为从辅助源和工件推断执行。这就归结为。。。

• 登录中,
• 登录中,

此外,有一个以防误操作为中心的配置指南和验证过程也会有所帮助。请记住,负责硬件和环境的人员很少了解他们托管的应用程序的配置要求。

我使用了一个可配置的日志系统,比如Log4J,来查看生产运行中发生了什么,这假设开发人员已经在日志中输入了有用的调试信息。

但是要注意,日志记录可能会暴露一些敏感的私有数据,在可能的情况下,应该对这些数据进行编码和/或跳过。

向错误消息添加更多细节也很方便。例如,当从例程中获取异常时,可以将调用中使用的参数添加到异常错误中。或者,至少是全局状态信息(谁登录了,他们在哪个高级模块中,他们在调用哪个高级函数等等)。

一些建议:

• 使用未处理的错误处理程序,它将跟踪错误并聚合类似的缺陷( greylog , ELMAH ).
• 对快速和肮脏的方法有固定的时间框架,然后采用系统的方法。
• 使用版本控制系统(GIT,SVN)进行分而治之。
• 小心修复,因为大约4%的修复最终会引入新的bug。
• 不要让生产中快速修复bug的压力让你忽略了标准的质量控制程序(比如代码评审)。