2021 年 6 月我接手内网解析，导出的记录一共五百一十二条，对应三百八十台机器。其中一条是 2014 年建的，指向一台早就报废的物理机。

这些记录背后是五种命名习惯：有人用 web01，有人用 Web-02，有人用 app_03，有人直接拿业务名加序号，还有人用拼音缩写。查一个问题，经常要先在三个地方确认同一台机器叫什么。

下面写我们怎么用三个月把这件事理出头绪，包括改解析时踩的两个坑。

## 一、命名乱到什么程度

### 1.1 五种风格并存

五百一十二条记录里，纯数字后缀的二百一十条，带环境后缀的一百四十条，拼音缩写六十八条，剩下的是历史遗留，看不出规律。

更麻烦的是同一台机器有两个名字。业务系统里写的是 order-db，运维脚本里写的是 db-order-01，两边指的是一台机器。这种情况有三十多组，没人说得清哪一个是"官方"名字。

### 1.2 两次误判

头一回是查一个接口超时。日志里出现 app-03，我按名字找到一台机器，登录上去看负载正常。折腾四十分钟后发现，报错的是另一台也叫 app03 的机器，属于另一个系统。

第二回是扩容。同事按清单申请了两台新机器，起名 web04、web05。上线后流量没涨，查了半天发现负载均衡里配的是 web-04 和 web-05，带横杠，两条新记录压根没被引用。这两件事都不难，但每次都吃掉半个下午。

### 1.3 为什么不能一次全改

起初的想法是重新规划一套名字，一次性全量替换。算了算影响面就放弃了：三百八十台机器，涉及配置中心、监控、证书、防火墙策略、定时任务里的硬编码。

改名的成本不在改记录，在改引用。一条记录改名，要找出所有引用它的地方，而引用可能写死在某个 2016 年的脚本里。所以我们换了思路：新名字先建，旧名字保留，逐步迁移引用，等引用清零再删旧的。

## 二、先定规则再动记录

### 2.1 四段式命名

定下来的格式是"区域-角色-序号.环境"，四段都有明确取值范围。区域是机房或可用区的代号，角色从八个值里选，序号两位补零，环境只有生产、预发、测试三个值。

举例，生产环境某个区域的第三台应用服务器叫 app-03.prod，前面带上区域代号就是完整名字。名字里不放业务名，业务归属放在资产系统里，因为业务会改名，机器名不该跟着改。

### 2.2 谁管哪一段

四段里，区域和序号由运维分配，角色由申请的人选，环境由部署流水线自动带。分开管的好处是没人能随手起一个名字。

分配动作走一个简单的申请流程：填用途、选角色、选环境，系统按区域和角色算出下一个可用序号，返回名字。这个过程不需要审批，但每一条分配都留了记录，事后能查到谁在什么时候申请了什么。

序号回收也要定规矩。机器下线之后，名字冻结九十天再释放，避免刚删掉的名字被新机器占用，日志里出现前后两段含义不同的同名记录。这条规矩是踩过一次坑才加的，当时一个旧名字被复用，查日志查了半小时才反应过来是两台不同的机器。

### 2.3 例外清单要写下来

有二十多台机器不能按规则改：三台老数据库的主机名被写进了授权文件，改了要重新申请授权；十几台设备的名字被硬件厂商的监控系统采集，改名会断采集；还有几台是客户侧配置里写死的。

这些进了一张例外清单，写清原因、责任人、复核时间。例外不可怕，可怕的是例外散在大家脑子里，新人不知道，改了之后出事。清单每季度过一遍，去年清掉了六条，因为对应的系统下线了。

## 三、改解析的顺序

### 3.1 TTL 先降下来

改解析之前，先把所有记录的 TTL 从一小时降到六十秒。这一步花了两周，因为要观察缓存命中的变化，确认解析服务的负载扛得住。

TTL 降下来之后，改错一条记录的影响时间从一小时缩到一分钟。这个动作没有技术含量，但它是后面所有操作的前提。没有它，每次改完都要等一小时才知道对不对。

### 3.2 新旧名字并存

每条记录改名，我们都先加新记录、保留旧记录，观察两周。观察期内两边指向同一个地址，谁用哪个名字都能通。

两周后查解析日志，看旧名字还有没有查询量。没有就删，有就去找那个还在用的客户端。这个办法慢，但没造成过一次中断。三个月里改了三百四十条，只有两条因为客户端写死需要单独处理。

### 3.3 CNAME 的层级别套太深

整理时发现有一批 CNAME 套了三层：业务名指向中间名，中间名指向机器名，机器名才是 A 记录。套一层是为了解耦，套三层就是排障障碍。

我们定的规矩是 CNAME 只能指向 A 记录，不允许 CNAME 指向 CNAME。已有的链路逐条拉平，把中间层删掉。这条规矩后来救过一次：某个中间名被误删，如果链路是平的，影响一台机器；套了三层，影响一片。

## 四、记录整理脚本

### 4.1 先归一，再比对

脚本做三件事。按规则把每条老记录算出一个新名字，把算出同一个新名字的记录分到一组，同组里指向不同地址的标成冲突。

归一的过程不猜。名字里认不出角色的，标成 unknown，交给人判断，不让脚本自己编一个。三百八十台里，有一百一十台落在 unknown，这部分是人工过的。

### 4.2 冲突比改名更值得看

五百一十二条算出四百七十个新名字，其中十九组冲突。冲突分两种：一种是一个名字对应多个地址，说明有人手工加过记录；另一种是多个名字对应一个地址，说明同一台机器被起了多个名。

十九组里，七组是真问题，十二组是老记录没删。真问题那七组，改完之后顺手清掉了四条防火墙规则，因为原来为了绕开命名混乱，开了不必要的放行。

### 4.3 三张表怎么用

脚本输出三张表：改名对照表、冲突表、无法识别表。三张表导出来之后，我没有直接改解析，而是放到搭贝的表单里让各系统负责人逐条认领，认领一条改一条。

```python
import csv
import re
import sys
from collections import defaultdict

ROLE = {"web": "web", "app": "app", "db": "db", "cache": "cache",
        "mq": "mq", "gw": "gw", "job": "job", "log": "log"}
ENV = {"p": "prod", "prod": "prod", "t": "test", "test": "test",
       "s": "stage", "stage": "stage"}

def normalize(name):
    s = re.sub(r"-{2,}", "-", name.strip().lower().replace("_", "-"))
    parts = [p for p in s.split("-") if p]
    env = "prod"
    if parts and parts[-1] in ENV:
        env = ENV[parts[-1]]
        parts = parts[:-1]
    role = next((ROLE[p] for p in parts if p in ROLE), "unknown")
    seq = next((p.zfill(2) for p in parts if p.isdigit()), "00")
    zone = parts[0] if parts and parts[0] not in ROLE else "default"
    return "%s-%s-%s.%s" % (zone, role, seq, env)

rows = list(csv.DictReader(open(sys.argv[1], encoding="utf-8")))
groups = defaultdict(list)
for r in rows:
    groups[normalize(r["name"])].append(r)

rename, conflict, unknown = [], [], []
for new_name, items in sorted(groups.items()):
    targets = {(i["type"], i["value"]) for i in items}
    if len(targets) > 1:
        conflict.append([new_name, len(targets), "|".join(i["name"] for i in items)])
    for i in items:
        if new_name.split("-")[2].startswith("00") and "unknown" in new_name:
            unknown.append([i["name"], i["value"]])
        elif i["name"] != new_name:
            rename.append([i["name"], new_name, i["type"], i["value"]])

for fn, header, data in (
    ("rename.csv", ["old_name", "new_name", "type", "value"], rename),
    ("conflict.csv", ["new_name", "target_count", "sources"], conflict),
    ("unknown.csv", ["name", "value"], unknown),
):
    with open(fn, "w", newline="", encoding="utf-8") as f:
        w = csv.writer(f)
        w.writerow(header)
        w.writerows(data)

print("记录 %d 条，改名 %d 条，冲突 %d 组，待人工 %d 条"
      % (len(rows), len(rename), len(conflict), len(unknown)))
```

脚本跑一遍几十秒，比人工翻表格快得多。它不负责改解析，只负责把"哪些要改、哪些要人看"列清楚。

## 五、三个月之后

### 5.1 排障从找 IP 变成说名字

以前排查一个问题，先在监控里找到出问题的实例，拿到 IP，再去资产表里查这台机器叫什么、属于谁。现在反过来：告警里直接带机器名，名字里有角色和环境，看一眼就知道该找谁。

有个具体的数字：定位到责任系统的时间，从平均十二分钟降到三分钟。省下来的不是技术能力，是查表的时间。人在着急的时候翻错表，才是这类事故里常见的浪费。

### 5.2 证书和记录对齐

整理过程中发现九张证书的域名和实际使用的名字对不上，其中两张两个月后到期，续签时如果按旧名字申请会签错。这件事顺手做了，避免了一次可能的线上中断。

后来把证书清单和解析记录做了一次比对，写进季度检查项。两个清单任何一边变更，都要在另一边确认。

### 5.3 还剩二十条没改

二十条例外还在，分布在三个老系统上。今年计划跟着老系统下线一起清掉，不再单独折腾。

这件事让我明白一个道理：整理命名不是为了好看，是为了让排障的路径短一点。规则可以有不完美的地方，但必须只有一套，且写下来。

## 常见问题

**问：机器不多，也需要统一的命名规则吗？**

答：二十台以上就值得。规则可以很简单，比如"角色加两位序号"，关键是所有人都按同一套来。人少的时候靠记忆能撑住，但记忆不写下来，换一个人就断了。

**问：改名会不会影响正在跑的业务？**

答：会，所以不能直接改。做法是先加新记录、保留旧记录，观察解析日志确认旧名字没有查询量，再删旧的。TTL 提前降下来，出错的影响窗口就短。真正危险的是硬编码在配置里的名字，这类要先扫一遍配置文件。

**问：CNAME 套多层的坏处是什么？**

答：排障时链路变长，一个名字要查三层才知道指向哪台机器；变更时影响面放大，中间层被误删会带走一片。建议 CNAME 只指向 A 记录，层级控制在一层，解耦的需求用配置中心解决，不要用解析链路解决。

**问：老设备不支持改主机名怎么办？**

答：给它加一个别名记录，指向同一地址，业务侧用新名字访问，设备自己叫什么不用动。别名不改变设备配置，只改变访问入口，风险低。这类记录单独进例外清单，标清原因和复核时间。

2021 年 6 月我接手内网解析，导出的记录一共五百一十二条，对应三百八十台机器。其中一条是 2014 年建的，指向一台早就报废的物理机。

内网域名整理：命名统一之后好排障

内网 DNS 域名多套命名规则并存，主机别名冲突、硬编码引用频繁引发排障误判。我们制定四段式主机命名规范，采用先新增别名、逐步迁移、冻结旧名的平稳方案，配合脚本自动梳理冲突，三个月完成域名治理，大幅缩短故障定位时长。

人工智能

三个月整改五百条DNS记录，从五种命名乱象到统一四段式规则。新名先建旧名保留，TTL降至六十秒防误改，两周观察期零中断迁移三百四十条。CNAME限指向A记录，脚本归一化识别十九组冲突，排障定位从十二分钟缩至三分钟，同步修正九张证书错配。

负载均衡

代码解释

数据库

服务器

防火墙

DNS解析新购特惠59元起，续费优惠低至5.3折！

让每一个 Agent，都跑在云上

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

内网域名整理：命名统一之后好排障-腾讯云开发者社区-腾讯云

内网域名整理：命名统一之后好排障

内网域名整理：命名统一之后好排障

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐