服务才是未来 腾讯游戏运维的实践分享

运维 系统运维 系统
运维服务的“四化建设”,即标准化、自动化、服务化、产品化,帮助游戏走向成功。对于智能运维,我们认为通过了之前的标准建设,通过了服务化建设之后我们有足够的平台,我们有这么多的业务数据,我们可以通过更好的闭环,通过更好的智能策略下发让整个游戏的运维服务更加智能。

   [[157725]]

从运维服务的“四化建设”谈起

2014年,腾讯游戏运维负责人刘栖铜在《腾讯游戏云的理想与实践》分享中讲到对下一代游戏运维的定义,通过运维服务的“四化建设”,即标准化、自动化、服务化、产品化,帮助游戏走向成功,具体包括运维服务体系的规划,运维工具体系的建设,用户游戏体验优化触达,产品运营决策辅助支持等等。

  今天,我跟大家分享一些腾讯游戏运维在过去几年里是如何落地去做的。我们经历了运维建设的三个阶段:

  ◆第一个阶段:聚焦标准化

  ◆第二个阶段:围绕服务化

  ◆第三个阶段:面向智能化

  运维转型前的状况

  腾讯有一个QQ游戏平台的业务里面有几百款的小游戏,日活跃百万,变更需求日益频繁,每天QQ游戏运维5名同事要面对数以百计的开发人员不计其数的日常各类需求。面对这些需求,一开始整个QQ团队处在非常被动的情况下,因为本身运维能力也比较单一,没有办法并发处理大量的需求。

  运维转型的多岗分工

  基于这种十分被动的情况,QQ游戏运维团队做了一件事情,运维转型。

  设置不同的运维岗位:

  ◆第一类:操作运维,专注反复度高的工作。

  ◆第二类:业务运维,专注基础运维工作。

  ◆第三类:规划运维,专注在运维工作项目管理及需求规划设计。

  ◆第四类:开发运维,专注运维工具的开发。

  多岗运维的互相配合

  1.业务运维:熟悉业务,并把常规的发布变更任务定义成原子。

  2.开发运维:通过平台的页面进行原子操作的流程作业开发,日常操作页面化。

  3.规划运维:把这些场景按操作流程,自由组合封装起来。

  4.操作运维:固化流程,并进行工具的操作。

  QQ游戏运维通过不断的工具建设,操作运维执行需求的比例不断上升,目前超过90%以上(也就是自动化程度)。业务运维基本上可以不用再做这些日常重复度很高的工作了。

  QQgame运维团队是腾讯游戏的一个缩影,通过这样的创新模式,我们看到运维完全可以通过标准化的工具建设来解决业务爆发式增长与运维人员人力支撑间的矛盾,这种模式可以给更多的业务进行复用,也是运维团队作为平台技术所体现的核心价值之一。

  标准化之路并不平坦

  实践路上,我们在标准化建设中也碰到一些问题,比如:

  ◆在我们标准化建设的第一个半年里面,整个蓝鲸平台也是在发展过程当中,它周边的接口也不够丰富。

  ◆我们认为标准化就是把之前做过三、四十款游戏经验总结出来,结果导致了对原有的业务再改造起来成本很高。

  ◆另外,蓝鲸平台并发的性能,最早期的时候,它是串型处理的。

  通过半年的调整之后,随着蓝鲸整个工具平台逐步的成熟之后,我们接口比原来丰富了。我们的步骤比原来更灵活了,并且允许不同的业务进行自定义。在工具上线过程当中有开发的标准界定,有工具审核。现在腾讯游戏的基础操作都要求并很容易进行标准接入了。

  过去一年里,通过标准化工具,在发布、开区、扩容,缩容、自定义等场景中共执行2W+次任务,剔除了等待、中途未完成的任务,相当于700天+工作量,这使得我们的运维有更多时间边喝咖啡边创造更多有意义的工作。

  看服务化运维是如何炼成的

  如果说标准化运维解决了运维本身的痛点,那么在服务化运维里面,其实更多的要去解决产品的痛点。

  基础的运维工作是被动的。服务化的运维是主动的运维,我们自己发现问题,并且通过我们的能力解决问题。我们通过数据驱动我们的服务。我们在整个的服务化当中,非常强调运维闭环服务。

  让我们一起看一下腾讯游戏“4大名著”之DNF(地下城与勇士)的运维怎么进行服务化运维的突破。

  我们就从DNF的玩家在线恢复时长优化来说。13年DNF在1月份大版本发布后,我们花了将近12个小时才恢复正常的玩家在线。经过3年不断的建设,我们在今年6月份的时候,仅用了0.9个小时就做到了。

那是怎么样做到的呢?

  首先来看一下进入游戏时长优化,在线恢复过程中,有一个重要的因子,就是玩家更新好最新的补丁后进入到游戏所用的时长,补丁包越大更新进入游戏的时间越长,比如在DNF,300M补丁包会使在线恢复的曲线很慢才能正常。

  所以我们就在补丁包的下载优化上进行尝试,13年时主要还是通过HTTP完成自动更新,玩家在开服的一瞬间涌进来更新,虽然CDN的峰值带宽很高,但实际上单用户平均下载速度只有157k,更新非常慢,所以第一步我们在特定时间范围内提升单用户下载速度到485k,这样先解决了燃眉之急。

  但这样的方案只是临时解决。

  紧接着,14年6月份我们对预下载方案进行第一个版本的测试,通过游戏登陆器,我们用预下载的方式推送补丁包,下载速度提升到650k,在今年的5月份整个预下载做进一步的优化,以及进行多渠道推送,下载速度又提升到1.2M,带宽峰值进一步下降。

  DNF的在线时长优化,第二个重点是策略下发。初期,我们采用了用户平均在线时长来控制策略下发以及下载速率,但发现一个问题,因为用户平均时长不能精确到某个时段,所以策略下发成功率可能只有50%。

  通过进一步的研究,我们发现可以通过用户活跃时长分布指标来进行更精准的策略下发。比如晚高峰的时候,策略对某一些大区或者某一类活跃用户进行预下载推送效果很好。

  用户活跃时长其实在很早以前的产品运营数据里就有。但如果没有长期深入的研究,谁会想到会跟下载数据、在线恢复时长数据等有如此紧密的关联?这在传统的运维工作中很难想象。

  除了这两点,在线恢复时长优化中,我们还时刻关注游戏内玩家的掉线率,依托蓝鲸平台提供的各类工具,我们可以实时监控,与开发人员定位问题,如遇程序Bug,争取晚高峰来临前修复问题,从而保证整体在线稳定。

  我们从12年开始进行建设,包括去归纳整个腾讯游戏用户生命周期的线路,从而形成了整个腾讯游戏运维服务体系。我们就是依托于这样的体系去进行运维服务建设的。

  我们会把游戏的服务场景分为登陆服务、下载服务、版本服务、用户体验服务、运营成本服务等等,每一种服务都有明确的定义以及数据衡量标准。

  这个体系还在不断完善当中,将来可以作为游戏运维服务标准的框架,希望能帮助到更多游戏行业的运维同学更好服务于业务,也希望除了游戏之外,未来还会有更多的互联网行业公司,可以从游戏的标准场景里获得大家本行业的一些思考与实践。

  智能化运维的探索

  腾讯游戏技术运营的愿景是:“游戏智能化运营的领航者”。

  对于智能运维,我们认为通过了之前的标准建设,通过了服务化建设之后我们有足够的平台,我们有这么多的业务数据,我们可以通过更好的闭环,通过更好的智能策略下发让整个游戏的运维服务更加智能。

  在智能化的运维服务里面,我们需要考虑这几点:

  1.业务数据的收集和清洗,经过大量的收集以后,去进行智能清洗以后才能找到每个不同业务的逻辑所需要的最核心的数据。

  2.希望通过复杂的业务场景进行智能分析,并且决策下发以及精准推送,目前还是一些人工做的,这一部分我们相信在未来智能运维服务里面不需要人工干预。

  3.所有的运维服务需要闭环自动执行,闭环对于我们运维服务将成为基本要求。

  4.运维大数据影响产品运营决策,在去年分享里面讲到运维服务未来应该影响到产品的决策,我们希望通过更多的运维大数据分析,能帮助到产品的运营决策。在智能运维里,成本和服务是互相兼顾的。

  总结

  腾讯游戏运维通过标准化走向了服务化,目前正在智能化运维方向不断向前探索,我们相信只有智能化运维实现后,运维的自我能力与业务价值才能更好体现。

如何一起愉快地发展

“高效运维”公众号(如下二维码)值得您的关注,作为高效运维系列微信群的唯一官方公众号,每周发表多篇干货满满的原创好文:来自于系列群的讨论精华、运维讲坛线上精彩分享及群友原创。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。

提示:目前高效运维新群已经建立,欢迎加入。您可添加萧田国个人微信号xiaotianguo8 为好友,进行申请,请备注“申请入群”。

重要提示:除非事先获得授权,请在本公众号发布2天后,才能转载本文。尊重知识,请必须全文转载,并包括本行。

责任编辑:武晓燕 来源: 高效运维
相关推荐

2015-08-12 16:41:25

运维服务公共化

2016-04-15 00:43:13

2017-07-25 10:53:27

2015-08-05 22:34:33

运维技术

2017-05-16 14:25:35

运维云服务DevOps

2015-09-01 09:23:38

360网络运维

2014-02-25 11:27:49

运维经验紧急故障

2018-04-19 09:32:46

2018-05-10 08:18:12

无服务器运维服务器

2013-06-09 10:38:54

IT运维管理运维管理ITIL管理

2016-05-12 17:23:43

用友iUAP

2013-04-12 13:30:47

2009-09-16 13:38:33

运维管理

2022-08-29 09:59:00

运维实践

2014-02-26 15:35:22

服务器运维

2016-04-06 11:22:28

运维游戏运维服务器

2015-02-04 11:45:52

高效运维

2012-12-28 16:30:05

IT运维服务企业

2012-09-03 10:39:13

Hadoop管理员

2011-02-28 14:14:06

点赞
收藏

51CTO技术栈公众号