腾讯游戏产品运营事故案例介绍课件.ppt

腾 讯 大 讲 堂第五十一期研发管理部大讲堂主页：WalkerWalker2腾讯游戏产品运营事故案例介绍课件讲述事故背后的故事，从案例了解网游运营讲述事故背后的故事，从案例了解网游运营3腾讯游戏产品运营事故案例介绍课件目录目录•凯旋游戏产品凯旋游戏产品–Mini Boss活动事故–白装备事故•堂游戏产品堂游戏产品–欢乐幸运星活动事故•幻想游戏产品幻想游戏产品–售卖系统道具复制游戏事故–“绛紫宝箱”道具复制事故• Mini Game Mini Game平台平台–Dir Server雪崩4腾讯游戏产品运营事故案例介绍课件腾讯游戏发布轨迹腾讯游戏发布轨迹20042004年年20052005年年20062006年年20032003年年20072007年年20082008年年20092009年年从从20032003年到年到20082008年，腾讯游戏的发展已经走过了年，腾讯游戏的发展已经走过了5 5年多的历程年多的历程2003-082003-08游戏大厅发布凯旋公测凯旋公测5腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品产品 《《凯旋凯旋》》是腾讯代理是腾讯代理IMAZICIMAZIC的一款的一款3D3D大型网游，也是我们试水网络大型网游，也是我们试水网络游戏市场的第一款产品。

为此腾讯在上海专门组建了网络游戏事业部游戏市场的第一款产品为此腾讯在上海专门组建了网络游戏事业部来负责该产品的运营工作，该游戏从来负责该产品的运营工作，该游戏从20032003年年8 8月月1 1日正式公测上市日正式公测上市6腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品产品 《《凯旋凯旋》》在当时是一款非常高端的产品，在当时是一款非常高端的产品，3D3D画面效果优画面效果优秀出色，采用了无缝地图技术，真实装备秀出色，采用了无缝地图技术，真实装备AvatarAvatar，任务链，任务链设计，宠物系统等等，设计理念新颖，市场影响力大设计，宠物系统等等，设计理念新颖，市场影响力大7腾讯游戏产品运营事故案例介绍课件网游运营事业部组织图网游运营事业部组织图 网络游戏事业部的组织架构图网络游戏事业部的组织架构图部门总经理市场部策划部客服部技术部海外部渠道部市场策划组网站设计组翻译测试策略8腾讯游戏产品运营事故案例介绍课件 《《凯旋凯旋》》公测之后，为了迎接十一长假，策划希望策划一些线上活公测之后，为了迎接十一长假，策划希望策划一些线上活动，继续冲高，动，继续冲高，Mini BossMini Boss活动就此出炉。

活动就此出炉9腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品产品•Mini BossMini Boss事故记录事故记录–由策划部提出希望在国庆节期间开展一个活动，营造游戏中的节日气氛，并提高节日期间；–活动策划案需求转交韩方后，韩方回复他们正好新开发了一个类似的活动包，可供我们使用；–这个活动包的内容主要是将游戏内地底深处的超级BOSS缩小后随机放到地面刷出，供普通玩家挑战，并且还有机会获得珍贵宝石；–策划部门同意采用该活动包，作为国庆期间节日活动的一部份，并相应准备了相关的网站宣传内容；–活动包由韩方提供给海外部，同时策划部之前提供了测试需求给海外部，海外部测试后认为符合需求，因此交给了技术部，然后技术部安排了自动更新的脚本，在10月1日凌晨自动启动10腾讯游戏产品运营事故案例介绍课件•Mini BossMini Boss事故记录事故记录–10.1期间，部门放假，活动自动执行，结果因为一些细节设计问题和宝石产出几率过高，导致活动期间珍贵宝石大量产出，玩家采用自动化方法大量获取珍贵宝石后对整个经济系统产生巨大影响；–流通道具的大量产生导致了一系列问题，游戏体验被迅速透支，流失玩家数量惊人；–假期结束后，整个游戏由4W多下跌到不足2W，游戏内经济崩溃，物价异常变动，大量忠实玩家离开，流失玩家数量巨大。

因此事故时间太久，无法回档，官方已经没有任何办法消除事故影响；–经此打击之后，凯旋的游戏一直未能得到恢复，之后再未突破过4W水平，持续下跌至目前水平11腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品产品韩方IMAZIC部门总经理市场部策划部客服部技术部海外部市场策划组网站设计组翻译测试策略12腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品产品•在Mini Boss事件中，错误究竟发生在哪里呢？•似乎每个部门都有错，但是每个部门却又没有能力去发现和制止错误，似乎大家一起努力的结果就是朝错误的方向越跑越远；•在错误产生之后，却很难找到责任人，甚至没有一个直接责任人出现事故之后，团队没有收获任何经验教训，只能继续这样运转13腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品产品•白装备事件记录白装备事件记录–2004年1月15日凯旋发布一个新的版本的时候出现的一个BUG，导致部分玩家背包中的带属性的绿色蓝色等高级装备变成没有属性的白色装备，同时还出现部分玩家角色消失问题；–在我方测试时，未及时发现此问题更新后，开始陆续接到玩家投诉，技术部检查后确认是游戏BUG造成，于是通过商务部向韩方提出紧急修复的需求，同时开始逐个手工处理玩家投诉；–当天下午的时候，玩家投诉量达到400单，技术部门开始通宵处理，到次日凌晨投诉量已经上升到1500单，手工处理已经无法承担。

这时候因为北京的展会缘故，相关领导均不在公司，一直无人拍板最终处理方案，只能继续手工处理14腾讯游戏产品运营事故案例介绍课件•白装备事件记录白装备事件记录–等到下午，韩方发来一个统计工具，用于统计受损的账户数量；–经过统计后发现受影响账号竟然在10万以上，于是又经过漫长讨论，最终决定回档此时距离发现问题已经过了30多个小时，需回档时间近2天，受影响活跃玩家几十万人；–回档过程中，再次发现数据异常，无法启动服务器，游戏停机时间一再延长，在18个多小时后才恢复了服务；–经此打击，更多的活跃玩家离开了凯旋，游戏下跌到1万余15腾讯游戏产品运营事故案例介绍课件 对于回档游戏数据，团队既没有成熟的运营处理预案，也没有进行过任何对于回档游戏数据，团队既没有成熟的运营处理预案，也没有进行过任何演练，迟钝的反应和生硬的处理手法显现出了运营团队的稚嫩演练，迟钝的反应和生硬的处理手法显现出了运营团队的稚嫩16腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品产品•在白装备事件中，我们得到了哪些教训呢？在白装备事件中，我们得到了哪些教训呢？•对于网游产品，测试部门是一定需要专业重点建设的；•对于紧急事故必须有完备的处理预案和责任人制度；•对于重大的备份恢复操作，平时要经常演习熟悉；•对于风险评估和具体应对，我们还需要更多的经验；•对于用户管理和运营维护方面的经验缺乏，舆论导向控制不力，用户反馈收集缓慢，信息不全，用户体验很差；•最重要的是，我们需要一个符合网游产品运营特点的团队管理结构。

17腾讯游戏产品运营事故案例介绍课件•只有合理的将一个整体任务的结果责任赋予某人，才能让其拥有与这个责任对等的权力来制约和控制整个事情•经验必须是沉积在每个人身上，而不是整个团队，富有经验的的产品经理是一个团队的重要财富18腾讯游戏产品运营事故案例介绍课件现在的运营团队工作模型现在的运营团队工作模型•一个运营团队的三层工作模型一个运营团队的三层工作模型客服客服市场市场运维运维渠道渠道网站网站研发研发用户用户……19腾讯游戏产品运营事故案例介绍课件现在的运营团队工作模型现在的运营团队工作模型•涉及的资源关系涉及的资源关系策策划划客客服服运运维维市场市场网网站站渠渠道道信信息息商商务务品品牌牌用户用户外外包包程程序序美美术术公公关关法法务务广广告告战战略略安安全全其他其他内部内部团队团队运营团队运营团队项项目目组组20腾讯游戏产品运营事故案例介绍课件现在的运营团队内部工作模型现在的运营团队内部工作模型运营项目A运营项目B运营项目C21腾讯游戏产品运营事故案例介绍课件《《凯旋凯旋》》产品后续产品后续•《凯旋》之后，公司在很长时间一直没有再代理海外的游戏产品；• Game的崛起让公司决策方面决定加强自研网游产品的投入，上海团队主要力量被拆散，大部分骨干人员流失，腾讯在大型网游市场的第一步就摔了一个不小的跟头；•自研 Game产品获得成功后，公司决定继续研发更加高端的游戏产品，第一款ACG产品《堂》2004年中正式立项了。

22腾讯游戏产品运营事故案例介绍课件腾讯游戏发布轨迹腾讯游戏发布轨迹20042004年年20052005年年20062006年年20032003年年20072007年年20082008年年2003-082003-08游戏大厅发布游戏大厅发布凯旋公测凯旋公测20092009年年2004-122004-12堂公测堂公测23腾讯游戏产品运营事故案例介绍课件《《堂堂》》产品产品 《《堂堂》》从从20042004年年6 6月开始开发，月开始开发，1212月月3030日正式公测上日正式公测上市，市，20052005年年7 7月月1 1日发布正式版本，游戏最高一度达到日发布正式版本，游戏最高一度达到2222万最高同时，注册用户数多达数千万玩家万最高同时，注册用户数多达数千万玩家24腾讯游戏产品运营事故案例介绍课件《《堂堂》》产品产品•堂产品第一次建立了产品运营团队，虽然才3个产品人员，但是已经开始建立项目和产品的负责制同时，部门也逐渐开始尝试将技术主导型的工作模式转变产品运营主导型的工作模式；•堂如果诞生在别的公司，注定将成为一个没有任何市场反应就会迅速失败的产品，但是我们的平台给这个产品源源不断的送去了用户，让产品研发运营团队得以生存，得以学习和提高。

在运营了7个月后，产品运营团队开始逐渐找到了感觉，终于开始学会如何掌控这个产品，7月的正式版本之后，堂慢慢发力，开始节节上升；•产品团队信心十足，甚至开始变得有点急功近利了25腾讯游戏产品运营事故案例介绍课件《《堂堂》》产品产品•堂堂““欢乐幸运星欢乐幸运星””抽奖抽奖–2005年8~9月间，因为互娱BU另外一款重量级产品《幻想》的跳票，互娱系统的月度考核指标遇到了极大的挑战，领导层号召各个产品设法拉高收入，严守KPI底线；–堂产品当时状况发展良好，如何转换成为收入的问题于是变得更加重要，大家开始群策群力的贡献点子，力求帮系统更多承担一些收入；–在几次风暴会议后，多个营销性质项目开始启动其中，有一个博彩类的项目非常被大家看好，这个项目叫做堂“欢乐幸运星”抽奖活动26腾讯游戏产品运营事故案例介绍课件《《堂堂》》产品产品–20052005年年9 9月月2929日晚日晚8 8点，在经过研发测试等同事加班加点的紧张开发之后，点，在经过研发测试等同事加班加点的紧张开发之后， ““欢乐幸运星欢乐幸运星””活动如期开发完毕，并按照版本计划，活动如期开发完毕，并按照版本计划， 更新到了外网环更新到了外网环境；境；–8 8点半钟，运营团队接客服报告，声称有两名玩家已经中到一千万游戏币点半钟，运营团队接客服报告，声称有两名玩家已经中到一千万游戏币的大奖。

运营团队按照紧急预案召集所有相关人员赶回公司处理；的大奖运营团队按照紧急预案召集所有相关人员赶回公司处理；–9 9点多，客服方面再次汇报，已经确认点多，客服方面再次汇报，已经确认BUGBUG存在，有大量玩家重复中奖存在，有大量玩家重复中奖运营负责人要求立即关闭道具售卖系统；运营负责人要求立即关闭道具售卖系统；–1010点前，运维同事关闭了道具售卖服务器，产品，研发，运维，测试等点前，运维同事关闭了道具售卖服务器，产品，研发，运维，测试等各线人员赶到，马上召开了事故分析处理会议，并通知平台线方面同事各线人员赶到，马上召开了事故分析处理会议，并通知平台线方面同事协助；协助；–1111点，事故原因查明，得到事故初步损失统计，参与得利玩家第一批名点，事故原因查明，得到事故初步损失统计，参与得利玩家第一批名单也已经获得，运营团队开始要求各方面协助拦截非法游戏币单也已经获得，运营团队开始要求各方面协助拦截非法游戏币27腾讯游戏产品运营事故案例介绍课件《《堂堂》》产品产品28腾讯游戏产品运营事故案例介绍课件•事故过程原因事故过程原因–在抽奖活动的设置中，集齐一套道具在抽奖活动的设置中，集齐一套道具(7(7块多块多Q Q币币) )，可能中奖，可能中奖10001000万游戏币万游戏币( (相当于相当于1000Q1000Q币币) )，一般情况概率应该是万分之零点六，但是策划文档几经修改后中奖表，一般情况概率应该是万分之零点六，但是策划文档几经修改后中奖表格已经出现了很多错误。

而策划评审，运营评审，程序实现各个环节中居然都没格已经出现了很多错误而策划评审，运营评审，程序实现各个环节中居然都没有发现中奖列表的机率加起来已经不是有发现中奖列表的机率加起来已经不是100%100%了；了；–程序实现后提交测试组测试两轮，在测试中因为没有使用大量程序实现后提交测试组测试两轮，在测试中因为没有使用大量QBQB来进行真实的模来进行真实的模拟测试，所以居然没有发现概率方面存在异常；拟测试，所以居然没有发现概率方面存在异常；–种种错误累加起来使种种错误累加起来使26%26%概率的特等奖终于出现在了外网环境中；概率的特等奖终于出现在了外网环境中；–从当晚从当晚8 8点多发布活动到点多发布活动到1010点之前关闭这个活动点之前关闭这个活动, ,仅一个多小时共产生游戏币仅一个多小时共产生游戏币2121个个亿，有亿，有700700多名用户参与了刷取游戏币；多名用户参与了刷取游戏币；–由于钱的数量巨大，玩家四处转移游戏币而冻结账户方面没有预案，虽然紧急由于钱的数量巨大，玩家四处转移游戏币而冻结账户方面没有预案，虽然紧急处理及时，但冻结不彻底，扣款程序又出问题等处理及时，但冻结不彻底，扣款程序又出问题等, , 最终损失还是构成了一级事故；最终损失还是构成了一级事故；–事故发生后对员工和相关领导都受到了处罚。

事故发生后对员工和相关领导都受到了处罚29腾讯游戏产品运营事故案例介绍课件•事后总结事后总结–需求文档需要更仔细check，评审环节的疏漏非常严重；–任何概率类设计都需要设置总量控制，设置多级阀门控制，不要把能广泛流通的货币或者道具直接及时的交到玩家手上，不要奖励；–紧急预案不够完善，只考虑到产品范围内的各种处理方案，没有考虑如果在部门或者公司级平台上出现问题后的处理措施•在处理过程中，产品人员才惊奇的发现我们原来还有游戏币银行这样的东西•在要求各个方面协助冻结相关账户的时候，各系统才开始编写相关的程序进行扫描和回扣，这其中又发生新的BUG，但是多次扣款失败，使损失额度没有能得到很好的控制30腾讯游戏产品运营事故案例介绍课件《《堂堂》》产品后续产品后续•“欢乐幸运星”事件之后，互娱停止了所有涉及抽奖Q币，游戏币的活动，再不涉及任何通过平台渠道发放Q币的活动，以避免风险；•堂团队也停止了这种直接通过抽奖获利的营销活动，开始继续专注于游戏内容的设计和付费挖掘；•2006年2月份，堂一系列游戏活动获得成功，同时达到22万高点，收入也实现了连续翻番，堂道具营销方面经验让很多产品学习得益31腾讯游戏产品运营事故案例介绍课件腾讯游戏发布轨迹腾讯游戏发布轨迹20042004年年20052005年年20062006年年20032003年年20072007年年20082008年年2003-082003-08游戏大厅发布游戏大厅发布凯旋公测凯旋公测20092009年年2005-062005-06宠物发布宠物发布2005-102005-10幻想公测幻想公测2004-122004-12堂公测堂公测32腾讯游戏产品运营事故案例介绍课件幻想产品幻想产品 《《幻想幻想》》是腾讯的一款战略级产品，是互娱自主研发了三年多的首是腾讯的一款战略级产品，是互娱自主研发了三年多的首款款MMOGMMOG产品。

这款产品也是互娱在凯旋项目失利之后，再次尝试运营产品这款产品也是互娱在凯旋项目失利之后，再次尝试运营的的MMOGMMOG产品该款产品产品该款产品20052005年年1010月月2525日公测，最高同时用户数一日公测，最高同时用户数一度达到度达到6666万，是互娱重要的收入产品万，是互娱重要的收入产品33腾讯游戏产品运营事故案例介绍课件幻想产品幻想产品•《幻想》产品是一款探索获取经验的产品，虽然我们投入了大量的人力和时间在这款产品上，但是也毕竟暴露出了我们的很多经验不足之处；•虽然借助腾讯平台的强大力量，《幻想》获得了公测的良好效果，但是游戏设计，运营理念方面的一些不足还是让产品不断下挫在收费后，产品已经不足公测时的一半；•在一年多运营过程中，这个项目也不断出现过一些不同程度的事故，活动的投诉率一直居高不下34腾讯游戏产品运营事故案例介绍课件•幻想道具复制漏洞事故记录幻想道具复制漏洞事故记录–2006年11月12日下午3点，客服方面报告，在游戏中出现一个开店售卖的BUG，会导致开店商人显示的物品列表和实际不符有玩家利用此漏洞进行欺诈，导致大量用户投诉，已经构成一级突发事故，事故已经分派到三线；–接报后，产品经理和PM（兼服务端主程）赶到公司处理。

经过分析，发现是因为客户端BUG导致看到的要买的宠物和实际要买的宠物不一致，从而被玩家利用进行欺诈产品方面分析了具体过程和投诉单据后认为该问题比较严重必须尽快解决，因此打通知测试组运维组，准备进行紧急更新；–因为客户端方面人员一时联系不到，因此PM决定从服务端解决该问题PM提出两个临时解决方案，一个是带宠物商品交易会直接失败，一个是带宠物商品交易，宠物商品会自动回到玩家背包产品方面建议采用后者方案，比如不容易引起玩家困惑35腾讯游戏产品运营事故案例介绍课件幻想产品幻想产品–下午下午5 5点，临时修改完毕，程序在内网更新，测试组进行了测试点，临时修改完毕，程序在内网更新，测试组进行了测试6 6点，点，更新到外网一台服务器，经过一个小时观察感觉正常，更新到外网一台服务器，经过一个小时观察感觉正常，7 7点半进行了全服点半进行了全服更新，产品方面在官网和论坛发布了暂停交易公告；更新，产品方面在官网和论坛发布了暂停交易公告；–再继续观察了半小时无异常，产品方面和客服方面沟通之后，大家回家再继续观察了半小时无异常，产品方面和客服方面沟通之后，大家回家吃晚饭其实这时一个严重的其实这时一个严重的BUGBUG已经被引入到整个游戏世界中已经被引入到整个游戏世界中36腾讯游戏产品运营事故案例介绍课件问题开始蔓延问题开始蔓延•一个游戏道具复制漏洞实际上已经被部分玩家发现，玩家在不断利用这个BUG复制道具的同时，开始通过各种途径传播这个问题：游戏内/各种论坛/群•越来越多的用户开始利用这个BUG复制道具，而且用户开始意识到大量非法道具一定会被官方查处，因此开始设法用各种各样的方式转移复制出来的非法道具。

37腾讯游戏产品运营事故案例介绍课件•幻想道具复制漏洞事故记录幻想道具复制漏洞事故记录–晚上8点多，客服报告，开店售卖可能还是存在问题程序组测试组赶回公司处理，分析后认为下午的修改，有极低概率可能导致道具复制，并且及时修改了这个问题；–晚上9点半，程序方面回报问题已经解决完毕，按问题出现概率来看，带来影响应该不大因此产品方面就没有将此问题升级到事故处理流程进行分析处理；–处理问题最有价值的黄金时段就这样过去了38腾讯游戏产品运营事故案例介绍课件•幻想道具复制漏洞事故记录幻想道具复制漏洞事故记录–次日上午，产品方面发现用户反馈意见很多，问题比较严重，于是要求程序组重新分析原因，要求运维组统计道具复制问题的程度–测试组重现BUG后发现还有更简单的重现办法，复制门槛很低运维统计的初步结果也表现涉及复制玩家多达千名，于是召集事故处理会议进行讨论；–事故处理会议决定先对嫌疑最大的963个账号进行查封处理，以防止复制道具进一步流传，同时开始进行扫描分析；–因为事故发生已经过去10多个小时，复制物品游戏内流向已经非常复杂，但是最近的数据备份时间却是在凌晨四点，在事故发生之后，再近一次的备份时间是前天的凌晨四点。

运营方面陷入两难境地，无论是否回档都面临重大损失39腾讯游戏产品运营事故案例介绍课件•幻想道具复制漏洞事故记录幻想道具复制漏洞事故记录–事故处理小组无法迅速做出回档决定，于是一方面向BU层面报告，一方面决定采用保守方案，扫描全服务器数据，以查找并冻结复制装备；–到中午时间，数千个拥有复制装备的账号已经被冻结，但是游戏内仍然有大量复制道具仍然还在流通，整个游戏的物价受到剧烈影响，经济系统陷入混乱之中；–为了稳定玩家情绪，运营团队通过官网发布公告，道歉并宣称不会回档处理，官方有能力收回非法装备，希望大家给与支持；–到下午时间，扫描数据的工作已很难取得成效，大量无意购买复制装备被封号的玩家也开始激烈投诉各渠道的一线客服压力剧增，大量人力被调派来协助处理，数以千计的投诉单据给产品方面增加了巨大压力；–在这样巨大的压力下，运营组决定先停止服务器，然后再决定具体处理方案40腾讯游戏产品运营事故案例介绍课件1111月月1313日幻想玩家在游戏内各大城市聚集，示威游行，强烈要求官方回档日幻想玩家在游戏内各大城市聚集，示威游行，强烈要求官方回档41腾讯游戏产品运营事故案例介绍课件•幻想道具复制漏洞事故记录幻想道具复制漏洞事故记录–一边是运营方已经做出的不回档保证、超越48小时的回档带来的损失、回档全部57组服务大区数据的难度和风险、回档后会产生的各种用户的海量投诉；–另一边是玩家越来越激烈的抗议情绪、游戏内混乱的经济系统、接近崩溃的物价和无数根本就无法处理的投诉；–系统和部门领导都参加了第二轮的事故处理讨论会议，会议到晚上1点钟做出决定，最终决定不惜一切损失和风险进行回档；–接着运维组开始连夜准备回档方案，程序组开始制作各种工具，产品组开始准备相关公告和补偿方案；–那天深夜，回档的公告在经过了无数人的反复的，斟字酌句的修改后，最后终于在向玩家承诺公布处理方案时限的最后半小时放到了官方网站上；–早晨8点，回档成功，服务器分批开始重新开放。

42腾讯游戏产品运营事故案例介绍课件幻想产品幻想产品43腾讯游戏产品运营事故案例介绍课件幻想道具复制漏洞事故记录幻想道具复制漏洞事故记录•回档公告告诉玩家：–整个幻想世界全部57组服务器将在此次停机维护结束之后恢复到11月12日凌晨4：00左右的状态，所有玩家的游戏数据也将全部回档到同一时间，所有玩家都需要回档48小时；–我们需要补偿玩家大量的经验值，道具，金币，宠物，游戏点卡，玩家寄售卡等等；–我们赠送给玩家两天免费游戏，两天双倍经验双倍掉率等等；–对于用户的一切概率事件，我们均无法复原•之后数千单的各种投诉还困扰了项目组将近一个月的时间，此次事故流失的玩家难以估量，直接经济损失数百万计在幻想游戏本来进入衰退期之前，此次事故无疑是起到了加速产品老化的效果44腾讯游戏产品运营事故案例介绍课件损失损失45腾讯游戏产品运营事故案例介绍课件收入损失收入损失46腾讯游戏产品运营事故案例介绍课件•南方都市报 11月16日 刊登题为“腾讯付费游戏停摆腾讯付费游戏停摆 玩家讨伐如潮玩家讨伐如潮”的负面报道，其后被很多媒体竞相转载舆论危机舆论危机47腾讯游戏产品运营事故案例介绍课件工作影响工作影响•事故善后历经2周，打乱原定的资料片开发计划；•程序、策划、测试、运维、客服，全体团队成员都超负荷运转；•客服一线从其他各个产品抽调人力组织力量突击消灭海量的投诉单据，一个多月后所有积单才基本被清理完毕；•事后，此次事故被确定为一级重大运营事故，相关责任人都受到了处罚。

48腾讯游戏产品运营事故案例介绍课件幻想产品幻想产品•事故总结事故总结–对于道具复制类型问题不够敏感，游戏内缺乏自动监测报警机制，导致事故之初没有得到足够重视；–事故分析速度较慢，对于道具复制问题需要进行长达数小时的全库扫描才能得到结论，过慢的分析能力影响了对事故的定性和处理决策速度；–游戏内严重缺乏防止物品复制的机制，缺乏各种有效的安全开关，缺乏各种不同的运行模式，使运营决策上处处为难；–游戏数据的备份回退机制不够灵活，无法实现根据账单回滚，游戏数据备份周期过长，回档过程缺乏演练，很多必备工具缺乏；–游戏测试机制不够完善，紧急发布流程存在很多隐患49腾讯游戏产品运营事故案例介绍课件•事故总结事故总结–需要在游戏产品设计之初就考虑到未来的可运营性–可监控性•单纯通过用户反馈来发现问题并不足够迅速，还是要系统本身对于各种异常现象有自动监控和报警的机制，比如关键道具的产生量，异常交易量等等–可管理性•在产品开发设计中需要加入设置可由产品运营人员进行配置操作的开关量，如允许/禁止某类物品买卖的开关在游戏中出现某些问题时，可以直接由运营人员通过配置操作来解决，而不需通过修改程序来解决 –可恢复性•在产品设计中就需要考虑灵活的备份机制，针对单用户，用户群的部分数据回退机制，单系统的复原机制等等50腾讯游戏产品运营事故案例介绍课件幻想产品后续幻想产品后续•幻想游戏在经历了这次波折之后，游戏衰退速度明显加快，到次年3月份人气已经跌破10万，游戏产品生命周期临近。

这之后，幻想还经历了一次727宠物捕捉系统事故，幻想产品正式进入快速衰退期；•项目组从07年初开始探索免费网游运营模式，制定了幻想“突围”研发计划，利用幻想已有资源在3个月内制作出一款采用免费运营模式的《自由幻想》产品迅速推出；•《自由幻想》取得了不错的运营成绩，将流失的幻想用户挽留了回来，到08年，自由幻想重回10万，并创造收入新高4月3日，自由幻想承载了团队的希望，将正式上市公测，以期重续幻想的昔日辉煌51腾讯游戏产品运营事故案例介绍课件幻想产品幻想产品•MMOG产品有其独特的复杂性，在各种复杂因素的作用下，有其无法避免的风险，一点点人为因素就有可能立即造成重大损失，所以只能让每位运营人员都要学会如履薄冰，随时提高警惕；•我们在技术上也不断的加强防范，现在的游戏安全机制已经比一年前要更加完善，各种安全开关，自动监测机制，防复制设置，更快的客服反馈制度，玩家的预警组织等等能帮助我们更早更快的发现问题，分析问题，更及时正确的作出处理决定•但是，只要网游运营一天，事故风险就会如影随行，总会有各种BUG逃过我们的重重拦截，随时等待爆发52腾讯游戏产品运营事故案例介绍课件回顾我们的经验回顾我们的经验•在管理层面上在管理层面上–合理的运营组织架构，确保产品责任/项目责任/设计责任/资源责任/日常工作责任等等都明确到人，工作流程清晰条理，关键环节多人审批，多人监督；–建立完善的事故预警/升级/处理机制，事先准备各级事故处理预案，指定各级事故召集人，建立事故召集处理会议制度；–加强用户管理，增加玩家层面预警能力，建立多种用户组织，加强舆论控制和引导能力，加强危机公关应对能力；–重视测试环节，保证充分的测试时间和规范的测试过程，测试用例需要各方面共同制定，高风险项目一定经过充分的外部测试。

53腾讯游戏产品运营事故案例介绍课件回顾我们的经验回顾我们的经验•在技术层面上在技术层面上–在产品设计之初就应该考虑产品的“可运营性”，预知未来可能的运营需求和风险，在架构设计上留有足够考虑；–完善灵活的备份机制，各种记录完善细致，各种统计和还原类工具齐备；–对于重大风险事故需要定期演练，各种处理手段机制制定详细的技术预案，做到有备无患•在策划层面上在策划层面上–在任何产品设计和活动设计的评审环节加入运营风险评估部分，重视安全性设计，共同回避可能发生的问题54腾讯游戏产品运营事故案例介绍课件自由幻想自由幻想““绛紫宝箱绛紫宝箱””事故事故•1月10日早上8点，《自由幻想》停机更新版本；•10点多开机后，玩家研究院玩家首先报告，发现连续开启付费道具“绛紫宝箱”会产生复制道具用户管理客服初步验证后迅速通知了产品负责人；•产品方面评估后认为应按重大事故处理，通知运维组立即关闭所有服务器，同时召集研发，测试，客服等方面参加的事故分析处理会议，组成事故处理小组；•10点30分左右，所有自由幻想服务器关闭，运维组按照预案开始使用工具扫描全区产生的复制道具，并统计影响用户总量，产品组发布紧急停机公告，客服组通知一线相应口径话术，同时通知所有玩家组织，准备舆论引导方案；55腾讯游戏产品运营事故案例介绍课件•11点，程序方面BUG原因查明，运维第一次扫描结束，复制道具用户被定位，根据实际情况，事故处理会议决定采用不回档，采用删除复制道具的方案来进行处理；•12点，程序BUG修复完毕，启动紧急发布流程，测试组开始进行发布前测试•1点，运维全服扫描完毕，所有复制道具及相关账号被定位；•2点，事故处理会议确定最终处理方案，开始删除复制道具，还原对等交易；•3点，新的脚本测试完毕并完成更新发布；•4点，所有用户数据处理完毕，产品发布开服公告；•4点半，所有服务器恢复运营，产品组开始协助处理后续疑难投诉，外部玩家舆论持续监测。

56腾讯游戏产品运营事故案例介绍课件自由幻想自由幻想“绛紫宝箱绛紫宝箱”事故事故57腾讯游戏产品运营事故案例介绍课件•充分信息监测收集，事故分级，指定召集协调人和事故处理会议的机制保证了我们能在最短时间和获知问题，并有效分析，快速应对各种意外事故，随着经验累积，事故的处理速度和方法也能得以不断改善客客服服用用户户运运营营测测试试研研发发运运维维运营事故处理会议运营事故处理会议停机/扫描通报分析/测试分析/解决召集解决解决方案方案事故召集人事故召集人信信息息源源58腾讯游戏产品运营事故案例介绍课件 Mini Game Mini Game平台平台• Mini Game Mini Game平台（平台（游戏平台）是互娱最大的休闲游戏游戏平台）是互娱最大的休闲游戏平台，最高已经接近平台，最高已经接近450450万，注册用户万，注册用户3 3亿，日活跃用亿，日活跃用户数近户数近23002300万，包含万，包含6060多款休闲游戏；多款休闲游戏；• 游戏平台是以休闲游戏为主，无用户交易系统，道具游戏平台是以休闲游戏为主，无用户交易系统，道具物品不流通，因此运营事故的发生风险与大型物品不流通，因此运营事故的发生风险与大型MMOGMMOG相比大相比大大降低；大降低；•游戏平台的运营事故主要与提供海量用户服务产生的压游戏平台的运营事故主要与提供海量用户服务产生的压力相关。

力相关59腾讯游戏产品运营事故案例介绍课件DirDir雪崩事件记录：雪崩事件记录：•1月14日中午13：40分，接到dir coredump告警登陆发现大部分dir server已经coredump简单查看了下发现问题很难定位同时从运营同事侧了解到中午12点左右增加了目录树的节点，于是让运营同事回退配置文件，然后拉起所有core掉的dir服务器 •大约在2：30左右所有服务器被拉起，由于大量用户不断登陆，使得网卡流量到达极限查看dir日志发现工作是正常的但是用户就是无法登陆 •3：00查看dir的负载正常，每分钟处理7万个以上登陆请求再查看前端tcpsvrd接入进程的日志，发现下行数据使用的共享内存队列已满，而下行数据在最高的时候单台机器每分钟有2G左右同时也出现大量的EAGAIN错误在4：00的时候确认是网卡流量过高导致用户无法获得登陆所需的两个response同时确认由于dir的处理能力远大于网卡的处理能力，因此有必要限制上行用户的请求数60腾讯游戏产品运营事故案例介绍课件  DirDir雪崩事件记录：雪崩事件记录：•另一方面，启动紧急预案，投入三台备用dir服务器进行服务，同时紧急更改域名指向。

由于域名指向生效需要1天时间，因此三台机器的访问量不是很高研发方面紧急修改限制流量的版本 •5：00第一个限制流量的版本放出去，限制上行共享内存当中存留的未被处理的数据包量，发现由于dir处理速度很快，很难限制住用户请求数同时增加的日志表明，每分钟有4万个请求包，有三万个响应回包失败 •6：30开始测试第二个限制流量版本，通过直接限制请求总数的上限来控制下行流量版本放出去之后效果非常明显，下行网卡流量立刻下降，发送失败的数量也迅速减小同时也能够正常登陆大厅 •经过观察后，于8点完成全网更新，并解决故障61腾讯游戏产品运营事故案例介绍课件 Mini Game Mini Game平台平台•事故总结事故总结–增加Dir服务器的请求过载保护功能，更换千兆网卡服务器–优化发布流程，严格执行灰度放量发布–加强数据监控手段，缩短故障定位时间–重新评估dir的容量，准备此类问题的应急预案，增加紧急扩容机器，提高容灾能力–更换能满足短时间内切换IP指向的新域名 –调整架构，使得dir不再成为业务关键点62腾讯游戏产品运营事故案例介绍课件腾讯游戏发布轨迹腾讯游戏发布轨迹20042004年年20052005年年20062006年年20032003年年20072007年年20082008年年2003-082003-08游戏大厅发布游戏大厅发布凯旋公测凯旋公测20092009年年2004-122004-12堂公测堂公测2005-062005-06宠物发布宠物发布2005-102005-10幻想公测幻想公测2006-062006-06音速公测音速公测2007-062007-06三国公测三国公测2007-082007-08华夏发布华夏发布2008-012008-01飞车公测飞车公测2008-042008-04自由幻想发布自由幻想发布2008-042008-04穿越火线发布穿越火线发布2008-062008-06地下城与勇士发布地下城与勇士发布2008-072008-07飞行岛公测飞行岛公测2008-092008-09寻仙发布寻仙发布2008-092008-09宠物宠物2 2发布发布2009-012009-01AVAAVA发布发布2008-052008-05炫舞公测炫舞公测63腾讯游戏产品运营事故案例介绍课件•从从《《凯旋凯旋》》到到《《自由幻想自由幻想》》，从事故案例也可以看到腾，从事故案例也可以看到腾讯的互娱系统从当年的一款运营产品到现在的运营研发十讯的互娱系统从当年的一款运营产品到现在的运营研发十几款产品的过程中，我们也在一路成长，学习怎样成为一几款产品的过程中，我们也在一路成长，学习怎样成为一家国内甚至世界一流的游戏研发运营商。

家国内甚至世界一流的游戏研发运营商•距离距离EAEA，暴雪这样的国际顶尖的游戏企业，我们还有很长，暴雪这样的国际顶尖的游戏企业，我们还有很长的路要走，但是我们会认准目标不言放弃的路要走，但是我们会认准目标不言放弃64腾讯游戏产品运营事故案例介绍课件 - End - - End -谢谢大家谢谢大家65腾讯游戏产品运营事故案例介绍课件。