2017 年 12 月 23 日，来自百田游戏运维总监卢祥钜在又拍云 Open Talk 第 39 期活动上作了题为《落地游戏自动化运维》的演讲，以下是演讲实录：

广州百田专注于儿童互联网产品的研发与运营，并以中国儿童为核心用户服务辐射到家庭互动内容及服务，其核心业务包含儿童网页游戏、手机游戏、在线教育产品、动漫IP孵化等，是中国儿童互联网内容与服务提供商先行者，也是目前中国儿童互联网娱乐首选目的地。

一、自动化运维的重要性

做游戏运维，有很多琐碎的事情，如果全部用人肉运维，其实跟搬砖没差，是一个很累且无趣的事情。

为什么要做自动化？首先，做游戏运维琐事很多，拿日志、发布各种文件、开服、合服等等，这基本会把你的工作时间压满，所以如果不做自动化，基本上你一整天都会做一些很无趣的工作；其次是效率低，有一些工作如果有脚本或者自动化平台，可能几分钟、十几分钟就完成了，但是如果人工去做的话，可能你需要花费半天甚至一天的时间；第三点是容易出错，做运维如果手工操作，很容易犯一些错误，包括误删、改错配置等。

二、如何做自动化建设？

（一）标准化

1、 打包格式

打包格式是指什么呢？通常开发会把一些程序包给运维，运维必须要将这些文件的命名进行规范。如果你不定义这些名称，那么开发们就会毫无规则，你就不能按照程序的角度去解析，需要人工介入更改，因此这些事情需要提前标准化。

2、线上标准

线上的规范与标准对运维来说，就是生产环境的东西，包括开源软件的使用（redis、MySQL等），机器配置等。

3、业务规范

业务规范是业务层面的事情，如何与运维对接？举个例子，可能每个游戏的开发、合服的设置都是不一样的，如果你不要求他们做成一样的，那么你就有可能要忙于对接各种不一样的游戏。运维在处理上会非常麻烦，需要人工介入、调用，到后期会相当痛苦。

运维标准

我们公司会制定很多标准，会把这些标准在部门内部固化下发，有一些标准会公示到项目组中，让他们按照这个标准来执行。如果他们不按照这个标准，我们就会将他们提交的东西打回，重新来过，严格按照标准。

这里面会包括监控、开源软件、目录等的情况。

（二）流程化

1、抽象运维流程

和标准化相比，流程化是定义怎么去做的问题。如果你要上线一个产品，你需要定义它的所有流程，规范好每一步如何执行，这样就不会因为不同的人理解不同而得到不同的结果。需要规范好，将每个步骤抽象出来。

2、规范化

如何做需要统一，不能每个人的做法都不一样。

3、减少琐事

减少琐事，可以避免一些会扰乱流程、让流程无法继续的事情。回过头来思考，其实很多琐事的产生都是因为源头的流程没有规范好。所以当你发现有很多琐事的时候，你需要重新查看你的流程，如果是流程的问题，就不是从运维层面来解决，而是需要推动项目组与运维对接整个流程。只有梳理好流程，你的琐事才会减少，才能有时间去做自动化运维的事情。

（三）设计 CMDB

CMDB

CMDB 相信大家都不陌生，自动化运维必须依赖一个 CMDB ，它其实就是组织线上的线网资源的关系。

我们设计的时候主要考虑两个方面。首先是主机层面、服务器和数据库，对于机器，需要了解它的 CPU 内存、IP 地址、硬件信息、系统信息、内容版本等这些主机上的一些信息。另外一个是服务的情况，主要考虑这台机器上部署的是什么，例如部署一个Web、redis 还是 MySQL 等，这些都需要在 CMDB 内定义好，然后主机通过 CMDB 关联到它的服务。

完成前面步骤后，我们需要在运维层面上对自动化做一些支撑。支撑主要用两块东西：其一是ansible，ansible 是一个比较简单的自动化工具；另一块是我们自己编写的 python ，我们的技术站就是比运维层面的技术站简单一些。如果 ansible 不满足的话，我们会自己研发一些脚本去完成一些自动化的操作。

三、自动化落地实践

自动化落地实践

我们去年打造了一个 OP 系统，是我们内容的一个自动化系统，它的名称我们定义为 OPUV ，就是运维的意思。

（一）OP 系统

OP 系统有几个模块，核心是 CMDB ，它依赖于监控系统、辅助系统和域名管理；还有角色管理、配置中心和流程系统。

1、CMDB

CMDB 是一个采集的同样，我们对 CMDB 做了 agent ，agent 通过代理把一些机器的信息包括主机的 CPU、内存或者系统内核版本等，全部通过 agent 自动采集下来。只要机器装好 agent ，它就会自动采集、搜集回 CMDB 。

另外有一个人工录入的部分，有一些信息其实没有办法很好地去自动采集，例如一些物理信息（机房信息、机架信息等），这些只能提前录入到系统中，然后与其他信息匹配起来，这些全部聚合起来就是完成了一个 CMDB 的录入。

CMDB

以上是我们做的 CMDB 的界面，这其中会有一些项目、分区、机器的信息。由于涉及到一些敏感信息，这里就隐掉了，它其实会把主机 IP ，网络情况都会列在这了。

CMDB

点进去还会有更详细的情况，可以看到这台机器的监控情况，例如我有多少分区、内存使用了多少、CPU 情况如何等，这些服务会关联到响应的主机。

2、流程系统

这个系统在不同的公司可能叫法不同，我们称之为流程系统，也有人会叫作业系统，不过原理其实是一样的。

流程

流程的极小粒度是命令，流程就是一系列有序的命令的组合，如上图大框是一个流程，有命令 1-7 的组合，然后按照命令 1、2……一直执行到命令 7 ，然后把它封装成一个流程。例如发布一个文件，第一步要关闭服务，第二步上传文件，第三步同步文件，第四步重新启动服务。这四步原始操作全部封装成一个一个命令，把四个命令组合起来，就是一个发布任务的流程。

流程化后，自定义的自由度比较高，无论是一个什么样的运维操作，只要能梳理出它运作的情况，就可以封装成一个流程。我们可以封装很多自己的一些运维操作流程，例如部署、下载日志、重启服务、以及各种自定义的操作，我们的人可以直接登陆到流程系统里面进行操作。

很多操作其实我们是放权给项目组使用，比如做 docker 测试，就有权限使用我们的流程系统。一些例如日志信息的一些比较固定的流程，根本不需要运维介入，只要是开发或者测试，在这里直接可以下载，如果有异常再由运维处理，这样可以大大节省运维的时间，提升工作的效率。运维需要做的事情就是提供各种不同的流程给自己或者项目组来使用，开发和测试等是没有权限去配置的。

当然，这个系统需要有一个日志记录，必须将什么人做了什么事情记录到系统内，这样会有一个审计的做用，不然某些人做了一些危险的操作却无处可寻。

我们的流程系统，会封装很多的操作，包括关闭站点、发布文件、获取日志等，都有总体的发版，发版就是一个完整的部署流程，我们都可以封装在这里使用。如果复杂的项目，可能会有很多的流程，可能会有很多的流程。这种流程自定义让之后的工作都变得很方便，如果有什么新的操作，就不用通知开发把自主化系统重新做一遍，只需要运维去添加流程，把对应的接口的脚本或者是 ansible 对接上，然后就会出现一个新的流程。之后不管遇到什么样的新的流程，都可以直接使用这套东西来应付。

3、配置中心

配置中心的功能比较简单，相当于提供一个模板和变量。把这两块组合起来，这就解决了开发环境与线上环境差异的问题；线上与线下可以共用一个模板，key-value 相当于一个变量和一个值，它就是不同环境的不同定义；CMDB 数据是我们之前录入的数据这三者结合可以生成到线上的一个真正的配置。

配置中心-模板

模板有很多种可以实现，很多模板语言包括 python 、java、smart 语言等，有很多开源的选择，不需要自己研发。以 iptable 举例，iptable 如果使用物理机，必须要开启 iptable 去保护他们的安全，限制或者放通我们的业务端口，因此需要这样一份模板。我们会定义一些变量，每台机器的变量是不一样的，配置也不同，公用的东西都可以用模板语言去写出来。然后当经过配置中心之后，变量会自动在配置中心去寻找 key—value 跟 cmdb 数据，自动来填入。key —value 是自己定义好的一些变量，数据中心提供一些 IP 或者端口的信息，端口是从服务组或者服务里面提供的。这样填充完之后，它就是一个适合到每一台机器或者集群的配置了。

（二）业务支持

自动化系统可以支持很多操作，例如自动部署、开服、部署新区等。部署新区的概念就是比如做海外发行时，一个游戏需要发布很多个区，如果需要发布韩国区域、日本区域等版本，同样的游戏其实它的代码与架构差不了多少。如果每一次都由运维介入开新区，其实是一个很麻烦的操作，所以我们把新区流程梳理出来，然后介入到我们的 OP 系统中，这样可以解决 90% 的问题，原来需要 2 天工作时间可能只需要半天甚至 2 小时左右就能完成。

查询获取日志和查询执行SQL ，通常这种事是由于项目组需要有权限获取一些日志或者自定义一部分的查询SQL 。

以部署和开服、合服为例。自动部署要先把之前说的流程做规范，大致有以下几个步骤：上传程序包、配置中心、分发文件、启动服务。

自动部署

如上图，用户相当于一个项目组的开发、测试或者运维，他可以把文件上传到我们的流程系统，接着流程系统通过配置中心或者 key-value 中心进行组合，一些关键的数据比如 IP 端口等可以通过 CMDB 获取，返回流程系统进行组合，按照之前定义好的命令就可以支撑到 ansible 或 python 脚本，执行一遍，然后把它同步到 game server 外部服务器，完成整个部署的操作。这个相当远只需要上传一份代码，整个过程都是自动化完成。

关于自动开服，我不知道业界游戏有没有做自动开服，如果开服多，其实开服是一个很麻烦的操作，我们目前是这样整理的。第一步，输入一些运营信息，例如有一个服务名，这个服的名字、ID、在哪个区、什么时候开服，这些都是运营信息，这些信息运维不太关系，完全是由运营来决定的。第二步，运维分配资源，其实就是 redis 用在哪里，数据库用哪个实例，game server 可能是放在哪个实例里面或者哪个机器等，之后 OP 系统可以通过一些 API 接口获取运营的信息。第三步，初始化流程，包括安装什么软件、配置什么文件等。第四步，清档，这个概念不做游戏的会比较陌生，它相当于是把数据库初始化一遍，清理赞数据，将活动信息、开发信息查到数据库中。

自动开服

如上图，流程系统中有一个 API 服务，API 会通过定时的任务在运营后台抓取数据。运维通过介入部分信息，解决服务放在哪里或者资源如何使用的问题，但如果资源足够多，运维其实不需要介入，会有一个算法可以实现。例如如果数据库可以放几个实例，在它容量还没满的时候，可以自动分配，但如果满了，就运维就需要介入，去生成新的资源，而且要指定哪个服的资源用到哪个实例里面。信息填充完全后，它会按照顺序执行你设定的流程完成后续的工作，会把它的一个分发或者应该操作的地方分到响应的服务组内，包括执行一个更改数据库的配置、把文件同步到游戏服里面等。

完成所有步骤后，就可以开服，开服的流程也自动化做好。开服其实不是立刻将那个游戏服打开。我们把时间插入到数据库中，由程序控制。当到了某一个时间会自动开服，而我们要做的事情就是把应该初始化的内容全部正确初始化，包括一些清档的工作也是在这一步完成。

完成之后，我们还会在流程系统上做一个邮件，保证在完成了一个开服功能后，会发一封邮件出来，然后运维可以人工再查看一下是否有其他问题。通常如果稳定的话都不需要怎么关注了，开服就是基本这样一个流程完成。

四、总结

总结一下，落地自动化运维的话，我认为比较关键的就是以下几步。

首先必须制定一个标准，这套标准将会影响到你能不能做成自动化。如果各自有各自的标准，那么很多东西就没有办法推行，可能你的自动化规则适应项目 A ，但是项目 B 一出，你就需要重新打造一套，那么相当于没有自动化，每个项目都要做人肉运维。

第二个是梳理流程，这个梳理流程就是要介入我们的流程系统，清楚每一步做什么事情。

第三个是制定 CMDB ，CMDB 在其他的很多分享，运维也都介绍过很多，所以我这里没有详细介绍。

last，是做一个自动化运维的平台，比较关键的就是流程系统与配置中心，只要这两步出来以后，整个自动化的流程基本上就可以打通。