正文
这个好像挺无解的，我们运维干了一件事情，我们从原来的开一个服，我们把它变成了一个池子，这个池子就是当注册和 PCU 达到一定量级的时候，我们将这个服关闭推荐，而自动推荐其他服。
推荐服是什么意思：大家玩游戏可能都会注意到一点，新手登进之后，会有个默认推荐服在那里，你自然会点进默认推荐服。
所以下次当你看到上面这条曲线是上面这个情况的时候，你可以把几个服做成一个池子去推荐，避免瞬间撑满，而是均衡灌满。右边这个流程是我们的整个自动推荐服的流程图，5分钟自动轮循一次，达到这样一个效果。
这时候你的项目组会非常买你做的事情，因为你干的活好像不是很复杂，但是解决了他们一个很大的痛点，他不需要一开服就合服。
3.4 合服向更高进阶
讲完开服的服务进阶我们再讲合服的，合服这个就相当于前面的一些鬼服把它合在一起。
最正常的一个工作流程是这样的。项目组运营团队会提交需求，开发团队会提交数据合并工具，因为合服最大的工作量就是把数据库里的数据做合并，你有很多社区、社团或者玩家的角色名称，你要把它合并在一起，开发必须提供数据合并工具。
运营团队会提供一个N合M的过程，有可能是2合1，有可能是3合1。大部分的运维同学会收到这样一个表格，xxx服务，活跃多少，合并到什么样子。这是普通的运营团队会给我们的数据报告。
做得好一点，他会给我们一个这样的报告，因为什么原因，从几个维度上看，分别选取，像日活跃、开服小于多少天的区服列表等，拿到之后，运维团队会挑选合适的服务器，这个是我们该做的。
接下来运维执行工具，做数据合并，然后正式对外开服。
整个运维的工作里面，最大的工作量就在数据合并的过程，有很多会出错，特别是做 DBA 的兄弟，肯定天天吐槽合服的事情。数据合并特别是在腾讯这样数据量特别巨大的情况下，我们目前能够做到的2016年的场景是2到3小时能够完成一个服的合并动作。
当然包括完成所有数据的清洗包括重新导入的，包括处理数据异常的过程。周而复始这样去操作。这样一个服务其实只能说你做好了本份的事情，整个增值的效益完全没有体现在这里。
既然做服务，看一下在腾讯游戏运维里面是怎么去做的，这个是目前我们真正的合服的流程图。
首先可以看到，我会根据项目组给我们的条件，会帮他们做一些筛选大区，比如说 PCU 小于多少，DNU 小于多少，活跃付费率小于多少的大区，筛选这些大区属于需要去合并的大区。
筛选完之后根据一些组合，我们不希望项目组只是通过很简单的 excel 表格去做，我们会去帮他做开服天数相近等来进行合服的组合，给项目组推荐哪几个合服组合是合适的。
最后会给到一个合服后的数据分析对比。这些数据我们做更好一点，我们会把这个数据放到合服预估里面去。
为什么叫合服预估？因为合服是一个周而复始的过程，你做得更好一步，你需要把这个定期推给项目组。
这个是我们内部的截图，会根据他的规则选择条件，当他有数据异常的时候会提醒他出来，会标示出哪些是符合规则、哪些不符合规则的。这些是项目组现在关注的，因为你帮他解决工作效率的问题，但那是不是就足够了？做完这个还不够，我们需要关注整个项目组未来能够做得更好的一点是什么。
做游戏有一个非常大的关键，如果你理解这个游戏业务的话，你会发现，如果想让这个服合并之后会效果更好的话，其实你需要去考虑，合服里面的用户，不只是说你只把 DAU、客户、付费能力相加一起就可以了，因为你还需要让玩家保持经济平衡或者社区平衡，引入这些因子之后，你对运维的技术挑战提升就会要求高很多。
你需要在组合里面考虑这些因子，我们怎么做，在这里面我们引入了大数据的算法，目前用聚类的算法，帮项目组
聚类
出哪几个服的战力平衡、经济水平平衡，通过这个推给项目组，这个是我们整个合服的进阶。
接下来整个合服之后的效果对比，我们会跟踪他的 PCU、DAU 的数据对比变化，给项目组更好的决策数据。包括 DAU 的分布、ARPU 值的收益分布等。
这是我们上线半年来我们做到的收益，我们已经累计给项目组节约了260个小时，我们的推荐区服已经被使用了7368次，详细效果如下：
3.5 服务建设过程中的几个问题
在整个服务建设过程，我们都会很怕产品团队提很多需求，因为做IT的实际上是不断在挖产品需求，你一旦开始挖产品需求了，就会带来一个问题，产品团队他的需求会不断的变化，他也会有自己很好的想法给到你。
我们从服务开发者的角度或者服务建设者的角度上讲，他会从集成平台这里，开发者中心，开发者框架，给我们快捷的支撑。
同时刚才大家也看到前面的服务建设里面，我们会用到很多的原子和功能，在下面这个作业平台里，有丰富的原子层，能够让我们组合起来灵活快速。
4、向外部产品的用户延伸—版本服务
讲完这个服务以后大家还是会有疑问，刚才讲到的都是服务于内部用户的，既然你想从幕后到台前，只是让你的产品团队、你的老板都知道这样还是不够的，最好的方法是你能够服务于你产品使用的用户，那才是最能够从幕后走到台前。延伸到产品的用户，怎么做？这里不讲太多废话和道理，直接来看案例。
从内部到外部，我们通过一个版本服务案例讲一下，这个案例大家可能会更容易理解一点。
4.1 版本服务在日常发布中的应用
因为做版本，只要做运维的都接触过，不像前面的开合服，只有做游戏的才会有这种业务场景，离开了游戏其实很难有这种业务场景。在做版本服务，做发布这个事情上，我们可以做什么？
还是看一条曲线，这个曲线有个非常简单的特点，红色的线是发布日的曲线，黑色的线是平时的业务曲线，这两个点是我们运维最关心的点，就是发布时长。从2012年的3到4个小时到2016年的0.88个小时我们可以完成一个版本的发布对外。
实际上来说这是不够的，我不是说发布时长我们优化得还不够，而是我们做运维来说，我们关注得还不够。因为关注的只是产品中你目前知道的事情，本份的事情。哪些是产品关心的事情？产品关注收入、DAU，一个在线恢复时长才是产品最关注的事情，在线恢复得快，DAU和日常的DAU是一样的。
4.2 版本服务在线恢复中的应用
在线恢复快，玩家的在线时长也会同样加长，比如说你等到晚上8、9点钟玩家才能进到游戏，你的在线恢复到正常水平到晚上8点钟，还是说你上午一发布完，中午玩家就进来了，其实这是有本质上的区别的。
