Logging 的逻辑

以及 PDF 的不合理之处

George Neville-Neil

尊敬的 KV,

我在一个相当开放的环境中工作，所谓开放是指很多人都拥有成为我们服务器 root 用户的能力，以便在服务器出现故障时能够修复。公司刚成立时，我们只有几个人做所有的工作，当服务器宕机或进程失控时，不同职责的人员都必须挺身而出提供帮助。那是几年前的事了，但现在仍然有很多人拥有 root 权限，一些是由于历史遗留原因，另一些则是因为他们被认为太重要而不能限制。问题是，其中一位历史遗留用户坚持几乎所有事情都以 root 身份执行，实际上，他使用sudo命令只是为了执行sudo su -.每次我需要调试这个人参与过的系统时，我最终都要进行两到四个小时的日志挖掘之旅，因为他也不记录他所做的事情，当他完成时，他只是简单地报告说：“修好了。” 我想你会同意这是一种令人恼火的行为。

被 Root 困扰的人

尊敬的 Routed,

我想告诉你，你可以做一件事然后说：“修好了”，但我不能那样告诉你。我也可以告诉你，下次他再这样做时就切掉他的小指尖，但我敢打赌，人力资源部会对工作场所的日本黑帮仪式皱眉头。

你遇到的问题更多的是文化问题，而不是技术问题，因为正如你在信中所说，对于允许用户拥有可审计的 root 系统访问权限的问题，存在技术解决方案。很少有人或组织希望以军事级别的安全级别运行他们的系统；而且，在大多数情况下，他们是对的，因为这些类型的系统涉及大量的过度保护——而且，正如我们最近看到的，仍然无法正常工作。

在大多数环境中，允许绝大多数员工仅访问他们自己的文件和数据就足够了，然后给予少数员工——那些角色真正需要的员工——访问更广泛权限的能力。那些在这个受信任的少数群体中的人不能被给予对系统的全权委托，而是应该再次被给予有限的访问权限，当使用像 sudo 这样的系统时，这非常简单。运行任何程序的权限都可以按用户或组列入白名单，拥有一个简短的白名单是保护系统的最佳方法。

现在我们来谈谈你关于日志记录的观点，这实际上是关于可审计性的。许多人不喜欢日志记录，因为他们认为这就像被监视一样，而且，事实证明，大多数人不喜欢被监视。任何处于信任职位的人都应该明白，信任需要被验证才能维持，而日志记录是维护一群人之间信任的一种方式。日志记录也是回答古老问题“谁在何时对谁做了什么？”的一种方式。事实上，所有这些都在当你第一次尝试使用 sudo 时，sudo 输出的消息中有所暗示

我们相信您已经接受了当地系统管理员的通常训诫。它通常归结为以下三件事

#1) 尊重他人隐私。

#2) 三思而后行。

#3) 能力越大，责任越大。

第 3 条引自漫画书《蜘蛛侠》，但斯坦·李的话在这种情况下是恰当的。Unix 系统中的 root 用户几乎可以做任何他们想做的事情，无论是恶意的还是因为他们在输入时考虑不周。通常，使系统恢复正常工作的唯一方法是弄清楚拥有 root 权限的用户对系统做了什么，而做到这一点的唯一机会是，如果这些操作被记录在某个地方。

如果我是这个人的经理，我要么完全取消他的 sudo 权限，直到他学会如何与他人好好合作，要么我会解雇他。没有人对公司有用处到可以允许他们在没有监督的情况下扮演上帝。

尊敬的 KV,

我最近正在基于现有的规范实施新代码。该文档是 30 页的表格，其中包含名称和值。不幸的是，这份文档仅以 PDF 格式提供，这意味着没有简单、程序化的方法将表格提取到代码中。原本只需几分钟用几个脚本就能完成的工作，变成了半天的复制粘贴，以及随之而来的所有错误。我知道许多规范——例如，Internet RFC（请求评论文档）——仍然以纯 ASCII 文本格式发布，所以我不明白为什么有人会将注定要被代码实现的规范以像 PDF 这样在程序上难以处理的格式发布。

复制、粘贴、穿孔、损坏

尊敬的 Mutilated,

显然，您不欣赏现代桌面出版中蕴含的美丽和庄严。字体的使用——许多，许多字体——以及粗体和下划线，肯定会像用火焰之手刻在石头上一样，增加书面文字的清晰度。

你要么是面临着一种过度自我膨胀的问题，就像某些人——通常是在大公司的营销部门——开始发送带有粗体、下划线和颜色的电子邮件，因为他们认为这会让我们关注，或者你是在与一个制定标准但从不实施标准的人打交道。在任何一种情况下，这都引出了一个不仅关于文档，也关于代码的问题。

除了在神话中，标准和代码都不是写在石头上的。任何必须更改的文档都应该在变更跟踪系统中（例如源代码控制系统）中进行跟踪，这对文档和将被编译的代码都是如此。将任何文档保持在可跟踪和可差异化的格式的优点是，也可以使用标准的文本处理程序（如 sed、cut 和 grep）以及脚本语言（如 Perl 和 Python）从中提取信息。虽然其他计算机语言也可以处理文本操作，但我发现许多做你建议的事情的人都在使用 Perl 和 Python。

我也希望生活在一个这样的世界里——当有人更新软件规范时——我可以对文档运行一组程序，提取值，并将它们与我代码中现有的值进行比较。这将减少错误并提高更新的速度。差异可能仍然需要目视检查，出于基本的偏执和不信任，我也会目视检查我的，但这将比打印 PDF 文件并用笔检查或使用 PDF 阅读器以电子方式完成相同的工作容易得多。虽然有一些程序可以为你分解 PDF，但没有一个非常好用；最大的问题是，如果作者在打开 Word 编写规范之前思考 30 秒，那么这些程序就都不需要了。

关于 IETF（互联网工程任务组），有很多事情可以抱怨，但继续以文本格式发布其协议的承诺不是其中之一。唉，不是每个人都有 Jon Postel 指导他们完成最初的几千份文档，但他们仍然可以从这个例子中学习。

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

[email protected]

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

最初发表于 Queue 第 12 卷，第 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 年引入，并在后来普及，就是那些成熟的解决方案之一。