5.7 云厂商锁定与迁移
一句话
锁定不是 “用了某家云”，而是某天想走时走不掉；它分六层（API / 数据 / 身份 / 网络 / 计费 / 技能），每层都要单独定价——可以接受锁定，但不能有未定价的锁定。
六层锁定：分开看，才知道哪层最贵
| 层 | 锁定长什么样 | 迁移代价 | 缓解手段 |
|---|---|---|---|
| ① API / 服务 | 专有数据库引擎、专有消息语义、SDK 深度耦合 | 代码改造，最大项 | 标准协议优先；专有调用集中在薄封装里 |
| ② 数据 | 专有存储格式、导出要工单、全量导出按 GB 收费 | 搬迁时间 + 出口费 | 每月演练一次全量导出与恢复 |
| ③ 身份 | IAM 角色、策略语法、SSO 依赖 | 重建权限模型与审计 | 用 OIDC 联邦，身份源自己掌握 |
| ④ 网络 | VPC 拓扑、专线、DNS、证书、私网地址规划 | 重新规划与割接 | 拓扑文档化 + IP 规划留余量 |
| ⑤ 计费 | 预留承诺、出口费、迁移期双付 | 现金流压力 | 承诺期与迁移窗口错开 |
| ⑥ 技能 | 团队只会这一家的抽象与工具链 | 学习曲线 + 招聘 | 保留一套通用技能底座（K8s / SQL / OTel） |
最容易低估的是 ⑥ 技能层：它不出现在合同里，也不出现在账单上，但决定了 “换一家要多久才恢复战斗力”。通常前五层 6 个月能迁完，第六层要 12 个月。
把锁定算成钱：迁移成本公式
迁移成本 ≈ 数据搬迁(GB ÷ 有效带宽 × 出口单价)
+ 代码改造(人日 × 人日成本)
+ 双跑期成本（通常为稳态成本的 30%–40%）
+ 业务中断风险（概率 × 损失）
+ 知识重建（培训 + 效率下降）
一个可复算的例子：50 TB 数据、出口 0.5 元/GB，光流量就是 2.5 万元；但 50 TB 在 1 Gbps 有效带宽下要搬约 5 天，再算双跑与改造，真实项目通常落在 6–12 人月。教训很直接：迁移成本里人力占大头，流量费只是零头——只算流量的退出方案，会低估一个数量级。
由此得到一条决策规则：迁移成本 ÷ 年节省 ≥ 2 年时，不要迁移，去议价。 换供应商的收益是每年 10%–20% 的单价差，而迁移是一次性的大额投入，多数情况下 “议价 + 逐步解耦” 比 “整体搬迁” 更划算。
可迁移性设计：八条可验证的动作
| 动作 | 做法 | 怎么验证 |
|---|---|---|
| 标准协议优先 | 对象存储用 S3 API、数据库用 PostgreSQL 兼容、可观测用 OTLP | 换一个实现，业务代码不改 |
| 专有能力集中隔离 | 所有厂商特有调用放在一个 vendor/ 模块 | 打开该目录就知道锁定面有多大 |
| 数据可导出 | 全量导出脚本 + 校验和 | 每月跑一次，记录耗时与体积 |
| 基础设施即代码 | Terraform / Pulumi，不用控制台点击 | 空账号能从代码重建整套环境 |
| 身份自己掌握 | OIDC 联邦，用户目录在自己手里 | 换 IdP 不改业务 |
| 网络拓扑文档化 | 子网、路由、专线、DNS 画成图并入库 | 新人能按图复现 |
| 出口流量进预算 | 把出口费当项目成本项 | 迁移/多活的账能提前算出来 |
| 退出演练 | 见下一节 | 有演练记录与通过标准 |
八条里最容易糊弄的是 “数据可导出”：导出脚本存在 ≠ 能恢复。验证方式必须是 “在另一个环境里恢复到可用状态，并对比行数与校验和”，而不是 “点了一次导出按钮”。
迁移的四种形态：先选形态，再排计划
| 形态 | 做什么 | 工作量 | 风险 | 什么时候选 |
|---|---|---|---|---|
| Rehost（lift & shift） | 原样搬 VM / 容器 | 最小 | 中（隐含依赖会暴露） | 时间压力大、先搬再优化 |
| Replatform | 换托管形态（自建 MySQL → 托管 MySQL） | 中 | 中（参数与行为差异） | 想顺手降运维成本 |
| Refactor | 按目标平台重构（如改 Serverless） | 最大 | 高 | 架构本来就要改 |
| Retire | 先下线不再需要的系统 | 负成本 | 低 | 迁移前必做的一步 |
顺序建议：先 Retire（能删的删掉），再 Rehost（把必须搬的搬走），最后对少数核心做 Replatform / Refactor。很多迁移项目失败，是因为把 30% 的精力花在了 “本来可以下线的系统” 上。
时间与双跑：给自己的项目留出余量
| 系统类型 | 迁移时间量级 | 说明 |
|---|---|---|
| 小服务（< 5 万行、无状态） | 1–3 个月 | 主要是联调与回归 |
| 中型核心（有状态、跨 3–5 个团队） | 6–12 个月 | 双跑 + 灰度切流 |
| 核心交易 / 账务 | 12–24 个月 | 对账、审计、合规签字 |
这些是量级判断而非统计值；真正的经验值是 双跑期占项目总时长的 30%–40%，且双跑期的成本要按 “两套都在跑” 计——这部分现金流经常被漏掉。决策 “迁 / 不迁 / 什么时候迁” 的记录方式见 4.6 决策框架与决策记录：把迁移成本、失效条件、owner 一起写进去。
退出演练：读演练、写演练、计费演练
| 类型 | 做什么 | 频率 | 通过标准 |
|---|---|---|---|
| 读演练 | 全量导出 + 在测试环境恢复 + 校验 | 每半年 | 行数与校验和一致，耗时在窗口内 |
| 写演练 | 切 1% 流量到备用实现，观察 24 小时 | 每年 | 错误率不高于基线，可切回 |
| 计费演练 | 算一次 “如果明天搬走，出口费 + 双跑费 + 人力是多少” | 每年 | 得到一个可写进预算的数 |
没有演练的退出方案，在出事当天会退化成聊天记录。这与灾备演练是同一个道理：方案的价值 = 演练过的部分。灾备侧的演练方法见 36.7 演练与验证。
反模式
| 反模式 | 后果 |
|---|---|
| “我们做了多云” = 两套锁定 | 成本翻倍，共同依赖（DNS、CI、IAM）没隔离 |
| 抽象层过厚 | 自造了一个功能更差、没人维护的 PaaS |
| 只备份不恢复 | 真要用时才发现导出不全、格式不可读 |
| 把合同条款当退出方案 | 条款能追责，不能恢复服务 |
| 迁移只做技术，不做组织 | 权限、审批、审计流程没搬，上线即卡住 |
| 为 “避免锁定” 放弃合适服务 | 过度设计，付出了 3 年复杂度换一个可能不发生的迁移 |
| 迁移成本只算流量费 | 低估一个数量级，预算超支 |
| 迁移不做 Retire | 把该下线的系统也搬了过去，永久背上 |
三条铁律
🔑 锁定可以接受，但必须定价：迁移成本写进决策记录，才有资格说 “我们考虑过”。
🔑 退出方案必须演练过；没演练的退出方案与没有退出方案等价。
🔑 先算 “迁移成本 ÷ 年节省”，再决定迁移还是议价；多数场景议价 + 解耦更划算。
自检
Q1 团队说 “我们用的是标准 PostgreSQL，没有锁定”。这个判断漏了哪几层？
▸ 答案：至少漏了三层：① 数据层（备份格式、全量导出速度、跨大版本升级）；② 身份与网络层（IAM 角色、VPC 拓扑、私网 DNS）；③ 技能层（只会这家控制台与工具链）。引擎标准只解决了 “①API 层” 的一部分，SQL 方言、扩展与运维习惯仍会带来迁移成本。
Q2 迁移成本算出来 400 万，每年能省 120 万。该迁吗？
▸ 答案：按 “迁移成本 ÷ 年节省 ≥ 2 年就不迁” 的经验规则，400 ÷ 120 ≈ 3.3 年，不建议整体迁移。更优的组合是：把省钱目标拆开——议价（用迁移意向换折扣）、局部解耦（把最贵的那部分换成标准实现）、以及 Retire 掉不再需要的系统。迁移是最后手段，不是第一反应。
Q3 为什么说 “数据导出脚本存在” 不等于 “可以迁走”？
▸ 答案：因为迁移要求的是可恢复，不是可导出。导出可能缺索引、缺权限、缺触发器，或格式只有原厂工具能读；真正的验证是 “在另一个环境里恢复到可用状态，并对比行数与校验和”。这一步没做过，锁定量化里的 “数据搬迁” 一项就是猜的。
Q4 双跑期为什么常被低估，它到底贵在哪？
▸ 答案：贵在 “两套都得是生产级”：双份资源、双份监控、双份值班，以及数据同步与对账的人力（这部分通常没人预先排期）。经验值是双跑占总时长 30%–40%，成本按 “两套稳态成本 + 对账人力” 计。只按 “迁移那几周的资源费” 估算，会低估 3–5 倍。
Q5 一个团队为了 “避免锁定”，把所有云能力都封装成自研抽象层。风险是什么？
▸ 答案：自造一个更差的 PaaS：抽象层要适配 N 家、每家的差异都要抹平，于是功能取交集、bug 自己修、升级自己跟，最终既没有得到任何一家的能力，又背上了长期的维护成本。正确做法是薄封装 + 专有能力集中隔离（第 ② 条），把锁定面控制在一个目录里，而不是消灭锁定。
跨篇相关：托管与自建的责任边界见 5.5 托管服务与自建的取舍；选型时的退出成本维度见 4.3 技术选型的评估维度；出口流量与承诺期的账单结构见 5.6 云成本结构；部署形态（公有 / 私有 / 混合）的选择见 5.2 部署模型：公有 / 私有 / 混合；迁移决策的记录与失效条件见 4.6 决策框架与决策记录；演练方法见 36.7 演练与验证。