DNS 通常是隐形的,直到产品发布当天。届时,一条过期记录就可能让运行正常的应用在半个世界范围内看起来像是宕机了。
计划变更前降低 TTL
在迁移之前提前降低相关记录的 TTL。已经缓存的答案仍会存活到旧 TTL 到期,因此在发布前五分钟修改并没有太大帮助。
分层排查问题
按以下顺序检查:
- 主机名是否解析到预期的边缘节点?
- 边缘节点是否能够到达源站?
- TLS 证书是否覆盖准确的主机名?
- 应用是否正确识别转发后的主机名和协议?
这样的顺序可以避免应用层调试掩盖 DNS 或证书问题。
保存回滚记录
修改前记录原来的值。只有在旧目标、代理状态、TTL 和证书假设都清楚时,DNS 回滚才真正简单。
小而稳定的运维习惯胜过发布当天的临时救火。让每一层都可观察,一次只修改一层,并让回滚保持简单。