腾讯游戏海量业务场景下的个性化安全运营之道

本文探讨了腾讯游戏在海量业务场景下如何应对运营安全的挑战,包括运营安全案例分析、面临的问题如运营流程复杂、动态运营、内部误操作等。文章提出,过去的安全方案虽有一定成效,但仍存在局限性,如告警波动大、告警量过多。为解决这些问题,腾讯游戏采取了新的监控和告警策略,通过自动化学习的方法动态更新大部分用户的特征,提高了异常问题的发现能力,降低了无效告警,实现了精细化运营。
摘要由CSDN通过智能技术生成


本文篇幅较长,建议收藏后慢慢学习。

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

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

1、个人介绍

2、主题

3、运营安全案例

4、挑战

5、过去的努力

6、新方案及效果

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

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

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

近期AWS技术峰会在北京也举行了,当时提了一个很重要的观点,安全是第一要务,对所有企业来说,也是第一要务,安全是重中之重,它和备份系统一样,没做好的时候,可以毁掉一个业务。

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

一、个人介绍

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

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

直到前两年新的DNF运维还在用这个工具,可能这个工具写得太好了,以致于我当时的leader对运维的工作复杂度没感觉(joke),也没有GOPS这样的舞台给我来发挥,就让我再干了好几年的基层工作。

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

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

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

本文和大家分享的内容和游戏紧密相关,希望分享的思路能够给各行各业的同行们带来些共鸣。

二、主题

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

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

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

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

三、运营安全案例

3.1、影响运营安全的案例1

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

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

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

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

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

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

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

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

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

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

3.2、影响运营安全的案例2

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

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

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

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

3.3、影响运营安全的案例3

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值