网的发展，网游行业慢慢进入了手游黄金时代，云时代的变革不仅挑战了整个游戏行业，也挑战了游戏运维。

3.1  手游的运维工种：系统型运维，业务型运维。

3.2  手游运维业务范围：阿里云、 亚马逊 、UCloud、 蓝汛CDN、 听云监控。

3.3  手游游戏服务器架构：一般来讲都是以一组服务器集群为一个平台单位，不同的集群提供不同的服务。

手游的架构理念是提供一组虚拟服务器，当短连接的时候，每开一组服，将玩家引导到Web集群，随后被分配到不同的MongoDB，数据缓存用在Redis。当第一个服务器玩家请求DB时，会落到Mongo1上；当开第二个服的时候，还是将玩家引导到Mongo1上；以此类推直到运维发现压力累积到一定程度时，便会新开一组MongoDB，Web集群也是如此但只有性能不够时才会添加，一般情况下，每50个新服可能需要添加1个MongoDB。这便实现并解释了当时在页游里希望实现的快速开服方法。

到此为止我们已经回顾了一遍游戏运维从端游到页游再到手游的演变过程，不难看出，手游对于区服的架构概念不同于端游：端游认为一个物理集群是一个服，而手游认为一个Web请求落到相应的数据库上就是一个服。这样的好处是开服合服都简单，如果前五十组服务器需要合并，实现起来很容易，因为同一个DB的数据是互通的，所以只需发一个公告，服务器加标识即可，不需要进行物理操作也不需要数据迁移。

游戏运维最强指南

说完了游戏运维的历史，我们要开始今天的重头戏，如何做好游戏运维？这里就用吴启超的一个冷笑话作为开始：运维为什么存在？a，有服务器；b，因为研发忙不过来。不管是笑没笑，运维确实因为上面两个原因才会诞生的。那么回到正题，想成为玩转上千服务器的游戏运维应该怎么样做呢？系统部运维构建大致如下图：

1，构建CMDB

21世纪什么最重要？信息最重要！运维所需信息要涉及：机房、物理服务器、虚拟机、交换机、网络、承载业务、业务配置、承载服务进程、端口等信息。不管是自己采购还是购买云服务，物理服务器和虚拟服务器都做为资产存在，在采购后录入相关的资产管理，给它打上标签，属于哪个游戏，哪个平台，这样不同游戏平台间就不能混用服务器了。然后，是再给不同的服务器标识它承担的业务角色，比如它是MongoDB，我们需要打上的标签会是大掌门-APPSTORE-MongoDB-主库-90000端口-第一组服务。这样一个基础信息录入就完成了。

这样的信息只要是用来将来批量化部署、管理服务器使用，以及当出现故障时，运维可以很方便的查询相当的服务器以及服务信息。但是数据的及时性、准确性、可检查是一个难点。

2，集中批量化管理

CMDB不是TXT文件，而是要变成EXE文件。运维在面临大量服务器的情况下，批量化工具的出现成为必须的结果，在日常的工作当中需要把其流程固化下来，为完成批量化安装、管理打下基础。大掌门喜欢使用 ssh sshpass paramiko libssh2这些基础的技术做批量管理。原因是不用安装简单、稳定、安全、可控。当然吴启超也表示推荐大家使用在市面上流程行puppet、Ansible、SaltStack等技术，为什么？简单、简单、简单！下图就是在做自动化半自动化运维过程中的模型。

批量管理的难点在于：

a. 命令的并发执行，要控制各点的超时时间

b. 执行过程中，不同功能的不同权限要求

c. 数据通信安全的保证，以及能够正常解析数据指令

d. 人员账号权限管理，权限分发及回收

e. 物理服务器、云服务器统一化安装及老项目改造

f. 网络质量不可靠的情况下，执行不完整的情况下业务功能回滚。

3，性能与业务监控

 应用性能监控

1、每天都会对服务器进行上线，升级等操作，每款游戏在一个平台的集群数在几十个到几百个不等（根据平台大小）。因此每天维护和升级服务器压力极大，服务器异常或响应慢等问题的发生会给用户体验带来伤害。 这样的隐患在于一旦发生游戏关服之后就必须对玩家进行游戏中货币和元宝的赔偿，平均每个玩家补偿的元宝至少在5元以上，游戏币和各类游戏道具若干，以此类推由于服务器故障造成的损失可想而知。

2、大掌门使用了听云Server，能够对服务器响应慢和不可用进行定位，查看慢应用追踪和Web应用过程功能，能够实时定位消耗资源最大的代码和语句，这样就能帮助实时进行有针对性的调整和优化，并且可以快速定位问题时间，最快能到分钟级别。

3、发生高并发、服务器压力激增的情况时，平时运行正常的服务器异常概率大幅增加，日常可能的性能瓶颈点会被成倍放大，这就需要实时定位和解决性能瓶颈点，和提前进行预防改善。一般来说，传统日志收集方式耗时耗力，效果非常不好，大掌门用了听云Server后，可以进行1分钟级定位能迅速有效发现瓶颈点。同时还结合了听云Network的压测功能，能够在服务器上线前提前发现到高压力下的瓶颈点，提前预防，避免由于高并发出现的服务器瓶颈

4、还有一种性能情况需要提前预防，游戏公司盈利在于玩家的充值，对于官网上从登陆到充值全流程的成功率业务部门极其关注，玩家点击跳转的失败会直接导致充值付费用户的转化率。对此，大掌门通过听云Network的事务流程功能能够实时对事物流程进行警报，帮助业务部门提升用户充值的转化率

 业务监控

除了性能和硬件监控之外，对于游戏业务运转是否正常也需要建立一套标准去评判。

对此，大掌门开发了一套适用于全公司所有的游戏的统一登陆、充值、交易平台，解决了前端的SDK接入的问题，一个所有游戏或第三方的API接口统一接入的平台。在做业务型监控时，运维会要求后端开发人员写一个特定账号，在访问现有系统时，会完整的走一遍业务流，这样就可以看到需要的业务数字。

4，数据仓库搭建

上图为大掌门数据仓库的结构图，由于数据仓库搭建的话题比较大，只是简单的从数据集市的角度来聊聊，DM指的是数据集市。由于数据集市需要面对不同的人群，因此在数据仓库中需要建立不同的数据集市以面对各方的查询需求，进而对数据按照业务类型进行分类。

1、财务：关心月度充值数据

2、商务：关心渠道结算数据

3、运营：关心用户登陆量、转化率、留存率、平台充值额

4、产品：关心功能热度、用户体验

5、客服：关心所有数据及玩家属性

对于数据方面，运维的压力来自于需要贯穿及掌握所有的数据，并且为所有部门服务。简单的以下图的ETL为例：

数据对于运维的痛点：

1、日志切