DataOps和AIOps 在腾讯游戏运维团队的运营实践-李世岗

彭小阳

作者简介：李世岗，来自腾讯IEG，目前主要负责AIOps相关的工作，做过多款腾讯自研业务工作，目前主要负责腾讯游戏智能化运维解决方案的建设和运维。

本文分3个部分：第一，腾讯游戏DataOPs和AIOps的发展背景；第二，工作当中实际案例的介绍；第三，服务模式的介绍。

一、腾讯游戏DataOPs和AIOps的发展背景

从2003年运维团队伴随着腾讯游戏成立，目前发展成为超过400人规模的团队。2017年的时候，我们进行DevOps、DataOPs和AIOps的转型，下面我针对这些内容给大家做具体案例的介绍。

这是我们一个PaaS平台的架构图，最初是运维使用PaaS平台，经过这么多年的发展和演练，已经成为一个研运一体化的PaaS平台。

我今天主要给大家介绍的是聚焦在数据平台和AIOps平台。数据平台和AIOps平台主要有这样的几个：数据集成、数据开发、数据存储、分析挖掘、数据管理及平台管理。这些具体的工作，我会在接下来的案例当中给大家具体的介绍。

我的案例有几个：第一，助力游戏的地图设计；第二，化解游戏运营危机事件；第三，辅助开发提升用户体验；第四，提升运维的工作效率；第五，改变运维监控的工作方式；第六，指导运维发现异常日志。

二，工作当中实际案例介绍。

2.1 助力游戏地图设计。

这是一个枪战类的游戏，它有攻守双方。当策划上线一个新地图之后，通过数据分析发现，双方的胜率是不平衡的。他想解决这个问题，可是无从下手。这时候，我们给他提供一个死亡的热力图，从这个热力图上就可以看到死亡分布的情况，然后知道从地图的哪一个地方去做相应的调整。

这个热力图，我们是如何得出来的呢？因为游戏内的地图场景非常多，一款手游里面涉及到100多张地图，地图的情况每一个都不一样，而且我们是为多个业务提供服务。

但坐标展示SaaS只有一个坐标系，如果想在唯一的坐标系上展出这么多场景地图，并且还要实现拉伸、偏移等功能，就得要做一个坐标映射，如何做坐标映射呢？其实也不难，就做一个迁移回归，如果能够找到系数、叠矩，就可以做映射。
在我们的数据平台和AIOps上如何实现？首先对数据做标准化和规范化的处理。我上述讲的思路，我们把它沉淀为机器学习的模型，当你想要使用我们的能力，把数据接入到我们的模型，我们就可以为你提供热力图的服务。

我们把热力图提供给策划，策划同学怎么来用呢？首先根据交战热区阻塞点或者是武器类型击杀热力图来调整关卡结构，或者是看阵营的胜率异常情况来看地图设计是否平衡，或者是根据武器使用的异常来看地图结构有没有被非法利用。

这是我们实际的案例，）这张地图上，黄色的这两个框是我框出来的两个出生点，我们在设计这个地图的时候，把它设计为非交战区。但是大家从这张图上可以看到它的分布，在这里有很多的交叉和死亡行为，为什么会发生这样的现象？我们调研发现，出生点有防守的优势，易守难攻，所以才会这样的现象。

经过优化之后，第二张图黄色的框里面，交战和死亡情况已经非常少。在游戏里面，如何实现这个效果呢？这是优化之前原始的地图，这个箱子比这个台阶高很多，如果这个人在这里防守优势很大。
第二张图，我们把箱子跟台阶保持持平，并且把前面的挡板去掉，出生点的优势就被大大削弱，从而就能达到了上一张热力图想要的效果。

这个案例是数据平台、AIOps平台与CO场景中数据感知、数据决策以及运营支撑、体验优化相结合的案例。

2.2 化解游戏运营危机事件

接下来给大家分享第二个案例，在游戏里面，大家会看到这样的敏感词，比如说做广告的、诈骗的或者是政治敏感的词语，这些词语出现会影响游戏的体验和游戏的运营。
有一次游戏出现了这样的情况，然后游戏就被勒令整改，如果在有限的时间内不能够马上整改这个问题，有可能就会被关停。然后他们就找到了我们，说我们能不能在一个小时内帮他解决这个问题？

我们接了这个案例，我们处理的是存量的数据，游戏里面有实时监控系统，存量数据体量非常大，如果按照现有去检测速度非常慢，同音字非常多，现有方案处理起来流程烦琐，那我们如何做？
如果大家打过游戏的话，游戏里面绝大部分的数据，大家看到的文字都是正常的，有问题的是其中非常小的一部分，如果能够找出非常小的部分做快速的检索，就能够马上找到我们想要的敏感词。

基于上述的思路，我们设计了这样的方案，由过滤器过滤出来疑似的敏感词，这个数据体量和原始的文本相比体量明显缩小，相差好几个量级，然后再利用AC自动机高效检索的机制，就能找出我们想要找的敏感词，然后对专家进行封号或者是禁言等相应的处理。

具体如何实现？首先构造一个过滤器的中间表，主要是两个步骤，以在游戏内卖浏览器这个词为例，上面这个步骤最后构造出来的是字与字的衍生映射表，衍生字和原字的映射表；下面的过程，构造出来的是字和词，就是原字和屏蔽词之间的关系。

得到了这两个映射表之后，我们怎么做呢？原始的文本体量非常大，通过字与字的交集，处理之后体量缩小了很多，再经过字与词的交集，经过更严格的匹配，体量又减小了，然后再通过AC自动多模块字串匹配的模式，很快就能找出想要的目标信息。

在这个平台上如何实现这个方案？这是一个敏感词扫描的模型，当想使用这个模型的时候，把原数据接入到这个模型，就能输出想要的结果。这次在1个小时的时间内解决这个问题。
如果下一次出现这个问题，下一次有多个业务出现这个问题怎么办？我们把这个能力沉淀为了敏感词扫描的SaaS，只要把想检测的数据接入到这个SaaS，这次事件所对应的敏感词的词表提交上来，很快就能反馈给你想要的结果。

我们对我们的方案优化之后，效果如何？优化前和优化后的标准模式扫描速率，由原来的100每秒提高到了现在的1200万每秒。拼命模式的速率由原来的10万每秒提高到了现在的600万每秒。

这个案例是数据平台和AIOps平台与CO类产品当中的数据展示、数据决策以及运营之间的体验优化等相结合的案例。

2.3 辅助开发提升用户体验

有一个大型的moba类游戏，总是有玩家投诉有掉线的行为，但占比不高，只有千分之3.5到千分之4的范围，由于占比非常小，开发商很难复现场景，很难短期内解决这个问题。但是问题又长期占据了玩家投诉排行榜top3，他想要让我们帮助他解决这个问题。

解决这个问题也面临一些问题，开发商比较随意，数据格式不规范，数据业务体量很大，所以面临服务器多、数据体量大等问题。

那数据平台和AIOps平台面对这些问题怎么办？首先在数据上报阶段，数据平台既支持标准格式的日志文件数据库等数据上报，还支持以自定义数据的上报，无论原数据是什么格式，都可以上报到我们的平台上。

上报上来之后，我们提供了丰富的清洗算法，有切分、替代、取值等，经过一系列的操作之后，数据可以落地在数据平台上，成为我们想要的标准数据，有标准的数据后，在以后的需求场景中就可以复用这些数据。

再回到我们的案例上，我去分析掉线相关的数据，我想分析哪些目标呢？我想要掉线的转化率、掉线的阶段、掉线的原因、重连耗时等目标数据。如果我要进行这些目标分析，我需要有运营商的、网络的、延迟的等属性的数据。它横跨了业务的登陆、匹配、对局等业务场景，这么多的属性和场景，从数据平台上如何快速拿到呢？
数据平台有一个数据极值的功能，数据上报的时候都会维护好数据对应的标签，当有需求的时候点开业务，无论是想要登陆还是网络、还是匹配、还是服务器等各种类型服务器，在上面点，就可以快速得到这些数据。
而且当你想要其他数据的时候，都可以看到哪些业务有这样的数据，你去申请这些数据，并且通过权限审批得到通过之后，就可以复用这些数据进行相应数据分析的工作。

拿到了数据，我们要给数据做处理，我们是怎么处理的？由于业务涉及的数据太多、场景太复杂，由于需求难度高，我们只用这些流式处理的方法还不足以解决我们的问题，我们还要借助于AIOps平台上的机器模型来解决我们的问题。

这个案例我们利用随机森林预测，为掉线相关的维度去做简单的处理，根据它的信息初步筛选出来我们要重点分析的维度，然后计算这些维度和掉线相关的系数等等，筛选出来我们要逐个去测试和验证的维度。

经过我们反复的测试和验证，发现了一个现象，这张图是重连耗时分布的，客户端和服务器发生了掉线，掉线之后发起重启请求的中间这段时间就是重连耗时，大家是不是都希望断开连接就能马上发起重启请求？这是我们比较理想的状态。
大家可以看到，除了零秒周围有一个分布之外，在大概7秒的地方还有一个比较集中分布的现象，为什么会有这样的信号？我们经过测试，找开发去问，经过和开发的求证，这个机制存在不太合理的地方，当断开之后要在这里等上7秒，虽然客户端有提示，但是做不了任何的操作。

有写代码经验的都知道，7秒已经是相当长的时间，这时候客户端和服务器可能已经完全断开连接。这对玩家的影响是，再次重连的时候已经找不到原来的队。这个现象是不合理的现象，经过我们的优化及开发的努力，最后得到的效果是这样的（PPT图示），这是我们想要的理想状态，绝大部分重连耗时分布都是趋近于零秒左右。

我们做了这些案例，给业务带来了哪些收益呢？重连失败率降低了2.44%，玩家掉线的准化率提升了1.94%，我们是moba类的游戏，一个对局里面有10个人，一个对局就会影响到10个玩家的用户体验，如果一天有200个对局，那2个点就是有20万的玩家受到了影响。

这个案例是数据平台和AIOps平台与CO场景当中的性能优化、运营支撑以及体验优化相结合的案例。

2.4 提升运维工作效能

有运维工作经验的同事，对这个场景肯定也非常的熟悉。如果没有办法进行及时扩容，这个业务会有玩家投诉，甚至后台服务器就直接雪崩。

在智能化运维时代，有没有办法借助于数据分析，发现规律，从而建立一个模型，自动预测下一次扩容的时间，并且去执行自动化的扩容作业呢？
按照这个思路，我们来分析一下。首先观察业务的在线，这是某一个业务3天的在线，大家发现什么现象？每天是有一定的规律，而且在一天的周期内，拐点和极值也是有个数。
基于上述的发现，首先对数据做预处理，统计极值以及拐点分布的情况。然后用最常见的方式，去拟合曲线的走合，线上应用的时候，结合最新的数据，实时刷新多样式，保证多样式的损失能够降到最低。

这个曲线的多样式拟合出来以后，如果把殿宇（音）延长，是不是可以预测未来一段时间的走势？就像蓝色的框部分，就是我们预测它未来一段时间的走势。大家也可以看出效果（PPT图示），红色的曲线是我们预测的效果，蓝色的曲线是实际业务在线的效果，我们预测的效果与实际在线非常接近。
如果我们能够预测未来一段时间这个数据的走势，而且我们大区的建设容量是一致的，这时候就知道下一个点应该是扩容或者是缩容。

我们上述的思路如何实现呢？首先也是对数据进行标准化处理，标准化处理之后，上述能力沉淀为了机器学习的模型，把标准化处理好的数据接入到这个模型提供在线预测的能力。

这个能力，我们也把它沉淀为了智能扩容的SaaS，以服务更多的场景。只要你的数据符合我们的接入标准就可以一键接入，享受我们给你所提供的智能扩缩容服务。

后面的扩容作业对大家来说就不难了，自动化程度在运维工作当中的程度已经非常高，只要知道什么时候去扩容，什么时候缩容，调用我们的扩容作业就能够达到目标。

这个案例是数据平台和AIOps平台与CD场景当中的任务调度、自动部署、应用发布以及CO场景中的数据展示、体验优化等相结合的案例。

2.5 改变运维监控工作方式

之前我们怎么做监控，一个业务不同的运维周期也要调整不同的策略，这个策略还不能保证它是准确的，在智能化运维的时代，人工不要去配策略，机器学习的模型能不能覆盖更多的场景？我们带着这些问题进行探索。

首先对游戏内的曲线做了归纳和总结，这4类的曲线持续波动的、叠加平滑的、概率统计的和耗时的曲线，已经能够涵盖游戏运营场景当中绝大部分的KPI曲线。

我们对这些曲线做这样的处理，首先汲取特征空间，利用神经网络对这些值进行预测，预测值和真实值之间的新序列，再结合业务在线数据，让它符合正向分布。在正向分布里面，累计大于0.99的点，我们就认为它是异常点，你的数据接入到这个模型就可以告诉你异常点是什么，以及它的告警等级是什么。

当你有需求的时候，你只需要把数据接入到这个算法模型，我们就可以告诉你，你的异常点和告警等级是时间。

这是我们的效果图（PPT图示），红色的线是一个个告警点，如果肉眼去观察，这些点不能准确判断出来是告警点，但使用机器学习的算法就能准确识别出来敏感度很低的异常点。

我们也把异常监测的能力沉淀为了SaaS，数据只要符合接入标准，无论是登陆的数据还是在线的数据等等都可以提供异常监测的服务。异常监测是一个完善的体系，不仅仅是异常检测，还有关联分析和后面要给大家介绍的边缘定位。

关联分析是这样的思路，首先基于业务的TOP关系，构造出来一个关系图谱，然后去分析它的图谱上下游的关系，从而给出某一个告警事件与之关联的告警事件。

比如说某一个大区有在线发生了告警，去分析这个大区服务器的分布和服务器所在的机房有没有异常事件的发生，比如某一个机房有单机流量告警，很有可能是由于机房内单机流量异常而导致业务在线发生抖动。

边缘定位是怎么做的呢？基于上述的关联分析步骤里面的海量标准化数据，构造出来了一个平方模式树，通过自研的一套最优路径的更新算法，我们把这颗树优化成一颗有向无环树，当其中一个节点发生异常的时候，通过去反向回溯就能够找到所对应的异常点，也就是可以找到某一个告警点的根本原因是什么。

这是一个业务的在线发生了告警，通过边缘定位的能力，可能是由于某些机器的单机流量异常所导致的在线发生的异常，经过我们和运维去求证，发现是由于某一台DB的单机流量异常，导致玩家访问延迟，从而体现了在线流下降。

这个案例是数据平台、AIOps平台与CO场景当中的边缘分析、监控自愈、体验优化等等相结合的案例。

2.6 指导运维发现异常日志

这些都是日志，我要是让大家告诉我，这些日志里的的哪些点是异常日志？那大家肯定很头大。

我们换个思路，如果看这张图，大家是不是就会有一定的思路。

我们把日志做了向量化的处理。首先，我们会去对日志做ETL处理，对日志里有特殊的符号和繁体字等进行处理，利用word2vc把它分解成一个个词向量，然后利用这个计算相似度，让向量到指定的区间内，再利用（英文）这个办法，组合成句向量，最后利用（英文）这些算法，把它据类成一个处。
当业务的日志类型的处，如果有新的处产生，那就说明有新类型的日志发生。在一个处内，如果数量稳定的前提下，数量发生变化，这日志就发生了异常。
我们把数据进行了格式化的处理，接入到日志检测的机器学习算法模型，然后就输出异常日志。

这是实际的案例，在右边的点，（英文）这个关联字的日志，在右边那个点，数量发生了一个抖升。下面是日志检索的平台，在日志检索平台上检索关键字，从那个点之后，异常日志的数量发生了增加。

这个案例是数据平台和AIOps平台在CO场景当中的日志分析、数据展示、运营支撑、体验优化等等相结合的案例。

三，服务模式的介绍

以上是我给大家带来的案例分享，在腾讯游戏的工作产品当中，我们这么多的能力是如何为业务提供服务呢？

我想问大家一个问题，腾讯游戏有多少款游戏？如果说有成百上千款游戏也不过分。游戏有登陆、在线、匹配、对局、支付等等很多的场景，那很多游戏，很多场景，需求就千变万化，如何能够以不变应万变，为这些需求提供统一的服务呢？

大家看我们的架构图，这里是我们的（英文），我们的能力都沉淀在数据平台和AIOps上面，我们通过（英文），把我们的能力封装成一个个的API，上层的SaaS，无论是CEI场景的，还是CB场景的，或者你是CO场景的，都没有感到，只要你符合我们的API数据使用标准，都可以调用我们的能力为你提供服务。
上面我们分享的内容就来自于运维小组的沉淀，整个运维团队超过400人的规模，分成了几十个小组，目前数据化运维和智能化运维普及程度是深入人心，在不同团队内，给不同场景服务的时候都有意识使用数据化运维或者是智能化运维思路，为业务提供更加高效和更加精准的运维服务。
谢谢大家！