在生产系统上进行调试

这更多的是一个社会问题，而不是技术问题。

亲爱的 KV，

我一直在尝试调试工作系统上的一个问题，但是运行我们生产系统的控制狂们不愿意给我访问权限，让我进入总是出现错误的系统。我没能在我的桌面测试环境中重现这个问题，但每天这个错误都会在几个生产系统上发生。我甚至开始考虑使用键盘记录器来窃取密码，以便能够进入生产系统，最终“在野外”看到这个问题。我职业生涯中从未为如此一群法西斯分子工作过。

被锁定在外

亲爱的被锁定者，

首先，虽然大多数公司本质上是非民主的，但很少有公司是法西斯主义的。法西斯主义在1945年左右就过时了，此后就再也没有真正复兴过。其次，我确实同情你——任何人都不应该仅仅因为无法访问适当的系统而被阻止修复错误。

许多程序员和技术人员未能理解的是，正如一位同事最近所说，“访问意味着责任”。这就是为什么 sudo 程序有警告，这句话是从蜘蛛侠漫画中偷来的：“能力越大，责任越大。”

调试程序或系统可能会，并且经常会，产生负面的副作用，无论是通过减慢系统速度还是以意外的方式更改某些计算结果。运行您生产系统的人员有理由对让任何随便的程序员在他们的领域内乱来保持警惕。如果您破坏了某些东西，很可能会由他们承担责任，他们将不得不修复它，而您只能在那里沮丧地重复说：“好吧，它不应该那样做！”

您最好的办法是首先在生产环境之外设置一个生产系统，作为测试机器。我惊讶于有多少公司在没有这种暂存机器的情况下工作，直接从开发人员的桌面转到他们的生产环境。如果没有实际的工作负载，错误就不会发生，那么现在是时候在生产环境中获得一台充分隔离的机器，以便在不破坏正在进行生产性工作的机器的情况下为其提供工作负载。

到现在为止，您可能已经注意到这个建议更多的是关于社会工程学，而不是技术。程序员需要愿意与那些必须保持系统每天 24 小时、每周 7 天运行的人员合作，如果他们希望获得足够的信任，以便能够调试实时或接近实时的系统。

最后两个想法：使用键盘记录器不是获得信任的方式，在公共专栏中告诉别人您正在考虑这样做就像在推特上发布您的谋杀计划一样愚蠢。

亲爱的 KV，

我刚在工作中接手的一个程序一直崩溃，每次我在调试器中查看它并检查各种内存位时，我都会在分配的内存的不同部分看到 0xdeadc0de 模式。这是一个玩笑吗？您认为我的同事在戏弄我吗？

对这段代码感到 0xDead 疲惫

亲爱的 0xDead，

程序员在尝试调试内存粉碎错误时，通常会将内存设置为易于识别的值。您可能认为他们会将缓冲区中的所有字节清除为 0x00，但这无济于事，如果某些代码将 NULL 字节写入您的缓冲区中。使用诸如 0xdeadc0de 之类的已知模式可以更轻松地在调试器中找到这些问题。正如您所见，您打印一个缓冲区，您会看到该模式。如果您看到的是，例如 0xde00c0de，那么您就会知道有人在您的内存中间写入了一个 NULL 字节。也许您想要那样做，也许您不想要，但现在，至少，您可以清楚地看到它。为了获得额外的聪明分数，您可以设置一个观察点——如果您的硬件支持它——如果某个变量或部分内存不等于 0xdeadc0de，则会停止程序。我倾向于将我正在调试的缓冲区设置为全部 0x69，因为如果我看到这个数字，那么我就知道这是我自己的个人工作。

对于处理网络数据包的程序员来说，已知模式还有另一个优势。大多数人在基于 Intel x86 架构的系统上编写代码，这在网络术语中被称为小端系统。小端系统最后存储多字节字的最重要的字节。网络协议是大端的，这与 x86 处理器在内存中存储数据的方式相反。所有网络程序员都知道 C 宏 htonl()、ntohl()、htons() 和 ntohs()，它们可以正确地进行主机到网络字节序的交换和反向交换。调试网络协议的一个好方法是在数据包中传输诸如 0xdeadc0de 之类的数据，然后确保当它到达您程序的内存中时，它看起来不像 0xdec0adde。使用这个技巧可以更容易地找出您可能遗漏字节交换宏的位置。

所以，尽管我很想认为您的同事在戏弄您，但更有可能的是他们在试图提供帮助。

KODE VICIOUS，凡人称之为 George V. Neville-Neil，为了乐趣和利润而从事网络和操作系统代码的工作。他还教授有关编程各个主题的课程。他的兴趣领域是代码探险、操作系统和重写您的糟糕代码（好吧，也许不是最后一个）。他在马萨诸塞州波士顿的东北大学获得了计算机科学学士学位，并且是、Usenix 协会和 IEEE 的成员。他是一位狂热的自行车爱好者和旅行者，目前居住在纽约市。

最初发表于 Queue 第 9 卷，第 9 期—
在数字图书馆中评论本文

更多相关文章

Charisma Chan, Beth Cooper - 调试 Google 分布式系统中的事件
本文介绍了 2019 年对 Google 工程师如何调试生产问题进行的研究结果，包括工程师在不同组合中使用以有效调试的工具类型、高级策略和低级任务。它考察了用于捕获数据的研究方法，总结了生产调查的常见工程历程，并分享了专家如何调试复杂分布式系统的示例。最后，本文将这项研究的 Google 特性扩展到提供一些您可以在组织中应用的实用策略。

Devon H. O'Dell - 调试心态
软件开发人员花费 35-50% 的时间来验证和调试软件。调试、测试和验证的成本估计占软件开发项目总预算的 50-75%，每年超过 1000 亿美元。虽然工具、语言和环境减少了花费在单个调试任务上的时间，但它们并没有显着减少花费在调试上的总时间，也没有减少调试的成本。因此，过度关注开发过程中消除错误是适得其反的；程序员应该将调试视为解决问题的练习。

Peter Phillips - 使用跟踪增强调试
创建一个模拟器来运行旧程序是一项艰巨的任务。您需要透彻了解目标硬件以及模拟器要执行的原始程序的正确功能。除了功能正确之外，模拟器还必须达到以原始实时速度运行程序的性能目标。实现这些目标不可避免地需要大量的调试。这些错误通常是模拟器本身中的细微错误，但也可能是对目标硬件的误解或原始程序中实际已知的错误。（原始程序的二进制数据也可能变得稍微损坏或不是预期的版本。）

Queue Readers - 又一天，又一个错误
作为本期关于程序员工具的一部分，我们在 Queue 决定就调试主题进行一项非正式的 Web 调查。我们请您告诉我们您使用的工具以及您如何使用它们。我们还收集了一些关于那些难以追踪的错误的故事，这些错误有时会让我们想到从事其他职业。