有的人会说，「即使云服务成本高些性能弱些，但是技术先进、多地冗余，高可用和容灾能力都是IDC托管比不了的」… 我以前也这么以为的，但是用了两年各家云服务，现在的我只想说：「不要神话云服务」

　　我还清楚记得收到第一封来自AWS，通知实例「退休」邮件时的心情：

　　这里AWS所谓的「退休（Retirement）」也就是中止实例了，甚至默认分配的公网IP都不一定能保留下来…… 而这样被「退休」的事，每年都还有4～5次左右。

　　阿里云和UCloud碰到同样情形时略好些，会尽量保留实例，只是做下物理宿主机迁移，短暂甚至不太影响业务。但是在一些大型的规划变更时，也是有关机时间长达数小时，IP地址也必须更换的经历。

　　再举个例子，各家云服务商的存储都是花大代价「两地三中心」「异地冗余」保证多个9的。但是今年2月底，亚马逊 AWS S3 服务也故障了。

　　所以真的不能神话云服务。

　　部署策略

　　当然，尽管发现了这么多问题。云服务还是在很多业务类型上有优势：

适合小于一个托管机柜的业务

　　IDC托管的规划配置比较高，对于低负载的业务来说，会造成比较多的资源浪费。

适合快速成长中的业务

　　成长特别快，难以预估峰值时间点和量级的业务，在IDC托管部署流程上，是缺乏灵活性，会受到拘束。存在IDC托管部署跟不上业务发展的风险。这种业务，更适合使用云服务。

适合对成本不敏感的业务

　　霸道总裁不需要解释。

适合缺乏运维能力的团队

　　IDC托管需要自己搭建数据库等服务环境，出现问题时辅助工具少，修复周期长，确实更需要有丰富经验可以信赖的运维团队。如果团队中没有这样的成员，就存有风险了。

适合责任重大（不敢自己背锅）的业务

　　当出现事故时可以对业务说，是XX云的锅…… 虽然我个人并不认可这个思路，但是我相信这在有些公司是客观存在的。

　　所以，尽管云服务成本比IDC托管高，性能比IDC托管差，但通过有策略的部署，将上述几个类型的业务部署到云服务商，还是能发掘很大价值。

　　游戏业务和互联网业务不同，在大尺度下业务负载曲线模型比较稳定，类似下图。而且大部分业务负载都会随着时间推移进入稳定期。

　　因此，如果我们按业务预估峰值去准备IDC托管资源，j2直播，那么在峰值过后，必然会造成计算资源的闲置。这时一旦没有新的业务上线，这些计算资源就会浪费。

　　所以我们心动游戏业务的上云策略，根据业务特点不同分为两类。一类是针对研发中和测试期间的游戏项目，鉴于负载低变化快，会优先使用云服务，利用云服务商的灵活性。

　　另一类是正式上线有压力预期的业务。对于这类业务，我们会将云服务商的计算能力作为弹性池。具体而言，就是对长期均线以下的计算负载部分，安排使用IDC托管资源提供服务。而对在弹性峰值的负载部分，尽量利用云服务商的服务能力来支撑。

　　在这样的策略下，让IDC托管承载业务稳定期的负载，可以获得最低的运维成本。同时充分利用云服务的弹性，支撑高峰期业务，使我们在成本和灵活性之间获得了一个平衡。

　　（文中数据均经过加扰处理，仅用于辅助说明推论过程，请勿用于财务投资参考）