收集计数器

收集统计数据很重要，但使其可供他人使用也同样重要。

尊敬的 KV，

在过去的一个月里，我一直在试图找出我们的系统在网络负载过重时出现的问题。大约两周后，我终于将问题范围从“网络坏了”（我的同事经常用这句话来惹恼我）缩小到我们的系统中的网络接口出现问题。

你可能认为我会问你关于网络问题，但我不是。我在研究这个问题时发现，硬件能够记录大量的统计数据和错误，但其中至少一半是系统用户无法访问的，因为它们没有暴露给驱动程序之上的任何层。我之所以能够发现这一点，是因为我们使用的是开源操作系统，我可以阅读驱动程序源代码。驱动程序中确实有代码可以从设备获取这些统计数据，但是没有代码可以将这些数据提供给其他人使用。为什么有人会编写代码来收集统计数据，却不编写代码使其可用呢？

驱动程序驱动

尊敬的 Driven，

对你问题的简短回答可能仅仅是时间不足。你看到的代码是驱动程序编写者当时的最佳意图，但这已经是他在被迫发布代码之前所能做到的全部。或者，也许编写者只是一个彻头彻尾的恶棍，他晚上睡觉时会嘲笑自己，因为他知道成千上万的人无法诊断他们的网络问题。我更倾向于后者，因为前者太平凡且无趣了。

然而，真正的问题更多地与硬件工程师和软件工程师之间的接口有关。设备驱动程序实际上构成了一个有趣的社会学视角，通过它可以研究两个不同的社会群体对其环境的不同反应。

广义上来说，硬件人员在他们的产品失败之前，进行返工的次数受到更多限制。创建一个新版本的电路板，即使是像网卡这样简单的东西，也是一个昂贵且耗时的过程。硬件人员很久以前就意识到，一旦他们无法再让工厂焊接绿色导线，解决硬件问题的最佳方法就是留给软件人员来处理。作为一种对软件世界的善意尝试，他们在硬件中为可能出错的每一件事都添加了计数器和统计数据。有时这些计数器甚至有文档记录，但它们之间的关系很少被明确到足以在不深入了解您正在使用的硬件的情况下使用。

软件人员的问题在于，面对如此众多的计数器，以及缺乏关于哪些计数器可能或可能对解决问题有用的信息，他们会走向两个方向之一：要么他们认为他们只需要暴露重要的计数器，这意味着他们理解的计数器；要么他们将所有计数器都暴露在一个大的块中，这使得它们难以使用。这两种方法都相当于驱动程序编写者举起双手，尖叫着：“够了！别烦我了！自求多福吧。”正如您可能已经注意到的，这对系统集成商或试图调试问题的人员没有任何帮助。

对于计数器收集和显示，我有一个非常基本的规则。如果你可以获取一个计数器，并且获取计数器不会对系统性能产生负面影响，那么你最好将其记录在某个地方。如果你记录了一些东西，你最好将其提供给使用你的软件的人员访问，因为不这样做就像给人挠不到的痒处。有时这很邪恶也很有趣，但绝对是糟糕的软件业力。当你的代码向用户呈现这些计数器时，它们需要以某种智能方式进行分组（例如，将错误计数器与显示非错误计数器分开）。在网络驱动程序的情况下，一个具体的例子是将所有用于数据包接收的计数器放在一组中，然后将所有用于数据包传输的计数器放在另一组中，最后是一组用于硬件处理的中断的计数器。

最后要避免的一件事是将计数器隐藏在调试语句中，而这些调试语句需要重新编译软件才能使用。事实证明，大多数使用软件的人不是软件工程师，并且不希望仅仅为了找出软件的问题而不得不重新构建软件。将计数器分为一组您希望用户能够访问的计数器和另一组您认为他们永远不需要的计数器，是通往地狱的道路。我可以保证，每一个将计数器隐藏在调试块中，不易于用户访问的软件开发人员，有一天都会后悔这个选择。今天在调试块中的计数器将是您需要在问题报告中让用户读回给您的计数器，如果它不容易获取，您将完全完蛋，而且是以一种不好的方式。

总而言之，如果你可以计数，那就去计数——如果你计数了，确保不是你的人也能访问它。

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

最初发表于 Queue 第8卷，第6期——
在数字图书馆中评论这篇文章

更多相关文章

Catherine Hayes, David Malone - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。出于各种安全需求，加密哈希存在许多标准，但在非加密方面，存在一定的民间传统，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布很有意义，但在面对具有特定模式的数据集时，这可能是一个挑战。

Nicole Forsgren, Eirini Kalliamvakou, Abi Noda, Michaela Greiler, Brian Houck, Margaret-Anne Storey - DevEx 实践
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者们在财政紧缩和人工智能等变革性技术的背景下，寻求优化软件交付。直观地看，技术领导者普遍认为，良好的开发者体验能够提高软件交付效率和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

João Varajão, António Trigo, Miguel Almeida - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极端低代码技术进行的实验室实验结果，以研究生产力差异，从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

Ivar Jacobson, Alistair Cockburn - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，新的工具、技术和方法不断被开发出来以服务于商业和社会，但它也很健忘。在快速前进的匆忙中，它容易受到时尚的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例，最早于 1986 年引入并在后来普及，就是这些成熟的解决方案之一。