游戏运维的最佳实践：搜狐畅游自动化运维之旅！

搜狐黎志刚见证了畅游游戏自动化运维平台的从无到有，经过在其中踩过的坑、解过的结，他向你们来阐述游戏运维的进阶之路。本文主要围绕畅游游戏管理体系与运维自动化的演变历程、运维自动化的实现及将来运维四方面展开。

畅游运维管理体系与运维自动化的演变历程

畅游运维管理体系演变历程

从 2008 年毕业以实习生的身份进入搜狐畅游，我同公司一块儿成长，经历了整个运维管理体系从小到大的过程。

整个运维管理体系是从最初石器时代（脚本化），以后的青铜时代（半自动化）、蒸汽时代（DevOPS）一路演变过来，如今处于自动化和智能化过渡阶段。

畅游运维自动化演变历程

以下图，是畅游运维自动化的步骤，分别是数据总线统1、业务自动化、标准化统1、服务驱动和智能运维。

对于已发生故障进行分析发现，40% 的故障由数据不许确致使。出现这样状况，是由于自产信息或不少系统之间交互信息带来的问题。

因此首要作的是数据的系统、准确性、调用及引用接口的统一。以后对数据和文件分发研发了一系列平台，还有各个平台标准化的统一。

以下图，是畅游运维体系架构：

最底层采用的是混合云的模式，在这基础上，又建设了多个如海豹、集中配置管理、管理和服务相关的支撑系统，还有最重要的天使和监控告警系统。

天使系统的主要职责就是权限管理，畅游各运维人员所负责的游戏各有不一样，因为游戏版本的特殊性，一旦泄露，会对整个游戏的营收形成很大影响。

因此，要严格管理每一个工程师的权限。监控警报系统之因此重要，是由于涉及到全部游戏玩家的体验和收入。

畅游游戏运维自动化实现

游戏运维的特色和痛点

面对这样的运维体系架构，畅游都在哪些部分作了自动化呢？咱们先来看看游戏运维有哪些特色和痛点。

每一个游戏的构架和应用场景，乃至于所使用的数据库和开发语言彻底不一样。还有不一样国籍开发的游戏，整个操做系统和数据库环境、版本都存在大量的不一样点。这样一来，运维整个平台和环境都要面临很大挑战。

游戏运维的痛点有不少，如：

● 运维脚本及工具零散、数量多、难复用。

● 资源需求弹性大。

● 成本、效率与可用性的平衡。

● 大流量的高并发。

● 故障须要实时处理且尽快恢复。

● 多版本管理。

为克服这些痛点，近四五年，畅游运维作了不少事情，业务和工程师人数等方面都有变化。

从 2014 年到 2016 年，业务每一年实现 20% 的增加，全职工程师在不断的减小，这是由于 2014 年到如今，咱们作了大量的自动化工具，利用自动化平台和资源整合，每一年资源成本减小 30%。

2016 年 CMDB 海豹系统上线，对全部在线资源进行整合，公共集群建设的完成，把单游戏和每一组游戏所需公共服务放在一块儿，使得资源成本减小 50%。

这里值得一提的有趣现象是 2014 年到 2015 年的人为故障数量基本持平，这是自动化带来的反作用，2016 年人为故障降低了 30%，此时自动化的做用开始发挥出来了。

2014 年到 2015 年的全局故障率（网络故障、硬件故障等全部的故障）减小了 20%，2016 年故障率降低了 35%。

咱们为何能够在业务增加的状况下，依然能够作到故障降低和成本节约？

分析缘由以下：

● 40% 的人为故障是因为信息不许确或是人为操做失误致使的。

● 30% 的人为故障是因为跳流程操做和研发的沟通壁垒。

● 50% 以上的成原本自于空闲资源和故障资源，以及服务器性能资源未能充分使用。

针对这些缘由，畅游运维作了不少事情，下面主要分享如何经过海豹系统作信息的统一化和标准化、PaaS 平台实现 Devops 自动化交付以及 Docker 容器技术和混合云架构等内容。

游戏运维自动化平台的技术及逻辑架构

对于游戏运维自动化平台应用来讲，是既定的计划，能够当作任务来执行，全部开服、关服、更新、数据回档及档案恢复等全部操做均可以定义成任务或工做流，以后把全部的设计所有按照任务系统的架构来设计便可。

在平台设计过程当中，系统主要使用 Python 来进行开发。由于从 2015 年开始，咱们发现，若是所有用 Java 来开发的话，运维人员的参与度会很是低。

假设运维人员对 Java 不了解，运维和开发之间需求沟通就不畅。这里的解决方案就是一线运维人员必需要懂 Python，并且要参与到开发过程当中。

以下图，是自动化运维任务的系统架构：

自动化运维任务系统是结合开源技术与公司现有资源的运维的基础操做平台。不只支持脚本执行、定时任务等基础运维场景外，还提供了流程式开发框架，使运维人员能开发本身须要的业务维护功能。

海豹系统（CMDB）

海豹系统承载畅游硬件层、应用层和网络层等运维层全部信息的记录，如设备、配置、关联权限、关联拓扑、关联环境、关联流程等。基于这些信息，以应用为核心，经过业务场景进行驱动。

以下图，是海豹系统（CMDB）的功能架构：

整个功能架构从下至上分为数据来源、数据层和应用层部分。用以管理系统中心的服务器及相关的软硬件资产信息，是全部系统资产信息的来源。数据层对全部资产进行查询、变动及管理，经过统计报表模块图展现资产的状况。

以下图，是海豹系统（CMDB）的功能架构和技术架构：

这是海报系统的最初时期，由不足五人用 Java 写的核心架构。引擎部分，之因此还在用 JSP 和 Freemarker 引擎，是为了兼顾老的系统。

以下图，是海豹系统（CMDB）的界面：

全部的端游、手游的信息会集中到海报系统，意味着资产管理专员能够经过这个平台作全部资源初始化和分配调度。

PAAS平台

经过业务逻辑把各个资源统筹起来，资源所见即所得，更容易的实现了持续集成，经过各项基础服务的组合，实现代码自动化发布、应用管理、环境初始化部署、线上运维一体化集成，提高项目代码编译、测试、发布效率。

PAAS 平台主要职责以下：

提供一致性环境保障。

● 提供应用多租户隔离以及资源的多租户隔离。

● 提供服务发现、可弹性伸缩、状态管理、资源分配、动态调度等能力。

● 支持预发布、一键发布、一键回滚以及自动化部署。

● 提供透明化的监控、容灾能力。

● 提供运维、开发、测试多角度业务场景。

以下图，是 PAAS 平台的主要技术选型：

从上图能够看出，PAAS 平台里也包含外部组件，Docker 也包含其中。由于游戏公司大量代码基本都放到 SVN，因此咱们也会选在 SVN 来管理。

Docker 容器技术

PAAS 平台的设计中，核心部分是 Docker。那搜狐畅游的 Docker 是如何设计的呢？

以下，是原 Docker 架构图：

以下，是最终版的 Docker 架构图：

从 2014 年至今，咱们已经迭代过两个版本，搜狐畅游在容器监控数据共享、稳定性和镜像管理等方面进行了优化。

以下图，是技术演化对比：

因 Ceph 副本之间不稳定，不支持集群共享，因此改为 NFS+DRBD。因 Consul 集群 Leader 切换频繁，业务数据不一样步，负载太高，改为 Etcd，来保证数据同步统一。

为应对 cAdvisor 没法汇总，没法查看历史数据的问题，咱们自研了 Hunter。操做系统从 2.6 升级到 3.18，应对运行久了后 devicemapper 的信息没法写入致使系统异常的问题。

混合云结构

畅游运维体系最底层采用的是混合云结构，开始考虑的方式是直接接入全部公有云，用专业的方式打通，但游戏须要 BGP（网关协议）。

这意味着必须多线接入，除电信、联通外，全部的小区宽带，第三方宽带也必需要接入，因此须要选择混合云的结构。

选择混合云相比畅游 IDC 下降成本在 20% 左右，而且使资源弹性，云上云下，扩缩容更快速。在可靠性方面，不只可实现异地双活，还有抗***、DNS 劫持、冗余可靠等优点。

畅游运维管理体系的下一步探索

畅游运维管理体系的下一步将把持续交付的分层能力和公共服务标准化做为探索方向。

持续交付的分层能力

在畅游运维作自动化时，会利用可持续交付的理念和原则去作。工具开发过程当中，必定要注意的问题是：工具越多，工具与工具之间的调用就会出现大量的问题。

因此必定要进行平台化和作成集群式服务，不然成本不会下降，反而故障依旧会不少。

公共服务标准化

以下图，是公共服务平台整合架构：

畅游把 redis、Nginx、MySQL 等集群所有接入，不须要作其余的事情。

写在最后

畅游运维作整个自动化过程当中的心得有三个：

● 简单有效，不要作特别花哨，由于对应用最实际才是有用的，对应用或开发人员来讲，最有效及效率最高是最好的。

● 符合实际业务，不是脱离研发和应用。

● 高效，游戏特性决定必须高效，快上快下，快速决策。

以上内容根据黎志刚老师在 DevOps 与持续交付专场的演讲内容整理。若有投稿、寻求报道意向技术人请联络 wangxy@51cto.com

游戏行业近十年技术管理经验。2008 年加入畅游天下，现任系统运维中心总监及项目管理部经理、打造百万用户在线游戏技术运维平台。   近年来，致力于建设一流的游戏技术团队，负责全面管理运维工做，包括   IDC/网络/硬件规划管理、系统运维、数据库运维、应用运维、运维平台与工具开发等；创建和完善规范化的运维体系，保障运维质量；   不断研发与探索运维自动化及各种创新途径，缩短运维响应时间，减低运维成本。