换机房不是搬完再切：割接批次、追平窗口和回滚点要怎么排

迁移方案文档翻到第三页，只有一行字：「周六 22:00 开始切换。」往下翻，没有第二步。谁在几点把写入停下、最后一次增量同步要跑多久、跑到一半报错是重试还是回退、回退要退到哪一版数据、什么信号出现才敢在群里说一句「成功了」——全都没写。现场坐着三个人，每个人心里都有一套顺序，谁也没说出口。凌晨一点，应用已经连上新库，附件还在往旧存储里落，两边对不上账，这时候没有人能回答该往前走还是往回走。

事后复盘时，这类事故通常被归结为「停机时长估短了」。但真正让那一夜失控的不是时长，是顺序：没人提前标出第几步之后不能再回头，也没人算过最后一次追平需要多久。这两个数字不落到纸面上，方案里那个开始时间写得再精确也没有约束力。割接排期真正要定下来的，是两个时间点而不是一个——追平窗口的边界在哪里，不可回退的起点在哪里。

一份只写了开始时间的割接方案，缺的是哪两段

一份割接方案里出现频率最高的字是时间：几点开始、几点结束、几点通知业务方。但时间本身不产生约束力，约束力来自「在这个时间点之前必须完成什么」。只写了开始时间的方案，本质上是把排期的责任推给了现场——谁先动手，谁就在定顺序，而定顺序这件事恰好最不该在疲劳和压力下完成。

缺的第一段是追平窗口。业务从旧环境迁到新环境，数据不可能在同一瞬间两边一致。全量搬迁结束之后，源侧仍在不间断地产生新数据，这些增量必须被追上。追平窗口指的是：从停止写入的那一刻起，到新侧数据追齐并可以对外服务为止，中间需要多长时间。这个数字不由方案决定，它由你的数据量、单位时间新增量、跨机房链路条件和同步方式共同决定，只能靠演练测出来。

缺的第二段是不可回退区间。割接不是一条匀速的直线，中间存在一个点，跨过去之后回退的性质就变了：在那之前，回退只是把流量指回旧侧；在那之后，回退意味着要人工合并数据，或者承认已经丢了数据。这个点通常出现在新环境第一次接受真实写入的时刻。方案里不把它标出来，现场就会在「继续还是回退」之间反复犹豫，而犹豫本身就在持续放大窗口。

这两段是连在一起的：追平窗口是风险的入口，不可回退点是风险的出口。排期要做的，是先找到出口，再倒推入口，最后才去填那个开始时间。顺序一旦反过来，方案里写得再细的分钟数也只是装饰——它描述的是期望，不是路径。

迁移对象先拆成三类：应用、数据源、文件与附件

排期之前要先做一次对象清点。迁移里几乎所有麻烦都可以归到三类东西上：应用、数据源、文件与附件。这三类的失败方式不同、追平方式不同、回退代价也不同，混在一起排必然出错。很多方案的第一个漏洞就出在这里——清单是按服务器列的，不是按对象列的。

应用这一层相对好办，尤其是无状态部分：它可以两套并存，切流只是改一个指向。真正的难点不在程序包，而在程序包之外——配置项里写死的地址、依赖服务的地址与账号、密钥与证书、定时任务、灰度开关，还有那些「只在某台机器上跑过、没人记得怎么配」的脚本。这些不列出来，切过去才会发现新环境缺了一半依赖。

数据源这一层是追平的主战场。它的特殊之处在于「一直有新数据产生」，所以必须拆成全量与增量两段来处理。除了记录本身，还要清点随库一起走的附属对象：视图、存储过程、触发器、库内的定时作业、账号与权限、字符集与排序规则、时区设置、自增序列的当前值。这些对象最常被漏掉，直到业务反馈「某个功能点了没反应」才被发现。

文件与附件这一层最容易被低估。它的数据量通常最大、小文件最多、也最少被校验。它有两个独特难点：一是引用关系——库里存的路径指向文件，两边必须一起对得上；二是迁移期间用户仍在上传，新产生的文件只存在于旧侧。从回退代价看，文件层比应用层高：反向同步大量小文件的耗时，往往远超团队预期。

列一张对象清单，每一行写清四件事：数据量、单位时间新增量、是否被外部引用、责任人。这张表不是文档装饰，它是后面估算追平窗口的唯一输入。缺少任何一栏，后面的窗口估算就只能靠感觉。

批次怎么划：按业务模块、按租户，还是按数据量

批次怎么划，决定了每一刀切下去的影响面有多大。常见的划法有三种：按业务模块、按租户、按数据量。三者不是互斥选项，但主次关系要清楚。

按业务模块划，边界最清晰，出问题时的波及范围可控，也便于安排多个独立的割接窗口。代价是需要多次割接，且耦合紧密的模块必须打包一起走。判断依据是看它们是否共用同一套存储、同一份缓存或同一个定时任务——只要共用，就应当视作同一个批次。

按租户划，适合多租户系统，可以先迁一小批租户做灰度。代价是共享部分难切：如果所有租户落在同一个库里，按租户切就要在应用层引入路由逻辑；跨租户的统计与查询也会在灰度期内给出不完整的结果，这一点必须提前和业务方讲清，否则很容易被当成故障上报。

按数据量划，通常只能作为前两种的补充手段。它只在「数据本身可分片且业务对分片无感知」时成立，比如按时间归档的历史数据。用它来划分主业务的批次，往往会切出业务上无法解释的中间态——用户看到一半订单、一半没看到。

一条实用的判断线是：批次边界尽量画在调用最少、共享最少的地方。先把必须捆绑的项目标出来——共享库、共享缓存、共享文件目录、只能单点运行的定时任务、外部回调入口——这些要么一起走，要么就得为它们单独设计过渡方案，不能靠"到时候再说"。

批次顺序上，先迁无状态、再迁只读、最后迁写入；先迁内部系统、后迁对外服务。第一批处理一个即使失败也不影响营收的模块，用它把流程跑通、把数字测出来。每批之间留出观察期，不要连着两晚连切两批——上一批的教训来不及进下一批的方案，那等于没排批次。

双跑期不是为了省事，而是为了给自己留回退空间

双跑期指的是新旧两套环境同时在线：旧侧继续承担写入，新侧通过同步持续跟随增量，并逐步承接一部分或全部读流量。很多团队把它理解成"保险措施"，其实它的核心作用是改变追平这件事的性质。

没有双跑期时，追平是一次性动作——你必须在割接当晚，把从全量搬迁完成那一刻起累积的所有增量一次性追完。有了双跑期，增量变成持续跟随，最后一轮要追的只是停写前那一小段尾量。前者的工作量随搬迁进度线性增长，后者基本恒定。这是双跑期最大的价值，也是它值得投入的原因。

第二个作用是暴露问题。全量搬迁只验证了"数据能搬过去"，双跑期才能验证"新环境能不能真的扛住"。同步延迟会不会持续拉大、新侧的慢操作会不会堆积、连接池会不会打满、缓存预热需要多久、后台任务在新环境下会不会重复执行——这些只有在真实或接近真实的负载下才看得出来。

第三个作用才是回退。只要旧侧仍在正常写入，流量切回去的代价就很低；一旦旧侧停了同步或者被改成只读，回退就从"切一下"变成"补数据"。所以，双跑期的长度本质上等于你给自己留的回退余量长度。

双跑期也有代价，要提前算清：两套资源的占用、写入侧的链路开销、两侧同时写同一条记录时的冲突。最省事的处理办法是写入只走一侧，另一侧保持只读跟随。如果业务形态决定了必须双写，就得先定好冲突规则——以哪一侧为准、如何检测冲突、冲突后如何补偿、由谁执行补偿。

双跑期的结束条件不是"时间到了"，而是一个判断成立：最后一轮追平能在业务可接受的窗口内完成，且这个判断有演练数据支撑。如果只是因为"当初定了两周就跑两周"，那双跑期就只剩成本，没有收益。

追平窗口怎么估：增量速率、最后一轮同步与重试余量

追平窗口指的是从停止写入到新侧数据可用之间的那段时间。它是整个方案里最该被精确估量的数字，因为它直接等于业务被暂停的时长。

估算需要三个输入：单位时间内新增的数据量、跨机房链路的实际可用吞吐、同步过程本身的处理速率。最终窗口取三者中的瓶颈，而不是取平均值。这里要特别提醒：增量速率应当按割接时段的历史峰值来取，而不是按全天平均——业务高峰与低谷之间往往差好几倍，用平均值估出来的窗口，在周五晚上一定不够用。

容易被忽略的是积压。如果双跑期的同步一直追不上，最后一轮要追的就不是"停写前那一点"，而是整个双跑期攒下的全部积压。所以在停写之前，必须先确认待追平积压已经降到低位，并且把这一条写成明确的判断项，而不是"看着差不多"。

重试余量必须单独列出来。只排一轮同步的方案，等于把"第一次失败"和"整体回退"直接连在了一起。合理的做法是至少预留一轮完整重试的时间，并在方案里写清：第一轮失败之后是重试还是回退、由谁判断、判断依据是什么。

怎么测：在双跑期里做一次"模拟停写"演练——按真实步骤停掉写入、跑完整一轮追平、记录时长、然后放开。多测几次，取最差的那一次，而不是取平均。演练环境与生产的数据量级差距越大，这个数字的可信度越低，所以尽量使用同量级的副本，而不是一份随手导出的小样本。

所有窗口长度、同步速率与校验方式，都必须以你自己的数据量、网络条件与实际演练结果为准。本文不提供任何时长承诺或性能数值，也不给出可以直接套用的经验值——这类数字换个环境就失效，照抄比不估更危险。

追平窗口在排期里的作用是决定"最早可以几点开始"，而不是反过来。如果估算结果超过业务能接受的暂停时长，只有三条路：提前降低增量（预热缓存、暂停非必要的写入型任务）、把批次切得更小、或者延长双跑期以换取更小的尾量。想靠"优化一下同步"把窗口压下去，通常做不到。

一致性校验：比什么、什么时候比、比不出来时怎么办

校验的作用是回答一个问题：新侧这份数据能不能用来对外服务。它至少要做三次：全量搬迁之后比一次，双跑期里定期比，最后一轮追平之后比一次。三次的目的不同，比的粗细也不同——第一次求全，第二次求快，第三次求准。

比什么，建议覆盖这几类：分片的记录数（不要只比一个总数，总数可能在两处错误相互抵消之后仍然相等）、主键集合的差集、抽样记录的逐字段比对、分片摘要值、自增序列的当前值、文件数量与总大小、以及文件路径与库里记录之间的对应关系。最后一项最常被漏掉，也是最容易出现「库搬完了、附件打不开」的地方。

抽样要有策略。随机抽样能覆盖总体，但抓不到边界问题，所以要额外加上定向抽样：最近写入的记录、最大与最小主键附近的记录、状态字段异常的记录、以及业务方点名的几张关键表。定向抽样发现问题的效率，通常比随机抽样高得多。

更关键的是「比不出来时怎么办」。这是方案里最常被跳过的分支，也是现场最容易卡住的地方。要提前定义：什么情况算校验无法完成（超时、源侧不可读、比对任务中途失败、结果超出可解释范围），以及每种情况下的动作——延长窗口继续比、中止并回退、还是降级为只对关键表校验后带风险推进。这三个选项必须提前有人拍板，不能留到凌晨现场讨论。

差异不等于失败。发现差异之后的第一步是分类：属于同步延迟范围内的时间差、真实的记录丢失、还是字符集、时区、排序规则或精度导致的表象差异。第一类可以等，第二类要立即止损，第三类要修正比对方法而不是修正数据。分错类会导致两种极端：误回退，或者带着真问题宣布成功。

两个实操提醒。一是校验结果要落盘保存，它既是宣布成功的依据，也是回退之后对账的依据。二是校验本身消耗资源，不要在最后一轮追平的同时跑全量校验，两者会互相拖慢，把窗口越拉越长。

切换窗口里的动作顺序：停写、追平、校验、切流、观察

切换窗口里的动作有固定顺序：停写、追平、校验、切流、观察。这个顺序不能颠倒，每一步都要有前置条件和出口条件。下面这张矩阵把六个阶段的目标、可回退边界、主要风险和需要你自己确认的部分列在一起，可以直接作为方案评审时的对照清单。

停写不等于关服务。它指的是让写入侧停止产生新数据，同时读仍可继续。最常漏掉的写入入口有五类：主业务写入、后台管理端、定时任务与批处理、第三方回调与消息消费、日志与埋点上报。前两类大家都会管，后面三类是「边追边有新数据」的主要来源。停写之后要立刻验证源侧是否真的不再有新增，而不是假设它已经停了。

追平：确认源侧无新增之后再跑最后一轮。完成的判定依据是同步延迟指标归零，而不是同步进程退出——进程退出只代表它跑完了它认为该跑的，不代表它跑全了。

校验：在窗口里只比关键项，把比对范围控制在能跑完的程度。全量比对放到观察期去做，那时系统压力小得多，也不占用窗口。

切流：先切读，再切写，或者按批次逐个切。切流之前先确认新侧的连接配置、地址、密钥、权限都已就位，并且已经在双跑期被真实流量验证过——切流那一瞬间才第一次连上的配置，出问题概率很高。

观察：切流之后的第一件事不是下线旧环境，而是确认没有残留流量还在往旧侧写。旧侧的访问日志与连接数，是这个阶段最有价值的信号。

最后，每一步都要写清「这一步失败了往哪走」。没有出口条件的步骤，等于把决策推迟到现场，而现场是最不适合做决策的地方。

地址与解析变更：缓存、长连接与客户端侧的影响

切流在很多方案里被简化成「改一条解析记录」。实际上地址变更的影响面比这大得多，而且大部分影响不在你能直接控制的地方。

解析缓存是第一层。记录的生存时间决定了变更的收敛速度，所以要把它在切换之前就调低。注意时间点：调低本身需要等待原有缓存过期后才生效，临时抱佛脚没用。切换完成并且确认收敛之后，再考虑调回去。

但只盯权威解析远远不够。操作系统层面、容器运行时、应用进程、客户端开发包、中间代理与缓存服务，都可能各自持有一份旧地址，而且各自的过期策略互不相干。这些地方的缓存，不会因为你改了权威记录而立即失效。

长连接是第二层。已经建立的连接不会因为解析变更而自动断开，持有旧连接的客户端还会继续往旧环境读写。所以切换之后，旧侧连接数应当呈现持续下降的趋势；如果不降反稳，说明有一批连接被遗漏了，需要主动处理，而不是等它自然退出。

客户端侧是第三层，也是最容易失控的一层。移动应用里写死的地址、开发包内的缓存、自建的白名单、证书与地址之间的绑定关系，还有那些装在客户那里、你无法强制升级的程序。这一层的收敛速度不由你决定，只能靠提前通知和延长旧环境保留时间来兜底。

对外依赖是第四层。第三方回调的目标地址、合作方一侧的地址白名单、回调验签的配置、报备过的出口地址——这些改起来往往要走对方的流程，耗时不可控，必须提前排期，不能算在切换窗口里。

实操建议是：切换之前枚举一遍「地址出现在哪些地方」，而不只是打开域名解析面板看一眼。切换之后的收敛判断，以旧侧的残留访问量与连接数降到你自己设定的阈值并且保持一段时间为准，不要以「感觉差不多了」为准。

回滚点要写成「到这一步之前可以回」，而不是「随时可回」

「本方案支持随时回退」是割接文档里最危险的一句话。它把一件有明确边界的事，说成了无条件的事。

回退的可行性随步骤推进而单调下降。最开始，任何一步失败都可以推倒重来，代价只是时间；到了中段，回退需要清理新侧已经产生的东西；跨过某个点之后，回退的性质就变了——从「切回去」变成「补数据」。

那个转折点通常出现在新环境第一次接受真实写入的瞬间。在此之前，旧侧是完整数据的唯一持有方，回退只是把流量指回去；在此之后，新侧产生了只属于自己的增量，旧侧不再完整，此时回退要么丢掉这部分数据，要么靠人工合并，而人工合并本身又是一个高风险动作。

次级转折点还有几个：旧环境停止接收同步的那一刻、旧环境被改为只读的那一刻、旧环境资源被释放的那一刻。每一个都让回退变难一档，而且它们常常在无意识中发生——某个人"顺手"把同步任务停了，回退窗口就悄悄关上了，等到需要回退时才发现旧侧已经落后了很久。

正确的写法是把回滚点写成条件句：「在完成 X 之前，可以通过执行 Y 回退到状态 Z，代价是……」。X 要具体到动作，Y 要具体到命令或脚本，Z 要具体到数据版本或时点。这样写还有一个附加好处：它强迫你去想代价是什么，而「随时可回」这句话恰恰回避了这个问题。

每个回滚点还应包含四项内容：触发条件（哪个指标越界、哪个步骤失败）、执行人、回退后的状态描述、回退后是否需要补做对账。缺了最后一项，回退成功之后业务数据处于什么状态，没人说得清。

还有一点必须写清：回退之后旧侧能否立刻接管。如果旧侧在双跑期已经落后于新侧，或者旧侧的某些服务已经被停掉，那么"回退"只是第一步，后面还有一段补数据、拉起服务的时间。这段也要算进方案的代价里，否则回退的实际耗时会远超预期。

最后，回滚点应当被真实演练过至少一次，而不是只存在于文档里。演练过它的人，和没演练过的人，凌晨三点坐在键盘前的表现完全不同。

把不可回退的那一段压到最短的几种做法

不可回退区间不可能被消灭——旧资源总要释放，总要有个终点。能做的是把它压到最短，并且让它的起点尽量靠后。

第一种做法是把可逆动作尽量前置。全量搬迁、读流量切换、配置与密钥同步、新侧地址预配置、权限与监控就位，这些都可以安排在割接日之前完成。把不可逆动作尽量后置：旧环境释放、旧数据清理、账号与权限回收、旧侧资源退租。很多团队的问题恰恰是反过来排的——先把旧环境腾出来，再慢慢验证新环境。

第二种做法是推迟「新侧首次写入」这个时点。在校验与首轮观察通过之前，让新侧保持只读跟随状态。只要新侧没写过，回退就始终是干净的。

第三种做法是给新侧写入留一条可导出的通道。即便真的要回退，也能把这段独占增量取出来补回旧侧。这条通道要提前建好并测试过，事到临头再想通常来不及。

第四种做法是保留旧环境的只读副本，而不是立即释放。把「不可回退」的起点从资源释放那一刻，推迟到归档副本删除那一刻。多留一段时间的成本，通常远小于一次无法回退的代价。

第五种做法是把大动作拆成小批次。每一批的不可回退段都更短，即便某一批出问题，损失也只限于该批，不会牵连整体。

第六种做法是明确「谁有权宣布进入不可逆阶段」。这个人应当不参与执行，专门负责判断，避免执行者在疲劳状态下边做边决定。同时，这个决定要有明确的依据清单，而不是「感觉没问题」。

需要说明：缩短不可回退段几乎总是有代价的——要么延长双跑期，要么多占一套资源，要么推迟资源释放带来的成本结清。这笔账要在方案评审阶段就和业务方讲清楚，不要等账单出来再解释。业务方那句"停机越短越好"，只有在你把代价摆出来之后，才会变成一个有取舍的真实约束。

观察清单与判定标准：什么信号出现才算可以宣布成功

宣布成功需要一个条件，而不是一种感觉。「页面能打开」「群里没人报错」都不是条件——前者只验证了最浅的一层，后者可能只是因为还没到业务高峰。

观察要分层。基础设施层看资源水位、连接数、错误日志的产生速率；数据层看同步延迟、写入成功率、主键冲突与重复、慢操作数量；应用层看接口成功率与延迟分位、队列积压、定时任务的执行结果；业务层看关键路径能否完整走通、对账类任务是否产出一致结果。四层都要有人盯，且盯的人不做操作。

判定标准写成「阈值加持续时长」的形式。比如某项指标在连续若干个统计周期内保持在阈值内，才算通过。只写阈值不写时长，容易被一个瞬时正常值骗过去；只写时长不写阈值，等于没有标准。具体阈值以你自己的历史基线和业务要求为准，本文不给出可以直接套用的数值。

必须专门覆盖周期性问题。割接当晚通常跑不到日切、对账、账单生成、报表、备份、证书轮换、月度统计这些任务，但它们第二天就会来。把这些任务列进观察清单，在观察期内主动触发一次，确认在新环境下能正常产出。这是割接后第二天早上出问题的重灾区——前一晚一切正常，第二天上午九点日切失败。

同时准备一份「必须讨论回退」的信号清单。比如写入成功率跌破某个比例、核心接口延迟持续超过某个水平、出现数据重复或主键冲突、对账结果不一致。清单上的信号一出现，就立刻召集决策人，而不是先自行排查半小时再说。

决策方式上，观察期是否结束由一个人宣布，并且要在公开群里说清楚依据。默认通过是最危险的模式——没人反对不等于没问题，可能只是大家都累了或者都在睡觉。

宣布成功时留三样东西：宣布的时间点、作为依据的指标快照、以及遗留问题清单和责任人。第三样最重要——割接结束不等于所有问题都解决了，把没解决的问题明确列出来并跟踪，比在报告里写「一切正常」有用得多。

人员分工与沟通节奏：谁盯哪一项、多久同步一次

割接现场最常见的失控不是技术失败，是两个人同时改同一个东西，或者没人改某个东西因为都以为对方会改。

角色至少分成五组：总指挥，唯一有权决定推进还是回退的人，不亲自操作；执行组，按步骤操作，不负责判断成败；观察组，只盯指标并上报，手上没有操作权限；业务验证组，走真实业务流程而不是看监控大盘；对外沟通，负责向业务方和用户同步进展。把判断和操作分开，是为了避免「边看边改」——那是最容易把小问题扩大化的工作模式。

每个步骤只指定一个执行人和一个确认人。执行人做，确认人核对结果并做签字式确认。两个人的名字要写在步骤旁边，而不是统一写在文档开头的「参与人员」里——后者在现场等于没有。

沟通节奏要固定。约定好每隔一段时间同步一次，比如每十五到三十分钟一次，而不是「有情况再说」。固定同步有三个作用：让不在现场的人知道进度、让异常有机会被说出来、也给总指挥一个规律的决策节拍。同步内容固定为四项：当前处于第几步、下一步是什么、是否有异常、预计多久再同步。

决策要在公开渠道里说。私聊里定大事是割接事故的高频诱因——执行组不知道决定已经改了，观察组不知道目标已经变了，两边按不同版本往下走。

操作要留痕。谁在什么时间执行了什么操作、结果是成功还是报错，都记录下来。留痕不是为了追责，是为了回退之后能准确还原「新侧到底发生过什么」，这直接决定了补数据的难度。

交接也要排。割接往往跨夜，人的判断力在后半夜会明显下降。明确交接时点和交接内容：当前状态、已完成的步骤、待办、已知异常、正在等待的信号。交接不是口头说一句"一切正常"，而是一份清单。

最后，提前备好应急联系方式：新机房一侧的值班、承载方的技术对接、域名与解析服务、上游依赖方。凌晨两点找不到人，是最常见也最冤枉的窗口延长原因。

三类迁移场景的适用边界

上面这套排法不是放之四海皆准的，它的适用边界值得先说清楚。同样是"换机房"，下面三类场景的不确定性来源完全不同，排期的重点也不一样。

第一类场景是同城或同一网络环境内换机房。这类迁移的链路条件相对可控，跨机房带宽与延迟的不确定性小，双跑期压力低，追平窗口相对好估，批次可以划得大一些。需要注意的是"相对"两个字——即便距离很近，也要按实际链路条件逐项确认，不能因为物理距离近就默认一切顺利。

第二类场景是跨城或跨区域迁移。此时链路距离、跨网质量、出网路径成为主要变量，追平窗口的不确定性显著上升，估算对演练的依赖度大幅提高。这类场景建议把批次切得更细、双跑期留得更长，并且把"最后一轮追平"的演练做足次数，取最差值而不是平均值。

第三类场景是业务拆分到多个区域，或者连同承载方一起更换。除了数据本身，还要处理地址变更、解析收敛、依赖方白名单、证书与报备信息，批次划分最为复杂。这类场景下，不可回退点的位置会因为外部流程（比如合作方改配置要走审批）而变得不可控，必须把这些外部耗时提前纳入排期，而不是算在切换窗口里。

边界说明：本文的方法针对的是「整体搬走、且迁移期间仍保持单一写入侧」的场景。多地多活、双向写入、单元化这类架构下，回退与追平的性质完全不同，本文的排期逻辑不适用，需要另按多写冲突的框架来设计。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。涉及新机房的机位、电力、带宽与跨机房互联方式时，这些变量要和承载方逐项确认，它们会直接改变追平窗口能排多长。

需要提醒的是，无论新环境落在哪个机房、由哪一方承载，追平窗口相关的一切数字都要以你自己的实际环境为准。机房一侧提供的是链路、电力与机位这些条件，它们决定了窗口的上限，但不会告诉你业务数据的同步需要多久——这个数字只能由你的演练给出来。

割接评审会上一定会被问到的六件事

能不能做到完全不停机？取决于业务形态，不能一概而论。如果写入可以在应用层做双写并且有可靠的冲突处理规则，同时读流量能平滑切换，理论上存在不停机的路径，但代价是架构复杂度和数据一致性风险大幅上升。对多数「整体搬走」的场景，更现实的做法是承认存在一段写入暂停，把精力放在缩短这段窗口和明确回退边界上。是否值得为不停机付出双写的代价，需要你自己评估。

双跑期要留多久？这个问题没有通用答案，它由两个条件决定：一是同步延迟能否稳定收敛到一个低位，二是关键功能与周期性任务是否都在新环境跑过一遍。建议把双跑期的结束条件写成这两个判断，而不是定一个日历天数。如果一定要给排期参考，那也应当来自你自己前几次演练的实测结果。

要不要先把读流量切过去？通常值得做，而且应该尽早做。读流量切换是可逆的，回退代价低，但它能提前暴露新环境的问题：连接配置、缓存命中、慢操作、资源水位。把这一步放在割接日之前，等于用真实负载做了一次长时间的压力测试。需要留意的是，确认切换期间新侧没有被意外写入，否则会产生只存在于新侧的增量。

最后一轮追平跑不完怎么办？这正是需要提前定义出口的地方。方案里要写清三条分支：延长窗口继续跑（前提是有余量且业务可接受）、中止并回退到已定义的回滚点、或者在限定范围内降级校验后带风险推进。每条分支的触发条件和决策人都要提前指定。最忌讳的是现场临时商量——那时每个人都很累，而且信息不全。

旧环境什么时候能关？建议把"关"拆成两步：先停止写入与同步、保留只读和日志，确认运行一段时间之后，再释放资源。中间这段时间的作用是对账和回溯——许多数据问题要等日切或对账任务跑过才暴露。具体保留多久，以你的业务周期和问题发现规律为准，本文不给具体时长。

要不要准备一份不回退的硬切方案？不应该把它当成默认选项，但可以准备一份"最后手段"清单：如果回退路径确实走不通，需要哪些额外动作、需要哪些人在场、代价是什么。这份清单的作用是让决策者知道兜底方案的成本，从而在还能回退的时候更果断地回退，而不是硬着头皮往前走。

数据比对有差异，但业务看起来一切正常，能宣布成功吗？不能先宣布，要先分类。判断差异属于哪一类：同步延迟导致的时间差、真实的记录丢失、还是比对方法本身的问题（字符集、时区、排序规则、精度）。第一类和第三类可以在记录清楚的前提下继续观察，第二类必须立即处理。把「看起来正常」当成一致性证明，是最常见的事后返工原因。

哪些判断必须你自己先演练一遍

这套排期方法里，凡是需要填数字的地方，都应当来自你自己的演练，而不是来自任何文章的推荐值。以下几项尤其不能靠估计。

第一，最后一轮追平的实际时长。这不是「增量除以带宽」能算出来的——同步过程本身的处理开销、小文件的元数据操作、索引维护、网络抖动带来的重试，都会让实际值偏离理论值。做法是按真实步骤完整跑一遍，多跑几次，取最差的一次。

第二，停写之后残留写入的检测方式。怎么确认源侧真的没有新增了？看进程、看连接、看访问日志，还是看数据本身的校验点？这几种方式的可靠性差别很大，要提前定好，并在演练里验证它确实能发现问题——一个从来没发现过问题的检测手段，可能只是因为它根本没在工作。

第三，回退动作的完整执行路径。回退不是把流量切回去就结束了，还包括：旧侧能否直接接管、同步链路是否需要反向重建、需要多长时间、回退之后是否需要人工对账。这些只有在演练里跑过一遍才知道，而它们的耗时直接决定了回滚点应该定在哪一步之前。

第四，解析与地址收敛的实际耗时。理论上的缓存过期时间，和客户端、代理、开发包各自缓存之后的实际收敛时间，往往不一致。用真实客户端抽样验证，而不是只看权威解析的返回值。

第五，校验任务在窗口内能否跑完。全量比对通常跑不完，那么「关键项比对」到底包含哪些、耗时多少，要提前测出来，而不是在窗口里第一次运行。

演练还要注意两点。一是环境量级要接近生产，小规模数据测出来的数字不能直接按比例放大套用；二是要专门演练失败分支，走通成功路径的演练只完成了三分之一的工作量。

演练结束之后，把方案里所有估算值替换成实测值，并把演练记录附在方案后面。这一步做完，方案才从「一份文档」变成「一份可执行的排期」。

关于割接排期顺序的几条判断线

一、先定不可回退点，再倒排追平窗口，最后才填开始时间。顺序反了，方案里的时间就只是装饰。

二、追平窗口不是「同步需要多久」，而是「从停写到新侧可用需要多久」，中间还包含校验和重试。只算同步时间是常见的低估来源。

三、不可回退的起点通常在新环境第一次接受真实写入的那一刻。在此之前，回退是切换动作；在此之后，回退是数据动作。

四、双跑期换来的不是省事，是回退空间。它的长度应当等于你愿意保留的回退余量长度。

五、批次边界画在共享最少的地方，先迁无状态、再迁只读、最后迁写入，第一批选一个失败也不心疼的模块。

六、所有数字以你自己的数据量、网络条件与演练结果为准。任何脱离具体环境的时长和速率，都不值得写进方案。

割接排期的口径与来源说明

本文只讨论割接的排期与顺序方法，包括批次划分、双跑期安排、追平窗口估算、一致性校验、切换动作顺序、地址与解析变更、回滚点与不可回退点的定义，以及观察与分工。本文不讨论任何具体数据源产品的复制或同步配置，不给出任何时长承诺或性能数值，不比较任何迁移工具或服务的优劣。涉及窗口长度、同步速率、校验方式与保留周期时，一律以你自己的数据量、网络条件与实际演练结果为准。文中出现的场景均为通用部署思路示例，不指向任何具体客户，也不构成性能承诺。

一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

具体的机型、机柜、带宽与报价，仍要以官方实时信息或咨询确认为准。