lift and shift 失败的原因

一句话总结

**原样迁移（lift and shift）通常会更贵。**本地环境的前提是尽可能用满已经购置的资源， 云环境的前提则是按使用量付费，两者的设计基础恰好相反。

为什么需要它

“把 30 台服务器原样搬到云上，成本结果翻了一倍”是非常常见的案例。 逐项分析后，原因如下。

• 本地服务器按照峰值负载采购，平时 CPU 使用率只有 10～20%。 如果按相同规格启动云实例，每个月都要为闲置资源付费。
• 在本地环境中，网络流量看似免费。在云上，所有离开区域的流量都会收费。
• 用于备份和复制的存储也全部会成为计费项目。

因此，迁移前必须重新测量并调整规格（right-sizing），在不使用时关闭资源， 并重新设计流量路径，云的价值才能体现出来。不做这些工作，云就只是更昂贵的数据中心。

排除迁移的标准

更适合留在原地的对象

对象	原因
全天满负荷运行的大规模批处理	无法获得按量计费的优势，购买设备更便宜
需要超低延迟的系统	某些场景必须在物理位置上靠近
依赖特殊硬件	许可证加密狗、特定扩展卡、工业接口
禁止数据跨境的对象	没有符合要求的区域时根本无法迁移
已完成折旧且稳定运行的系统	迁移一个运行良好的系统同样有成本
经常向外传输大量数据的工作负载	出口流量费用会吃掉全部收益

最后一项经常被忽视。入站流量通常免费，但**出站流量（egress）**价格很高。 如果服务持续向外发送大文件，云账单的大部分可能都来自这里。

适合采用混合架构的场景

没有必要把选择看成全有或全无。

• 只把波动较大的前端放到云上——吸收流量高峰，稳定的后端继续留在本地。
• 只把灾难恢复放到云上——平时维持最小规模，发生事故时才扩容。 这是最能体现按量计费价值的用途。
• 只把开发和测试放到云上——需要时创建，结束后删除。

决定迁移后的执行顺序

1. 清点资产——画出各组件之间的依赖关系。没有这一步，就无法继续。
2. 分类——原样迁移 / 重新构建 / 改用托管服务 / 淘汰。 找出可以淘汰的对象，往往才是价值最大的一步。系统里总有无人使用的服务器。
3. 重新计算规格——以实际使用指标为准，不要照搬峰值规格。
4. 从小对象开始——先选择可回滚的对象，用它们完善流程。
5. 观察成本——从迁移后的第一个月开始按标签查看。事后再补标签通常已经来不及。

生产现场中的表现

• 迁移后费用翻倍 → 没有重新计算规格。
• 出口流量费用高于计算费用 → 没有分析流量特征。
• 迁移到一半后中止，最终两边都要维护 → 开始前没有绘制依赖关系。

成本由设计决定

迁移后再尝试降低费用，通常已经没有太多可做的事情。因为大部分云成本在决定使用什么、如何使用的那一刻就已经确定。因此，需要在设计阶段单独检查以下事项。

**已知会长期使用的资源，应提前签订期限承诺。**承诺使用 1 年或 3 年，可以显著降低同类实例的价格。相反，随时可能被回收的低价实例，只能用于允许中断的任务。批处理和测试环境适合这种模式；如果用于持有状态的服务，每次回收都可能造成事故。

按访问频率划分存储等级。日志和备份这类很少读取的数据，如果与高频数据放在同一等级，费用会高出数倍。但低价存储等级可能会在取出时收费，或需要较长等待时间；如果把恢复所需的数据放进过冷的等级，真正需要时就会陷入困境。较稳妥的做法是通过生命周期规则，只把较旧的数据自动降级。

**画出流量的流向。**同一区域内部、可用区之间、区域之外以及流向互联网的费用都不同。为了可用性，把数据库放到不同可用区是有必要的，但也会产生相应费用。主动了解后作出选择，与在不知情的情况下形成这种架构，性质完全不同。

**托管服务应按包含运维成本的总价衡量。**自行运维的数据库只看价目表会更便宜，但备份、高可用、版本升级和夜间响应都需要人员完成。**如果不把这些时间换算成成本，自行运维永远会显得更便宜。**团队越小，这一项的比重越高。

最后，从一开始就强制使用标签。没有标明所属团队和服务的资源，几个月后就会无人敢动。因为不知道能否删除，只能继续保留，而这些遗留资源最终会占据账单的很大一部分。

下一门课程

下一门课程将学习权限。这是云环境中最常发生事故的位置，也是无需真实账号， 只编写策略文档就能直接学习的领域。