机房命名的行业习惯考

打开任何一家国际云厂商或机房服务商的节点列表，你大概率会看到三个大写字母：HKG、SIN、NRT、FRA、LAX。这套字母不是发明出来的，是借来的——借自航空业。

IATA（国际航空运输协会）自上世纪中叶起为每个机场分配三字母代码：HKG 是香港国际机场、SIN 是新加坡樟宜、NRT 是东京成田。数据中心行业在需要给「地理位置」一个短标识时，直接沿用了这套已经全球通行的编码——原因很实际：它够短（三个字符进得了任何系统字段）、它无歧义（一个代码一个地点）、而且它对差旅中的运维工程师天然友好。于是「机房代码=所在城市机场代码」成了行业默认习惯，连城市与机场不完全对应的情况也被沿用（东京有 NRT 成田与 HND 羽田两个码，机房圈约定俗成用哪个，各家略有差异——本站测速矩阵的东京节点标 NRT，即成田口径）。

云厂商带来了第二套体系：Region 与 AZ。以 us-east-1a 类的命名为代表——Region（区域）是地理集群，AZ（可用区）是区域内相互独立的机房。字母后缀 a/b/c 刻意不指向具体物理位置，这是设计而非含糊：厂商不希望用户把业务绑死在「某一个具体机房」上，而是绑在「可用区之间的独立性」这个抽象上——你申请两个 AZ 做冗余，至于它们是城市哪两头，交给厂商调度。这套体系的哲学与机场代码相反：机场代码要的是「精确指地」，AZ 命名要的是「故意模糊」。

第三套是分级体系：Uptime Institute 的 Tier I 到 Tier IV，按冗余与可维护性把数据中心分四档——Tier III 的关键词是「可并行维护」（检修任何一路电力或制冷不必整体停机），Tier IV 是「容错级」。常见的误用是把 Tier 当成「豪华程度」的营销词——它本义是工程口径，有明确的判定条目；见到「Tier IV 级机房」的宣传，值得追问一句认证证书编号（通说：认证有正式流程与公开名录）。

三套体系各司其职：机场代码回答「在哪」，Region/AZ 回答「怎么容灾」，Tier 回答「多可靠」。一个测速工具选机场代码命名节点，理由也在这个分工里——测速的用户关心的是「离我的用户有多远」，这是一个纯粹的地理问题；地理问题用地理编码回答，最短的路径就是三个字母。至于容灾与等级，那是选型阶段的问题，选型页会用另一套语言说话。

命名从来不只是名字。三套体系背后是三个行业视角：航空业给了地理、云厂商给了抽象、评级机构给了工程标准——下次看到 HKG 或 us-east-1a，你会知道自己在看哪一层的世界。

写一篇 900 字左右的行业考据小品：数据中心/机房命名的几套体系——IATA 机场代码（HKG/SIN/NRT 类三字母码）为什么成为行业习惯、云厂商的 Region/AZ 命名（us-east-1a 类）逻辑、Uptime Institute Tier I-IV 分级的含义与常见误用。要求：史实部分只写有公开依据的（不确定的写明「通说」），结尾解释一个「测速工具用机场代码命名节点」的产品视角理由。