题外话：

笔者就职于某上市游戏发行公司，主导整个发行业务线从双 IDC 到腾讯云的搬迁。在此过程中踩了不少坑，便以文章的形式记录下来。

如有错漏之处，敬请指正。

我先简单介绍下我自己：

我是业务开发出身，负责渠道登录/支付业务，熟悉前端，研究后台开发框架后，逐步往运维方向摸索。

业务除了登录/支付业务，也做过风控系统、聊天监控系统，主要是一些防刷保护、敏感词判别、垃圾信息过滤等等。

本系列篇幅较长，共有 7 篇文章，本文是第 7 篇。文章列表：

某上市游戏公司从 IDC 上腾讯云的落地经验（1）——上云必要性与方案设计
某上市游戏公司从 IDC 上腾讯云的落地经验（2）——方案实施之接入层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（3）——方案实施之应用层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（4）——方案实施之缓存层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（5）——方案实施之数据层上云
某上市游戏公司从 IDC 上腾讯云的落地经验（6）——方案实施之中间件上云
某上市游戏公司从 IDC 上腾讯云的落地经验（7）——总结与回顾

总结与回顾

前面的文章写了非常多，最终感觉还是有一篇总结性的文章好一些。

文章的整体脉络围绕为什么上云和如何上云两大模块，并详细展开方案实施整个模块。

文章结构图：

一、业务为什么要上云？

1. 提升业务价值

   • 1.1 稳定大于一切
   • 1.2 业务效率提升

2. 工程师价值

   • 2.1 运维工程师视角
   • 2.2 开发工程师视角

二、业务该如何上云？

1. 上云准备
2. 方案设计

3. 方案实施

   • 3.1 接入层上云
   • 3.2 应用层上云
   • 3.3 缓存层上云
   • 3.4 数据层上云
   • 3.5 中间件上云
4. 效果评估

本文是最后的效果评估模块。

现在回想起来，整个过程的顺利执行，也离不开流程规范。

每一轮变更，我们都提前走了测试流程，保证整个过程不对业务产生影响。变更过程中眼睛盯紧监控系统，有影响时实施回滚策略。

变更结束，也按照流程实施回归测试，及时发现问题。

最终也取得了瞩目的成就，我们的故障时间极大缩短，从以前频繁发生 B 级以上的故障，到后来连续两个季度零故障。

开发也更信任我们：）

• 以前上云时千万个不愿意：“我业务跑得很好，为什么要动我的业务？”
• 现在对我们都是说：“我也要上云，怎么上啊？”

每次回想到这里，再苦再累也值得。毕竟为了减少业务影响，很多时候都是在凌晨操作，甚至通宵到第二天白天。

总结出这样的经验文章，确实耗费我好几个周末，中间不乏修修改改，总算完成了任务！希望对读者有所帮助。