运营事故浅析—林祥

1、 林祥 2011-5-24 所有对产品产生负面影响的问题 都是运营事故。 什么是运营事故？什么是运营事故？ 用户流失，活跃、在线、充值等日常数据大幅下降。 产品口碑、公司形象被摧毁，形成舆论危机，失去玩 家信任，甚至产生对立抵触情绪。 团队超负荷运转，原订后继规划全部被打乱。 运营事故的危害？运营事故的危害？ 1、运营事故的产生 2、运营事故的发现 3、运营事故的处理 4、运营事故的防范 活动开服合服 版本升级天灾人祸 只要游戏运营一天，事故风险就会一 直存在，如同一只悬在我们头上的达摩克 利斯之剑。随时保持危机意识，谨慎对待 运营中每个环节的工作，是安全运营的前 提。 运营公告 活动执行 奖

2、励发放 开服配置 版本升级 开服关服 功能开发 道具制作 网络故障 机房故障 黑客攻击 还有么？ 有：用户导流、 媒体激活码、DB 营销 运营 研发 运维 其他 千头万绪、防不胜防，究竟该怎么办？千头万绪、防不胜防，究竟该怎么办？ 警惕：警惕：游戏内游戏内任何任何的异常现象都可能是的异常现象都可能是 一次运营事故的前兆。一次运营事故的前兆。 活跃、消耗等基础 数据异常 玩家/英雄等级异 常 高阶道具大量产生交易次数大幅增加 数据异常数据异常 QQ群聊天室论坛 CS客服电话运维监控 运营 测试 研发 运维 客服 事故事故 分析分析 处理处理 护维护维 机停机停 舆论舆论 控制控制 信息信息 通报

3、通报 测试测试 处理处理 方案方案 事故出现后，每耽误一分钟就增加一分钟的损失，增加 事故处理的复杂度。所以发生事故时，首先需要做的就 是杜绝问题的继续。 事故非常严重，且不立即处理会产生更大的破坏时，才 能停服以避免问题的扩大，这需要运营有良好的判断力 和决断力。 止损 杜绝问题的同时，必须立即给玩家一个说法，千万不要 让玩家在无休止的猜测中去恶意揣测官方。 这时可以不用告知处理方案和补偿方案等等。 安抚 充分收集信息，召集相关负责人 根据事故的表现协调各关联部门进行问题分析，找 出事故原因，完成修正。 修正 范围：影响了多少人？他们是免费还是付费玩家？ 内容：玩家损失or获取了什么？危害程

4、度？ 回档：是否可回档至问题出现之前玩家状态？能否 针对受影响玩家单独处理？ 评估 绝不损害玩家正常的既得利益 法不责众在游戏运营中也适用 全服回档永远是最后一招 处理 补偿只是马后炮，不要对此希望过高 不要扣扣索索，给就给的大方，但只给消耗，不给时 长和永久 通过多渠道了解玩家对补偿的期望值，对确定补偿方 案很有帮助 补偿 玩家都是盲从的，所以我们处理的第一目标就是那些 “刺头”，单独沟通，避免形成群体性事件。 论坛及时跟进回复，对言辞激烈、煽动性强的帖子， 警告、锁贴、沉底一条龙，不要给玩家讨论和煽动的 土壤，控制事故影响的范围。但注意的是，需要留给 玩家一个发泄的渠道，防止事故向外扩展。

5、 通过一些对官方有好感的玩家站出去帮我们说话，引 导言论向有利于官方转移。 电话是最有效的沟通方式，尤其是对大户的安抚，单 对单的交流更容易形成一种坦诚、轻松的气氛。 客服的兄弟姐妹们是处理这类问题的专家，多沟通。 舆论控制 数据波动敏感性 定期的数据对比 长期的数据跟踪记录 完整的日志记录 严格执行活动上线Readiness 规范 自动化要比手动好，配置表更可靠 配置 全面的测试用例,内外网双重测试 所有测试相关的结果必须通过邮件等方式进行确认，口头沟通不能作为最 终确认依据。 测试 描述清晰、举例到位 发布前组内要审核公告 开服各流程相关负责人和审核人签字 Sn_服务器名开服checkli

6、st.xls 开服公告、新服活动专题、版本说明、平台广告位地址、新手指导员招募、公会入驻等链接地址 Sn_服务器名相关公告专题地址.xls 所有付费功能、付费道具的购买、调整内容的使用测试 Sn_服务器名付费项目测试.xls 新服活动备案 Sn_服务器名开服活动readiness.doc GDSS配置、GMT和CS、导流后台相关确认（截图） Sn_服务器名服务器配置审核.xls 开服活动内容测试 Sn_服务器名开服活动测试备案文档.xls 确定开发内容，提交程序制作 制作 提供开发文档，编写测试用例，内网完成测试 上传至外网测试服务器，进行复测 测试 外网功能发布，跟进后继反馈 上线 对当前游

7、戏内玩家发展水平进行监控，对 超出设定之外的数据进行报警。 数据报警 建立各级事故处理预案和事故召集协调 制度 事故召集 单系统后台控制功能，自由开关游戏内某 个单项系统。 后台开关 灵活的备份机制 交易、摧毁等还原机制 备份回档 u 事故时间：2009年8月28日 u 首次事故：装备属性丢失： 10点开服后，开发的合服相关代码，在附魔装备的处理上有问题，导致合服后用户装 备的附魔属性丢失。在11点的时候，经过一定时间的搜集数据和尝试处理，最终发现 无法修正这个错误，所以对服务器进行了回档操作，并于11点半重新开启服务器。 u 再次事故：装备数据错误导致的角色复制： 由于运营活动添加的新装备类

8、型未更新到合服服务器上，导致玩家角色无法正确读取 出装备信息。当用户拥有活动发放的那几个装备时，导入角色操作在导入道具数据时 会异常退出，而角色表中的角色数据没有被删除，从而出现了玩家角色复制的情况， 只能再次回档，于18点再次开启服务器。 u 事故影响： 合服服务器H6和H7延后6小时才正式开放，对玩家的耐心和信心都有很大打击。 涉及数据错误的玩家角色合计100多个，且全部为付费玩家，这些玩家在之后的一周 内流失了30%。 合服后的收入比合服前收入还要低，完全失去了合服的效果。 u 避免惯性思维 由于之前合服一直非常顺利，没有出现过任何数据方面的问题， 因此本次合服的验收工作做的也不到位，只

9、进行了很常规的验收工 作，对近期更新的内容并没有很好的警惕性。 “犹太人的生意经上，明确地写着一条：永远都是第一次交易犹太人的生意经上，明确地写着一条：永远都是第一次交易” u 关联问题的排查 在第一次因为装备出问题后，并没有对装备相关的所有程序进行 排查，最终装备上还是出现了第二次问题。 u 寒酸的补偿 一错再错已经让玩家非常不满，而之后我们公布的补偿方案过 于寒酸，更是招致玩家强烈反弹。 u 事故时间2009年10月28日 u DNB处于不断的衰退期，收入锐减，面临KPI的压力，运营向研发申请制作了英雄转 生卡和属性重置卡，形成新的付费点，来拉升游戏后期的收益。 英雄转生卡设计过程中忽视了

10、转生后英雄属性会变垃圾的问题，且英雄转生前后没有 日志记录，这成为后继事故另一个爆发点。 u 出于盈利最大化的考虑，运营决定在重阳节通过宝箱进行新付费点的首次投放（ 而 此时上一个宝箱活动才刚刚结束1天），并在最后临上线前拍脑袋决定通过登陆送给 免费玩家也送几个宝箱，很显然，这个测试并不充分，只关注了活动奖励发放是否正 确，却没有看到登陆送之间的衔接问题。 运营活动开始后，在新付费点的强烈刺激下，收益呈现爆发式增长，沉浸在喜悦中的 运营组万万没有想到，问题即将出现。 u 10月29日凌晨1点，杯具发生了。 登陆送任务出现严重漏洞，玩家可以无限领取任务奖励，原因正是临时新增的绑定宝 箱导致，于是

11、赠送的宝箱泛滥成灾。 凌晨3点多，运营得到玩家反馈，立即通知技术，但很遗憾，手机关机了。 于是，事故处理的最佳时间段就这么过去了，随着时间的流逝，事故升级了。 u 10月29日9点 运营开始协调各关联部门进行紧急应对。 因为事故已经发生近10个小时，玩家获益已经被大量消耗和转移，根本无法进 行跟踪，而事故之前的最后一次备份则是在28日凌晨4点，距离现在已经有30个小时。 此时无论回不回档，都很难处理，对此非常纠结。 u 10月29日9点30分 经过和项目组和关联部门的讨论，考虑到转生卡等高端道具的大量产生对整个游戏破 坏性的影响，游戏体验会被迅速透支，付费用户的消费会极大的贬值，最终决定进行

12、回档处理，并立即进行停服。 u 10月29日16点 回档工作处理完毕，数据一切正常，服务器再次对外开启。 然而，这仅仅是事故处理的第一步，更棘手的问题随后出现：回档期间，用户的概 率获益如何处理？活动购买宝箱后开到极品道具、使用转生卡后获取极品英雄属性、 副本掉落极品装备等等。 由于受影响的均为游戏内的大户，运营无法承担这些用户 流失的风险，于是只能吃下这枚苦果对回档期间宝箱开启的极品道具给予补偿 u 高负荷的工作量 项目组成员承受了巨大的压力，超负荷的处理了一周才基本完成玩家补偿审核、 发放工作。 u 付费需求被严重削弱 付费玩家通过补偿获取了大量的极品道具，付费需求大幅削弱。 而转生卡的导

13、致的英雄属性变垃圾更是让事情火上浇油，由于没有转生前后的日 志记录，根本无法对转生英雄进行重置，运营不得不再次做出让步赠送属性重置 卡。经过这一系列的折腾，新增的2个付费点名存实亡，还没来得及盈利就已经被废 掉了。 u 游戏口碑荡然无存 尽管运营对玩家做出了重大的让步，给予了足够多的补偿，并对所有的付费用户进 行单独电话回访，但玩家还是不买账，不满情绪、不信任感导致了玩家在游戏内的停 止消费，再加上付费需求的不足，11月DNB的收入相比10月下降了64.19%。 再多的补偿也安慰不了玩家那颗受伤的心。再多的补偿也安慰不了玩家那颗受伤的心。 11月月DNB的收入高台跳水，之后再也没有恢复。的收入

14、高台跳水，之后再也没有恢复。 0 100000 200000 300000 400000 500000 600000 10月 11月 12月 DNBQ4月度消耗金额月度消耗金额 消耗金额 线性 (消耗金额 ) u 处理不及时 事故处理最有价值的黄金时段往往就在问题出现后的3小时以内。 这次事故虽然发现及时，但因为缺乏事故处理预案，最后只能手足无措的看着事 故扩散，宝贵的时间被白白的浪费了。 u 说一千道一万，流程最重要 没有按流程严格执行活动上线流程，是出现问题最主要的原因，运营对此责无旁 贷。 u 急功近利的运营思路，让活动的制作和测试都无法得到保证 那时所有的活动都是技术手动去配置，本身就存在很大的