1 迁移方案要回答什么
零售订单 API 已经能够创建订单、查询订单状态，并接收支付结果。现在团队准备把它从旧运行环境迁到新环境。迁移的理由可能是旧设备即将到期、容量难以扩展，或者希望降低维护负担。但「新环境部署成功」只说明程序能够启动，不能证明顾客下的订单不会丢失，也不能证明收银、库存和客服仍然看到相同的业务事实。
本课沿用零售订单 API 这个案例：创建订单时写入订单记录，并向库存服务发起预留请求；支付结果随后通过回调更新订单状态；顾客可以查询订单。客户端遇到超时可能重试，因此相同业务请求携带相同的幂等键，用它识别已经处理过的请求。迁移必须保留这项行为，否则网络切换造成的重试就可能变成重复订单。库存与支付系统暂不搬迁，但它们的地址、权限、回调入口与订单 API 的连接都在迁移检查范围内。
方案首先要说明迁移对象和责任边界。应用实例、订单数据库、配置、密钥引用、定时任务、入口路由分别由谁迁、谁验收？日志存储与备份是否随迁？历史订单是否必须全部在线可查？只迁应用与同时迁数据库，风险和切换步骤并不相同。把这些内容写成明确清单，比直接画出新架构更能暴露遗漏。清单还要标出不迁移但必须验证的依赖，避免把「外部系统不动」误解成「无需联调」。
接着定义成功。本课采用教学用判据：已确认成功的订单丢失数为 0；同一业务请求产生的重复订单数为 0；创建订单请求的成功率至少为 99.5%；请求耗时的第 99 百分位，即 P99，不超过 800 毫秒。性能指标在约定负载下按 5 分钟窗口观察，主动停写的维护窗口单独报告，不通过剔除失败请求来美化成功率。平时约 200 请求/秒、促销峰值约 600 请求/秒只是本案例的容量输入，不能直接当成其他零售系统的通用标准。
业务还接受最长 3 分钟的计划停写，要求切换失败后在 30 分钟内恢复约定服务。恢复时间目标称为 RTO；允许丢失的数据范围称为 RPO。本案例对已经确认成功的订单要求 RPO 为 0。这里的「确认成功」以服务向调用方承诺订单已持久保存为准，不能以页面是否显示成功为准。超时但可能已经提交的请求，也必须能通过幂等键查询确认。
迁移方案最终应回答：为什么迁、迁哪些内容、选择哪条路径、何时允许进入下个阶段、失败时怎么办，以及谁有权宣布完成。它把前面需求、选型、架构决策记录 ADR、成本和高可用讨论汇成可执行约束。ADR 记录为什么选择当前路径、放弃了哪些候选以及适用条件；迁移计划把这些理由变成带有负责人、证据与截止时间的行动。
2 评估、双跑与切换窗口
评估从现状证据开始。团队收集代表性时段的请求量、订单增长量、数据库大小、主要接口耗时和依赖失败率，同时核对运行时版本、数据格式、时区、字符编码与证书有效期。数据库能够导出，并不意味着目标环境能够正确解释其中的金额精度与时间字段。选取包含退款、取消、支付超时和历史状态的样本，比只试验最新的正常订单更有价值。容量估算还要给复制和校验留下空间，因为迁移期间旧环境仍在承接业务。
可以比较 3 类路径。停机搬迁是在暂停写入后复制并验证数据，操作关系较简单，但数据量较大时可能突破业务停写预算。持续复制是在旧环境服务期间完成全量搬运，再持续追赶变更，最后短暂停写收尾；它减少切换时需要处理的数据量，却增加复制监控和一致性校验工作。分批迁移则按门店或租户逐步切换，能限制影响范围，但前提是订单归属清晰，路由稳定，而且跨分组查询与共享库存有明确处理方式。不能只因「分批听起来稳妥」就采用它。
本案例选择持续复制、整体切换订单写入口，原因是停写预算只有 3 分钟，而现有数据库无法在该时间内完成全量搬迁；团队又缺少成熟的门店隔离路由。这个选择不代表持续复制天然更可靠。它要求团队能观察复制进度、证明切换前的数据一致，并控制任意时刻的唯一写入方。若这些条件无法在演练中满足，方案应重新评估停机预算或分批边界，不能靠压缩检查步骤勉强上线。
「双跑」必须先说明双跑什么。旧应用继续处理正式请求，新应用可以对复制得到的数据执行只读查询并比较结果，也可以接收去除副作用的影子请求。影子请求用于观察新应用怎样处理相同输入，其结果不返回给顾客。创建订单、扣减库存、发送通知等动作不能直接在生产依赖上执行，否则比较环境本身就会制造真实交易。对写接口，应在隔离环境使用测试订单验证业务行为；正式迁移期间仍由旧环境承担唯一权威写入。
切换窗口包含的时间比停写时间更长。例如安排 12 分钟切换操作窗口，其中最多 3 分钟停写，其余时间用于入口调整和初步验证；随后至少观察 30 分钟，覆盖相关业务链路后再申请业务验收。到窗口结束时仍没有达到放量条件，应按预定边界决定恢复旧入口或进入故障处置，不能自动延长顾客不可下单的时间。支付回调可能延迟到达，观察还要覆盖实际回调周期。
切换前建立闸门：新环境配置核对完成、容量验证通过、复制健康、值班人员到位、回退操作可执行，才允许进入窗口。动画中的每次前进都需要具体证据；如果只有「负责人认为没问题」，闸门就没有约束力。窗口选择也应避开促销开始、结算批次和库存集中更新，让业务能够理解短暂停写，并为异常处置保留人员。
3 数据复制与回滚边界
全量复制解决「已有数据怎样搬过去」，增量复制解决「搬运期间新变化怎样跟上」。全量复制应对应可说明的数据时间点，并从与该时间点衔接的位置开始追赶后续变化，避免中间出现缺口。这里不展开数据库内部日志协议，只要求方案明确工具提供什么保证、如何发现中断，以及中断后能否续传。若无法解释全量与增量怎样衔接，就不能宣称迁移期间没有数据遗漏。
复制延迟是重要信号，却不是完整证明。仪表盘显示延迟为 0，可能只是最近没有新事件，也可能监控已经停止更新。切换前暂停所有订单写入来源，等待在途请求结束，记录旧库最终的复制位置，并确认目标库确实应用到该位置。写入来源除了 HTTP 创建接口，还包括支付回调处理、取消订单任务、管理后台和人工修复脚本。遗漏任何来源，都可能让「最终位置」在宣布完成后继续变化。
停写期间，新建订单请求返回明确的暂不可用响应和重试提示，不把尚未持久保存的请求报告为成功。支付回调需要单独约定：本案例由既有的持久化回调接收层继续接收，接收成功表示事件已可靠保存，但暂停向订单库应用；恢复后按幂等规则补处理。这个接收层属于现状依赖，须验证容量、积压告警和重放能力。若系统没有这样的接收能力，就应验证支付方重试约定或调整停写策略，不能临时假设所有回调都会自动重来。
数据验收同时比较结构与业务。结构检查包括必要表和索引是否完整、关键字段是否兼容；业务检查包括订单总量、按门店和日期分组的金额、状态分布及选定订单的状态轨迹。金额使用双方约定的精确表示，避免浮点汇总误差影响判断。聚合一致也不能代替逐笔关键样本核对：恰好少 1 笔又多 1 笔，可能让总数相等。样本用于补充风险覆盖，已确认订单是否完整还需依靠完整标识集合比对等可解释的校验方法。
最关键的回滚边界是新环境何时开始接收权威写入。在它开始写入之前，旧库保留全部已接受数据，只要配置和入口恢复经过验证，通常可以恢复旧写入口。在它开始写入之后，旧库就可能缺少新的订单或状态变化。此时仅把路由改回旧应用会丢失业务视图，也可能造成订单重复处理。回滚按钮仍然存在，业务上却未必允许按下。
若计划支持新写入后的回滚，必须事先验证反向同步、写入隔离和再次校验，并确保旧版本理解新数据。反向复制本身不能证明兼容。为保持入门范围，本课不展开双向冲突处理；默认策略是目标开始权威写入后优先在新环境修复，必要时暂停写入，在核对数据和兼容性后重新制定恢复动作。高可用副本用于处理某些故障，并不能自动把已经发生的数据格式变化撤销。
4 动手：画一条迁移决策与验收路径
现在为订单 API 画出可以交给值班人员执行的路径。先在纸上或绘图工具中放入旧应用、旧数据库、新应用、新数据库、入口路由、库存服务和支付回调接收层。用箭头标出正式读写路径，再用不同标签标出复制与影子查询。每个阶段都写出权威数据库的位置。若同个阶段出现 2 个未受约束的订单写入方，就暂停设计，先说明如何防止它们同时创建或修改相同订单。
第 1 个决策框写「是否满足迁移前提」。把停写不超过 3 分钟、已确认订单丢失数为 0、峰值容量验证通过等要求连到这里。前提不满足时，箭头返回评估与调整，不能连接到强制切换。随后写明本次采用持续复制和整体切换，并在 ADR 中记录没有采用全量停机搬迁及门店分批迁移的原因。这样即使换了执行人员，也能理解哪些条件变化会使原决策失效。
第 2 个决策框是「是否允许停写」。在旁边放置配置核对结果、备份恢复演练记录、复制状态和业务确认。备份存在只能证明文件存在，恢复演练才提供恢复路径可用的证据；备份也无法找回备份之后尚未保存进去的新订单。配置核对至少覆盖数据库地址、库存环境、支付身份、回调地址、密钥引用和定时任务开关，并记录配置版本，避免检查结果与实际切换版本脱节。
第 3 个决策框是「是否允许目标接管写入」。操作序列应写成：暂停旧侧全部订单写入、处理在途请求、记录最终复制位置、确认目标应用完成、执行关键业务校验、隔离旧侧写权限、切换入口、开放目标写入。每个动作要有完成证据和失败去向。隔离旧侧写权限的方式必须与其他业务依赖核对，不能因为共用账号而误伤未迁移系统。失败去向取决于是否跨过权威写入边界，不能统一写成「异常即回滚」。
再补 1 个验收框，分别写技术与业务证据。技术证据包含创建订单成功率、P99、复制与回调积压状态、应用错误和关键依赖连接。业务证据包含订单可查、支付状态正确、库存预留能够关联、重复请求不生成新订单、门店和客服抽验通过。每个框都指定执行人、复核人和记录位置；业务负责人确认顾客流程，数据库负责人确认数据证据，切换负责人统一宣布阶段变化。不要用大量同时操作代替分工。
最后桌面推演 3 个异常：停写前目标连接失败、最终校验不一致、目标已经接单后支付更新异常。沿箭头逐步描述谁停下、哪里仍在写、顾客收到什么、旧库缺少哪些数据，以及谁可以批准恢复。若某条箭头只能靠临场猜测补全，就把它改成有条件的路径。动手产物是带证据的决策图和简短操作清单，不需要安装复杂迁移平台。它们应使没有参加设计讨论的值班人员也能指出下一步的依据。
5 停机窗口与风险取舍
停机预算来自业务可以接受的影响，不能从迁移工具的宣传数字倒推。假设停写时段有 200 个创建请求/秒，停写 180 秒可能影响约 36000 次请求尝试。这里统计的是请求尝试，包含重试，不能直接解释为 36000 笔订单损失。真正的业务影响还与顾客是否重试、活动时段、前端提示和替代渠道有关。技术团队应把估算依据交给业务方，让对方评估收入、客服和门店作业影响。
停写时间主要花在等待在途写入、追平剩余变更、最终校验与入口控制。可以用简化模型理解追平：若停写时还有 12000 条变更待应用，目标实际应用速度为 300 条/秒，在停写后不再产生新变更的前提下，仅追平就需要约 40 秒。这个结果没有包括校验和切换。停写之前若新变更产生速度持续高于应用速度，积压反而会增长，不能使用同个公式承诺一定赶得上窗口。
本课的滑块把停写前积压作为输入，固定演示应用速度和其他准备步骤的预算，帮助识别「复制看起来在运行」与「切换能按时完成」的差别。真实速度应来自接近正式条件的演练，并考虑索引维护、存储争用、依赖慢响应和网络波动。估算满足预算，只代表可以进一步准备；正式放行仍需要最终位置确认和数据校验。不能通过调小模型参数，把未知风险变成绿色灯。
减少停写通常会增加准备成本。持续复制需要额外资源、监控、演练和故障处理；分批迁移需要路由与归属管理；延长双跑需要为新旧环境同时付费。成本表应分别列出持续运行费用、迁移期间临时费用和人员投入，并写明旧环境预计保留多久、由谁批准延长。否则团队可能把旧环境长期保留当作保险，却没有维护其配置、补丁和恢复能力，最后同时承担费用与失效风险。
风险应结合发生可能性、影响和可发现性讨论。数据库格式不兼容可能导致立即失败，也可能只在少见退款订单上暴露；入口连接未刷新可能造成少量旧实例仍收到请求；旧定时任务未关闭可能在半夜修改状态。对每项风险写出预防措施、发现信号、处置人和剩余风险接受人。风险登记表的作用是改变准备工作，而不是给未知问题贴上低、中、高后就结束。
高可用还要落实到迁移过程。新环境有多副本，只能说明某些实例故障有接替可能，不能解决全部副本都使用错误支付配置的问题。复制服务、入口调整权限和回调接收层也可能成为关键依赖。团队应验证新环境承接正式负载时的基本故障恢复，并确认迁移操作不会同时破坏所有可用路径。更复杂的跨地域容灾与冲突协调可在后续专题展开，本课先要求故障域、责任与数据边界说得清楚。
6 常见坑：把演练成功当切换完成
演练回答「在这些输入和环境条件下，这套动作是否奏效」，正式完成回答「真实顾客和外部系统是否已经稳定使用新路径」。两者之间可能隔着配置版本、数据规模、支付回调节奏、入口缓存和人员安排。只保存演练成功的截图，不保存版本、负载和数据条件，无法判断证据是否适用于本次切换。演练发现的问题修复后，还应对受影响路径重新演练，不能把最早的绿色记录一直沿用。
常见误判是入口控制台已经显示新地址，便宣布所有流量完成迁移。实际连接可能复用旧地址，后台任务也可能绕过公开入口直连旧服务。因此要观察旧侧请求与写入，并检查来源。旧侧还有读流量，不一定意味着必须立即中断；旧侧继续出现订单写入，则说明权威写入隔离没有达到预期。正确处置依据业务边界，而不是要求所有旧侧图表立刻归零。
还有团队把「健康检查通过」当作业务验收。健康接口可能只检查进程是否响应，既不创建订单，也不连接真实库存和支付系统。目标应用使用错误库存地址时，健康接口依然可能返回成功。切换验证应包含可追踪的受控业务交易，并事先约定测试标记、执行权限和后续清理规则。不能为了验收而随意制造真实扣款，也不能用全程模拟的依赖证明真实连接正确。
平均值也容易掩盖问题。平均响应时间正常时，少数门店可能因为专属配置错误持续失败；总体订单数正常时，支付完成率可能下降。因此需要按门店、接口和关键状态观察，但不必无限增加图表。选择能回答验收问题的少量分组指标，同时保留从告警定位到具体订单的关联信息。监控若没有数据或更新时间过旧，应标记证据缺失，不能把空图当成没有错误。
「已经有备份」「旧环境还在」都不等于可以随时回滚。备份能否在 30 分钟目标内恢复，需要演练证据；旧环境是否拥有目标刚接受的写入，需要数据证据。旧环境保留期内还要维护必要的证书、配置和权限，并防止误启动定时任务。保留应有用途、期限与退出条件，不能无限期留下可写的旧副本。否则旧环境从恢复资产变成另 1 个事故入口。
完成条件还包括移交。观察结束后记录遗留风险、回调积压、对账结果和配置版本，确认值班人员拥有新环境的排查权限，再由指定人员签字。旧环境下线安排在单独阶段执行，并检查审计记录、备份保留和依赖解绑。演练完成、技术切换完成、业务验收完成、旧资源退出是不同里程碑；只有把它们分别记录，团队才不会因为项目看板显示「完成」而停止必要的观察。
7 案例：切换后配置漂移导致回滚失败
这次迁移的演练表现正常。旧环境与新环境使用核对过的支付身份配置，团队还演练了目标向旧库回传变更的备用路径，希望在必要时支持接单后的恢复。正式切换前 1 天，支付接入人员更新了新环境的凭据引用和回调校验配置，却没有同步更新旧环境，也没有重新执行回滚演练。这种运行配置偏离已验证基线的现象称为配置漂移。迁移清单只写「演练通过」，没有绑定实际版本，因此没有拦住这次变化。
正式切换时，复制位置确认和订单校验都通过。目标开始接单后，创建接口仍然正常，但部分支付回调更新失败。排查发现新环境的回调校验配置没有与支付方约定一致。同时，备用回传任务仍引用旧凭据，导致它在权限变更后停止工作。两个问题来自配置变化的不同影响：前者破坏业务状态更新，后者破坏原计划中的回滚前提。不能因为都发生在切换后，就笼统归为数据库迁移失败。
值班人员最初准备把入口切回旧应用，却在回滚前校验中发现旧库缺少目标新建的订单。若此时恢复旧入口，顾客查询可能得到「订单不存在」，重试也可能产生重复交易。旧环境的支付配置同样过期，即使补齐数据也不能保证回调处理正常。因此，这里的「回滚失败」是原回滚方案的准入条件不成立，回滚被阻止；它不应被描述为安全回滚已经完成，也不应继续盲目尝试入口操作。
团队先暂停新的订单写入，保留回调接收层对事件的持久化接收，确认目标库仍是唯一权威数据源。随后核对目标配置与支付约定，修复回调校验，验证受控事件后补处理积压，再检查订单、支付与库存的关联情况。处置期间按既定节奏更新业务影响，并持续评估 30 分钟恢复目标。若预计无法满足目标，应升级事件响应与业务决策，不能为了满足时间数字而恢复不完整的旧库。
复盘证据包括配置变更记录、部署版本、回传任务报错时间、目标开始写入的位置和订单对账结果。它们帮助区分事故触发点、发现延迟与恢复障碍。不能只把原因写成「操作人员忘记同步」：流程允许已演练配置被修改而不失效，监控没有及时暴露备用路径停止，切换闸门也没有要求再次验证实际运行配置，这些都需要改进。备用能力平时无正式流量，更需要主动证明其可用。
改进后的方案把已批准配置基线与迁移记录绑定，允许紧急修订，但相关检查与演练结果随变更失效。切换前再次验证实际支付连接和备用路径；目标接单后若备用路径未持续通过校验，系统明确显示「当前不可回切」，由负责人选择前向修复或暂停写入后专项恢复。这个案例说明，回滚是一条有数据与配置前提的业务恢复路径，不能由路由按钮的可点击状态来代表。
8 把迁移判据写进上线方案
上线方案中的每个判据都应具有对象、指标、阈值、时间范围、证据来源和责任人。例如「新环境稳定」没有明确含义；可以改为「开放目标写入后，按连续 5 分钟窗口观察创建接口，成功率至少 99.5%、P99 不超过 800 毫秒，持续观察至少 30 分钟，由应用负责人提供监控记录」。低请求量时还要检查样本量和实际错误，避免只凭少量成功请求得出稳定结论。
数据判据要有更强的约束。本案例要求切换前暂停全部订单写来源，记录最终复制位置，证明目标已应用到该位置，并完成约定的完整性校验；发现已确认订单遗漏或无法解释的金额差异，立即阻止目标接管。性能短暂波动可以触发观察或限流决策，订单丢失则不能简单通过延长平均窗口消失。方案要区分需要立即停止的条件和需要持续观察的条件，并给出明确的决策负责人。
回滚判据必须按阶段书写。目标接受权威写入前，若校验失败且旧侧恢复检查通过，可恢复旧入口；目标接单后，只有已验证的数据回传、旧版本兼容和配置就绪同时满足，才允许回切。缺少任意证据，转入暂停写入或在目标修复的预案。具体恢复动作由事件负责人根据业务影响确认，不能让自动脚本遇到任意告警就把流量送回落后的旧库。
成本与风险也要进入批准条件。临时双跑资源允许保留到什么日期，超期由谁审批，日志与备份需要保留多久，都应给出依据。对尚未关闭的风险，写明影响范围、替代措施和接受人。例如历史订单抽验发现少量展示格式差异，可能经业务确认后安排修复；金额或支付状态错误则可能阻断上线。不能把所有遗留问题打包成「不影响核心功能」，也不能让技术负责人独自接受业务损失。
证据记录应能串起需求与结论。需求编号连接到 ADR，ADR 连接到迁移步骤，步骤连接到演练结果和验收记录。值班人员查看的是本次实际版本与实际时段的证据，不是上次迁移的通用附件。对于敏感配置，记录版本和验证结果即可，不把密钥正文复制进方案。这样既能复查判断依据，也减少多人交接时对聊天记录和个人记忆的依赖。
最后约定批准与执行的关系。业务负责人批准停写窗口和剩余业务风险，数据负责人批准数据验收，应用与运维负责人确认可观测性和恢复能力，切换负责人依据全部结果决定进入下个阶段。任何负责人发现硬性条件不满足，都能发起暂停。方案由此成为共同执行的约定：它既说明什么证据允许向前，也说明什么变化会让原有批准失效，避免上线会议中的口头承诺替代实际检查。
9 从迁移方案走向互联网行业方案（P22）
完成迁移设计后，订单 API 的接口看起来没有改变，但我们已经补齐了从需求到运行的链条：业务可接受的影响决定停写预算，数据完整性要求决定写入边界，团队现有能力影响迁移路径，成本与风险决定临时资源保留方式，恢复目标约束演练和故障处置。理解这条链，比记住某种复制工具的操作顺序更容易迁移到其他项目。换用工具时，成功条件与证据责任仍然需要重新核对。
P22 将继续使用这个零售订单 API，讨论互联网行业方案。关注点会从「如何把既有服务安全迁过去」扩展到「业务持续增长时，怎样组织入口、应用、数据与依赖，使用户体验和运营目标能够共同成立」。促销流量、外部支付响应变化、客户端重试和多门店访问，都会继续出现；我们不另换 1 个没有历史包袱的示例来规避这些约束。迁移留下的基线数据，会成为后续容量与稳定性讨论的输入。
进入下课前，应保存本次测量结果：代表性负载下的接口分布、订单状态变化、依赖耗时、回调积压恢复时间和运行费用。只保存峰值吞吐量不够，因为相同吞吐量可能对应完全不同的失败率和顾客等待时间。还应记录哪些现象来自迁移，例如临时复制负载，哪些属于日常运行，例如库存预留超时。否则下课可能把临时成本误认作长期成本，或把环境问题误认作业务架构问题。
对高可用的理解也要延续。迁移结束后，旧环境退出，新环境的故障恢复责任仍然存在；复制工具撤除后，业务备份和恢复演练还要持续；切换会议结束后，配置变更仍然可能造成漂移。后续方案应把这些工作纳入日常运行，而不是每次活动前重新临时组队。这里先保留基本责任与验证方法，复杂的多地域写入、分布式事务和自动流量调度留待相关专题，不把尚未具备的能力写成默认前提。
可以用 3 个问题检查当前方案是否能够承接下课。若明天请求量接近促销峰值，能指出哪个环节先需要证据吗？若目标已经接受新订单，能说明为什么不能直接回旧库吗？若支付配置发生变化，能知道哪些验收记录必须重新生成吗？回答应落在本案例的指标、写入边界和配置版本上，而不是只说「扩容」「回滚」或「再测试」。这些具体回答将帮助我们在更大的业务场景中保持判断依据一致。
本课的交付物应能够交接：迁移范围清单、选择理由、阶段决策图、窗口预算、数据验收记录模板、分阶段恢复条件以及负责人安排。它们不要求读者掌握数据库复制的内部实现，却要求读者识别哪里仍有未知。对尚未验证的条件明确标为待办，并让它阻止相关阶段前进，比把它埋在附录中更有效。下课将在这些约束上继续讨论行业方案的组织方式，而不是把迁移做完当成架构工作已经结束。
放进方案里
本次迁移覆盖零售订单 API、订单数据库及相关配置，库存与支付系统保留现有部署，连接和回调能力纳入验收。采用全量复制加持续追赶，旧环境在切换前保持唯一权威写入；新环境通过隔离测试、只读比对和容量验证后进入切换准备。选择该路径的原因是全量搬迁无法满足 3 分钟停写预算，而现有系统尚不具备可靠的门店分批路由。
切换安排 12 分钟操作窗口，计划停写不超过 3 分钟。停写覆盖创建、后台修改、定时任务及回调应用，回调接收层继续持久保存事件。旧侧在途写入结束后记录最终复制位置，确认目标应用完成，并完成订单标识、金额、状态与关键业务链路校验。验收记录须绑定本次配置版本、最终复制位置和校验时间；旧侧写权限隔离后，应验证后台任务与直连脚本均无法继续修改订单，并保存验证结果。证据缺失或出现无法解释的数据差异时，阻止目标接管，不通过延长窗口默认获得批准。
目标接单前，旧侧数据、配置和入口恢复检查通过后可按预案恢复服务。目标接单后默认在目标修复；只有数据回传、旧版兼容及配置验证均通过，才允许回切。已确认订单丢失数和重复订单数均须为 0，服务恢复目标为 30 分钟。超过预计恢复时间或业务影响扩大时，由事件负责人升级决策。
目标接管后至少观察 30 分钟，按连续 5 分钟窗口检查创建成功率至少 99.5%、P99 不超过 800 毫秒，并验证支付回调、库存关联与客服查询。停写影响单独记录。应用、数据与业务负责人分别提交证据，由切换负责人确认完成；旧资源按批准期限保留并另行验收退出，临时费用和遗留风险均指定责任人。
10 小结：下一步互联网行业方案（P22）
迁移方案把路径选择、数据边界、窗口预算和恢复条件组织成可以执行的决定。能否上线取决于本次实际证据，演练通过只是其中的准备条件。请尝试沿决策图解释：最终校验失败时怎么办，目标接单后旧库缺数据时怎么办，以及配置变化会使哪些批准失效。
下一课继续围绕零售订单 API，把迁移中建立的需求、容量、成本与高可用约束放进互联网行业方案，讨论它们如何共同支撑持续运行与业务增长。