分析目前运维自动化建设过程中，各业务运维自动化系统不统一、各自为战的问题；开发团队(业务开发/运维开发)与运维团队在建设运维自动化产品配合上的冲突等多种矛盾，由此展开光宇游戏在解决这些矛盾的道路上的经历与“运维自动化开发平台(ELVES)”产生的背景，以及光宇如何基于ELVES解决上述矛盾并走上打造高效、统一的运维自动化平台的道路。

光宇游戏系统部经理黄振在演讲中分析目前运维自动化建设过程中，各业务运维自动化系统不统一、各自为战的问题；开发团队(业务开发/运维开发)与运维团队在建设运维自动化产品配合上的冲突等多种矛盾，由此展开光宇游戏在解决这些矛盾的道路上的经历与“运维自动化开发平台(ELVES)”产生的背景，以及光宇如何基于ELVES解决上述矛盾并走上打造高效、统一的运维自动化平台的道路。

运维系统化建设思考

光宇运维发展历程应该跟绝大部分同体量级的互联网公司历程基本相似，从06年11年我们一直都处于人肉运维的阶段，使用Excel,终端来管理我们线上的业务，当然随着业务的发展与机器数量的增加，这种运维方式已经无法追上我们业务发展的步伐，后来进入到了系统运维阶段，在这期间，我们开始建立专门的运维研发团队，自研运维系统百花齐放，像远程管理、交换机管理、DNS管理、以及一大堆的业务管理系统，截止到去年我们线上在用的独立运维系统还有超过50款以上，更不用提开发后用过一段时间并下线的，随着这些独立的运维系统越来越多，这些系统在上线后的维护上需要投入大量的成本，16年开始我们基于对目前已有的这些线上系统的分析及思考，通过更科学的方法将系统功能分层，并依托于底层服务系统合并众多的独立运维系统，并开始建设更加统一以及便于维护的运维自动化平台。

我说一下我们在进行这些系统平台化建设的一个思考，主要是两个层面，第一层思考是针对运维系统与服务器间的交互：对于这些独立的运维自动化系统来讲，他们的自动化过程基本上是可以归纳为对大量分布在各个IDC或者公有云机器上的系统及软件层面的操作，如我们的资产管理系统/配置管理系统在人为数据录入后需要进行真实数据的采集校验，持续集成系统需要进行构建以及分发、启动等等，为了进行这些操作我们几乎每一款运维系统都需要自己建设一个远程的运维通道供自身的系统使用。

当然现在很多这类的开源实现如Chef，puppet，Ansble，SaltStack，相信大家也都有在用，或者也可以使用Fabric、甚至Paramiko直接进行编程开发，我们以前也是使用类似的技术集成在我们的众多系统中来实现自身业务的运维自动化操作。

但随着系统的越来越多，我们发现这样做的效率越来越低，每套系统自己建设远程运维通道，且都需要进行可控机器的权限的配置管理，需要维护他们的通信安全，甚至因为我们对网络的严格管理，每个系统都需要单独进行可控机器的网络互通，导致大量人力物力甚至沟通成本的增加。

第二层思考是针对团队的建设与配合，在光宇我们非常重视运维自动化的产品的开发，最开始运维相关系统都有由运维人员开发的，一般的运维系统都是基于WEB化进行管理的，运维人员去学习这种WEB开发技术还是存在一定门槛的， 我们在10到11年就已经开始建设专门服务于运维产品的开发团队即运维开发团队，目前光宇运维开发团队也已经有20多人的规模，他们具备很强的产品设计及WEB开发技能，这样运维产品的研发工作就交由开发团队去主导，但开发出来的产品运维不愿意用，所以我们一直在摸索改进运维团队，开发团队之间如何进行高效的合作，经过长时间的摸索目前我们的合作模式为项目组形式，由开发团队的开发工程师与运维团队的运维工程师组件相应的产品研发团队开展研发工作，这样他们荣辱与共对于开发出来的系统落地情况有了很好的改观，但是同团队内的沟通及配合同样遇到较大的挑战。

要实现一款运维产品，运维工程师为需求方，他们最了解运维的痛点以及也了解业务如何实现，但是他们产品感往往不强，且缺少前端实现经验，尤其是对于现在这种前端大爆炸时代，对于他们的学习成本太高，开发工程师的产品感略强，且具备前端技能，但是他们对运维业务并不熟悉，且系统技能欠缺，这样即使他们在同一个项目组内，各自做自己擅长的工作最终整合的时候成本非常之高，往往逻辑开发1天，联调测试3天，甚至更多都有可能。

ELVES开源运维自动化开发平台

介绍完Elves后我们来对标看一下我们所提到的两个问题，第一个问题是运维通道问题，我们使用Elves建立统一的运维通道，所有运维系统不再允许自建运维通道，所有的远程调用过程统一使用ELVES实现，ELVES上游为各个运维系统，并为运维系统提供一套统一化的RESTful API，下游为操作各个业务机器，以运行在各个机器上的APP实现。且Elves内部实现安全认证，权限划分，以及多种任务模式等一系列的功能。

第二个问题在团队合作上，运维人员以Python或其他语言开发Elves-App实现业务功能，App可以手动触发运行，也可以自行在Elves-Agent提供的WEB界面上进行可视化的运行，开发工程师对接RESTful接口，每款APP的每个方法均为固定格式的接口，功能实现后运维人员只需要提供给开发人员一份简单的方法文档，开发人员即可将其对应为RESTful接口，进行WEB产品的整合，目前我们的最佳实践是运维人员先进行APP功能的开发，并且将APP当做工具来使用一段时间后再由开发人员实现WEB化的功能，所以前期不需要开发人员介入，后期基本也不需要运维人员在进行开发以及BUG的修复，只需要给开发人员讲清楚业务即可。

Elves在解决了上述统一及配合问题的同时，经过对以前各个系统任务的分析，我们实现了三种APP任务执行模式，以同步模式调用的即时任务，调用RESTfulAPI后直接获取返回结果，异步模式的队列任务和计划任务，队列任务允许用户配置各个调用的依赖，提交到ELVES后稍后再使用对应接口获取返回结果，计划任务可以设置类似于cron的精确到秒的规则，通过ELVES定期远程调用，基本上这三种模式可以涵盖绝大多是的任务过程。

下面来说一下ELVES的相关实现的技术部分，先从ELVES的组件聊一下，Elves整体由三大部分组成，Elves-Center,Elves-Agent,Elves-App。

第一个为Elves-Center为整套系统的核心Server部分，负责整体的任务调用过程，内部涵盖8个组件，这些组件是可以按需进行部署的，整套系统最小化部署为Scueduler和OpenAPI即可完成，提供无权限管理的即时任务，Scheduler为任务调用组件，直接向各elves-agent发送命令，OpenAPI向外提供服务接口，这样一条指令从OpenAPI进入到达Scheduler后发送至Elves-Agent并同步的返回执行结果。

若需要检测Agent的存活状态且支持App的自动更新，可以追加部署HeartBeat组件，HeartBeat组件开启后Elves-Agent会定期向HeartBeat发送自身信息并获取自身应安装的APP信息。如需要进行分APP的新增、删除、授权等管理，可以追加部署supervisor组件，这个组件会提供一个WEB界面供用户进行上述信息的管理工作。下面的两个组件是我们的两个独立功能组件，一个是Queue组件，另一个是Cron组件，Queue组件提供异步的队列任务的实现，用户通过OpenAPI设置的队列任务将进入Queue组件，由Queue组件根据用户的设置需求将指令发送到Scheduler后到达Elves-Agent，同样的Cron即实现Elves中异步计划任务功能。下面就是对于被控机可运行APP的授权了，CMDBProxy以非常简单的方式接入自身的CMDB系统，通过配置sql语句查询自身CMDB的方式为Elves-Center提供分类业务授权信息，这样当cmdb系统发生变化，Elves-App的授权会同步跟着变化。

最后一个组件Dashbord是为运维人员提供的组件，在这个组件上可以查看ELVES所有组件的运营健康状况，比如某组件启动是否存活，启动了几个实例以及可以查看各组件间消息的传递情况。

Elves-Center整体使用JAVA语言开发，所有组件均注册至Zookeeper进行集群管理，Elves-Center间各个组件之间的数据交互采用RabbitMQ作为媒介进行，各组件的信息传递过程使用与OpenStack一致的交互形式，及rpc-call的同步request-resonse和rcp-cast的one-way方式。

下一个部分是Elves-Agent，Elves-Agent跑在每台被控机器上，为了部署的方便采用Golang开发，提供Thrift接口供Elves-Center调用，以进程调用的方式调用Elves-App，每一个Elves-Agent提供一个信息展示及开发模式调试的WEB界面，供信息查看和快速调试开发使用。

最后一个部分为Elves-App，根据目前我们团队的情况目前我们对内提供两种语言的SDK，分别为Python的和Csharp的，每款Elves-App由两部分组成，分别为app-worker和app-processor，app-worker是每款app必须实现的，它运行在被控机上，由Elves-Agent负责触发调用，如果你想基于ELVES构建一个C/S模式的运维系统你可以实现一个app-processor，这样在目标机执行后的结果会直接发送至app-processor，当然这样你需要自己确保Agent机器与部署app-processor机器的权限互通问题。

组件介绍了，下面我们看一下一个全部组件进行部署后的Elves架构全貌，包含任务的下发，调用，执行，APP的更新等全过程。

下面说一下Elves的过程及在光宇实际业务运营中的现状，Elves项目的前身为专门实现一个WEB异地容灾产品WebOps，经过一个月的简单开发及在网站运维业务组上线了，随后我们即开始了Elves项目的研究及设计工作，经过多方面的设计与考虑，Elves1.0版本在2月进行立项开发，整体周期1个月，在今年5月份的时候随着接入的Agent以及App的增多我们对Elves进行了一次全新的兼容1.0的重构升级，并在7月在github进行了开源发布，截止到目前Elves经历了7次更新迭代，并且会继续持续更新，目前光宇的Elves已经接入超过5000+机器，平均每分钟2000+的App调用，超过10个APP，几乎每个APP都对标一个运维系统，所有的APP加起来更新超过200次。

光宇游戏平台化建设运营实践

这里我以光宇运维支撑平台下的几个重点的系统及子平台进行部分的介绍与说明，光宇目前的运维支撑平台是依托于Elves平台建立的，就像刚刚说的，目前已经有超过10款APP对标的运维相关系统，有些系统是原有自建运维通道的基础上改造的，有些系统是直接从无到有基于Elves开发的，在基础运维系统上，CMDB在光宇内部为CenterApp中心应用系统，本系统接入Elves主要采集机器的软硬件信息，与人工录入的信息进行比对，并且将中心应用中记录的应用类型信息写入相应机器的指定文件内供运维人员查看使用。监控报警上我们以自研的Radar监控报警系统为核心，接入Elves后我们实现了部分报警功能的自愈功能，如当硬盘空间报警时我们会根据不同的业务场景进行清理；安全方面我们有基于Elves研发的Odin入侵检测系统，批量操作方面有Bumblebee命令执行工具以及部分的业务子平台，这些会在后面做一些简单介绍。

先说一下我们基于Elves研发的第一款在内部使用率极高的一款工具;Bumblebee命令执行工具，这个工具是一个桌面端程序，支持批量的命令行指令执行，且兼容Window和Linux平台，并且支持运行Daemon进程的启动指令，除此之外我们还基于NC做了反射shell供紧急情况使用。为了安全性上考虑。本系统并不是每个客户端直接调用ELVES RESTful API进行命令执行，本系统本身也是CS结构，Server端进行权限的分配，以及黑名单指令的限制等一些工作，发送指令也均通过Bumblebee的Server调用ElvesAPI实现。虽然饶了好几道弯，整个命令的发送和结果回收还是非常快的，200台机器运行简单的指令如ls，pwd等立即返回结果的指令大概只需要5-6s钟的时间既可以完成，顺便说一下，我们这个系统也是开源的。

再来聊一下我们基于Elves研发的另一款产品，当我们建立好通道后有了手段可以快速的接入操作所有的机器可以非常快速便捷的开发很多有意思有价值的系统，比如Odin入侵检测系统，原理非常简单，我们通过定期的抓取所有机器的登录日志，进程，数据库连接，重点系统问题，启动项等信息，并根据不同的业务类型设置相应的白名单，当发现异常后进行报警操作，整套系统的开发非常迅速，运维人员开发相应的数据抓取APP，剩下的全部由开发工程师进行业务逻辑实现。

下一个是我们一个比较重量级的运维自动化子平台，Tron网站运维自动化平台，这个的前身就是我之前提到的WebOps系统，也就是ELVES的前身，后来将远程操作独立出来就形成了Elves，本套平台上面介绍的只是平台的冰山一角，期初建立这套系统的目标是为了我们游戏平台的异地容灾操作的，我们为光宇的游戏平台在异地建立的容灾，且定期的进行切换演戏，切换时依赖于本系统进行集群内机器hosts操作，DB主从切换操作，DNS切换操作等一系列的连贯动作，最终实现点击一键即可将所有业务从本地切换到异地。随后我们继续丰富Tron系统的功能，目前像机器初始化、Nginx集群，Tomcat集群，IIS、Squid、Redis、Memecache等服务均可以通过Tron系统进行WEB化界面的操作。整个Tron Elves app内部有超过100个功能，这也是我们在运维团队和开发团队上基于Elves合作的第一个项目也是非常成功的一个项目。

最后一个要介绍的项目使我们目前正在进行中的一个项目，Wizard混合云管理平台，在这个上面我们基于ELVES进行我们KVM的管理操作，单机的Iptables管理工作，以及接入多家公有云的API实现机器相关的所有操作。