主机命名是件难事

此外，还有过早重启的风险

乔治·内维尔-尼尔

尊敬的KV：

最近，我们的系统管理团队内部就下一批主机的命名问题爆发了一场争论。一方希望以服务名称命名机器，每个主机都有一个数字后缀，另一方则希望继续我们当前为每个主机分配唯一名称的方案，不带数字字符串。现在我们有太多的主机，任何唯一的名称都变得很长，而且输入起来很麻烦。最近有人建议，每个主机可以在我们的内部DNS（域名系统）中拥有两个名称，但这似乎过于复杂。您是如何决定主机命名方案的呢？

匿名

亲爱的匿名者：

我向您推荐T.S.艾略特，他指出——某种程度上是这样

主机命名是件难事，
它不仅仅是你的假日游戏之一；
当你告诉我，一个主机必须有三个不同的名字时，你可能会认为我疯了。
当你告诉我，一个主机必须有三个不同的名字时，你可能会认为我疯了。

《猫的命名》（不是主机的命名）是T.S.艾略特的诗集《老负鼠的猫经》中的一首诗，其舞台剧改编是安德鲁·劳埃德·韦伯的热门音乐剧《猫》。这首诗向人类描述了猫是如何获得名字的。我稍微修改了艾略特的措辞——正如其他人之前所做的那样——并将这种类比扩展到描述主机的命名。但考虑到T.S.艾略特去世时，正值第一批小型计算机被设计出来的时候，我认为他在写这首诗时并没有考虑到主机名。这是一件好事，因为如果你认为两个名字很糟糕，那么三个只会更糟！

主机命名是一件难事，它与编码风格、编辑器选择和语言偏好在计算机人员争论的事情中并列，而这些事情对世界上其他任何人来说都无关紧要。更令人恼火——或者说好笑——但实际上是恼火的是，如果你在错误的时间出现在错误的酒吧，你将不得不听到醉醺醺的系统管理员争论命名方案，并为他们在以前的公司深情地给主机起的名字而对着啤酒哭泣。这真是毁了好兴致！

给事物命名有一个简单的目的：使其对一群人来说易于理解和记忆。在简短的示例程序中，将变量命名为foo、bar和baz很有趣，但你不会想维护100行像那样编写的代码。主机名也是如此。主机有名是因为人们需要知道如何访问它们——要么使用其服务，要么维护它们，或者两者兼而有之。如果没有人参与，主机可以简单地通过其Internet地址来识别。不幸的是，主机命名是Geek们喜欢发挥创造力的地方。更不幸的是，Geek们并不总是知道创造性和烦人之间的区别。决定你的主机应该以《星际迷航》、《星球大战》或托尔金或《暮光之城》中的角色命名，这完全没问题。对于托尔金，你可能可以编写——而且，天哪，可能已经有人这样做了——一个脚本，根据他的作品生成新名称，以防万一《霍比特人》、《指环王》三部曲和《精灵宝钻》没有足够荒谬的名字开始！

每个人都有一个命名恐怖故事。我的第一个是在一所大学，那里的主机以河流命名。如果你能记住塞纳河的拼写，那本来是不错的，但是一旦你用完了好听的短名字，你就会得到密西西比河和第聂伯河。这就是当我想远程登录到一台主机时想在脑海中做的事情，我想在我的脑海中，“M-I 弯曲的字母弯曲的字母 I 弯曲的字母弯曲的字母 I 驼背驼背 I”，这就是我和许多其他美国小学生学习拼写密西西比河的方式。我可以继续说下去，但那样我就听起来像我提到的那些毁了我的好兴致的人。因此，以下是选择主机名的简短指南。

你每天都要使用的名称需要易于键入。这意味着没有不发音的字母，例如Dnjeper，也没有太长的名称，例如thisisthehostthatjackbuilt。

选择你工作中的每个人都能发音的名字是个好主意。随着全球化，找到可发音的名字变得更加困难，因为有些人无法区分L和R，或者理解你是否使用了双o还是单o，而双元音会让你抓狂（不，双元音不是新款巴西泳衣）。这里的重点是避免选择带有大量难以翻译成打字的声音的名称。打字仍然比使用语音识别系统更快；所以请记住，这些名称必须键入。

如果你要使用服务作为名称，请确保你可以更换名称背后的系统而不会出现问题。如果mail.yourdomain.com宕机时，每个人都必须使用mail2.yourdomain.com，那么每个人都会感到恼火，这应该是显而易见的。（这一点实际上与命名无关，因为任何一位合格的系统管理员都可以构建这样的系统；但我见过以错误的方式完成的，所以我想在此记录一下。）

务必避免为同一事物使用两个不同的、不相关的名称。事实上，这在代码和主机名中都是如此。如果你有两个类似的服务，并且想要两个不同的名称，请完全清楚地说明如何将一个名称映射到另一个名称以及如何返回。当一个人问到以下问题时，来回反复会让人发疯：

“嘿，我可以重启fibble吗？”

“可以。”

然后有人问：

“谁重启了mail1？”

“但我不知道它是mail1；我以为它是fibble。”

最后，尽量避免卖弄可爱。我知道给出这个建议基本上是与风车作战，但我不得不说，那些将他们的邮件服务器命名为male和female的人让我的冰冷血液沸腾。

尊敬的KV：

我公司的一位一线工程师——在负责查看实时流量冲击我们的交换机和服务器的团队中——不断报告问题，然后，在任何人可以查看出现问题的服务器之前，重启系统以清除问题。你如何向某人解释，当系统出现故障时，需要收集一些信息，这些信息对于查找和解决问题至关重要？

重启者

亲爱的重启者：

我会先用脚踩在这个人的胸口，然后大喊：“当系统出现故障时，需要收集一些信息，这些信息对于查找和解决问题至关重要。”但我认为你已经尝试过了，尽管可能没有足够尖叫。

没错，系统在执行过程中倾向于积累状态，这些状态不会经常写入到某些永久存储中。你需要解决的问题不是阻止此人立即重启出现故障的机器，而是确保系统运行时正在做什么有一个良好的、可搜索的记录。现代服务器上的大多数系统监控工具都会生成纯文本输出。编写脚本定期写入这些工具（例如procstat、netstat、iostat等）的输出到将在重启后保留的文件中，这很简单。

对于更棘手的问题，你可以编写自己的工具，无论是脚本还是在系统关闭或重启时执行的新程序。这样，如果人们在你到达之前就立即重启你的机器，你可以让他们重启命令执行你的指令。你甚至可以进一步修改你的操作系统，使其在每次重启时生成内核核心转储。这为你提供了系统在崩溃时的快照，你可以稍后返回并仔细检查。但我警告你，仔细检查内核核心转储就像从狗身上挑跳蚤一样有趣。

收集所有这些数据的唯一缺点是分析它。由于不再真正需要删除数据，你可能会花费大量时间将其组织成文件树的树。我提供几个快速建议。不要使树方案过于难以遍历，无论是对于人还是程序。由于遍历目录树的成本，访问深层树中的大量文件可能需要很长时间。为自己和你的分析程序保持简单。在开始之前，制定一个计划，说明你想要存储什么、想要存储在哪里以及计划如何访问它。大多数人会将这种想法投入到他们的应用程序中，但没有足够多的人投入到他们如何以及在哪里存储系统生成的日志或其他运行时信息中。你应该至少将一半的时间投入到后者，就像你投入到前者一样。

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

[email protected]

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

最初发表于Queue vol. 11, no. 6—
在数字图书馆中评论本文

更多相关文章

凯瑟琳·海耶斯，大卫·马龙 - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。许多标准的存在是为了满足各种安全要求的加密哈希，但在非加密方面，存在一定程度的民间传说，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对现实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。

妮可·福斯格伦，埃里尼·卡利亚姆瓦库，阿比·诺达，米凯拉·格雷勒，布莱恩·霍克，玛格丽特-安·斯托雷 - DevEx在行动
随着领导者在财政紧缩和人工智能等转型技术的背景下寻求优化软件交付，DevEx（开发者体验）在许多软件组织中越来越受到关注。直观地看，技术领导者普遍认为良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而，在许多组织中，旨在改善DevEx的拟议倡议和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。

若昂·瓦拉若，安东尼奥·特里戈，米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来研究生产力差异，从而为该主题提供新的见解。低代码技术显然显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究的机会。

伊瓦尔·雅各布森，阿里斯泰尔·科克本 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，在这个世界中，新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在其快速前进的步伐中，它容易受到时尚的支配，并且可能会忘记或忽略一些针对其面临的永恒问题的成熟解决方案。用例，最早于1986年引入并在后来普及，就是那些成熟的解决方案之一。