大促前做DNS切换与CDN调度演练，核心是先用最小成本验证“切得动、切得回、切得对”，再按业务影响面从小到大分阶段推进，最终形成一份带时间戳和责任人签字的切换预案。很多团队把演练当形式，真到618、双11那天才发现解析卡在TTL、CDN命中率上不去、回源链路被压爆，这篇文章把整个演练拆成可落地的步骤，包括怎么设计场景、怎么观察指标、怎么回滚,以及如何用日志反推问题。
大促前DNS切换演练步骤：先搞清楚你要验证什么
DNS切换的本质是修改解析记录，让流量从旧节点走到新节点，但“修改”这个动作本身不是风险，风险在于你根本不知道修改后要多久才能生效，以及生效过程中有没有流量被带到错误的地方。
第一步：梳理当前解析拓扑和TTL现状
登录云解析控制台，把所有域名和子域名的记录类型、TTL值、解析线路、CNAME指向列一张表，重点关注不同运营商和地区线路的差异化解析，比如电信、联通、移动各自的TTL是否一致,有没有配置地域线路指向不同源站。
实际操作中你会发现，很多历史记录是从别的平台迁移过来的，TTL还保留着默认的600秒甚至3600秒，这直接决定演练时流量切换的生效速度，行业共识认为，大促前应该把核心域名的TTL临时调低到60秒或120秒，演练完再恢复，这个动作必须提前三天做，因为TTL调低本身也需要时间在各级Local DNS缓存中失效。
第二步：设计切换场景，别只做“成功路径”
典型的失败案例是：演练只测了把域名从A源站切到B源站，一切正常就结束了，但真实大促中，你会遇到的是源站机房出口带宽打满、CDN节点被刷、某些省份解析异常这些叠加情况。
建议至少准备四个场景：
- 单域名解析切换到备用IP，验证全链路联通性
- 主域名切换CNAME到CDN新域名，验证CDN接管速度
- 按比例切流量（比如先切10%的省份），验证灰度效果
- 模拟DNS服务商故障，把全部解析记录迁移到备用服务商
每个场景都要写清楚前置条件、操作人、操作命令、预期观察项、回滚触发条件，没有回滚方案的演练,等于把大促当天可能发生的故障提前演练了一遍。
演练过程中的关键观察指标
- 各运营商Local DNS递归解析到的新IP是否和预期一致
- 新节点收到的HTTP状态码分布，有没有大量502、503
- 源站回源流量曲线与切换时间点的吻合度
- 客户端实际感知的解析时延变化（用dig +trace验证）
这里有个容易忽略的细节：不要用你自己电脑的DNS解析结果判断切换是否成功，因为你的Local DNS缓存可能还在旧IP上，正确做法是在多台不同运营商的机器上，用
dig @指定的公共DNS（如223.5.5.5、119.29.29.29）来查询,强制绕过本地缓存。
CDN调度演练怎么做：从预热到压测的完整闭环
CDN调度演练比DNS切换更贴近业务，因为CDN层面出问题，用户看到的直接是白屏或图片加载失败，很多人把CDN调度想简单了，以为调个权重、改个回源地址就行，实际上大促前要做的是验证CDN调度策略在真实流量冲击下的表现。
先做节点预热，再做调度切换，顺序不能反
如果直接切换调度，让CDN节点从源站拉取冷资源，大促首次请求的响应时间会飙升到两三秒甚至更长，还会把源站带宽打满,正确顺序是：
- 在目标CDN平台上，上传URL和目录列表，提交预预热任务
- 检查每个节点的命中率（有些平台的命中率统计有延迟,要等十分钟再看）
- 确认预热的资源确实缓存，而不是只在源站准备好了清单
- 然后才允许调度策略把流量导入新节点
要知道，CDN调度的核心是边缘节点选择，你在控制台设置的调度规则，比如按地理位置、按运营商、按权重分配，实际生效与节点容量、故障摘除状态都有关系，演练时建议在非核心时段（凌晨两点到四点）进行,用真实用户请求做小流量灰度。
用日志和性能数据反推调度效果
切换完成后，不要只盯着CDN控制台的“流量带宽”曲线。打开源站访问日志和CDN节点访问日志，按省份、运营商、ISP维度对比,具体操作：
- 从源站日志中提取响应时间超1秒的请求，看这些请求分散在哪些边缘节点
- 从CDN日志中提取节点状态码，统计4xx、5xx占比变化
- 对比切换前后同一条URL的平均首字节时间（TTFB）
如果切换后某个省份的TTFB从50ms涨到800ms，很可能是调度策略把该省份流量导到了偏远节点，这时候要回滚调度策略,把该省份指向回原节点。
演练中必须测试的异常场景
大促当天CDN节点也可能出问题，所以演练还要模拟单节点故障下的调度逃生，具体操作是在CDN平台强制下线一个节点，观察其他节点能否自动接管其流量,以及接管过程中有没有出现丢灰率上升。
常见的问题是：忽略回源带宽限制，CDN节点从源站拉数据时，如果多个节点同时回源，源站带宽可能瞬间被打爆，计算一下全量资源回源所需带宽，再对比源站的出口带宽上限，如果回源带宽超过上限的70%,就需要启用分层回源或设置缓存规则。
大促前DNS切换与CDN调度演练的常见坑和排查方法
即使演练方案写得很完整，实操中还是会遇到各种怪问题，下面按问题频次排序,给出对应的排查路径。
TTL已调低但切换后仍大量请求打到旧IP
原因往往不是运营商Local DNS不听话，而是
你的域名在HTTP/3（QUIC）或TLS会话复用层有连接保持，长期在线的应用会复用旧IP的TCP连接，不会立刻发起新的DNS解析，排查方法是在客户端加上强制刷新参数，比如给URL加随机query参数，或者用ipconfig /flushdns配合curl --resolve强制指定新IP来测试接口联通性。
另一个隐蔽原因是某些App内置了HTTPDNS服务，绕过了系统的DNS解析，直接向HTTPDNS服务器查询域名，这种场景下，你只改云解析控制台是没用的，必须去HTTPDNS平台同步更新域名映射关系，大促前演练时把这一项单独列出,作为验证点。
CDN调度后回源URL路径不一致导致缓存命中率低
如果切换前源站的URL带参数（比如?version=123），切换后的CDN平台可能默认忽略参数缓存，也可能默认区分参数，这会导致同一份资源在CDN节点上缓存了多个副本，占用容量还影响命中率，建议在演练中对比切换前后的缓存命中率，如果下降了超过十个百分点，就去CDN控制台调整“过滤参数”设置。
同时检查回源Host头是否正确，不少团队在切换CDN时，把源站地址设置成了另一个bucket或服务器，但回源Host还指向旧源站,导致CDN节点总是拿到404或302重定向循环。
演练时一切正常，大促当天一切换就故障
这是最典型的“假演练”问题,常见原因包括：
- 演练用的流量是测试流量，与真实用户行为（如大量图片、CSS合并请求）差异很大
- 没有验证大促当天的扩展策略，比如自动扩容触发后新机器是否注册到调度系统
- 没有记录并固化每次操作的精确时间点和执行人，大促时大脑一片空白
行业专家指出，检验演练是否成功，不是看“流程走完”，而是看“操作过程中是否发现了至少一个需要修改的问题”，如果演练全程零波澜,反倒要提高警惕。
演练后的复盘清单和预案固化
演练结束后，需要在一小时内产出三份文档，越快越好,因为很多临时修改的细节会很快被遗忘。
第一份：切换操作时间线
按分钟列出操作内容和对应人员，
- 02:00 操作A执行，解析TTL修改为60秒（张三确认）
- 02:05 多地区dig验证解析结果（李四输出截图）
- 02:10 CDN切换权重至30%（王五执行,赵六复核）
这份时间线在大促当天会直接变成操作指导书，没有具体到分钟的操作清单,本质上就是没有预案。
第二份：回滚触发条件和步骤
写清楚什么情况下必须回滚，
- 全站5xx错误率超过5%，持续两分钟
- 核心接口可用性低于99.5%
- 源站带宽持续高于阈值的80%
回滚步骤要精确到按钮名称和API命令，不能写“把解析切回原域名”这种模糊描述，最好在演练中实际触发一次完整的回滚,记录回滚耗时。
第三份：监控大盘和大促当天的盯盘清单
把演练期间发现的关键指标整理成一张表格，包括具体视角和告警阈值,表格字段可以这样设计：
| 指标项 | 数据来源 | 日常阈值 | 大促阈值 | 告警动作 |
|---|---|---|---|---|
| 解析成功时延 | 云解析平台 | <50ms | <80ms | 立即查看Local DNS |
| CDN命中率 | CDN平台 | >90% | >95% | 检查缓存配置 |
| 回源带宽 | 源站出口监控 | <30% | <50% | 启动限流或扩容 |
实际操作中，这张表要比文本文档有用得多，因为它让每个盯盘的人都能快速判断“现在算不算问题”。
大促后DNS切换和CDN调度需要做哪些补充验证
很多人演练完就收工，等到大促结束后再复盘，其实已经晚了，正确做法是在流量回落后的24小时内，再做一轮小范围验证,确认切换回来的过程中没有留下隐患。
- 检查回切后旧节点是否残留了未刷新的缓存，如果旧CDN节点还没摘除，需要主动清除全站缓存
- 检查各Local DNS的解析记录是否已经从新IP回到原IP，方法是用全国拨测工具跑一遍
- 检查HTTPDNS平台上的记录是否已经回滚，避免App用户仍然指向新IP而新IP已被回收
这一步容易被人忽略,但它决定了你下一次大促是否还能继续用这套方案。
常见问题解答
Q：大促前DNS切换演练一般需要提前多久做？
建议提前三到四周完成第一次全流程演练，提前一周做一次带真实流量的复演，如果中间改动过配置或更换过云服务商，必须重新演练一遍，不能直接复用旧文档，真实大促当天只做“按时间线执行”,不做任何临时决策。
Q：DNS切换和CDN调度可以放在同一天演练吗？
可以，但顺序有讲究，先做CDN调度演练，因为CDN层面的调度只影响边缘节点选择，不会影响解析可达性；等CDN验证通过后，再做DNS切换，因为DNS一旦切错，所有流量都会断掉，演练时间间隔最好超过四小时，给足数据观察窗口，多数情况下，这两个演练放在不同天完成更稳妥,方便单独复盘。
Q：手动测试看不出问题，大促时能否依赖拨测工具自动切换？
拨测工具只能做辅助判断，不能作为唯一依据，因为大促时的流量特征和拨测点分布差异很大，拨测结果正常不代表边缘节点调度合理，更可靠的做法是结合拨测工具和源站日志，让拨测工具在检测到连续多个省份解析异常时，自动发工单给运维人员，由人决策是否触发切换预案，自动化切换建议只在小流量域名上开启,核心域名保留人工确认环节。