命名约定

Question 1

很大程度上取决于你的工作环境。

首先，最重要的是——删除任何对（流行）文化的引用，坚持使用有意义且描述性的名称。

你可能知道“zeus”是代理服务器，因为你安装了它。但未来的同事很可能会喜欢用以下方式来指代服务器：它能做什么，而不是他的给定的名称是。

如果您接受这一点，我建议您进行头脑风暴会议，写下您拥有哪些不同类型的网络实体（“主机”），如何将它们分组在一起，以及哪些信息足够重要，需要编码到主机名中。您的命名约定应该能够明确地命名所有现有设备，并让用户大致了解主机的功能。确保留出足够的增长空间以适应未来的发展，这样您就不必在几个月内就抛弃命名约定。

记录您的命名约定（不仅是如何，而且是为什么），确保每个需要定期使用它的人都了解它的布局方式，对意见/建议持开放态度，不要将其吹捧为圣杯，并在需要时进行调整。

例子

为了发人深省，以下是我以前的一位雇主使用的模式：

Web 服务提供商，负责 Web 项目的开发和运营。主要涉及 LAMP 项目，但规模较大（指项目规模，而非数量）。

对于物理设备：

<站点>-<机架>-<设备>.in.<域>.<TLD>

SITE 是唯一的站点标识符，主要由三个字母组成
RACK 是我们分配的标识符，或者从托管设施接管，应该能够唯一地标识 SITE 上的机架
DEVICE 是一个带有计数器的“设备类”，例如，OpenVZ 节点的 vnodeXX、千兆交换机的 swge 等。
DOMAIN/TLD 是给定设备所有者的域。

对于逻辑实体：

逻辑实体可能是任何具有 IP 地址但与给定物理设备/位置没有紧密关联的事物。这主要是客户操作系统（在我们的例子中是 OpenVZ 或 ESX）的 IP 地址。

<项目>-<环境>-<服务>.in.<域>.<TLD>

PROJECT 是一个项目标识符，它将项目的各种服务分组在一起。
环境可以是生产、阶段或开发，4 个字母的缩写
SERVICE 相对自由，但常见的情况是标准化的，如 web、db、mailout 等。
DOMAIN 是本项目的主域名。

对于 IP 地址：

我们的所有服务都只能通过私有网络访问，我们有 NAT 和/或负载均衡器，带有“服务 IP 地址”，供面向互联网的主机访问我们的服务。对于这些，我们使用了类似这样的方法：

<项目>-<环境>-vip-<标识符>.<域>.<TLD>

IDENTIFIER 是唯一标识 IP 地址用途的地址，例如，专门用作项目德国域名的 Web VirtualHost 的地址可能被称为“wwwde”。

总结

命名惯例对我们来说很好，但有些人（比如我们的开发人员 ;) ）可能会认为它太夸张了。请记住，它是如果你只维护一个网站，并且只为一个项目分配服务器，那么这完全是夸大其词。但对我们来说，它满足了一些非常重要的事情。

在处理逻辑实体的主机名时，我们始终知道：

涉及哪个项目：
各个项目的重要性各不相同，由不同的开发团队负责。快速浏览一下主机名，你就会知道需要如何确定任务的优先级，以及需要向管理/开发方面的谁咨询
主机所处的环境：
开发环境中的问题会导致开发人员的速度变慢。临时环境中的问题会给测试人员带来麻烦，并可能危及产品展示。如果生产过程中出现问题，公司就会蒙受损失。
受影响的子系统：
邮件假脱机程序、批处理工作器等并不是那么重要，但如果 Web 服务器或数据库服务器瘫痪，情况就会很快变得糟糕。

对于物理设备，始终可以根据主机名推断出确切位置。

物理设备和逻辑服务器之间的弱耦合可能会让一些人望而却步（例如，当我拔掉交换机 x /服务器 y 的插头时，我怎么知道哪些项目会受到影响），但这在我们的环境中是必须的，因为我们的项目周转率很高，而且我们往往不知道哪些项目将托管在我们刚刚配置的新硬件上。

Answer