qq游戏修复工具|腾讯游戏海量业务场景下的个性化安全运营之道

01. 个人介绍

02.主题

03.操作安全案例

04.挑战

05. 过去的努力

06.新方案及疗效

游戏运营安全遇到的问题，包括腾讯游戏遇到的问题，以及行业内的典型案例。 在说解决方案之前，先说一下解决这类问题遇到的挑战，我们这几年也想了一个办法，尝试了一些方法来解决安全问题。 今年我们采用了一些新方案，疗效还不错。 最后，让我告诉你我们的具体计划。

近日，AWS技术大会也在上海召开。 当时提出了一个很重要的观点。 安全是重中之重，也是所有企业的头等大事。 安全是重中之重。 它与备份系统相同。 如果做得好，企业可能会毁掉。

我们在行业中也看到了很多负面案例。 例如，雅虎之前想出售。 初始市值为40亿美元。 但是由于一些安全问题，被挖角之后，最后几乎没有人要这个业务，所以安全问题一旦发生意外，影响会非常大。

01

自我介绍

2008年加入腾讯，开始从事DNF运维工作。 DNF上线后，PCU数量增加，2008年和2009年服务器数量达到几千台。当时我在做运维工作，用ruby写了一个配置管理工具。 一个命令生成所有服务器的配置和启动和关闭脚本。 现在看来，这个工具已经有了一些前卫的概念，包括CMDB、自动化、自动生成等现代高级概念。 确实比较好用，而且还结合了我们自己公司新的内部系统。 直到前三年，新DNF运维还在用这个工具。 可能这个工具写的太好了，所以当时没觉得（开玩笑）运维工作的复杂，也没有像GOPS这样的舞台让我发挥，就让我做草根工作好几年了年。

后来还负责了御龙、飞车、火影等多款端游和手游的运维和管理工作。 目前，我在运营部负责运营安全，职责比较复杂。 因为业务层面的东西需要落地，范围包括腾讯所有游戏的应用运维安全、游戏经济系统的安全、审计部门的技术支持。 从2008年到现在已经快六年了，我还在游戏领域。 我从来没有离开过，以后也不一定能离开。

本文与您分享的内容和游戏密切相关。 希望分享的想法能够引起各界同仁的共鸣。

02

主题

在大家眼里，可能会有这样一种想法，认为做游戏是一件很赚钱的事情，也有一种共识，就是做游戏不容易。 没有做过的人可能完全无法想象整个过程有多么艰难。

腾讯也是如此。 一款游戏从立项到上线，要经过无数次的测评、数据分析、改版、优化。 挑战将展现在你的眼前，也就是运营期间遇到的各种挑战。

什么样的产品是游戏？ 是一款以玩法多样、操作动感为重要特征的产品。 玩法很多，操作过程也很灵活。 测试遗留的 BUG、来自外部制金工作室和作弊的威胁，以及内部风险，包括计划不周和误操作的破坏性影响，从受伤到骨头。 ，影响了游戏经济的平衡，更重要的是公关危机，只好改名从头再来。

因此，一款游戏成功的基础离不开一个健康的经济体系，有稳定的生产者和消费者，有稳定的游戏规则，经济体系按照预设的路径稳定运行。

03

操作安全案例

3.1. 影响运行安全的案例一

拿出来给大家带来近期影响游戏运营的案例。 有过去的、现在的、外在的影响、内部的误操作。 这些产品都比较知名，为免麻烦，这里就不点名了。

某游戏寄售商城，当订单请求中的物品数量改为超小正数时，由于数值下限溢出，游戏中任意道具、装备、宝石都可以刷直接分批。 如果您对作弊有一定的了解，您应该知道这种情况。 你可以抓取它的客户端和服务器端的请求包，解压重放，这样你就可以篡改游戏数据了。 这些是游戏开发过程中由于代码不严谨而遗留下来的一些比较常见的问题。

虽然手游时代的外挂和辅助程序不像端游时代那么猖獗，但这和平台还是有一定关系的。 这个游戏很受欢迎qq游戏修复工具，如果有利可图，总会有人想方设法找些漏洞。 这种情况太多了，我们在开发过程中没有注意到它们。 比如在一场球赛中，通过好友的赠送可以获得大量的金币。 原因是服务端和客户端都存在缺陷，没有对分发资质进行严格校准。 玩家可以通过无限断连重连的方式反复刷取奖励。

这些场景比较常见。 如果没有经验的人可以写出这些代码，为什么会出现这些问题呢？ 是因为我们收到后，服务器并没有立即将分发记录返回给数据库。 收到离线消息后，会将数据写回数据库。 这也是一种从性能上考虑的机制，在这些情况下，因为涉及到关键数据，所以不应该做。 声明后应立即将数据返回到数据库，以防止播放器异常断开连接，导致记录不被记录。 .

例如某款手游可以通过修改订单请求数将订单请求数变为0，即可获得免费道具。 你相信吗？ 如果电商有这些BUG，我怕我要破产了。

游戏其实只是电子虚拟产品，电子商务是实体产品。 如果有这些bug，就没有办法了。 业内也有这样的案例。 比如通过游戏内的离婚、结婚、再离婚，可以重复发放奖励。

3.2. 影响操作安全的案例2

通过现金返还赚取重复利润。 某游戏推出礼包活动。 原先的设置是100元可以购买100个礼包，配置的时候把数量错误配置成了上千个礼包。 玩家可以用100元订购原装礼包的数十倍。

且不说这个礼包有多少，如果能以极低的成本大量拿到，那影响就特别大了。 相当于在游戏中放了很多这些东西，对游戏的平衡性会有很大的影响。 这种情况也很常见，不一定是策划或操作失误。 可能是内部操作系统真的没做好。

我看到有些集成系统可以在里面设置。 玩家的 UIN 离砖石很近。 如果我们不小心把这两个东西填反了，那就麻烦了。 比如玩家本来发了几百块砖，结果发了上亿。 这很麻烦。 例如，您可能听说过业内广为人知的“女儿节”丑闻。 这些事情如果不及时处理，问题会很严重。

3.3. 影响运行安全的案例三

某天凌晨5:00左右，某知名游戏中两对前端redis出现故障。 一对重启后成功，另一对重试后继续失败，导致部分数据丢失。 充值活动的奖励只能发放一次，但由于本次一次性活动的记录已经清空，可以重复发放。

这个案子的影响不是很大。 如果游戏中的服务器不多，问题可能很快就会暴露出来。 如果一个游戏的服务器很多，比如很多页游都是以开服作为主要的反弹方式来增加活跃度和收入。 它有很多服务器，一个频道上有成百上千台服务器。

如果出现这种情况，运维和DBA可能会恢复服务器，在游戏中影响不是那么明显。 恢复后没有完整的测试，或者玩家举报，很难查出来，玩家会接受。

3.4. 案例四影响运营安全

还有一种情况是玩家发现了，举报了，通知了官方，结果却因为处理的拖延，出了大问题。

最近在业界有一个非常有名的案例。 玩过这款游戏的小伙伴应该不少，对于这款游戏的过年风波也有所了解。

2017年春节前后，曝出BUG。 玩家可以在不消耗套票的情况下无限挑战低难度值的副本，但是否还能获得副本的专属中级武魂和大量经验。 以最坏的情况计算，副本需要15秒。 从过年到修复3天时间，一个玩家大概能得到5000多颗四星专属御魂，价值约100万+RMB，导致大R极度不平衡。

如果这件事处理的及时一些，问题就不会影响到游戏的平衡和品牌，也不会演变成公关危机，虽然那时候已经是公关危机了。 当时甚至有玩家要求退货，有的甚至联名起诉游戏开发公司。 因为有各种各样的玩家，有法律专业人士，也有土豪，他们都有很强的维权意识。

大家对公关危机这个词的理解不一样吧？ 但最重要的是，如果游戏运营商能够在问题蔓延之前发现问题，他们就会非常主动地处理它。 我觉得这个能力很重要。

3.5. 一个有趣的想法

这是网上有人对这个案例的有趣思考。

3.6. 问题

3.7. 先定个小目标

所谓隐藏BUG，顾名思义，如果知道和掌握BUG的人不公开细节，就不会在玩家层面蔓延开来，运营商和开发商也不会知道游戏中的BUG。 随着时间的推移，隐藏的错误将变得有利可图。 观点。 在游戏中，获得这种点数就可以卖掉，这将成为对游戏运营和游戏经济系统安全的最大威胁和挑战。

04

挑战

4.1. 游戏安全运营的挑战

总的来说，游戏的安全运营存在两大挑战。

第一，复杂性；

第二，有些问题比较单一，数量少的时候，没那么复杂，等量上来的时候，这个问题里面有很多未知的问题。 这种坑你一定要跨过，你才能感知到问题所在。 那里。

4.2 复杂点之一：操作流程长

这是我们最常见的业务发布流程。 不管是服务端还是客户端，都要经过这个过程。 在版本上线之前，经历了很多环节。

可以想象，问题不一定是代码的bug，也不一定是测试检测不到，也可能是发布过程中运维出现了一些问题。 比如前端机器的故障导致玩家在少数场景下获得了冗余的砌体输出。 这是与我们运维密切相关的干扰。 每个环节都可能出问题，复杂度很高。 它确实可以帮助我们简化整个流程，实现从开发环境到生产环境的高度一致性。

4.3. 第二复杂：动态操作

如果游戏要成功，玩家的父亲就必须享受游戏，让玩家父亲花的钱和时间值得。 这样一来，开发者和运维人员就必须根据运营情况不断快速调整，才会被玩家接受和理解。

我相信每个产品都是这样，包括电商、商务等等。 正因如此，好游戏都是改的。

上图是我们公司某款游戏一年发布的版本数。 它看起来并不多，一年可能超过 400 个版本。 事实上，它们中的大多数都是在不停机的情况下更新的。 版本多了之后，很容易形成BUG。 有可能新问题刚搞定，老问题又下来了。

游戏是一个功能众多的小社会，交互非常复杂，很难做到完美。

4.4、第三种复杂性：有些“不专心”

这种复杂性与人有很大关系，存在一些“漫不经心”的行为。 比如操作上难免会出现问题。

比漫不经心更可怕的是故意为之，内部人是有目的的做一些操作。 这方面是涉及利益和诱惑的东西，是对人性最大的挑战。

4.5 巨大挑战之一：海量业务

说到海量，我们的游戏在 cmdb 中已经有 1000 多个条目。 不仅业务量巨大，我们还有很多打破世界纪录的PCU业务，比如LOL，《王者荣耀》等等。 这些业务来自自主研发的工作室，以及全球知名和非知名的开发公司。

游戏开发是一种艰苦的脑力劳动。 每个架构师和主程序都有多年的工作经验，对游戏架构设计有着深刻的理解，虽然整体游戏架构可以用同样的方式来理解。 通常分为：

各层的设计和具体实现取决于个人经验和游戏的实际需求。 一些开发者喜欢以平板电脑的形式存储物品数据，每个玩家的背包中包含数百条单独的物品记录； 为了方便和节省空间，一些开发人员喜欢以二进制补码的形式存储书包数据。 后者便于相关结算，前者便于服务器合并迁移时的记录迁移。

游戏日志根据不同的游戏场景有不同的日志输出。 比如：各种道具的产出和消耗，参与活动，奖励的获得，游戏关系的改善和终止等等，都是游戏上经济活动的真实记录，形形色色。 从海量业务中发现问题，首先要从了解游戏入手qq游戏修复工具，了解海量的游戏数据和日志。

4.6. 海量挑战二：海量支持系统

不仅是游戏本身，运营期间的游戏都需要配备各种支持系统来辅助游戏运营，以满足活动、客服、数据分析等各种需求。 随着需求的减少和时间的积累，支持系统的多样性和插座的复杂性也是海量支持的挑战。 在游戏中发现异常问题时，会带来很多注意或消除的激励。

里面图片右边是最常见的游戏和我们公司内部系统的关系，包括游戏的访问时间。 根据标准化要求，应提供各种插座给游戏官网、客服平台、营销平台、内部合作伙伴等方使用。 因为有些游戏是从外面导入的，可能会有单独的GM管理系统，不仅是为了运营需要，还需要运维、开发、测试等各个方面通过向游戏下发各种指令，包括刷新一些配置等。

这些外设系统或者插座是游戏变化的源头，有一定的概率会导致游戏出现非预设的问题，也就是一些难以想象的问题。 一般来说：

05

过去的努力

在我的团队成立后，我开始想方设法发现游戏中的异常问题。 我们从2010年左右开始在这方面做建设，过去的努力有一定的局限性。 虽然跟我们的一些想法有关，但是也跟行业内的技术是否成熟有关。

5.1. 基本保障&监控报警

过去我们做一些技术上的支持，包括对日志进行标准化，支持系统日志，给它们一个序列号，这样我们就可以追踪每一个游戏日志是为什么形成的，是在哪里形成的。 在流程规范上做了很多建设，避免了大量的人为错误。 之后，建立了常规的风暴处理机制，快速应对所有异常，防止公关危机的形成。

这些情况对于腾讯游戏来说极为罕见。 同时，为了及时发现游戏的异常波动，我们与游戏策划紧密合作，根据策划表进行监控。 一旦玩家端的数值变化超过规划表的数值，就会发出警报。

5.2. 旧方案疗效不理想

以下这些基本保障，已经帮我们在异常监测上打下了良好的基础，而基于定值监测的方式，闭着眼睛也能猜出结果，其疗效可以说是不费吹灰之力。

一是报警波动较大。 游戏是一个小社会，上面有形形色色的玩家，中级玩家和普通玩家的情况有很大的不同。 包括品级、属性、权益。 有可能参加同一个活动，他的权益不同，他的产出也不同。 玩同一个副本获得的经验也是不一样的。

其次，告警量巨大，平均每家企业每周告警数超过1000条。 运营人员告诉我们，如果我被提醒，我将无法玩LOL。 随着时间的推移，此类监控方案和系统受到的批评比以往任何时候都多。 运营商说，“你们不仅帮不了游戏发现问题，还给我带来了巨大的额外工作量。” 该系统没有获得信任和声誉，并逐渐从运营商可以依赖的列表中消失。

06

新方案及疗效

6.1. 新主意

游戏社会的特点类似于现实社会中的一种情况。

游戏社会的特点，大部分情况都是按照预设的规则运行，大多数人的行为特征符合正态分布的原则。 只有一小部分人不遵守规则。 如果我们抓住了大多数人的特点，就很容易找到少数人的特点。 这与我们的**工作也有一些共同的想法，但这些人中的大多数人的特点并不是一成不变的。 一款游戏的整体价值，是从开服到几个月后逐渐演变的。 如果我们能找到一种方法来不断更新大多数人的特征，那么现有的这种固定阈值的问题就会迎刃而解。

这些特征是什么？

这里的特性指的是游戏中的道具，它的每一个通道，我去商店点东西，打副本或者打怪形成一个通道。 每个道具形成了每个通道的消耗和输出规律，也就是我们所说的特性。 一个RPG游戏可能有数以万计的特征和规则，因此估算成本非常特殊。 为此，我们使用最流行的“自动学习”思想来帮助我们解决个性化问题。 这个计划从今年开始。 为了提高检测游戏异常问题的能力，我们将工作分为三个阶段。

6.2. 第一阶段：监测能力建设

在监控能力建设方面，我们改变了结构，增加了很多监控模型。

这是我们的总体技术框架。 底层和所有业务一样。 是游戏的原始数据或者经过一定标准化后上报给大数据平台的数据。

第二层和很多用过大数据平台的人一样，包括spark、kafka、es等，只要对大数据感兴趣，自己实践，相信在座的每个人都能搭建一个大数据一周内完成基本系统，包括数据接收层、存储层、计算等。

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

最上层是展示层，是向用户端发送告警的内容，告警分析层。 这里可以使用离线工程帮助您分析告警是怎么回事，查看问题的具体发生情况。 在那个用户头上，有什么日志，所有关联的用户信息都可以导入。 因为我们不是游戏运营商，所以一旦发现问题，需要游戏运营商和开发者详细查看。

使用这个框架，如果我们看 50 场比赛，每小时的日志量大约是 500 亿。 总共有300个CPU在运行，每个核心的使用率都超过80%。 总的来说，它是非常高效和节能的。

经过一年多的不断积累，在此简单介绍一下系统支持的重要监控模型。 日志就是我昨天说的玩家层面的一些活动，它落地到游戏上的就是游戏的日志。

关注频率异常和趋势异常。

频率异常模型：这个是以用户输出频率为维度，以持续高频为监控算法，比如隐藏BUG，玩家为什么要用，一个是好奇，如果他有组织，他一定得到如果你不赚钱，就没有继续工作的必要。 要想盈利，就得反复做，少做几次，生产的东西就少，盈利的时间就有限。 如果他能一直重复发请求，就让这个游戏反馈给我吧。 在上面的第一种情况下，有一个动画。 小人向服务端发送契约包，客户端会不断弹出消息，可以获得某样物品。 这就是游戏频率异常模型需要应对的。 对网络合约级作弊有很好的疗效。

趋势异常模型：是以整个服务器单个角色的最大输出为维度，虽然最大值是有区间的，不是数值。 我们监控所有玩家的活动是否超过这个范围，这个范围会不断动态变化，不断更新整个区域或者整个服务器的特性。 监控范围会比较广，但是容易受活动和版本的影响。 比如我把一个道具放到游戏里，它的输出会比平时高很多倍，而且还会报警，所以需要辅以其他模型，也需要后续的报警确认机制协助。

6.3. 第二阶段：告警分析能力建设

第二阶段是告警分析能力。 报警后可以分析哪些报警信息是有效的，是否需要跟进。

我们通过各种模型算法找到告警。 其实报警不一定是真正的问题，而是你需要注意的信息。 我们会告诉运维人员，该告警应该消除，加入白名单或者深度分析。

这涉及到很多相关信息，我们会提供离线分析工具来分析这个告警是否有效。 通过这些信息，我们可以快速判断该告警是否需要深度处理。 我把这种能力看作是这个系统的一个重要里程碑。 在我们不参与游戏运行的情况下，我们可以识别游戏是否有异常，真正达到了我们的初衷。 不寻常的问题”。

6.4. 第三阶段：精细化运营

第三阶段是报警的细粒度运行，导致每个月的报警准确率都有所提升。

通过对告警的细粒度操作，不断剔除一些本应忽略的日志，细化告警级别，系统逐渐变得更加健壮。

我们最近跟其他公司的朋友交流，如何应对游戏中farm道具的威胁。 他告诉我们，他们公司的游戏不多，每个游戏都有专门的人分析经济系统的异常。 我觉得这个投资特别大。 其实，如果他能解决问题，这笔投资也是非常值得的。

我们后面会提到，一款游戏的健康运营离不开健康的经济体系。 只有保护好游戏的经济系统，游戏的生命周期才会显得更长。 可能半年后上线，但半年后排名就会跌到垫底。 去吧，如果经济系统比较健康的话，可以常年运营，玩家可以感受到这些问题，感受游戏是否健康。

这个解决方案是没有接入成本的，接入一个游戏只需要几分钟，所以我们的游戏是集成的，不管有没有收入，不管玩法，一视同仁。

单笔业务每周平均报警量从原来的K级下降到个位数。 产品和运营也告诉我，他很害怕我的游戏怎么没有警告。 之后，终于可以跟老板吹牛了。

我们还有一些关于告警的具体问题，并建立了完整的案例库。 上图模型经过一年多的时间逐步建立，新的模型也在不断的加入。

我们半年发现率大概是88%，现在会更高。 之所以没有注意到，是因为在游戏接入系统的时候，设计本身就已经充满了一些bug。 我在手动学习的时候，就已经把这些问题，这些BUG值和特性都学成正常了。 如果不是我告诉系统这些特征应该是不正常的，他自己也分不清。

后来我们推出了一些分区算法，上线后，这些情况都被排除了。 所谓的分区算法，如果我们的游戏是分分区分服的话，有的分区开了一年，虽然大玩家比新分区多了很多倍，但是玩家层级风格会更加明显。 而新区的玩家刚进来，你还在菜鸟区呆了一周。 可能是因为关卡比较新，所以新玩家比较少，但是他们的消费特征没有那么明显。 这些是分区算法需要兼容的一些情况。

6.5. 影响

以上就是我分享的内容，主要是大数据分析和运营。 我觉得运维可以做很多事情，因为我们有很多数据和资产，你可以在安全方面进行开发，也可以做很多相关的产品给运维和开发者辅助他们工作，还可以深入到玩家层面，优化体验。

更多好玩的游戏app就在我想玩网站，（https://www.wxnmd.com）