腾 讯 大 讲 堂

第五十一期

研发管理部

大讲堂主页： http://km.oa.com/class与讲师互动： http://km.oa.com/group/class

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

目录

• 凯旋游戏产品–Mini Boss 活动事故

–白装备事故

• QQ 堂游戏产品–欢乐幸运星活动事故

• QQ 幻想游戏产品–售卖系统道具复制游戏事故

–“绛紫宝箱”道具复制事故

• QQ Mini Game 平台–Dir Server 雪崩

腾讯游戏发布轨迹

2004 年 2005 年 2006 年2003 年 2007 年 2008 年 2009 年

从 2003 年到 2008 年，腾讯游戏的发展已经走过了 5 年多的历程。

2003-08QQ 游戏大厅发布

凯旋公测

《凯旋》产品

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

《凯旋》产品

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

网游运营事业部组织图

部门总经理

市场部 策划部 客服部 技术部 海外部 渠道部

市场策划组 网站设计组 翻译 测试 策略

网络游戏事业部的组织架构图

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

《凯旋》产品

• Mini Boss 事故记录–由策划部提出希望在国庆节期间开展一个在线活动，营造游戏中的节日

气氛，并提高节日期间在线；

–活动策划案需求转交韩方后，韩方回复他们正好新开发了一个类似的活动包，可供我们使用；

–这个活动包的内容主要是将游戏内地底深处的超级 BOSS缩小后随机放到地面刷出，供普通玩家挑战，并且还有机会获得珍贵宝石；

–策划部门同意采用该活动包，作为国庆期间节日活动的一部份，并相应准备了相关的网站宣传内容；

–活动包由韩方提供给海外部，同时策划部之前提供了测试需求给海外部，海外部测试后认为符合需求，因此交给了技术部，然后技术部安排了自动更新的脚本，在 10月 1日凌晨自动启动。

• Mini Boss 事故记录

–10.1 期间，部门放假，活动自动执行，结果因为一些细节设计问题和宝石产出几率过高，导致活动期间珍贵宝石大量产出，玩家采用自动化方法大量获取珍贵宝石后对整个经济系统产生巨大影响；

–流通道具的大量产生导致了一系列问题，游戏体验被迅速透支，流失玩家数量惊人；

–假期结束后，整个游戏在线由4W多下跌到不足 2W，游戏内经济崩溃，物价异常变动，大量忠实玩家离开，流失玩家数量巨大。因此事故时间太久，无法回档，官方已经没有任何办法消除事故影响；

–经此打击之后，凯旋的游戏在线一直未能得到恢复，之后再未突破过 4W水平，在线持续下跌至目前水平。

《凯旋》产品

部门总经理

市场部 策划部 客服部 技术部 海外部

市场策划组 网站设计组 翻译 测试 策略

韩方 IMAZIC

《凯旋》产品

• 在 Mini Boss事件中，错误究竟发生在哪里呢？

• 似乎每个部门都有错，但是每个部门却又没有能力去发现和制止错误，似乎大家一起努力的结果就是朝错误的方向越跑越远；

• 在错误产生之后，却很难找到责任人，甚至没有一个直接责任人出现。事故之后，团队没有收获任何经验教训，只能继续这样运转。

《凯旋》产品

• 白装备事件记录–2004 年 1月 15日凯旋发布一个新的版本的时候出现的一个 BUG ，导致部分玩家背包中的带属性的绿色蓝色等高级装备变成没有属性的白色装备，同时还出现部分玩家角色消失问题；

–在我方测试时，未及时发现此问题。更新后，开始陆续接到玩家投诉，技术部检查后确认是游戏 BUG 造成，于是通过商务部向韩方提出紧急修复的需求，同时开始逐个手工处理玩家投诉；

–当天下午的时候，玩家投诉量达到400单，技术部门开始通宵处理，到次日凌晨投诉量已经上升到1500单，手工处理已经无法承担。这时候因为北京的展会缘故，相关领导均不在公司，一直无人拍板最终处理方案，只能继续手工处理。

• 白装备事件记录

–等到下午，韩方发来一个统计工具，用于统计受损的账户数量；

–经过统计后发现受影响账号竟然在10万以上，于是又经过漫长讨论，最终决定回档。此时距离发现问题已经过了 30多个小时，需回档时间近 2天，受影响活跃玩家几十万人；

–回档过程中，再次发现数据异常，无法启动服务器，游戏停机时间一再延长，在 18个多小时后才恢复了服务；

–经此打击，更多的活跃玩家离开了凯旋，游戏在线下跌到 1万余。

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

《凯旋》产品

• 在白装备事件中，我们得到了哪些教训呢？

• 对于网游产品，测试部门是一定需要专业重点建设的；

• 对于紧急事故必须有完备的处理预案和责任人制度；

• 对于重大的备份恢复操作，平时要经常演习熟悉；

• 对于风险评估和具体应对，我们还需要更多的经验；

• 对于用户管理和运营维护方面的经验缺乏，舆论导向控制不力，用户反馈收集缓慢，信息不全，用户体验很差；

• 最重要的是，我们需要一个符合网游产品运营特点的团队管理结构。

• 只有合理的将一个整体任务的结果责任赋予某人，才能让其拥有与这个责任对等的权力来制约和控制整个事情。

• 经验必须是沉积在每个人身上，而不是整个团队，富有经验的的产品经理是一个团队的重要财富。

现在的运营团队工作模型• 一个运营团队的三层工作模型

客服

市场

运维

渠道

网站

研发

用户

……

现在的运营团队工作模型• 涉及的资源关系

策划

客服

运维

市场

网站

渠道

信息

商务

品牌

用户

外包

程序

美术

公关

法务

广告

战略

安全

其他内部团队

运营团队运营团队项目组

现在的运营团队内部工作模型

运营项目 A

运营项目 B

运营项目 C

《凯旋》产品后续

• 《凯旋》之后，公司在很长时间一直没有再代理海外的游戏产品；

• QQ Game的崛起让公司决策方面决定加强自研网游产品的投入，上海团队主要力量被拆散，大部分骨干人员流失，腾讯在大型网游市场的第一步就摔了一个不小的跟头；

• 自研QQ Game 产品获得成功后，公司决定继续研发更加高端的游戏产品，第一款 ACG产品《 QQ堂》 2004 年中正式立项了。

腾讯游戏发布轨迹

2004 年 2005 年 2006 年2003 年 2007 年 2008 年

2003-08QQ 游戏大厅发布

凯旋公测

2009 年

2004-12QQ 堂公测

《 QQ 堂》产品

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

《 QQ 堂》产品

• QQ 堂产品第一次建立了产品运营团队，虽然才 3 个产品人员，但是已经开始建立项目和产品的负责制。同时，部门也逐渐开始尝试将技术主导型的工作模式转变产品运营主导型的工作模式；

• QQ堂如果诞生在别的公司，注定将成为一个没有任何市场反应就会迅速失败的产品，但是我们的平台给这个产品源源不断的送去了用户，让产品研发运营团队得以生存，得以学习和提高。在运营了 7个月后，产品运营团队开始逐渐找到了感觉，终于开始学会如何掌控这个产品， 7月的正式版本之后，QQ堂慢慢发力，在线开始节节上升；

• 产品团队信心十足，甚至开始变得有点急功近利了

《 QQ 堂》产品

• QQ 堂“欢乐幸运星”抽奖–2005 年 8~9 月间，因为互娱 BU另外一款重量级产品《QQ幻想》

的跳票，互娱系统的月度考核指标遇到了极大的挑战，领导层号召各个产品设法拉高收入，严守 KPI底线；

–QQ堂产品当时在线状况发展良好，如何转换成为收入的问题于是变得更加重要，大家开始群策群力的贡献点子，力求帮系统更多承担一些收入；

–在几次风暴会议后，多个营销性质项目开始启动。其中，有一个博彩类的项目非常被大家看好，这个项目叫做 QQ 堂“欢乐幸运星”抽奖活动。

《 QQ 堂》产品

– 2005 年 9 月 29 日晚 8 点，在经过研发测试等同事加班加点的紧张开发之后， “欢乐幸运星”活动如期开发完毕，并按照版本计划， 更新到了外网环境；

– 8 点半钟，运营团队接客服报告，声称有两名玩家已经中到一千万游戏币的大奖。运营团队按照紧急预案召集所有相关人员赶回公司处理；

– 9 点多，客服方面再次汇报，已经确认 BUG 存在，有大量玩家重复中奖。运营负责人要求立即关闭道具售卖系统；

– 10 点前，运维同事关闭了道具售卖服务器，产品，研发，运维，测试等各线人员赶到，马上召开了事故分析处理会议，并通知平台线方面同事协助；

– 11 点，事故原因查明，得到事故初步损失统计，参与得利玩家第一批名单也已经获得，运营团队开始要求各方面协助拦截非法游戏币。

《 QQ 堂》产品

• 事故过程原因

– 在抽奖活动的设置中，集齐一套道具 (7 块多 Q 币 ) ，可能中奖 1000 万游戏币 ( 相当于 1000Q 币 ) ，一般情况概率应该是万分之零点六，但是策划文档几经修改后中奖表格已经出现了很多错误。而策划评审，运营评审，程序实现各个环节中居然都没有发现中奖列表的机率加起来已经不是 100% 了；

– 程序实现后提交测试组测试两轮，在测试中因为没有使用大量 QB 来进行真实的模拟测试，所以居然没有发现概率方面存在异常；

– 种种错误累加起来使 26% 概率的特等奖终于出现在了外网环境中；

– 从当晚 8 点多发布活动到 10 点之前关闭这个活动 , 仅一个多小时共产生游戏币 21 个亿，有 700 多名用户参与了刷取游戏币；

– 由于钱的数量巨大，玩家四处转移游戏币。而冻结账户方面没有预案，虽然紧急处理及时，但冻结不彻底，扣款程序又出问题等 , 最终损失还是构成了一级事故；

– 事故发生后对员工和相关领导都受到了处罚。

• 事后总结–需求文档需要更仔细 check ，评审环节的疏漏非常严重；

–任何概率类设计都需要设置总量控制，设置多级阀门控制，不要把能广泛流通的货币或者道具直接及时的交到玩家手上，不要奖励；

–紧急预案不够完善，只考虑到产品范围内的各种处理方案，没有考虑如果在部门或者公司级平台上出现问题后的处理措施。

• 在处理过程中，产品人员才惊奇的发现我们原来还有游戏币银行这样的东西。

• 在要求各个方面协助冻结相关账户的时候，各系统才开始编写相关的程序进行扫描和回扣，这其中又发生新的 BUG ，但是多次扣款失败，使损失额度没有能得到很好的控制。

《 QQ 堂》产品后续

• “欢乐幸运星”事件之后，互娱停止了所有涉及抽奖 Q币，游戏币的活动，再不涉及任何通过平台渠道发放 Q币的活动，以避免风险；

• QQ堂团队也停止了这种直接通过抽奖获利的营销活动，开始继续专注于游戏内容的设计和付费挖掘；

• 2006年 2月份， QQ堂一系列游戏活动获得成功，同时在线达到 22万高点，收入也实现了连续翻番， QQ堂道具营销方面经验让很多产品学习得益。

腾讯游戏发布轨迹

2004 年 2005 年 2006 年2003 年 2007 年 2008 年

2003-08QQ 游戏大厅发布

凯旋公测

2009 年

2005-06QQ 宠物发布

2005-10QQ 幻想公测

2004-12QQ 堂公测

QQ 幻想产品

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

QQ 幻想产品

• 《 QQ幻想》产品是一款探索获取经验的产品，虽然我们投入了大量的人力和时间在这款产品上，但是也毕竟暴露出了我们的很多经验不足之处；

• 虽然借助腾讯平台的强大力量，《 QQ幻想》获得了公测的良好效果，但是游戏设计，运营理念方面的一些不足还是让产品在线不断下挫。在收费后，产品在线已经不足公测时的一半；

• 在一年多运营过程中，这个项目也不断出现过一些不同程度的事故，在线活动的投诉率一直居高不下。

• QQ 幻想道具复制漏洞事故记录

–2006 年 11月 12日下午 3点，客服方面报告，在游戏中出现一个开店售卖的 BUG ，会导致开店商人显示的物品列表和实际不符。有玩家利用此漏洞进行欺诈，导致大量用户投诉，已经构成一级突发事故，事故已经分派到三线；

–接报后，产品经理和 PM（兼服务端主程）赶到公司处理。经过分析，发现是因为客户端 BUG导致看到的要买的宠物和实际要买的宠物不一致，从而被玩家利用进行欺诈。产品方面分析了具体过程和投诉单据后认为该问题比较严重必须尽快解决，因此打电话通知测试组运维组，准备进行紧急更新；

–因为客户端方面人员一时联系不到，因此 PM决定从服务端解决该问题。 PM 提出两个临时解决方案，一个是带宠物商品交易会直接失败，一个是带宠物商品交易，宠物商品会自动回到玩家背包。产品方面建议采用后者方案，比如不容易引起玩家困惑。

QQ 幻想产品

–下午 5 点，临时修改完毕，程序在内网更新，测试组进行了测试。6 点，更新到外网一台服务器，经过一个小时观察感觉正常， 7 点半进行了全服更新，产品方面在官网和论坛发布了暂停交易公告；

–再继续观察了半小时无异常，产品方面和客服方面沟通之后，大家回家吃晚饭。

其实这时一个严重的 BUG 已经被引入到整个游戏世界中

问题开始蔓延

• 一个游戏道具复制漏洞实际上已经被部分玩家发现，玩家在不断利用这个 BUG复制道具的同时，开始通过各种途径传播这个问题：游戏内 /各种论坛 /QQ群

• 越来越多的用户开始利用这个 BUG复制道具，而且用户开始意识到大量非法道具一定会被官方查处，因此开始设法用各种各样的方式转移复制出来的非法道具。

• QQ 幻想道具复制漏洞事故记录

–晚上 8点多，客服报告，开店售卖可能还是存在问题。程序组测试组赶回公司处理，分析后认为下午的修改，有极低概率可能导致道具复制，并且及时修改了这个问题；

–晚上 9点半，程序方面回报问题已经解决完毕，按问题出现概率来看，带来影响应该不大。因此产品方面就没有将此问题升级到事故处理流程进行分析处理；

–处理问题最有价值的黄金时段就这样过去了

• QQ 幻想道具复制漏洞事故记录

–次日上午，产品方面发现用户反馈意见很多，问题比较严重，于是要求程序组重新分析原因，要求运维组统计道具复制问题的程度。

–测试组重现 BUG 后发现还有更简单的重现办法，复制门槛很低。运维统计的初步结果也表现涉及复制玩家多达千名，于是召集事故处理会议进行讨论；

–事故处理会议决定先对嫌疑最大的963个账号进行查封处理，以防止复制道具进一步流传，同时开始进行扫描分析；

–因为事故发生已经过去 10 多个小时，复制物品游戏内流向已经非常复杂，但是最近的数据备份时间却是在凌晨四点，在事故发生之后，再近一次的备份时间是前天的凌晨四点。运营方面陷入两难境地，无论是否回档都面临重大损失。

• QQ 幻想道具复制漏洞事故记录–事故处理小组无法迅速做出回档决定，于是一方面向 BU层面报告，一方

面决定采用保守方案，扫描全服务器数据，以查找并冻结复制装备；

–到中午时间，数千个拥有复制装备的账号已经被冻结，但是游戏内仍然有大量复制道具仍然还在流通，整个游戏的物价受到剧烈影响，经济系统陷入混乱之中；

–为了稳定玩家情绪，运营团队通过官网发布公告，道歉并宣称不会回档处理，官方有能力收回非法装备，希望大家给与支持；

–到下午时间，扫描数据的工作已很难取得成效，大量无意购买复制装备被封号的玩家也开始激烈投诉。各渠道的一线客服压力剧增，大量人力被调派来协助处理，数以千计的投诉单据给产品方面增加了巨大压力；

–在这样巨大的压力下，运营组决定先停止服务器，然后再决定具体处理方案。

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

• QQ 幻想道具复制漏洞事故记录–一边是运营方已经做出的不回档保证、超越 48小时的回档带来的损失、回档全部 57组服务大区数据的难度和风险、回档后会产生的各种用户的海量投诉；

–另一边是玩家越来越激烈的抗议情绪、游戏内混乱的经济系统、接近崩溃的物价和无数根本就无法处理的投诉；

–系统和部门领导都参加了第二轮的事故处理讨论会议，会议到晚上 1点钟做出决定，最终决定不惜一切损失和风险进行回档；

–接着运维组开始连夜准备回档方案，程序组开始制作各种工具，产品组开始准备相关公告和补偿方案；

–那天深夜，回档的公告在经过了无数人的反复的，斟字酌句的修改后，最后终于在向玩家承诺公布处理方案时限的最后半小时放到了官方网站上；

–早晨 8点，回档成功，服务器分批开始重新开放。

QQ 幻想产品

QQ 幻想道具复制漏洞事故记录• 回档公告告诉玩家：

–整个 QQ幻想世界全部 57组服务器将在此次停机维护结束之后恢复到 11月 12日凌晨 4 ： 00左右的状态，所有玩家的游戏数据也将全部回档到同一时间，所有玩家都需要回档 48小时；

–我们需要补偿玩家大量的经验值，道具，金币，宠物，游戏点卡，玩家寄售卡等等；

–我们赠送给玩家两天免费游戏，两天双倍经验双倍掉率等等；

–对于用户的一切概率事件，我们均无法复原。

• 之后数千单的各种投诉还困扰了项目组将近一个月的时间，此次事故流失的玩家难以估量，直接经济损失数百万计。在幻想游戏本来进入衰退期之前，此次事故无疑是起到了加速产品老化的效果。

在线损失

收入损失

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

舆论危机

工作影响

• 事故善后历经 2周，打乱原定的资料片开发计划；

• 程序、策划、测试、运维、客服，全体团队成员都超负荷运转；

• 客服一线从其他各个产品抽调人力组织力量突击消灭海量的投诉单据，一个多月后所有积单才基本被清理完毕；

• 事后，此次事故被确定为一级重大运营事故，相关责任人都受到了处罚。

QQ 幻想产品• 事故总结

–对于道具复制类型问题不够敏感，游戏内缺乏自动监测报警机制，导致事故之初没有得到足够重视；

–事故分析速度较慢，对于道具复制问题需要进行长达数小时的全库扫描才能得到结论，过慢的分析能力影响了对事故的定性和处理决策速度；

–游戏内严重缺乏防止物品复制的机制，缺乏各种有效的安全开关，缺乏各种不同的运行模式，使运营决策上处处为难；

–游戏数据的备份回退机制不够灵活，无法实现根据账单回滚，游戏数据备份周期过长，回档过程缺乏演练，很多必备工具缺乏；

–游戏测试机制不够完善，紧急发布流程存在很多隐患。

• 事故总结

–需要在游戏产品设计之初就考虑到未来的可运营性

–可监控性

• 单纯通过用户反馈来发现问题并不足够迅速，还是要系统本身对于各种异常现象有自动监控和报警的机制，比如关键道具的产生量，异常交易量等等

–可管理性

• 在产品开发设计中需要加入设置可由产品运营人员进行配置操作的开关量，如允许 /禁止某类物品买卖的开关。在游戏中出现某些问题时，可以直接由运营人员通过配置操作来解决，而不需通过修改程序来解决。

–可恢复性

• 在产品设计中就需要考虑灵活的备份机制，针对单用户，用户群的部分数据回退机制，单系统的复原机制等等

QQ 幻想产品后续

• QQ 幻想游戏在经历了这次波折之后，游戏衰退速度明显加快，到次年3月份在线人气已经跌破 10万，游戏产品生命周期临近。这之后， QQ幻想还经历了一次 727 宠物捕捉系统事故，幻想产品正式进入快速衰退期；

• 项目组从 07年初开始探索免费网游运营模式，制定了幻想“突围”研发计划，利用幻想已有资源在 3个月内制作出一款采用免费运营模式的《 QQ自由幻想》产品迅速推出；

• 《 QQ自由幻想》取得了不错的运营成绩，将流失的幻想用户挽留了回来，到 08年， QQ自由幻想重回 10万在线，并创造收入新高。 4月 3日， QQ自由幻想承载了团队的希望，将正式上市公测，以期重续 QQ幻想的昔日辉煌。

QQ 幻想产品

• MMOG 产品有其独特的复杂性，在各种复杂因素的作用下，有其无法避免的风险，一点点人为因素就有可能立即造成重大损失，所以只能让每位运营人员都要学会如履薄冰，随时提高警惕；

• 我们在技术上也不断的加强防范，现在的游戏安全机制已经比一年前要更加完善，各种安全开关，自动监测机制，防复制设置，更快的客服反馈制度，玩家的预警组织等等能帮助我们更早更快的发现问题，分析问题，更及时正确的作出处理决定。

• 但是，只要网游运营一天，事故风险就会如影随行，总会有各种 BUG逃过我们的重重拦截，随时等待爆发。

回顾我们的经验

• 在管理层面上–合理的运营组织架构，确保产品责任/项目责任 /设计责任 /资源责任/日常工作责任等等都明确到人，工作流程清晰条理，关键环节多人审批，多人监督；

–建立完善的事故预警 /升级 /处理机制，事先准备各级事故处理预案，指定各级事故召集人，建立事故召集处理会议制度；

–加强用户管理，增加玩家层面预警能力，建立多种用户组织，加强舆论控制和引导能力，加强危机公关应对能力；

–重视测试环节，保证充分的测试时间和规范的测试过程，测试用例需要各方面共同制定，高风险项目一定经过充分的外部测试。

回顾我们的经验

• 在技术层面上– 在产品设计之初就应该考虑产品的“可运营性”，预知未来可能

的运营需求和风险，在架构设计上留有足够考虑；

– 完善灵活的备份机制，各种记录完善细致，各种统计和还原类工具齐备；

– 对于重大风险事故需要定期演练，各种处理手段机制制定详细的技术预案，做到有备无患。

• 在策划层面上– 在任何产品设计和活动设计的评审环节加入运营风险评估部分，重视安全性设计，共同回避可能发生的问题。

自由幻想“绛紫宝箱”事故

• 1 月 10日早上8点，《 QQ自由幻想》停机更新版本；

• 10点多开机后，玩家研究院玩家首先报告，发现连续开启付费道具“绛紫宝箱”会产生复制道具。用户管理客服初步验证后迅速通知了产品负责人；

• 产品方面评估后认为应按重大事故处理，通知运维组立即关闭所有服务器，同时召集研发，测试，客服等方面参加的事故分析处理会议，组成事故处理小组；

• 10点 30分左右，所有自由幻想服务器关闭，运维组按照预案开始使用工具扫描全区产生的复制道具，并统计影响用户总量，产品组发布紧急停机公告，客服组通知一线相应口径话术，同时通知所有玩家组织，准备舆论引导方案；

• 11点，程序方面 BUG原因查明，运维第一次扫描结束，复制道具用户被定位，根据实际情况，事故处理会议决定采用不回档，采用删除复制道具的方案来进行处理；

• 12点，程序 BUG修复完毕，启动紧急发布流程，测试组开始进行发布前测试

• 1点，运维全服扫描完毕，所有复制道具及相关账号被定位；

• 2点，事故处理会议确定最终处理方案，开始删除复制道具，还原对等交易；

• 3点，新的脚本测试完毕并完成更新发布；

• 4点，所有用户数据处理完毕，产品发布开服公告；

• 4点半，所有服务器恢复运营，产品组开始协助处理后续疑难投诉，外部玩家舆论持续监测。

自由幻想“绛紫宝箱”事故

• 充分信息监测收集，事故分级，指定召集协调人和事故处理会议的机制保证了我们能在最短时间和获知问题，并有效分析，快速应对各种意外事故，随着经验累积，事故的处理速度和方法也能得以不断改善

客服

用户

运营

测试

研发

运维

运营事故处理会议

停机 /扫描通报

分析 / 测试

分析 / 解决

召集

解决方案

事故召集人

信息源

QQ Mini Game 平台

• QQ Mini Game 平台（ QQ 游戏平台）是互娱最大的休闲游戏平台，最高在线已经接近 450 万，注册用户 3亿，日活跃用户数近 2300 万，包含 60 多款休闲游戏；

• QQ 游戏平台是以休闲游戏为主，无用户交易系统，道具物品不流通，因此运营事故的发生风险与大型MMOG 相比大大降低；

• QQ 游戏平台的运营事故主要与提供海量用户服务产生的压力相关。

Dir 雪崩事件记录：

• 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 的处理能力远大于网卡的处理能力，因此有必要限制上行用户的请求数。

  Dir 雪崩事件记录：

• 另一方面，启动紧急预案，投入三台备用 dir 服务器进行服务，同时紧急更改域名指向。由于域名指向生效需要 1天时间，因此三台机器的访问量不是很高。研发方面紧急修改限制流量的版本。

 

• 5 ： 00第一个限制流量的版本放出去，限制上行共享内存当中存留的未被处理的数据包量，发现由于 dir处理速度很快，很难限制住用户请求数。同时增加的日志表明，每分钟有 4万个请求包，有三万个响应回包失败。

 

• 6 ： 30开始测试第二个限制流量版本，通过直接限制请求总数的上限来控制下行流量。版本放出去之后效果非常明显，下行网卡流量立刻下降，发送失败的数量也迅速减小。同时也能够正常登陆大厅。

 

• 经过观察后，于 8点完成全网更新，并解决故障。

QQ Mini Game 平台

• 事故总结

–增加 Dir 服务器的请求过载保护功能，更换千兆网卡服务器

–优化发布流程，严格执行灰度放量发布

–加强数据监控手段，缩短故障定位时间

–重新评估 dir 的容量，准备此类问题的应急预案，增加紧急扩容机器，提高容灾能力

–更换能满足短时间内切换 IP指向的新域名

–调整架构，使得 dir不再成为业务关键点

腾讯游戏发布轨迹

2004 年 2005 年 2006 年2003 年 2007 年 2008 年

2003-08QQ 游戏大厅发布

凯旋公测

2009 年

2004-12QQ 堂公测

2005-06QQ 宠物发布

2005-10QQ 幻想公测

2006-06QQ 音速公测

2007-06QQ 三国公测

2007-08QQ 华夏发布

2008-01QQ 飞车公

测

2008-04QQ 自由幻想发布

2008-04穿越火线发布

2008-06地下城与勇士发布

2008-07QQ 飞行岛公测

2008-09寻仙发布

2008-09QQ 宠物 2 发

布

2009-01AVA 发布

2008-05QQ 炫舞公

测

• 从《凯旋》到《 QQ 自由幻想》，从事故案例也可以看到腾讯的互娱系统从当年的一款运营产品到现在的运营研发十几款产品的过程中，我们也在一路成长，学习怎样成为一家国内甚至世界一流的游戏研发运营商。

• 距离 EA ，暴雪这样的国际顶尖的游戏企业，我们还有很长的路要走，但是我们会认准目标不言放弃。

- End -

谢谢大家