▮▮Coloprice

迁移 · 执行手册

迁移执行手册

一次迁移波次,从两周的变更冻结到事后评审。以下时间表假设在周末窗口执行一波10–30个机柜的迁移;更大规模的迁移会分批进行而不是延长时间。这份文档之所以是执行手册而非计划,有两个原因:每个步骤都有明确的负责人,执行/暂停标准在迁移当晚之前的数周就已确定。

T时间操作负责人详情
T-14d提前两周变更批准,波次锁定迁移负责人变更申请已批准,波次内容已冻结。T-14清单上没有的任何内容都不会在本波次中迁移——临时添加项目正是导致顺利迁移变成事故的原因。
T-7d提前一周目标位置已安装、已布线、已通电、可达现场工程替换或接收硬件已在目标位置就位、连接到正确的电路,并已验证可从公司网络外部进行带外访问。
T-72h周二执行验证脚本演练应用负责人对当前生产环境执行迁移后检查。如果检查现在失败,那就不会变成周六凌晨2点的迁移失败——而是说明这个检查本身有问题。
T-48h周三DNS TTL 降低至 300 秒网络工程提前降低至足够短的值,确保所有 DNS 解析器在切换前都已获取到新 TTL。
T-24h周四进行完整备份及恢复测试备份团队验证备份的可恢复性,而非仅确认完成。未曾恢复过的备份是一种信念,而非真正的控制措施。
T-4h周五 17:00变更冻结开始,协调电话启动迁移负责人停止整个基础设施范围内所有不相关的变更。与基础设施、网络、应用所有者和现场团队启动协调电话。
T-0周五 21:00继续/不继续 #1迁移负责人 + 业务赞助方逐项检查条件:备份已验证、目标可达、团队全员到位、其他地点无活跃 P1。任何一项不满足则全部否决。延期需付出一个周末的代价;在不稳定情况下继续进行需付出整个季度的代价。
T+0:15周五 21:15优雅关闭,最终增量同步应用所有者按依赖顺序关闭应用程序,最后一个复制增量已刷新,源系统标记为只读,防止任何数据写入即将被清空的源站点。
T+1:00周五 22:00从源站点撤除、装载、运输现场工程团队导轨和电缆在拆除时逐一标记。拆除任何东西前,拍摄每个机柜的前后照片 —— 这是最快的回滚助力。
T+4:00周六 01:00接收、上架、布线、通电现场工程分阶段群组启电而非一次启动,使跳闸的断路器自我识别,而不是导致整行宕机。
T+7:00周六 04:00启动/不启动 #2 — 回滚截止时间迁移负责人这是回滚仍能在窗口内执行的最后时刻。如果基础设施未在此固定时刻启电并可达,则执行回滚——决定在 T-14 做出,此时不改。
T+8:00周六 05:00网络切换、DNS 重新指向网络工程路由移转、防火墙策略激活、DNS 记录重新指向。监控应该在告知任何人前从新站点显示绿灯。
T+10:00周六 07:00自动化验证应用所有者与演练使用的相同脚本,现在针对目标执行。通过或失败,基于事实而非意见。
T+14:00周六 11:00业务验证与批准业务赞助人指定用户执行真实交易。批准以书面形式逐应用提供,属于应用所有者而非迁移团队。
T+24:00周日 21:00冻结解除、超级护理启动迁移负责人冻结解除、五个工作日内启动提升级支持,源环境保持完整至超级护理结束。
T+7d次周周五回顾会、运行手册更新迁移负责人更正写入runbook,趁细节记忆犹新。每个后续批次继承这些更正。

禁止启动的条件

在变更批准时达成一致,在每次启动/不启动决策时朗读。任何单一条件都是停止信号。提前写下来的目的是凌晨4点时论证已经结束。

  • 备份未验证可恢复性
  • 目标站点通过带外通道不可达
  • 会议中缺少指定的负责人
  • 任何地方存在活跃的P1事件
  • 运营商链路未确认可用
  • 自上次变更以来未测试回滚路径

回滚截止时间

只有能在剩余时间内完成,回滚才是现实的选择。在试运行中测算耗时:重新上架、重新布缆、上电和重新指向DNS至源站需要多久。从时间窗口末减去这个时间,就是固定的截止时刻——第二次启动/不启动决策。如果未在此之前达到通电的、可达的目标,就必须回滚,无论团队觉得多接近完成。跳过这步的团队不会避免回滚;他们只会在早上7点才发现已无选择。

当晚需要携带的物品

在runbook之前:计划

只有前期勘查工作顺利,迁移才能顺利进行。先完成迁移清单,用成本计算器建模方案,从数据中心目录中筛选目标。

获取目标站点报价

告诉我们批次规模和市场——我们返回符合条件的设施和基准定价。

我们在一个工作日内回复。无垃圾邮件,不转售您的联系方式。