在面临高速发展的移动互联网游戏行业，对运维能力的要求变得越来越高，传统运维已经无法适应当下的节奏，如何随着时代演变而进步，如何能在危机中给自己创造机会，抓住要领才能坦然面对万变。

运维服务定义

谈运维服务体系之前，首先明确什么叫运维服务。发布、变更、故障处理+SLA就是运维服务，但不能算为全部，这仅仅只是基础服务。今天在这里我们将重新定义运维服务，运维服务是指被你的产品或你服务的团队关注并且产生增值价值点，同时可计价的服务，也可以称之为运维增值服务。 运维服务具备三个特征：

用户关注

增值效益

可计价

腾讯游戏运维服务体系的演变历史

腾讯游戏运维服务体系如我们人类工业时代变迁一样，一直在随着“技术”的发展而不断演变。

1.0 手工时代和 2.0 脚本时代

第一个时代，我们称为手工时代，在2008年以前，服务器的搬迁和业务的上线发布都是由人工进行的，该时代不堪回首，运维又苦又累。从 2008 年到 2012 年，随着 shell 的大量使用，我们进入了2.0脚本时代，据统计，我们一共拥有超过5万个脚本，这两个时代的运维服务体系的特征，就是支撑着发布、变更、故障以及迁移等基础服务，做好基础是整个团队存在的关键点。

3.0 自动化工具时代

从2013年开始我们正式迈入了3.0自动化工具时代，在这个时代，业务规模增大、自动化运维工具上线、团队成员逐渐成长，我们得以思考运维服务的进一步演进。目前使用的腾讯蓝鲸平台得益于标准化的建立、运维岗位分工的细化。该平台依托SOA理念和云技术构建的运维模式，以“原子服务集成”和“工具开放构建”的方式致力于解决“运维基础服务”的无人值守及“运维增值服务”。

运维服务要如何设计才可以让产品关注并且体现运维团队的技术和专业度以及效益。

首先要做产品关注的事情，所以服务设计必须从产品运营活动场景出发，其次要体现效益，运维以技术为根基，服务通过整合技术解决方案并且通过服务窗口统一对外提供，助力业务取得更好业绩。

依据这些因素，我们根据产品运营活动的八个场景设计出对应的运维服务：

产品运营规划 ：架构设计服务

版本活动 ：版本服务

营销活动 ：营销活动服务

关注高可用 ： 高可用服务

用户体验 ： 用户体验优化服务

成本控制 ： 成本优化服务

安全保障 ： 安全保障服务

运营决策辅助 ： 数据视图服务

同时需要配套一套运维服务的质量衡量指标，用来衡量和体现自己的价值。

服务体系中的某项服务是如何运作和产生效益的？下面分享两个案例：

案例分享 1：版本服务

版本发布是运维的日常工作之一，在提供版本服务时，运维一般比较关注发布时长，通过标准化和自动化的工具建设，可以去不断优化和压缩版本发布时长。而产品则比较关注在线恢复时长，也就是什么时候在线可以恢复到平时的水平。因为在线恢复时长会直接影响到业务的两个指标，DAU和在线时长，这两个指标是项目的运营指标，所以产品团队会更加关注它。

这意味着我们运维团队要做好版本服务就需要做在线恢复时长的缩短。在线恢复时长从某些意义上说，完全由用户行为来控制，我们运维团队如何去影响？

深度分析影响在线恢复时长的因素：

玩家游戏的时间点，会影响版本发布时间点和更新包投放时间点；

玩家更新版本包所需的时长，它由分发量、用户增量、更新成本、部署自动化和投放自动化来决定；

为了减少在线恢复时长，我们采取了如下图的措施：

从 2013 年我们进入了自动化工具时代之后，在用户和包量增长200%的情况下，我们

的在线恢复时长下降了 90%，并且带宽只用到了原来的 50%。

接下来介绍版本服务的逻辑框架。

不同的业务有不同的版本需求，除了我们日常做得最多的部署之外，其他最关键的是灰度控制、拆包、用户数据分析、推送时间、自动推送等模块，底层支撑均由“蓝鲸”的PaaS平台提供。如果只有标准化和自动化的手段，是无法让我们实现这样的效果的，依托蓝鲸数据通道，可以很容易地获取和分析业务数据，利用蓝鲸的定时任务管理系统可以精准投放版本包以及拆包的内容。

介绍到这里，我们发现“用户关注”、“增值效益”、“可计价”均可以实现，从效果看还是不错的，正所谓少花钱多办事。是否说我们服务体系的建设就按照这个思路继续进行下去就可以了？其实并不够，我们在建设版本服务中碰到了几个关键的问题：

逻辑框架环环相扣：单个服务内的能力很难被其他服务借用；

依赖业务运维个人的能力：需要去了解和驱动获得每个业务的数据；

业务团队更加复杂的需求：触发业务团队本身的思考，对于单用户有更多的需求；

成本控制：服务在运营成本的投入减少了，但是会增加人力的投入，特别是腾讯的游 戏业务类型和个数众多，并不能所有业务一视同仁；

因为架构的思路更加容易被运维技术团队接受，我们引入了“微服务”架构设计思路，它有三个关键点：去中心化、解耦合、独立演进。接下来将以“下载服务”来给大家介绍我们是如何做的，前面介绍的版本服务有一部分跟下载服务有关联，服务分解之后也可以有效进行服务间的复用，所以我以下载服务为例，介绍拆分后的效果。

案例分享 2：下载服务

依据“微服务”，我们进行了服务分解，消除环节依赖，并且进行了成本细分。服务分解之后可以有效进行服务间的复用，下载服务一共拆分为7个服务子项，拆分之后每个服务子项可以独立提供服务能力，同时也可以随着需要进行组合，两两组合、三个组合甚至更多，通过组合可以更好地提供业务所需要的解决方案以及服务独立演进和计价。

经过了独立演进，下载服务从原来四个服务子项，优化拓展到八个服务子项，其中也

包含了可以独立提供给版本服务的功能子项，以及能够不断演进，特别是以单个用户为维度的演进，我们做到了“用户分级”、“地域”以及“单用户 IP”。

引入“微服务”架构设计思路之后，整个服务体系更加“灵活”、“可见收益”、“独立计价”、“独立演进”并且更具“拓展”能力，同时具备服务之间的解决方案联动使用。

在新模式下，下载完成率整体业务提升20%+，玩家关注的下载时长下降60%+，这些都是在没有增加下载CDN成本的条件下做到的。这些还不够，业务团队还不够关注，我们还解决了业务团队最为关心的转化率问题，在整体转化率方面，我们也提升了10%+，并且可以跟踪到单个异常玩家。

游戏运维服务体系进阶

腾讯游戏运维服务体系按照产品关注和活动场景重新划分为版本、运营活动、成本、用户体验、运维咨询以及安全六个大类，六个大类下再进行划分服务子项，原来的高可用服务和架构设计服务均衡分布在各大类服务中，并且具备按照业务项目团队进行按需组合和复用。

服务化、产品化是运维团队的专业和价值体现，依托业务助力业务一直是我们的理念，推动运维团队不断向前，这个是我们内部称之为“云梯”的服务体系。

信息和物理融合正在继续驱动工业走向4.0。云的快速应用以及蓝鲸的加速成长，压缩了整个业务运维团队的空间，但同时蓝鲸结合运维大数据、Docker等技术的快速应用也给了业务运维更多的机会，我们将持续演进，迈向运维智能化。

运维智能化需要具备“感知、分析、决策、执行、呈现和保护”六个能力项，同时需要团队的文化氛围支持以及人才的转型，在这六个能力以及两个关键因素的支撑下，我们必将迎来运维行业的4.0--智能化时代。