云平台故障时实例迁移与业务恢复顺序，不能只看哪项操作更快，而要先判断故障是否影响数据、网络和控制面。若仍有健康副本，尽快恢复关键业务往往优先；若实例所在故障域仍不稳定，或数据卷存在风险，则应先隔离故障并迁至可用位置。顺序的核心是保护数据、缩短中断时间，并避免把故障带到新位置。
先判断故障，再决定先后
先确认受影响的是单台计算实例、存储、虚拟网络，还是云平台管理控制面。实例无法登录，不一定意味着业务进程已经停止；反过来，实例显示运行，也不代表数据库和依赖服务可用。通过平台监控、应用探测和日志交叉核验，记录故障起点、影响范围及数据是否仍在写入。
随后对照恢复时间目标（RTO）和恢复点目标（RPO）：前者是业务可接受的恢复时长，后者是可接受的数据回退范围。若恢复副本的数据落后程度超过业务容忍范围，不能为追求快速上线就直接切换。
两种顺序，各有适用条件
先恢复业务，再迁移实例
适用于故障实例之外已有健康副本，且业务能通过负载均衡、备用节点或已验证的恢复流程重新提供服务。例如，前端计算节点异常，但 PostgreSQL 主库和备用应用节点健康，可先确认备用节点连接数据库正常、关键请求通过，再逐步摘除故障节点。优点是恢复用户访问较快；风险是旧节点仍可能接收写入，因此要先隔离或停止其流量，防止双写和状态冲突。
先迁移实例，再恢复业务
适用于故障域持续不稳定、实例或其依赖必须离开故障位置，且平台支持迁移并能保证数据卷一致性。迁移前要核对目标位置的计算资源、存储挂载、网络策略和启动依赖；若云平台控制面不可用，在线迁移可能无法执行，此时应使用预先准备的备份、镜像或跨故障域副本，而不是反复尝试迁移。
按这个顺序执行，降低二次故障
- 冻结高风险变更：暂停非必要发布、扩缩容和批量重启，保留告警、日志及平台事件记录。
- 确定业务优先级：列出用户入口、身份认证、数据库、消息队列等依赖，优先恢复能形成完整服务链的关键组件。
- 检查数据一致性：确认副本状态、最近可用备份和写入位置。涉及数据库时，按既定恢复流程核验日志回放与主从角色，避免旧主继续写入。
- 选择恢复路径：有健康副本且数据满足RPO，先切换并验证业务；没有可用副本，或故障位置不适合继续运行，则先隔离，再迁移或从备份重建。
- 分批恢复并观测：先开放少量流量，检查错误率、请求延迟、队列积压和数据读写，再逐步扩大；确认稳定后处理故障实例和容量余量。
用业务状态而非实例状态验收
实例启动只是中间结果。验收至少要覆盖真实业务路径：用户能否完成关键操作、数据写入后能否读回、后台任务是否继续运行，以及告警是否解除。迁移后还应确认存储挂载点、访问权限、定时任务和服务发现配置没有沿用旧环境信息。若只看到控制台显示“运行中”就宣布恢复，可能遗漏依赖断开或数据落后的问题。
因此，云平台故障时实例迁移与业务恢复顺序应随故障范围和数据状态调整：健康副本可用时，先恢复业务并隔离旧节点通常更合适；故障域不安全或数据必须先保护时，则先迁移或重建。最终以关键业务验证通过、数据符合恢复目标为准。
常见问题
迁移实例会不会自动恢复业务？
不会。迁移只改变实例运行位置，应用依赖、数据一致性、流量切换和权限仍需分别核验。
故障时能否直接重启实例？
只有在确认存储与数据状态安全、重启不会造成重复写入或扩大故障时再做。数据库等有状态服务应优先执行既定恢复流程。
没有备用实例，应该先做什么？
先判断原实例和数据卷是否可用，同时确认备份及恢复点；若原故障域不稳定，隔离后在可用位置重建，并按恢复目标选择数据。
什么时候算业务恢复完成？
关键操作通过端到端验证、数据状态符合预期、服务指标趋稳，并且没有持续扩大的错误或积压后，才可视为恢复。