海量业务场景下的个性化安全运营之道 --- 关义春

北哥

我分享的内容跟运营安全相关。运营安全跟传统理解应用安全、反外挂有一些不太一样的地方，它更注重运营过程中的安全问题。

今天的分享主要分为以下五大部分：

1. 个人介绍
2. 今日主题
3. 运营安全案例
4. 挑战
5. 过去的努力
6. 新方案及效果

游戏运营安全中遇到的问题，包括腾讯自己遇到的问题，还有行业内的典型。

在讲解决方案之前，我给大家讲一下在解决这些问题遇到哪些挑战，还有我们过去几年也曾经想了办法，尝试了一些方式来解决安全的问题。

去年我们采取了一些新的方案，效果也还不错。最后给大家讲一下我们具体的方案。

近期AWS技术峰会在北京也举行了，当时提了一个很重要的观点，安全是第一要务，对所有企业来说，也是第一要务，除了业务之外安全是第一重要的东西。

我们在行业内也看到很多反面案例，例如雅虎之前要卖掉，最初估值是40亿美金，但是因为出了一些安全问题，被挖了之后，到最后这个业务几乎没有人要了，所以安全问题一旦出事之后影响非常非常大。

一. 个人介绍

• 运维
  
  • DNF/御龙/三国/飞车等数十款端游
  • 火影/七雄等数十款手游
  • 运维自动化、开放接入游戏等系统设计
• 运营安全
  
  • 应用运维安全
  • 游戏经济系统安全
  • 审计支持
• 与游戏结缘

我在2008年加入腾讯公司，刚开始做的是DNF运维工作，DNF上线之后PCU水涨船高，服务器在08、09年也到了好几千的水平。

那时候我做运维工作，用ruby写了个配置管理的工具，一个命令生成所有服务器的配置和启动关闭脚本。这个工具现在看来，已经具备了一些比较先进的理念，包括CMDB、自动化、自动生成等现代化先进理念。确实比较好用，也结合我们自己公司内部新的系统。

直到前两年新的DNF运维还在用这个工具，可能这个工具写得太好了，老板对运维的工作复杂度没感觉，也没有GOPS这样的舞台给我来发挥，就让我再干了好几年的基层工作。

后来我还负责过御龙、飞车、火影等多款端游、手游的运维和管理工作。

目前在运营部负责运营安全，职责比较杂，因为业务层面的东西需要落地，范围覆盖腾讯所有游戏的应用运维安全、游戏经济系统安全、审计部门的技术支持。

从08年至今有近十年，一直在游戏领域，从未离开过，可能以后也离不开。

今天和大家分享的内容和游戏紧密相关，今天来到GOPS是各行各业的同学，希望分享的思路能够给各行各业的同行们带来些共鸣。

二. 今日主题

2.1 游戏运营中的内外部安全挑战和应对

• 外部挑战
  
  • 游戏的玩法多样性、设计复杂性、运营动态性
  • BUG、外挂等影响经济系统平衡的因素
• 内部挑战
  
  • 误操作、设计失误等影响游戏口碑的因素
• 应对之道

在所有人眼里，可能都有这么一个看法，认为做游戏是一个很赚钱的事，同时也有一个共识，做成一款游戏非常不易。没做过的可能完全无法想象整个过程有多不易。

腾讯也是一样的，一款游戏从立项到上线，要经历无数的评估、数据分析、修改和优化，当你付出了巨大的努力，成功的把游戏从预研阶段拉扯到上线，更大的挑战会摆在你眼前，也就是运营期的所遇到的各种挑战。

游戏是什么样的产品呢？它是一种以玩法多样性、动态运营为重要特性的产品，游戏玩法非常多，运营过程也非常灵活，天生就决定了它在运营过程中会面临来自，比如策划期遇到的问题，开发测试遗留的BUG、外部打金工作室和外挂的威胁，还有来自内部的风险，包括策划上不周到的地方，以及误操作带来的毁灭性影响，这些影响，轻则伤筋动骨，影响游戏经济平衡，重则公关危机，只好改名再来。

所以说一个游戏成功的基础离不开健康的经济系统，里面有稳定的生产者和消费者，玩法规则，经济系统通货膨胀按照预设的路径稳定运营。

三. 运营安全案例

3.1 影响运营安全的案例1

接下来给大家带来近期发生的影响游戏运营的案例。有过去，有现在的，也有外部影响的，也有内部误操作导致的。这些产品都是比较有名的，为了避免麻烦，在这里不会点名。

某游戏的寄售商店中,可直接批量刷取游戏中任意道具、装备与宝石。

某游戏的寄售商店中，把购买请求中物品数量篡改为一个超小的负数时，由于数值下限溢出，可直接批量刷取游戏中任意道具、装备与宝石。

如果对外挂有些了解的同学，应该知道这个情况，你可以抓它的客户端、服务端请求包，解出来以后重播，就可以实现篡改程序。

这种是比较常见的游戏开发过程中代码不严谨留下的一些问题。

虽然手游时代的外挂和辅助程序没有端游时代那么泛滥，这个跟平台有关。这个游戏很火，有利可图的话，总有人想法设法找一些漏洞。

这种案例非常多，我们在开发过程中也无法发现。例如某某球游戏，可以通过好友赠送来获取大量金币，原因是服务器和客户端存在缺陷，没有对领取资格进行严格校验，玩家可以通过无限断线重连的方式来重复刷取奖励。

这种场景是比较常见的，如果没有经验的人可以写出这种代码，为什么导致这种问题呢？是因为我们领之后，服务器没有立刻把领取记录回写到数据库，要等离线消息收到之后，才会回写数据到数据库里。

这也是一种从性能上考虑的机制，但是这种情况下，因为涉及到关键数据不应该这么做，应该领取之后立刻把数据回写到数据库，避免玩家异常断线，导致记录没有被记录下来。

比如某某手游，可以通过篡改购买请求的数量，把数量改为0，就可以实现免费刷物品，你敢相信吗？要是电商有这种bug，我估计会被破产吧。

游戏毕竟只是电子虚拟产品，但是电商是实体产品，如果也这种bug就没办法了。行业当中也不乏这种案例，例如，通过游戏内结婚离婚再结婚可以重复领取奖励。

3.2 影响运营安全的案例2

某游戏上线了一个礼包活动,玩家可以用100元购买到几千 个礼包,超出预设几十倍。

通过充值返利获得重复收益。某游戏上线了一个礼包活动，原设定是100元人民币可以购买100个礼包，但是配置的时候将数量错误配置成了几千个礼包。导致玩家可以用100元购买到原设定几十倍的礼包。

这个礼包我们先不说多少钱，但是我通过很低成本可以大量获取的话，影响是非常大的。

相当于游戏里投放大量这种东西，会对游戏平衡带来很大影响。这种情况也是非常常见的，不一定是策划或者运营犯2了，有可能是内部运营系统真的是没做好。

我见到一些集成系统可以在上面设定活动，玩家的UIN离钻石很近的，我们不小心把这两个东西填反了就麻烦了。比如玩家本来就发几百个钻石，结果发了几个亿，这个是很麻烦的。例如同行比较出名的母亲节事件可能大家也有所耳闻，这种事情如果处理不及时，问题非常严重。

3.3 影响运营安全的案例3

某著名游戏,两对后端redis failover失败,导致部分数据丢失,充值活动的奖 励,本来只能领取一次的,因为记录被清除了,可以重复不断领取。

某日早上5点多，某著名游戏，两对后端redis failover失败，其中一对重启后成功，另外一对重试后仍然失败,导致部分数据丢失。

充值活动的奖励，本来只能领取一次的，因为这个1次的记录被清除了，可以重复不断领取。

这个案例影响并不是很大，如果游戏的服务器不多，可能问题很快显现出来。如果一个游戏的服务器非常多，如很多网页游戏就是以开服为主要拉升手段，拉活跃，拉收入，它的服务器非常多，一个服在一个渠道就有几百上千个。

如果出现这种情况，可能运维、dba把服务器恢复了，但是游戏内的影响不那么明显，没有恢复后的完整测试，或玩家举报，就很难发现，玩家拿了就拿了。

3.4 影响运营安全的案例4

XXX并不像撸啊撸,只要你有时间就能一直玩下去。体力不可能凭空而来,花钱买体力花时间刷体力,结果却让人绝望。玩家的爱意变成恨意,对游戏的坚持变成了对游戏开发者的疑虑。

还有一种是玩家发现了、举报了、通知官方了，结果由于延误处理带来大问题的。

近期行业里有个很出名的案例，在座玩这个游戏的同学应该不少，对这个游戏的元旦事件多少有些了解。

在2017年元旦前后，它爆出YYH BUG。玩家可以通过不消耗门票的方式，以低难度值无限挑战副本，并且还能够获得副本专属的高级御魂和大量经验。

按最坏的情况估算，该副本15秒一把，从元旦至修复刷3天，1个玩家大约能刷得5000多个六星专属御魂，价值约一百万+RMB，导致游戏中的大R极度不平衡。

这次事情如果处理的更及时些，问题不会对游戏平衡性和品牌产生影响，也不会演变成一场公关危机，其实当时已经是公关危机了。

有的玩家当时甚至要求退款，有的还联合起诉游戏开发公司。因为玩家各种各样的人都有，有法律人士，有土豪，对自己权利保护意识很强。

对公关危机四个字，大家的理解都不一样对吧？但最关键的是，如果游戏运营商能够在扩散前发现问题，处理起来就很主动了。我觉得这个能力是很重要的。

3.5 一个有意思的思考

这是网上有一个人对这个案例很有意思的思考。

3.6 问题

• 测试、防误操作、预警、快速响应机制到用时方恨少？
• 这些措施都做到了,就能止住这些严重问题的发生吗？

3.7 先定个小目标

在讲解决前面这些问题挑战之前，我们先给自己定一个小目标。

• 我们尽早发现运营期隐藏缺陷及导致经济体系失衡的异常。
  
  • 把搞事的人抓出来！保障玩家爸爸的权益和体验！
  • 把隐藏的Bug抓出来！保障玩家爸爸的权益和体验！
  • 再说一次，玩家爸爸的权益和体验很重要。

所谓隐藏bug，顾名思义，如果没有被知悉缺陷、掌握缺陷的人公开细节，就不会在玩家层面扩散，运营人员和开发人员对游戏的漏洞也不得而知，久而久之，隐藏缺陷就成为可获利的点。

在游戏里，拿到这些点就可以去卖了，这将成为游戏运营安全、游戏经济系统安全最大的威胁和挑战。

四. 挑战

4.1 游戏安全运营的挑战

• 复杂性
  
  • 运营流程长，产生问题的环节多
  • 动态运营
  • 一些“不小心”
• 海量
  
  • 海量业务
  • 海量支撑系统
  • 海量数据
  • 海量角色

总的来说，游戏安全运营有两大方面挑战。第一，复杂性。第二，当一些问题单个和少量的时候没有那么复杂，但是当量上来的时候，这个问题就存在很多未知问题，必须要经过踩过这些坑了，才能感知到这些问题到底在哪里。

4.2 复杂性之一 --- 运营流程长

这是咱们最常见的一个业务发布流程，不管是服务器也好，客户端也好，都要经历这些过程，版本上线前经历过很多个环节。

大家可以想象的到，出问题的不一定是代码的bug，也不一定是测试发现不了，还有可能是运维在发布过程中出了些岔子。

例如，后端机器failover失败，导致玩家可以在少量场景下获得多余的钻石产出，这就是和咱们运维密切相关的事件。

各个环节都有可能出问题，复杂性非常高。Devops确实能够帮助到咱们，把整个流程精简，实现开发环境到生产环境的高度一致性。

4.3 复杂性之二 --- 动态运营

游戏要成功，就得让玩家爸爸玩得爽，让玩家爸爸花的钱和投入的时间值得，这样开发人员和运维人员要不断根据运营的情况来快速调整，才能被玩家接受、理解。

我相信每款产品都是这样的，包括电商、业务等等。因此，好的游戏都是改出来的。

上面这个图，是我公司某个游戏一年下来的版本数量图，看起来不多，大概一年也就400多个版本吧，当然大多数都是不停机更新的。版本一多以后，就容易产生BUG，有可能新的问题刚刚修复，老的问题就又出来了。

游戏是一个小社会，里面有很多功能，交互非常复杂，很难做到十全十美。

4.4 复杂性之三 --- 一些“不小心”

这个复杂性跟人有很大关系，有一些“不小心”的行为。比如运营上难免会出现问题。

相对不小心更可怕的是故意而为之，内部人员故意做一些操作。这方面是涉及利益和诱惑的东西，这是对人类天性最大的挑战。

4.5 海量挑战之一 --- 海量业务

• 海量业务
  
  • 人员角色的多样、复杂
  • 开发框架的各式各样
  • 海量数据的存储、使用

说到海量，我司游戏在cmdb中已经超过1000个条目，不单是业务量巨大，也拥有不少打破世界记录PCU的业务，例如LOL、《王者荣耀》等等。

这些业务有来自自研工作室，也有世界各国著名和非著名的开发公司。

游戏开发是一种高强度脑力劳动的活，每位架构师、主程都有很多年的工作经验，有他对游戏架构设计的深刻理解，虽然游戏架构总体可以用同样的方式去理解。

一般分为：

• 接入层
• 逻辑层
• 存储层
• 日志平台
• 大数据平台

每一层的设计和具体实现得看个人经验和游戏实际需要。

有些开发喜欢用平板的方式存储道具数据，每个玩家的背包是几百条单个道具记录；有些开发喜欢用二进制的方式存储背包数据，目的是方便和节省空间。前者方便关联结算，后者方便记录以及合服迁移的时候，比较容易做迁移。

游戏日志更是根据游戏场景的不同而有不同日志输出。例如：各种道具的产出、消耗，活动的参与，奖励的获取，游戏关系的建立和解除等等。这些都是游戏里面经济活动实际的记录，各式各样。

要从海量业务里发现问题，首先要从理解游戏，理解海量的游戏数据和日志开始。

4.6 海量挑战之二 --- 海量支撑系统

• 海量支撑系统
  
  • 业务需求多样性
  • 运营管理便利性、效率
  • 接口复杂性
  • 授权的开放与回收

除了游戏本身，运营期的游戏需要配以各种各样的支撑系统，协助游戏运营实现活动、客服、数据分析等各种需求。

随着需求的增加和时间的积累，支撑系统的多样性和接口的复杂性，也是海量支撑中的一个挑战，它会给游戏异常问题的发现，带来很多需要关注或者排除的因素。

上面图的右边是我司最常见的游戏和内部系统的关系图，包括游戏接入期，要按照标准化要求，提供各种接口，给到游戏官网、客服平台、营销平台、内部合作方等方面使用。

因为有些游戏是外部引进来的，可能存在的单独的GM管理系统，除了运营需要，运维、开发、测试等方面也要通过接口对游戏下发各种指令，包括刷新一些配置等等。

这些周边的系统或者接口，都是对游戏产生变化的源头，可能有一定的概率会导致游戏发生非预设的问题，就是产生一些想象不到的问题。

总的来说：

• 游戏运营极其复杂、节奏极其快！
  刚才大家看到一个游戏一年有400多个版本，非常恐怖的。像每天可能有一到两个版本发布，停不下来在转。
• 游戏是极具个性化的业务!
  每个游戏玩法不一样，很难用标准监控一个游戏。
• 异常快速发现
  除了做好开发流程中的规范、保护措施，运营阶段的异常快速发现能力十分重要，它真实反映了用户侧正在发生的事。

五. 过去的努力

在我这个团队成立之后，就开始想办法做游戏异常的问题发现。大概从2010年开始就做这方面建设，但是过去努力有一定局限性，其实跟咱们一些思路有关，也跟行业里面的技术是否成熟有关系。

5.1 基础保障 & 监控告警

• 基础保障

  • 日志规范： 游戏日志、支撑系统日志、流水号
  • 流程规范： 开发测试规范、应急响应规范
  • 权限管理： 最小化授权、定期审计

• 监控告警

  • 依赖策划表
  • 固定阀值
  • 纯手工配置

过去我们做了一些技术保障的内容，包括规范流水日志和支撑系统的日志，还给他们打上流水号，让我们可以跟踪每一条游戏日志是因何原因产生，从何处产生。

在流程规范上做了很多建设，规避大量人为失误的情况。

在事后，形成常规的事件处理机制，对所有异常快速反应，避免产生公关危机。

腾讯游戏来说这种情况是很少的。同时，我们为了发现游戏中的异常波动，和游戏策划紧密合作，基于策划表进行监控。一旦玩家侧的数值变化超出策划表的数值，就发出告警。

5.2 旧方案的效果吃力不讨好

• 告警压死人
• 问题发现不了
• 还被骂死

前面的基础保障，帮助我们在异常监控方面打下了很好的基础，但是基于固定值的监控方法，大家闭上眼睛都能猜到结果，它的效果可以说是吃力不讨好。

第一方面，告警波动非常大。游戏是一个小社会，里面有各种玩家，高级玩家和普通玩家的情况严重不同。包括等级、属性、权益，可能参加同一个活动他的权益不一样，他获得产出也不一样。打同样的副本获取的经验也不一样。

第二方面，告警量巨大，平均每个业务每周超过一千个告警，运营人员跟我们说，告警了我LOL都打不了了。久而久之，这样的监控方案和系统，被唾骂不止。运营人员说，“你不单不能帮游戏发现问题，还给我带来了巨额的额外工作”，系统得不到信任和口碑，逐渐就消失在运营人员可以依赖的名单中了。

六. 新方案及效果

6.1 新思路

• 不把个性化当个性化
• 借助自动学习的思路解决个性化问题

游戏社会的特征，类似现实社会的一种情况。

游戏社会的特征，大部分情况都是按照预设的规则在跑，大部分人的行为特征是符合正态分布的原则的。不守规矩的只有那么一小波人。

如果我们掌握了大部分人的特征，就容易把小部分人的特征找出来。这个跟咱们公安办事也是有一些共同的思路，但这大部分人的特征不是不变，一个游戏从开服到几个月之后，整体数值是慢慢在演变的。

如果能想办法不断去更新大部分人的特征，那么固定阈值的既有问题就得到解决了。

那么特征是什么呢？

我们这里的特征是指游戏里的道具，它的每个渠道，我去商店来购买一个东西，打一个副本或者打一个怪形成一个渠道。每个道具在每个渠道产生消耗产出的规律，就是我们所谓的特征。一个RPG游戏可能有几千上万个特征和规律，因此对这个计算消耗非常非常的。因此，我们借助当前最流行的“自动学习”的思路来帮我们解决个性化问题。

这个方案是从去年开始，为了提升游戏异常问题的发现能力，我们把工作分为三个阶段建设。

6.2 阶段一 --- 监控能力建设

• 监控能力建设：
  
  • 技术架构改进
  • 新监控模型

监控能力建设，我们把架构改变，新增不少监控模型。

这是我们一个大体的技术架构，底层跟所有业务都一样，是游戏的原始数据或者是经过一些标准化上报到大数据平台的数据。

第二层就跟很多在座如果用过大数据平台的话，跟你们都是一样的，包括spark、kafka、es等等。只要你对大数据感兴趣，亲自动手实践一下，相信在座每一位同学都能够在一周内把一个大数据基础系统给搭起来，包括数据接收层、存储层、计算等等。

再上一层是我们自己开发的脚本，实现了算法模型，这是自动学习的核心。

最顶上的一层是展示层，也就是发给用户侧的告警的内容，以及告警分析的一层，在这里你可以通过离线工程，帮助你分析告警是怎么回事，看到问题具体发生在哪个用户身上，有哪些日志，还可以导出所有相关联的用户信息。因为我们不是游戏运营人员，一旦发现问题以后，需要游戏运营人员，开发人员来具体看。

借助这个架构，如果拿50个游戏来看，每小时日志量大概500亿，总共有300个CPU在跑，每个核使用率超过80%，总体来说是非常高效和节能的。

• 日志：
  
  • 频率异常
  • 趋势异常
  • 分区差异
  • 持续性
  • 单条产出

这里简单介绍一下，经过一年多的不断积累，系统支持的重要监控模型。

日志是我刚才说的玩家层面的一些活动，它落地到游戏里面体现的是游戏的日志。

频率异常和趋势异常来重点讲一讲。

频率异常模型：这是基于用户产出频率作为维度，以持续高频作为监控算法，比如隐藏的BUG，玩家为什么要利用，一个是好奇心，如果他是有组织的话，他必须要获利，不获利没有必要干下去。如果要获利，这件事情要重复做，但是如果你重复次数少的话，产出的东西就比较少，获利空间就比较有限。如果他能不断重复去发请求，让这个游戏给我反馈。前面第一个案例里是有动画的，坏人给服务器发一个协议包，客户端会不断弹出一个消息，你才能获得某个物品。这是游戏频率异常模型需要应付的。它对网络协议级外挂有较好的效果。

趋势异常模型：它是基于全服单角色产出最大值作为维度，其实最大值有区间的，不是一个数值。我们监控所有玩家的活动是否超出这个区间，这个区间会不断动态变化，不断更新整个区域或者整个全服玩家的特征。监控面会比较广，但容易受活动与版本影响。例如我投个物品到游戏里，它的产出就会超出平时很多倍，就会告警，所以需要其他模型补充，也需要后续的告警确认机制来辅助。

6.3 阶段二 --- 告警分析能力建设

• 告警分析能力建设：
  
  • 辅助维度
  • 离线分析工程

第二阶段是告警分析能力，告警以后还可以分析哪些告警信息是有效的，该不该跟进处理。

我们通过各种模型算法把告警找出来，当然告警也不一定是真正有问题，但是是你需要关注的信息。

我们会告诉运维人员告警应该排除，加入白名单还是深入分析。

这里面涉及很多相关联的信息，我们会提供离线分析工具来分析这个告警是否有效。借助这些信息我们可以快速判定，是否应该深入处理告警。我把这个能力，当成这个系统的重要里程碑，在我们不参与游戏运营的情况下，识别出游戏是否存在异常，才真正达到了我们的初衷“在海量游戏运营中，发现影响游戏运营安全的异常问题”。

6.4 阶段三 --- 精细化运营

• 精细化运营：
  
  • 业务快速接入
  • 告警处理

第三阶段是告警的精细化运营，使得告警准确率逐月提高。

通过告警的精细化运营，不断的把一些该忽略的日志排除掉，把告警分级精细化，这个系统逐步趋向完善了。

我们最近与其他公司的同事交流，怎么应对游戏里面的去刷物品的威胁。他跟我们说，他们公司游戏不多，但是每个游戏都配了一个专人做经济系统异常分析，我觉得这个投入非常大，当然如果他能解决问题，这个投入也非常值得。

前面我们提过，一个游戏健康运营是离不开健康的经济系统的，保护这个游戏的经济系统能够使得游戏生命周期变得更长一些，原来可能半年上线，半年之后就会掉到排名很后里去了，但是经济系统比较健康的话，可以长期去运营，玩家能够感受到这种问题，感受到这个游戏是否健康。

这个方案没有接入成本，接入一个游戏就几分钟时间，所以我们游戏都接入进去了，不管有没有收入，不管是什么玩法，一视同仁。

平均每个业务平均一周的告警量，从原来的K级别，降到个位数。产品和运营还跟我说，我这个游戏怎么没有告警，他非常担心。然后终于可以和老板吹吹牛逼了。

我们对告警还有具体的问题，建立了完整案例库。前面展示的模型也是经过一年多逐步完善的，而且还不断的有新的模型来补充。

我们的发现率半年下来大概88%，现在会更高一些。没有发现的原因，是由于这个游戏接入系统的时候，设计上本身已经含有一些BUG了。我自动学习的时候，已经把这种问题，把这种BUG数值、特征学习成正常的。如果我没告诉这个系统，这种特征应该是异常的，他自己是不会分辨的。

后来我们上了一些分区算法，上线之后，这种情况也被消灭了。所谓的分区算法，我们游戏如果是分区分服的游戏，有些区开了一年，其实里面的大玩家是比新区多很多倍的，玩家层级风格会更明显一些。但是新区玩家刚进来，一个星期大家还都在新手区，可能存在比较新的级别，所以新的玩家比较少一些，而且他们消费特征也没那么明显。这都是分区算法需要兼顾的一些情况。

6.5 效果

• 阀值自动化学习，接入成本从1天降到5分钟
• 发现量从个位数上升到百位数
• 告警确认时间从4小时降低到20分钟
• 1-2玩家“搞事”的时候发现问题
• 解决“海量”、“个性”带来的障碍

以上就是我分享的内容，主要是大数据分析和运营。我觉得运维可以做的事情非常非常多，因为我们掌握的数据和资产非常多，你可以往安全方面发展，也可以给运维、开发人员做很多相关产品，辅助他们的工作，也可以深入玩家层面，去做体验优化。