腾 讯 大 讲 堂

1. 腾 讯 大 讲 堂 第五十一期 研发管理部 大讲堂主页：http://km.oa.com/class 与讲师互动：http://km.oa.com/group/class

2. 游戏产品运营事故案例介绍 Walker

3. 讲述事故背后的故事，从案例了解网游运营

4. 目录 • 凯旋游戏产品 • Mini Boss活动事故 • 白装备事故 • QQ堂游戏产品 • 欢乐幸运星活动事故 • QQ幻想游戏产品 • 售卖系统道具复制游戏事故 • “绛紫宝箱”道具复制事故 • QQ Mini Game平台 • Dir Server雪崩

5. 2003-08 QQ游戏大厅发布 凯旋公测 腾讯游戏发布轨迹 从2003年到2008年，腾讯游戏的发展已经走过了5年多的历程。 2003年 2008年 2009年 2004年 2005年 2006年 2007年

6. 《凯旋》产品 《凯旋》是腾讯代理IMAZIC的一款3D大型网游，也是我们试水网络游戏市场的第一款产品。为此腾讯在上海专门组建了网络游戏事业部来负责该产品的运营工作，该游戏从2003年8月1日正式公测上市。

7. 《凯旋》产品 《凯旋》在当时是一款非常高端的产品，3D画面效果优秀出色，采用了无缝地图技术，真实装备Avatar，任务链设计，宠物系统等等，设计理念新颖，市场影响力大。

8. 网游运营事业部组织图 网络游戏事业部的组织架构图

9. 《凯旋》公测之后，为了迎接十一长假，策划希望策划一些线上活动，继续冲高在线，Mini Boss活动就此出炉。

10. 《凯旋》产品 • Mini Boss事故记录 • 由策划部提出希望在国庆节期间开展一个在线活动，营造游戏中的节日气氛，并提高节日期间在线； • 活动策划案需求转交韩方后，韩方回复他们正好新开发了一个类似的活动包，可供我们使用； • 这个活动包的内容主要是将游戏内地底深处的超级BOSS缩小后随机放到地面刷出，供普通玩家挑战，并且还有机会获得珍贵宝石； • 策划部门同意采用该活动包，作为国庆期间节日活动的一部份，并相应准备了相关的网站宣传内容； • 活动包由韩方提供给海外部，同时策划部之前提供了测试需求给海外部，海外部测试后认为符合需求，因此交给了技术部，然后技术部安排了自动更新的脚本，在10月1日凌晨自动启动。

11. Mini Boss事故记录 • 10.1期间，部门放假，活动自动执行，结果因为一些细节设计问题和宝石产出几率过高，导致活动期间珍贵宝石大量产出，玩家采用自动化方法大量获取珍贵宝石后对整个经济系统产生巨大影响； • 流通道具的大量产生导致了一系列问题，游戏体验被迅速透支，流失玩家数量惊人； • 假期结束后，整个游戏在线由4W多下跌到不足2W，游戏内经济崩溃，物价异常变动，大量忠实玩家离开，流失玩家数量巨大。因此事故时间太久，无法回档，官方已经没有任何办法消除事故影响； • 经此打击之后，凯旋的游戏在线一直未能得到恢复，之后再未突破过4W水平，在线持续下跌至目前水平。

12. 《凯旋》产品 韩方IMAZIC

13. 《凯旋》产品 • 在Mini Boss事件中，错误究竟发生在哪里呢？ • 似乎每个部门都有错，但是每个部门却又没有能力去发现和制止错误，似乎大家一起努力的结果就是朝错误的方向越跑越远； • 在错误产生之后，却很难找到责任人，甚至没有一个直接责任人出现。事故之后，团队没有收获任何经验教训，只能继续这样运转。

14. 《凯旋》产品 • 白装备事件记录 • 2004年1月15日凯旋发布一个新的版本的时候出现的一个BUG，导致部分玩家背包中的带属性的绿色蓝色等高级装备变成没有属性的白色装备，同时还出现部分玩家角色消失问题； • 在我方测试时，未及时发现此问题。更新后，开始陆续接到玩家投诉，技术部检查后确认是游戏BUG造成，于是通过商务部向韩方提出紧急修复的需求，同时开始逐个手工处理玩家投诉； • 当天下午的时候，玩家投诉量达到400单，技术部门开始通宵处理，到次日凌晨投诉量已经上升到1500单，手工处理已经无法承担。这时候因为北京的展会缘故，相关领导均不在公司，一直无人拍板最终处理方案，只能继续手工处理。

15. 白装备事件记录 • 等到下午，韩方发来一个统计工具，用于统计受损的账户数量； • 经过统计后发现受影响账号竟然在10万以上，于是又经过漫长讨论，最终决定回档。此时距离发现问题已经过了30多个小时，需回档时间近2天，受影响活跃玩家几十万人； • 回档过程中，再次发现数据异常，无法启动服务器，游戏停机时间一再延长，在18个多小时后才恢复了服务； • 经此打击，更多的活跃玩家离开了凯旋，游戏在线下跌到1万余。

16. 对于回档游戏数据，团队既没有成熟的运营处理预案，也没有进行过任何演练，迟钝的反应和生硬的处理手法显现出了运营团队的稚嫩。对于回档游戏数据，团队既没有成熟的运营处理预案，也没有进行过任何演练，迟钝的反应和生硬的处理手法显现出了运营团队的稚嫩。

17. 《凯旋》产品 • 在白装备事件中，我们得到了哪些教训呢？ • 对于网游产品，测试部门是一定需要专业重点建设的； • 对于紧急事故必须有完备的处理预案和责任人制度； • 对于重大的备份恢复操作，平时要经常演习熟悉； • 对于风险评估和具体应对，我们还需要更多的经验； • 对于用户管理和运营维护方面的经验缺乏，舆论导向控制不力，用户反馈收集缓慢，信息不全，用户体验很差； • 最重要的是，我们需要一个符合网游产品运营特点的团队管理结构。

18. 只有合理的将一个整体任务的结果责任赋予某人，才能让其拥有与这个责任对等的权力来制约和控制整个事情。只有合理的将一个整体任务的结果责任赋予某人，才能让其拥有与这个责任对等的权力来制约和控制整个事情。 • 经验必须是沉积在每个人身上，而不是整个团队，富有经验的的产品经理是一个团队的重要财富。

19. 现在的运营团队工作模型 用户 运维 市场 客服 渠道 …… 网站 研发 一个运营团队的三层工作模型

20. 现在的运营团队工作模型 公关 渠道 运维 客服 法务 信息 网站 市场 广告 商务 品牌 项目组 运营团队 战略 策划 安全 外包 程序 美术 其他内部团队 用户 涉及的资源关系

21. 现在的运营团队内部工作模型 资源与接口 运营项目A 运营项目B 运营项目C

22. 《凯旋》产品后续 • 《凯旋》之后，公司在很长时间一直没有再代理海外的游戏产品； • QQ Game的崛起让公司决策方面决定加强自研网游产品的投入，上海团队主要力量被拆散，大部分骨干人员流失，腾讯在大型网游市场的第一步就摔了一个不小的跟头； • 自研QQ Game产品获得成功后，公司决定继续研发更加高端的游戏产品，第一款ACG产品《QQ堂》2004年中正式立项了。

23. 2003-08 QQ游戏大厅发布 凯旋公测 腾讯游戏发布轨迹 2004-12 QQ堂公测 2003年 2008年 2009年 2004年 2005年 2006年 2007年

24. 《QQ堂》产品 《QQ堂》从2004年6月开始开发，12月30日正式公测上市，2005年7月1日发布正式版本，游戏最高在线一度达到22万最高同时在线，注册用户数多达数千万玩家。

25. 《QQ堂》产品 • QQ堂产品第一次建立了产品运营团队，虽然才3个产品人员，但是已经开始建立项目和产品的负责制。同时，部门也逐渐开始尝试将技术主导型的工作模式转变产品运营主导型的工作模式； • QQ堂如果诞生在别的公司，注定将成为一个没有任何市场反应就会迅速失败的产品，但是我们的平台给这个产品源源不断的送去了用户，让产品研发运营团队得以生存，得以学习和提高。在运营了7个月后，产品运营团队开始逐渐找到了感觉，终于开始学会如何掌控这个产品，7月的正式版本之后，QQ堂慢慢发力，在线开始节节上升； • 产品团队信心十足，甚至开始变得有点急功近利了

26. 《QQ堂》产品 • QQ堂“欢乐幸运星”抽奖 • 2005年8~9月间，因为互娱BU另外一款重量级产品《QQ幻想》的跳票，互娱系统的月度考核指标遇到了极大的挑战，领导层号召各个产品设法拉高收入，严守KPI底线； • QQ堂产品当时在线状况发展良好，如何转换成为收入的问题于是变得更加重要，大家开始群策群力的贡献点子，力求帮系统更多承担一些收入； • 在几次风暴会议后，多个营销性质项目开始启动。其中，有一个博彩类的项目非常被大家看好，这个项目叫做QQ堂“欢乐幸运星”抽奖活动。

27. 《QQ堂》产品 • 2005年9月29日晚8点，在经过研发测试等同事加班加点的紧张开发之后， “欢乐幸运星”活动如期开发完毕，并按照版本计划， 更新到了外网环境； • 8点半钟，运营团队接客服报告，声称有两名玩家已经中到一千万游戏币的大奖。运营团队按照紧急预案召集所有相关人员赶回公司处理； • 9点多，客服方面再次汇报，已经确认BUG存在，有大量玩家重复中奖。运营负责人要求立即关闭道具售卖系统； • 10点前，运维同事关闭了道具售卖服务器，产品，研发，运维，测试等各线人员赶到，马上召开了事故分析处理会议，并通知平台线方面同事协助； • 11点，事故原因查明，得到事故初步损失统计，参与得利玩家第一批名单也已经获得，运营团队开始要求各方面协助拦截非法游戏币。

28. 《QQ堂》产品

29. 事故过程原因 • 在抽奖活动的设置中，集齐一套道具(7块多Q币)，可能中奖1000万游戏币(相当于1000Q币)，一般情况概率应该是万分之零点六，但是策划文档几经修改后中奖表格已经出现了很多错误。而策划评审，运营评审，程序实现各个环节中居然都没有发现中奖列表的机率加起来已经不是100%了； • 程序实现后提交测试组测试两轮，在测试中因为没有使用大量QB来进行真实的模拟测试，所以居然没有发现概率方面存在异常； • 种种错误累加起来使26%概率的特等奖终于出现在了外网环境中； • 从当晚8点多发布活动到10点之前关闭这个活动,仅一个多小时共产生游戏币21个亿，有700多名用户参与了刷取游戏币； • 由于钱的数量巨大，玩家四处转移游戏币。而冻结账户方面没有预案，虽然紧急处理及时，但冻结不彻底，扣款程序又出问题等, 最终损失还是构成了一级事故； • 事故发生后对员工和相关领导都受到了处罚。

30. 事后总结 • 需求文档需要更仔细check，评审环节的疏漏非常严重； • 任何概率类设计都需要设置总量控制，设置多级阀门控制，不要把能广泛流通的货币或者道具直接及时的交到玩家手上，不要奖励； • 紧急预案不够完善，只考虑到产品范围内的各种处理方案，没有考虑如果在部门或者公司级平台上出现问题后的处理措施。 • 在处理过程中，产品人员才惊奇的发现我们原来还有游戏币银行这样的东西。 • 在要求各个方面协助冻结相关账户的时候，各系统才开始编写相关的程序进行扫描和回扣，这其中又发生新的BUG，但是多次扣款失败，使损失额度没有能得到很好的控制。

31. 《QQ堂》产品后续 • “欢乐幸运星”事件之后，互娱停止了所有涉及抽奖Q币，游戏币的活动，再不涉及任何通过平台渠道发放Q币的活动，以避免风险； • QQ堂团队也停止了这种直接通过抽奖获利的营销活动，开始继续专注于游戏内容的设计和付费挖掘； • 2006年2月份，QQ堂一系列游戏活动获得成功，同时在线达到22万高点，收入也实现了连续翻番，QQ堂道具营销方面经验让很多产品学习得益。

32. 2005-10 QQ幻想公测 2005-06 QQ宠物发布 2003-08 QQ游戏大厅发布 凯旋公测 腾讯游戏发布轨迹 2004-12 QQ堂公测 2003年 2008年 2009年 2004年 2005年 2006年 2007年

33. QQ幻想产品 《QQ幻想》是腾讯的一款战略级产品，是互娱自主研发了三年多的首款MMOG产品。这款产品也是互娱在凯旋项目失利之后，再次尝试运营的MMOG产品。该款产品2005年10月25日公测，最高同时在线用户数一度达到66万，是互娱重要的收入产品。

34. QQ幻想产品 • 《QQ幻想》产品是一款探索获取经验的产品，虽然我们投入了大量的人力和时间在这款产品上，但是也毕竟暴露出了我们的很多经验不足之处； • 虽然借助腾讯平台的强大力量，《QQ幻想》获得了公测的良好效果，但是游戏设计，运营理念方面的一些不足还是让产品在线不断下挫。在收费后，产品在线已经不足公测时的一半； • 在一年多运营过程中，这个项目也不断出现过一些不同程度的事故，在线活动的投诉率一直居高不下。

35. QQ幻想道具复制漏洞事故记录 • 2006年11月12日下午3点，客服方面报告，在游戏中出现一个开店售卖的BUG，会导致开店商人显示的物品列表和实际不符。有玩家利用此漏洞进行欺诈，导致大量用户投诉，已经构成一级突发事故，事故已经分派到三线； • 接报后，产品经理和PM（兼服务端主程）赶到公司处理。经过分析，发现是因为客户端BUG导致看到的要买的宠物和实际要买的宠物不一致，从而被玩家利用进行欺诈。产品方面分析了具体过程和投诉单据后认为该问题比较严重必须尽快解决，因此打电话通知测试组运维组，准备进行紧急更新； • 因为客户端方面人员一时联系不到，因此PM决定从服务端解决该问题。PM提出两个临时解决方案，一个是带宠物商品交易会直接失败，一个是带宠物商品交易，宠物商品会自动回到玩家背包。产品方面建议采用后者方案，比如不容易引起玩家困惑。

36. QQ幻想产品 • 下午5点，临时修改完毕，程序在内网更新，测试组进行了测试。6点，更新到外网一台服务器，经过一个小时观察感觉正常，7点半进行了全服更新，产品方面在官网和论坛发布了暂停交易公告； • 再继续观察了半小时无异常，产品方面和客服方面沟通之后，大家回家吃晚饭。 其实这时一个严重的BUG已经被引入到整个游戏世界中

37. 问题开始蔓延 • 一个游戏道具复制漏洞实际上已经被部分玩家发现，玩家在不断利用这个BUG复制道具的同时，开始通过各种途径传播这个问题：游戏内/各种论坛/QQ群 • 越来越多的用户开始利用这个BUG复制道具，而且用户开始意识到大量非法道具一定会被官方查处，因此开始设法用各种各样的方式转移复制出来的非法道具。

38. QQ幻想道具复制漏洞事故记录 • 晚上8点多，客服报告，开店售卖可能还是存在问题。程序组测试组赶回公司处理，分析后认为下午的修改，有极低概率可能导致道具复制，并且及时修改了这个问题； • 晚上9点半，程序方面回报问题已经解决完毕，按问题出现概率来看，带来影响应该不大。因此产品方面就没有将此问题升级到事故处理流程进行分析处理； • 处理问题最有价值的黄金时段就这样过去了

39. QQ幻想道具复制漏洞事故记录 • 次日上午，产品方面发现用户反馈意见很多，问题比较严重，于是要求程序组重新分析原因，要求运维组统计道具复制问题的程度。 • 测试组重现BUG后发现还有更简单的重现办法，复制门槛很低。运维统计的初步结果也表现涉及复制玩家多达千名，于是召集事故处理会议进行讨论； • 事故处理会议决定先对嫌疑最大的963个账号进行查封处理，以防止复制道具进一步流传，同时开始进行扫描分析； • 因为事故发生已经过去10多个小时，复制物品游戏内流向已经非常复杂，但是最近的数据备份时间却是在凌晨四点，在事故发生之后，再近一次的备份时间是前天的凌晨四点。运营方面陷入两难境地，无论是否回档都面临重大损失。

40. QQ幻想道具复制漏洞事故记录 • 事故处理小组无法迅速做出回档决定，于是一方面向BU层面报告，一方面决定采用保守方案，扫描全服务器数据，以查找并冻结复制装备； • 到中午时间，数千个拥有复制装备的账号已经被冻结，但是游戏内仍然有大量复制道具仍然还在流通，整个游戏的物价受到剧烈影响，经济系统陷入混乱之中； • 为了稳定玩家情绪，运营团队通过官网发布公告，道歉并宣称不会回档处理，官方有能力收回非法装备，希望大家给与支持； • 到下午时间，扫描数据的工作已很难取得成效，大量无意购买复制装备被封号的玩家也开始激烈投诉。各渠道的一线客服压力剧增，大量人力被调派来协助处理，数以千计的投诉单据给产品方面增加了巨大压力； • 在这样巨大的压力下，运营组决定先停止服务器，然后再决定具体处理方案。

41. 11月13日幻想玩家在游戏内各大城市聚集，示威游行，强烈要求官方回档。11月13日幻想玩家在游戏内各大城市聚集，示威游行，强烈要求官方回档。

42. QQ幻想道具复制漏洞事故记录 • 一边是运营方已经做出的不回档保证、超越48小时的回档带来的损失、回档全部57组服务大区数据的难度和风险、回档后会产生的各种用户的海量投诉； • 另一边是玩家越来越激烈的抗议情绪、游戏内混乱的经济系统、接近崩溃的物价和无数根本就无法处理的投诉； • 系统和部门领导都参加了第二轮的事故处理讨论会议，会议到晚上1点钟做出决定，最终决定不惜一切损失和风险进行回档； • 接着运维组开始连夜准备回档方案，程序组开始制作各种工具，产品组开始准备相关公告和补偿方案； • 那天深夜，回档的公告在经过了无数人的反复的，斟字酌句的修改后，最后终于在向玩家承诺公布处理方案时限的最后半小时放到了官方网站上； • 早晨8点，回档成功，服务器分批开始重新开放。

43. QQ幻想产品

44. QQ幻想道具复制漏洞事故记录 • 回档公告告诉玩家： • 整个QQ幻想世界全部57组服务器将在此次停机维护结束之后恢复到11月12日凌晨4：00左右的状态，所有玩家的游戏数据也将全部回档到同一时间，所有玩家都需要回档48小时； • 我们需要补偿玩家大量的经验值，道具，金币，宠物，游戏点卡，玩家寄售卡等等； • 我们赠送给玩家两天免费游戏，两天双倍经验双倍掉率等等； • 对于用户的一切概率事件，我们均无法复原。 • 之后数千单的各种投诉还困扰了项目组将近一个月的时间，此次事故流失的玩家难以估量，直接经济损失数百万计。在幻想游戏本来进入衰退期之前，此次事故无疑是起到了加速产品老化的效果。

45. 在线损失

46. 收入损失

47. 舆论危机 • 南方都市报 11月16日 刊登题为“腾讯付费游戏停摆 玩家讨伐如潮”的负面报道，其后被很多媒体竞相转载。

48. 工作影响 • 事故善后历经2周，打乱原定的资料片开发计划； • 程序、策划、测试、运维、客服，全体团队成员都超负荷运转； • 客服一线从其他各个产品抽调人力组织力量突击消灭海量的投诉单据，一个多月后所有积单才基本被清理完毕； • 事后，此次事故被确定为一级重大运营事故，相关责任人都受到了处罚。

49. QQ幻想产品 • 事故总结 • 对于道具复制类型问题不够敏感，游戏内缺乏自动监测报警机制，导致事故之初没有得到足够重视； • 事故分析速度较慢，对于道具复制问题需要进行长达数小时的全库扫描才能得到结论，过慢的分析能力影响了对事故的定性和处理决策速度； • 游戏内严重缺乏防止物品复制的机制，缺乏各种有效的安全开关，缺乏各种不同的运行模式，使运营决策上处处为难； • 游戏数据的备份回退机制不够灵活，无法实现根据账单回滚，游戏数据备份周期过长，回档过程缺乏演练，很多必备工具缺乏； • 游戏测试机制不够完善，紧急发布流程存在很多隐患。

50. 事故总结 • 需要在游戏产品设计之初就考虑到未来的可运营性 • 可监控性 • 单纯通过用户反馈来发现问题并不足够迅速，还是要系统本身对于各种异常现象有自动监控和报警的机制，比如关键道具的产生量，异常交易量等等 • 可管理性 • 在产品开发设计中需要加入设置可由产品运营人员进行配置操作的开关量，如允许/禁止某类物品买卖的开关。在游戏中出现某些问题时，可以直接由运营人员通过配置操作来解决，而不需通过修改程序来解决。 • 可恢复性 • 在产品设计中就需要考虑灵活的备份机制，针对单用户，用户群的部分数据回退机制，单系统的复原机制等等