1 混合云与多云方案要回答什么
零售业务准备把订单 API 放到云上。顾客提交订单后，希望立即知道是否创建成功；门店库存系统仍在自有机房，财务数据还要按周期对账。促销时请求量会上升，平时又不愿为闲置容量付费。此时讨论混合云与多云，起点应是订单链路的约束：哪些步骤必须同时可用，哪些数据允许延迟，哪些故障需要业务继续服务，哪些故障可以暂停写入。
本章沿用这套零售订单 API：创建订单会校验请求、预留库存、提交订单，再异步通知后续履约。客户端给每次业务提交携带幂等键，用来识别重复请求。库存预留必须有结果；没有拿到结果时，接口不能把订单说成已经成功。订单提交完成后，通知可以稍后重试。这里先把业务顺序说清，具体数据库与消息产品不作为前提，也不在本章展开分布式事务内部实现。
混合云强调自有机房或私有环境与公有云共同承担业务，多云强调使用多个云环境。企业可以同时采用两者：库存位于机房，订单 API 运行在云 A，云 B 保存可恢复的订单副本。名称本身不说明可用性。只要订单仍依赖机房库存，机房到云 A 的链路就是生产依赖；只要云 B 还没有完成恢复演练，它就不能被写成已经就绪的接管站点。
先写可验证的需求。本例在方案评审中暂定：月度服务可用性目标为 99.9%，常态创建订单的端到端响应时间第 95 百分位不超过 800 毫秒；订单恢复点目标 RPO 不超过 5 分钟，恢复时间目标 RTO 不超过 30 分钟。这些是教学案例的业务约定，不代表任何平台的默认能力。RPO 表示允许丢失的数据时间窗口，RTO 表示恢复服务允许花费的时间。已经确认成功的订单是否允许丢失，还必须另列业务规则。
本例进一步约定：已确认订单必须能追溯，异步副本暂时落后不自动满足这一要求。若灾难恢复可能缺少最近 5 分钟的订单，接管前必须核对仍可取得的提交记录，无法核对时暂停相关写入并启动业务补偿。因此，“达到 RPO”与“每笔订单都已闭环”是不同的验收项。把数字和业务语义放在一起，才能知道恢复是否真的完成。
需要比较的候选方案包括：云 A 承载订单并连接机房库存；在此基础上增加云 B 的恢复能力；将订单写入同时放到多个云。它们对应不同的建设和运行负担，不能仅凭“更多云”决定排序。本章先选择第 2 种作为待评审方案：云 A 负责日常写入，云 B 用于受控恢复，库存仍在机房。接下来逐项验证这个选择是否值得、是否做得到。
2 控制面、数据面与身份统一
把资源画到不同环境之后，还要标出控制面与数据面。控制面负责创建、配置和管理资源，例如修改访问规则、发布订单服务、颁发工作负载身份。数据面承载顾客的实际订单请求，例如网关接收请求、订单服务访问数据库、库存接口返回预留结果。它们可能共享部分基础设施，但故障表现不同：无法发布新版本，不必然等于正在运行的订单服务已停止。
这项区分会改变依赖设计。若每次创建订单都必须向某个外部管理接口申请临时配置，管理服务就进入了订单同步链路。控制面短暂异常也会直接阻断业务。合理做法是确认运行中的服务能在多长时间内使用已取得的有效配置和身份，同时规定到期、撤销与刷新失败后的行为。这里的目标是明确依赖，不是无限缓存凭据，更不是绕过权限校验。
身份统一首先统一“谁可以做什么”的规则。人员身份可以来自统一身份源，再映射到各环境的角色；订单服务使用独立的工作负载身份，访问库存和订单库时只获取所需权限。云 A 的角色名称与云 B 相同，不代表权限相同。平台团队需要比较具体动作、资源范围、条件和有效期，尤其要防止恢复环境为了方便接管而长期保留过大的写入权限。
统一也不等于共享管理员密钥。若同一个长期密钥能修改所有环境的网络和数据，密钥泄露就能同时击穿多个故障域。本例将发布权限、网络变更权限与订单数据访问权限分开，跨环境调用优先使用可审计的短期凭据。用于紧急恢复的受控账号需要独立保存、限定用途并定期验证。业务接管步骤必须能说明：身份源不可用时谁能执行恢复，以及执行记录如何补回审计系统。
在数据面上，创建订单从入口到库存再到订单库，每次跨边界都需要明确身份、路由、加密和超时。允许网络连通，只解决“报文能否到达”；身份校验与授权还要回答“到达后能否操作”。反过来，权限正确也不能修复路由错误。排查时把这几层分开，可以避免见到超时就扩大权限，或见到拒绝就反复修改网络。
还要梳理公共依赖：域名解析、证书签发、时间同步、镜像分发和监控入口可能被多个云共同使用。即使计算资源分散，这些依赖仍可能只有 1 个管理入口或运行实例。方案应标明哪些故障只影响发布，哪些会在缓存或凭据到期后影响订单，哪些会立即影响请求。用失效时间与影响范围描述依赖，比笼统写“统一管理平台高可用”更有用。
本例要求订单请求携带可关联的请求标识，各段日志记录请求标识、环境、调用结果和必要的耗时信息，避免记录完整个人信息与凭据。跨环境时身份可以变化，请求标识应能继续关联。这样既能追踪订单在哪个边界停住，也能检查恢复时是否误用了日常环境身份。控制面日志与业务调用日志分别保存，再按时间和变更记录建立联系。
3 可移植性与云特色能力
可移植性指在环境变化时，应用、数据和运行方式能以可接受的代价迁移。它不是“所有文件都能复制”。订单服务能启动，还要能够读取正确的数据、识别原有身份、连接库存、输出可用的监控信息，并满足订单语义。评估时至少分开看应用运行、数据、身份与运维流程。某个部分使用开放格式，并不能证明整条订单链路已经可以替换。
应用运行层可以采用较通用的打包方式和配置约定，减少环境差异。但镜像相同，运行环境仍可能不同，例如入口超时、可用区数量、默认出站规则和磁盘行为。可移植方案需要列出应用真正依赖的能力，并在云 B 用代表性请求验证。本例首先验证创建订单、重复提交、库存失败和恢复后查询；仅显示健康检查通过，不能说明订单 API 已经具备接管能力。
数据往往比应用更难搬。订单库除了表结构，还包含索引、事务行为、时间处理与备份格式。使用云特色数据库能力可能减少日常运维工作，但迁移到其他环境时，需要确认等价能力或修改应用。方案可以允许主环境使用这些能力，同时提供定期导出、恢复校验和订单核对流程。导出文件存在，只证明有数据产物；能按业务要求恢复并读写，才说明退出路径可用。
并非每个接口都值得提前抽象。对订单创建与库存预留等关键边界，可以定义稳定的业务接口，让环境差异落在适配部分。对当前只有 1 个使用位置、短期没有迁移需求的管理功能，过早建设复杂的通用层，可能增加排障难度。抽象范围应由更换需求、数据风险和团队维护能力决定。不能为了声称可移植，把所有云能力改造成自己维护的基础平台。
也不能只追求各环境的最低共同能力。若团队缺少数据库运维经验，放弃成熟的托管备份与故障恢复能力，可能使日常可靠性下降。可以把选择写成明确的取舍：当前使用某项托管能力降低运行负担，接受相应的替换工作；每个季度验证导出和恢复路径，并记录预计耗时。这样既利用现有能力，也把未来变化需要付出的代价显式保留下来。
本例把云 B 定义为受控恢复环境，因此不要求每次发布都同时承担生产写入，但要求关键版本有可部署产物、恢复所需配置有记录、数据库变化与恢复工具兼容。若云 A 的数据结构更新后，云 B 仍使用旧程序，备用环境就会逐渐失效。发布完成的定义应包含兼容性检查，而不是把“备用环境以后再补”长期留在待办列表中。
评审可移植性时，可以问 3 个具体问题：换环境前要改哪些内容，完成切换需要哪些人，演练证明需要多长时间。答案若只有“使用容器，所以可以迁移”，证据还不够。与其给方案贴上可移植标签，不如附上依赖清单、替代方式与验证日期。高级的数据复制和事务协调机制留到后续专题，本章先要求每项承诺都有对应的恢复动作和业务验收。
4 动手：对照一次跨云故障域图
本节用纸面演练检查故障域，不需要开通真实云资源。准备订单链路图，把顾客入口、云 A 的订单服务与订单库、机房库存、云 B 恢复环境分别画出来，再补上解析服务、跨环境链路、身份源和部署入口。每个框标注所在环境与负责团队，每条线标注用途。图中省略的公共依赖，往往正是评审最容易漏掉的故障来源。
第 1 步，沿正常请求走完整条链路。顾客提交后，入口把请求送到云 A，订单服务检查幂等键，向机房库存申请预留，获得明确结果后提交订单，并在提交成功后返回确认。异步履约通知另画分支。沿线检查每段超时是否有总预算，避免库存已经等待较久，订单服务却仍允许客户端无限重试。800 毫秒是端到端目标，需要通过实际观测分配预算，不能直接当成每段调用都可消耗的时间。
第 2 步，用边框圈出可独立失效的范围。云 A 的某个可用区故障、云 A 整体不可达、机房断电、跨环境链路中断，属于不同的演练题。将订单实例放进云 A 的多个可用区，可以处理部分区域内故障；它不会自动解决机房库存故障。把云 B 画在右侧也不会切断共同依赖，如果云 B 访问库存仍经过同一条中转链路，这条链路就依然是共同风险。
第 3 步，选择“云 A 无法对外提供订单服务”作为演练输入。先识别故障影响和主环境写入状态，再决定是否启动灾难恢复。RTO 从业务约定的服务中断时刻计起，应包含检测、判断、数据检查、启用资源、切换入口和业务验证，不能只计算应用启动耗时。若这些步骤分别由不同团队操作，等待交接的时间也必须计入。
第 4 步，检查云 B 的数据恢复点与机房库存可达性。假设云 B 最新可用恢复点落后 3 分钟，它满足 5 分钟 RPO 的时间要求，却仍需要核对这段窗口内可能已经确认的订单。若无法取得可靠提交证据，先暂停相关写入并说明影响。不要用“副本延迟在目标内”替代已确认订单的业务核对，更不要为了尽快恢复页面而让库存重复预留。
第 5 步，在启用云 B 写入前确认云 A 已被阻止继续写入。阻止旧主写入的措施及证据必须事先设计；只改变入口地址，不足以证明所有旧连接、后台任务和内部调用都已停止。若无法确认写入归属，就保持受控暂停。随后检查云 B 的身份、路由、容量和配置，切换入口，并验证新建、查询和重复提交行为。恢复后还要持续观察错误率与库存预留结果。
最后把纸面结果记成事实表：故障条件、观测证据、执行角色、经过时间和业务结果。验收同时检查 30 分钟 RTO、5 分钟 RPO 与订单闭环要求。若云 B 能运行却连不上库存，结论应是恢复链路不完整。演练的价值在于找出条件缺口，下一次补齐并复测；没有必要为了让报告好看，把没有验证的步骤写成成功。
5 锁定成本与工程复杂度取舍
供应商锁定常被理解为“将来换平台很贵”，但成本来源需要拆开。数据导出、跨环境传输、应用适配、权限重建、团队培训和恢复期间的业务损失，都可能成为替换成本。合同退出条款也会影响时间。方案应标出哪些代价现在就会发生，哪些只在迁移或灾难恢复时发生，再依据业务变化的可能性决定是否提前投入。
多云的运行成本也不只是备用计算资源。本例需要云 B 的数据保存、按需恢复能力、身份与网络维护，以及持续演练。备用平时不接收顾客请求，仍可能产生存储、传输、日志和管理支出。还要计算工程师维护 2 套配置、处理差异和参加值守的时间。没有算进平台账单的人力成本并不会消失，只会进入发布速度与故障恢复时间。
用透明假设做小规模比较。假设当前云 A 与机房连接的月成本为 4 万元，新增云 B 恢复环境的资源费用为 6000 元、跨环境传输费用为 2000 元，演练与维护平均每月投入 12 人时。这里只演示列项方法，数值不是报价。若内部采用每人时 300 元核算，新增月成本为 6000＋2000＋12×300＝11600 元。总额为 51600 元，仍需检查是否漏掉重复授权、备份留存和测试流量。
再把成本与收益放到同一张决策记录里。云 B 可能降低云 A 长时间不可用带来的损失，但无法解决仍然共享的库存故障。若库存故障才是订单中断的主要来源，先投入库存高可用或链路改造，可能比扩展第 2 个云更有效。不要把所有停机损失都归入多云可以避免的收益，也不要把可用性目标直接换算成必然发生的财务回报。
可移植性投入也有边际成本。增加配置标准、数据导出与恢复演练，通常能减少明显的退出障碍；继续追求所有环境完全一致，就可能需要维护越来越多的适配代码。下面的交互用教学指数展示这个方向，指数不是金额，也不是对真实项目的预测。它帮助读者提出问题：为了降低未来替换工作，当前愿意增加多少工程投入；这份投入是否有明确的验证对象。
方案评审最终应回到真实证据。记录当前预计的迁移任务、最近演练耗时、实际传输量和维护人时，定期修正估算。若恢复环境长期没有完成业务验证，即使费用很低也难以证明收益；若已经证明只需较少投入就能满足恢复目标，也无需为了追求架构对称继续扩大范围。预算约束与可靠性目标需要共同决定建设边界。
本例的阶段性选择是保留云 A 的托管能力，并建设云 B 的受控恢复路径，暂缓多地同时写入。理由是业务更需要可验证的灾难恢复，而团队暂时没有足够能力承担多个写入位置的日常协调。这项选择应写进架构决策记录 ADR：背景、候选方案、决定、代价与重审条件齐全。若演练持续超过 30 分钟，或退出要求变化，就重新评估资源预置和可移植范围。
6 常见坑：为多云而多云
第 1 类误区是先决定使用多个云，再寻找可以填入的业务理由。结果可能是订单 API 在云 A、订单库在云 B、库存仍在机房，每次请求跨越多个环境，延迟与排障边界一起增加。这样的拆分并不必然错误，但必须证明其收益足以承担新增依赖。若只是为了在架构图中出现多个云标识，就没有回答订单成功率、恢复时间或退出要求中的任何问题。
第 2 类误区是把资源分散等同于故障独立。多个云可能共用同一个身份源、同一段接入线路、同一套错误配置，或由同一条发布流程同时更新。平台的规模不能消除这些共同原因。方案需要逐项说明遇到什么故障可以继续服务，遇到什么故障需要暂停。独立性是对具体故障的判断，不是根据环境数量自动得到的属性。
第 3 类误区是把所有依赖都放进同步链路，以为每次跨云确认就更可靠。实际上，同步链路增加后，任何必需环节不可用都可能阻断创建订单。异步复制可以降低请求等待，却引入数据滞后与恢复核对问题。选择同步还是异步，首先看业务步骤是否允许延迟。本例库存预留必须确认，履约通知允许稍后送达；灾难恢复副本的延迟则用 RPO 和订单核对共同约束。
第 4 类误区是把重试当成普遍解法。超时只说明调用方没有按时拿到结果，库存可能已经预留，订单也可能已经提交。若客户端、网关和服务各自无节制重试，就会放大请求并制造重复操作。本例要求沿链路约定超时和有限重试，对重复创建使用幂等键，对结果不明的操作先查询或核对。具体重试间隔与退避算法可以后续细化，但业务含义现在就要明确。
第 5 类误区是只维护主环境。恢复环境的证书、凭据、程序版本、容量配额和访问规则会随时间变化。即使昨天备份成功，今天恢复时仍可能因为身份过期或规则变化而失败。可以通过定期恢复代表性数据、执行订单验收流程来发现漂移。演练必须使用接近实际的身份和访问路径，否则管理员手工操作成功，不能证明正式恢复角色也能完成接管。
第 6 类误区是统一工具之后就忽略差异。相似的网络策略在不同平台上可能作用于不同层级，规则优先级和默认行为也可能不同。统一配置入口能够减少重复工作，却不能替代对执行结果的检查。平台应保存变更前后的有效规则、测试结果和责任人。当模板修改影响多个环境时，还要限制变更范围，避免同一次发布把主环境和恢复环境同时破坏。
判断是否“为多云而多云”，可以把第 2 个云从方案中暂时拿掉，观察哪项业务要求因此无法满足。如果回答只是“看起来不够先进”，应收缩范围；如果回答是“无法在约定时间内恢复云 A 整体故障”，就继续验证云 B 是否真的能完成恢复。这个方法让复杂度始终对应具体价值，也方便向业务负责人解释预算投向和剩余风险。
7 案例：两套网络策略互相打架
纸面演练后，团队安排云 B 的恢复测试。订单服务启动正常，查询已恢复的订单也成功，但创建订单持续超时。机房库存的业务监控没有发现对应请求。最近有 2 项变更：云 B 调整了出口地址，机房安全团队更新了库存接口的来源白名单。团队最初认为两边都已放行，因为变更单上使用了相同的订单服务名称。
实际链路是：云 B 的订单服务先经过环境内的出站控制，再经跨环境链路和机房入口策略访问库存。云 B 的出站规则允许访问库存地址的 TCP 443 端口，但流量到机房前经过地址转换；机房白名单仍只允许云 A 的出口地址。于是云 B 本地规则允许发出，机房入口规则拒绝进入。规则各自看起来合理，组合之后却让恢复链路断开。
排查先确定业务影响。团队暂停恢复环境的正式写入测试，保留请求标识和测试时间，用专用测试订单复现。随后依次核查域名解析结果、目标地址、路由选择、转换后的来源地址和各层规则命中记录。云 B 出站记录显示允许，机房入口记录显示拒绝，库存应用日志没有接收记录。证据将问题收敛到网络边界，此时没有理由先修改库存业务权限。
“两套策略互相打架”并不一定是规则语法直接矛盾，而是它们对同一业务流量的理解不同。云 B 团队按服务所在网段配置，机房团队按边界实际看到的来源地址授权，双方又没有记录地址转换。若只在任意一侧增加笼统的允许规则，可能仍然失败，也会扩大访问范围。需要按完整路径比较流量到达每个位置时的身份和地址。
修复方案是登记云 B 恢复流量实际使用的出口范围，在机房侧仅允许该范围访问库存接口的必要端口，并确认云 B 出站规则指向正确目标。修改前记录现有规则与回退方式，修改后验证规则命中，再跑库存预留、新建订单、重复提交和无权限调用。测试不仅要证明允许的调用成功，还要证明超出授权范围的访问仍然被拒绝。
恢复测试通过后，团队补充了平台变更约束：出口地址、路由或入口白名单变化时，必须检查跨环境依赖清单，并由链路两端确认。监控同时展示云 B 的库存调用失败与机房边界拒绝数量，日志按请求时间关联。没有请求标识的网络记录仍可通过时间窗口和连接信息辅助定位，但不能宣称每条网络拒绝记录都能直接对应某笔订单。
这个案例的最终结论是恢复准备不足，而不是增加云环境没有价值。备用计算和数据已经具备，遗漏的是跨边界网络策略及其变更协作。团队把恢复判定从“服务启动且查询正常”改为“关键业务路径及权限边界均通过验证”，并将此次失败用时计入恢复演练记录。高可用的证据应覆盖业务链路，不能停在应用进程存活这一层。
8 把云边界写进平台方案
平台方案应让业务负责人看清结果，让执行团队知道动作，让接班团队理解约束。首先给出业务与数据边界：云 A 承载订单主写，机房承载库存预留，云 B 承载受控恢复；订单副本传到哪里、允许落后多久、由谁核对都写明。若有地域、隐私或合同限制，应落实到具体数据类别和流向，不能仅在总则里写“满足相关要求”。
随后给出网络与身份边界。每条关键调用都应列明发起方、目标、用途、可见来源地址、端口、认证方式和责任人，地址转换也要标出。人员管理身份与业务服务身份分开描述。哪些角色能启用恢复写入，哪些角色能阻止旧主继续写入，哪些操作需要审计，都要对应实际权限。文档中的责任分工还应与日常值守、紧急联系和替补角色保持一致。
高可用部分按故障场景写，而不是只写部署数量。云 A 内部某个可用区故障，主要依靠云 A 的区域内冗余；云 A 整体失去服务，进入云 B 的恢复流程；机房库存不可用，则暂停依赖库存确认的新订单写入，并按业务规则处理查询与已提交订单。每个场景都有检测方式、触发条件、恢复动作与剩余风险，才能说明当前架构到底覆盖了什么。
对恢复顺序要明确单写责任。先确认故障和接管授权，再检查数据与库存依赖，阻止旧主写入，启用新主并切换入口，最后做业务验收。不同系统可能采用不同的具体顺序或工具，但任何步骤变化都必须保持写入归属清楚。回切同样需要核对接管期间新增数据，确认复制方向与应用版本；不能将入口改回云 A 就认为回切完成。
ADR 则记录为什么选择这套边界。本例保留 3 个候选方案的比较，写明选择云 B 受控恢复是为了覆盖云 A 整体故障，同时接受恢复时间、演练费用与数据核对工作。暂缓多地同时写入的理由，是当前业务收益不足以覆盖新增协调与运行负担。重审条件包括 RTO 无法达标、关键托管能力退出要求变化，以及库存系统的部署方式发生变化。
验收材料应包括最近的故障域图、代表性调用结果、恢复点证据、恢复耗时、权限检查与成本清单。监控负责人确认能否区分库存故障和云端故障，业务负责人确认结果不明订单如何处理，运维负责人确认恢复步骤能否由值守角色执行。对暂未验证的能力标记状态和责任人，不把计划中的能力算作已经实现的保护。
最后给平台留出持续维护入口。每次影响身份、出口地址、数据结构、恢复工具或共享依赖的变更，都要判断是否需要更新图和重做部分演练。可以依据变化范围选择验证深度，避免所有小改动都触发完整灾难恢复，但关键路径改变后不能仅靠文档审阅。方案由此成为可维护的运行约定，而不是项目结束时保存的架构图片。
9 从混合云与多云方案走向迁移方案（P21）
本章确定的是目标边界与选择理由，下一章需要回答如何安全地到达目标。迁移不是把架构图上的框移动到另一个云，而是改变真实流量、数据和责任归属。对本例来说，即使最终仍由云 A 主写、云 B 恢复，也要安排库存连接、身份、备份和监控的建设顺序，并保证切换期间顾客能理解订单结果。
交给 P21 的第 1 份材料是依赖清单。它包括订单 API 的入口、机房库存、订单库、异步通知、身份源和解析服务，以及每项依赖的责任人、访问方式和可验证结果。清单同时保留已发现的限制，例如出口地址必须提前登记、恢复账号需要单独验证。迁移计划才能据此安排前置条件，避免直到切换当天才发现外部团队尚未完成配置。
第 2 份材料是数据与流量约束。记录哪些数据要先复制、如何判断复制已经追上、结果不明订单如何核对，以及何时允许新环境写入。若使用少量流量验证，也要区分只读验证与生产写入；读请求成功不代表写入可以直接分散到多个位置。幂等键、库存预留记录和订单提交记录需要保持可追踪，帮助迁移期间判断某次请求究竟完成到了哪里。
第 3 份材料是迁移门槛和回退边界。把本章的可用性、延迟、RPO、RTO 与业务核对要求转换为切换前后的检查项。回退不仅要有旧环境，还要说明新环境产生的数据如何处理。出现重复预留、持续超时或数据无法解释时，按约定暂停或回退；不要因为已经开始切换就放宽验收条件。具体分批策略、切换窗口和迁移步骤将在 P21 展开。
由此可以看出，混合云与多云是满足需求的部署和管理选择，迁移方案则把选择变成可执行的变化过程。前者必须留下明确边界，后者才有条件控制变化风险。若本章还有未验证的恢复路径，迁移计划应将验证列为前置工作，而不是默认目标环境天然可用。带着这份事实清单进入 P21，比带着更多环境名称更能推进项目。
放进方案里
本零售订单平台采用混合云部署，并配置跨云受控恢复能力。云 A 承载订单 API 与订单主写，机房承载库存预留，云 B 保存可恢复数据与经过验证的部署产物。创建订单必须获得库存预留结果后再提交，履约通知采用异步处理。已确认订单必须可追溯，结果不明请求通过幂等键与提交记录核对，禁止直接重复创建。
方案目标为月度可用性 99.9%、常态创建订单第 95 百分位响应时间不超过 800 毫秒、RPO 不超过 5 分钟、RTO 不超过 30 分钟。恢复点满足时间要求后，仍须核对可能缺失的已确认订单。云 A 内部故障优先使用区域内冗余；云 A 整体故障时，确认数据、身份、容量及库存连通，阻止旧主继续写入，再启用云 B 并切换入口。无法确认写入归属时暂停写入。
平台团队维护故障域图、身份映射和恢复步骤，网络团队维护跨环境路由、出口地址与库存白名单，业务负责人确认订单核对和补偿结果。每个季度开展恢复演练；关键网络、权限或数据结构变化后补做相关验证。验收材料包括恢复点、实际耗时、关键订单流程结果和授权边界测试，服务启动不作为接管成功的充分证据。
成本同时核算备用资源、数据传输、日志、授权与维护人时。当前保留云 A 的托管能力，通过导出和恢复验证降低退出障碍，暂缓多地同时写入。ADR 记录该选择的收益、代价与剩余风险；若恢复目标连续未达标、退出约束变化或库存架构调整，则重审方案。迁移前需完成依赖确认、数据核对办法与回退条件，将尚未验证的能力列为前置任务。
10 小结：下一步迁移方案（P21）
混合云与多云方案的核心，是让业务要求、故障域、数据归属和工程投入相互对应。部署在多个环境，只增加了可选位置；可验证的身份、网络、数据与恢复流程，才让这些位置真正形成可用能力。
本例最终形成了明确的订单主写位置、云 B 的受控恢复职责、机房库存的共同依赖，以及有成本依据的 ADR。进入 P21 时，将这些结论转换为建设顺序、数据准备、流量切换、验收与回退步骤，使目标架构能够通过受控迁移落地。