自动化淹没

无论何时有人请你信任他们，都不要信任。

尊敬的 KV：
最近，为了推动从测试构建到文档更新等所有流程的自动化，我的团队——应我们一个开发团队的要求——部署了一个作业调度系统。部署这个系统的想法是，任何人都可以设置一个定期运行的作业，以执行一些耗时但对于公司日常工作并非绝对关键的工作。这是一种避免人们在自己的桌面上运行cron作业，并提供一套集中的后台处理服务的方法。

但是，这个系统存在一些问题。第一个问题是它非常消耗资源，尤其是在内存使用方面。第二个问题是我们团队中没有人知道它是如何工作的，或者它真正是如何被使用的，而只知道如何在我们的服务器上部署它——大约每周都会有人以一种新的、意想不到的方式使用该系统，然后这会破坏所有先前用户的系统。使用该系统的人太忙了，无法解释他们是如何使用它的，这实际上违背了我们最初部署它的主要原因——为了节省他们的时间。文档也不是很好。支持该系统的团队中没有人有时间阅读和理解源代码，但我们必须做些什么来了解该系统的工作原理以及它的扩展方式，以便将我们自己从这段代码中解救出来。您能否就如何在不陷入代码泥潭的情况下继续前进提供一些见解？

淹没

尊敬的“淹没”：

所以你的团队掉进了“只需安装这个软件，一切都会好起来的”的陷阱。这是一个古老的伎俩，它不断地困扰着系统管理员和其他在开发人员周围扮演支持角色的人。无论何时有人请你信任他们，都不要信任。虽然这可能很愤世嫉俗，但总比被愚弄好。

但是现在你已经被愚弄了，你如何摆脱被愚弄的状态呢？虽然通常解决此类问题的方法是艰难地啃下成千上万行来源可疑的未知代码——一种“硬着头皮”的努力——但还有其他一些方法可以在不从main()开始并阅读每个函数的情况下尝试理解系统。

第一种方法是为你们自己构建第二个系统，并为你们的环境创建一套典型的测试作业。第二种方法是使用已经部署的系统来测试你可以将其推到多远。在这两种情况下，你都需要对机器进行检测，以便你可以衡量增加工作对系统产生的影响。

一旦你有了这套测试作业，或者你正在生产机器上运行，你就可以检测你的机器，以衡量每个作业对系统产生的影响。在你最初的问题中，你说内存是作业控制系统大量使用的东西之一，所以那是首先要关注的事情。当你添加一个作业时，系统使用多少实际内存，而不是虚拟内存。如果你添加两个作业，它会占用两倍的内存吗？三个呢？内存使用量如何扩展？一旦你可以绘制出内存使用量如何扩展的图表，你就可以了解在开始出现内存问题之前，系统可以承受多少工作量。你应该继续添加工作，直到系统开始交换，届时你就会知道系统的内存限制。

不要犯只尝试一两个作业的错误——要一直测试到系统的极限，因为有些影响你只做少量工作是找不到的。如果系统在一两个作业的情况下就失败了，你就根本不会部署它，对吧？请告诉我这是对的。

另一个需要衡量的指标是作业结束时会发生什么。内存会被释放吗？在大多数现代系统中，你不会看到内存被释放，直到另一个程序需要内存，所以你必须通过运行作业直到系统交换，然后删除所有作业，然后再添加相同数量的作业来进行测试。在热身运行后，系统在较少的作业下会发生交换吗？系统可能存在内存泄漏。如果你无法修复泄漏，那么猜猜会发生什么，你将不得不定期重启系统，因为你不太可能有时间自己找到泄漏。

当你试图理解系统如何扩展时，最好也看看它如何使用内存以外的资源。所有系统都有简单的工具来查看CPU利用率，当然，你应该确保作业控制系统是占用所有CPU时间的那个，因为这会增加总的系统开销。

可以使用诸如netstat和procstat以及lsof等程序来理解系统使用的文件和网络资源。系统是否打开了大量文件而只是将它们留在那里？这是一种你需要了解的资源浪费，因为大多数操作系统都限制了一个进程可以拥有的打开文件数量。系统是否是磁盘密集型的，或者它是否使用锁文件进行大量工作？一个使用大量锁文件的系统需要在本地的、非联网的磁盘上为锁文件提供空间，因为网络文件系统在文件锁定方面特别糟糕。

一个相当极端的措施，也是我赞成的一个措施，是使用ktrace, strace，特别是DTrace来弄清楚程序正在对系统做什么。前两个肯定会减慢它们正在测量的系统的速度，但它们可以快速显示程序正在做什么，包括它在等待I/O完成时发出的系统调用，以及它正在使用的文件等等。在支持DTrace的系统上，跟踪的开销会降低，并且在对延迟不敏感的系统上，使用DTrace进行大量跟踪是可以接受的，比使用ktrace或strace更好。甚至还有一个脚本，dtruss，与DTrace一起提供，它的工作方式类似于ktrace或strace，但具有与DTrace相关的较低开销。如果你想知道程序正在做什么，而又不想小心翼翼地翻阅源代码，我强烈建议使用某种形式的跟踪。

最终，理解系统的目标总是更好，但对于工程师和程序员来说，这可能就像拔牙一样困难。倒不是说拔牙不好玩——相信我，我做过——但它比看起来更费力，有时牙仙不会因为你的辛勤工作而给你额外的钱。

喜欢它，讨厌它？请告诉我们

[email protected]

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

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

更多相关文章

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 年引入并在后期普及，就是那些成熟的解决方案之一。