引入一个灰度发布的概念。 有个线上项目事故分析报告，其中明确列出哪些问题是容易被忽略放到外网的，占比有多少。项目事故分析
无数的线上事故和金钱损失，换来如下的教训： 对于网游产品，测试部门是一定需要专业重点建设的； 对于紧急事故必须有完备的处理预案和责任人制度； 对于重大的备份恢复操作，平时要经常演习熟悉； 对于风险评估和具体应对，我们还需要更多的经验； 对于用户管理和运营维护方面的经验缺乏，舆论导向控制不力，用户反馈收集缓慢，信息不全，用户体验很差； 最重要的是，我们需要一个符合网游产品运营特点的团队管理结构。
腾讯QQ堂曾今出过一个抽奖活动，有个0.06%的特等级价值1000w游戏币，相当于1000块人民币。但因为策划填表的错误，导致所有奖励概率加起来不是100%，而程序逻辑在判断到特等奖的时候用的不是有效区间判断，而是随机数没有落在非中奖和其他奖项区域下，就认为是特等奖了，结果使得真实的特等奖奖励概率变成了26%。最坑爹的是这个游戏还可以将游戏币转化成Q币，所以最终导致外网被刷了21亿游戏币，紧急处理后依然有价值10多万的Q币被转移，无法追回。
QQ幻想有一个商城物品里的物品显示的与实际的不相符，说是客户端bug引起的，但感觉更像是前后端配置表不一致，然后被玩家利用进行欺诈，导致其他玩家遭受损失并进行投诉。在之后的修复过程中，又引发了一个复制道具的bug，这个bug在4天造成150万的损失；还引发了舆论危机。
在管理层面上 合理的运营组织架构，确保产品责任/项目责任/设计责任/资源责任/日常工作责任等等都明确到人，工作流程清晰条理，关键环节多人审批，多人监督；
建立完善的事故预警/升级/处理机制，事先准备各级事故处理预案，指定各级事故召集人，建立事故召集处理会议制度；
加强用户管理，增加玩家层面预警能力，建立多种用户组织，加强舆论控制和引导能力，加强危机公关应对能力；
重视测试环节，保证充分的测试时间和规范的测试过程，测试用例需要各方面共同制定，高风险项目一定经过充分的外部测试。
在技术层面上 在产品设计之初就应该考虑产品的“可运营性”，预知未来可能的运营需求和风险，在架构设计上留有足够考虑； 完善灵活的备份机制，各种记录完善细致，各种统计和还原类工具齐备； 对于重大风险事故需要定期演练，各种处理手段机制制定详细的技术预案，做到有备无患。
在策划层面上 在任何产品设计和活动设计的评审环节加入运营风险评估部分，重视安全性设计，共同回避可能发生的问题。
QQ Mini Game平台对网络流量评估不足，造成用户无法登陆。
修改不测试的问题示例
《剑网3》曾今有一个配置表是二维表，有一次追加了一行后，没有对应增加一列，然后就直接提交入库，也没有经过测试，结果导致当天临上线的版本编译不通过，产品推迟了1个小时上线。
《剑网3》有一次修改了NPC加载模块，忽略了身上有绑定商店的NPC处理，提交前也有测试，但测试的两个场景中的NPC都没有绑定商店。结果当天正式版本启动后，加载到有商店的NPC场景时，服务端会中止运行。
某次运维同学修改了SVN的账号密码后，没有对应修改自动构建系统里配置的账号密码，导致自动构建一直更新失败，影响了当天的版本制作。
《奇迹破坏神》某次上线版本，服务端没有关闭GM指令，不过幸好测试提前进入发现了问题，避免了外网可能使用GM指令的问题。
《剑侠世界》修改配置表导致游戏功能里的时间轴错误，自动开放了等级上限，很多玩家超出了等级上限，需要临时关服处理，影响了当天4个小时的游戏运行。
《剑侠世界》曾今出现过，某个程序员临时解决了一个BUG，但因为晚上时间太晚不想打扰测试同学休息，就自己测试完后发布了一个版本，结果导致了一个更大的BUG。
设计上考虑不足
《剑侠世界》有个家族活动，设计上没有考虑到非正式成员不能参加活动，结果程序逻辑中没有处理到，非正式成员可以刷积分。
《剑侠世界》处理前一次事故发放补偿的时候，采用了玩家参加活动直接获得双倍奖励的方案，结果设计上没有明确只有参加某个活动才能获得双倍奖励，导致所有功能活动都刷了双倍奖励。影响了整个游戏内的经济产出和公平性。
信息同步的问题
《剑网3》NPC的创建时间只有研发的策划和测试知道，但是运维那边不知道，两边没有共同约定好正确的服务器维护时间，导致问题。解决方法：关于特定时间维护的更新必须得和运营说明，在邮件中特别标记出来，保证信息到位。
《剑网3》使用物品的脚本一般没有特殊就用通用的脚本，但是这次使用的是技能脚本的机制，策划在制作的时候不清楚这个脚本每个参数的含义，导致问题的产生。解决方法：写脚本的时候一定要清楚脚本每个传入和传出的参数的含义，严格使用。没有特殊情况一律使用通用脚本。
《剑网3》在制作这个副本的时候没有通用副本制作规范，制作的策划是新人，又没有全面的培训，很多潜规则都不清楚。解决方法：整理了一个通用副本制作规范，制作和测试的时候严格执行，保证规范里的每个检查点都没有问题
《剑网3》功能新老交接的问题，导致后来制作的策划和测试完全不知道原来的是个什么样的东西
《剑网3》这个更新包第一天下午更新到体服，结果第二天早上上班前就更新到收费服了，体服反馈的问题根本来不及收集。解决方法：研发不会提前告诉运维准确的更新时间，只告诉一个大概的时间，运维不能在确定更新前提前发更新公告。更新包上收费服必须在体服稳定三天，如果期间有严重问题，修改完毕后再在体服稳定三天再更新收费服。
《剑网3》策划疏漏没有按照规范填写，导致配置表的默认参数不是实际想要的结果。掉落检查工具不完善，只检查了掉落率，没有检查叠加数量，忽略了问题。
《剑网3》版本差异文件比较要比较整个表的全部差异，不能只看自己负责的，发现不是自己负责的要和组员沟通，防止忽略隐藏的问题。——所以后来我在做配置表检查工具时，除了会即时检查修改了的配置表，还会每天定时检查一遍所有的配置表，因为有些配置表的修改会影响到其他配置表。
修改不谨慎，随意删减内容
《剑网3》程序觉得屠杀功能关闭，相应的脚本接口没用了，所以就删除了脚本接口，导致进副本的脚本判断失败，解决方法：现有接口程序中一般不删除，只在相关脚本中屏蔽。如果一定要删除必须和相关功能的策划和测试核对清楚到底有哪些关联的地方并做好完成的解决方案
《剑网3》strings.ls这种策划编辑器自动生成的文件，不允许手动修改
《剑网3》老角色兼容问题，由于美术觉得某个发型废除了，就让策划把这个发型的ID删除，测试的时候没有导入外网的角色，而是直接新建角色，没有发现问题。解决方法：配置表在运营后绝对不允许做删行或者删列的操作，如果行列不用，就留在表中其他地方不调用。如果一定要删，必须邮件通知全项目组确定删除后所有相关影响的功能。
设计上防刷
- 《剑网2》野外小怪会掉落一些杂物，卖给商店后会获得极少的金钱；但外挂通过创建大量的角色不断在野外刷怪，每天也能产生极其可观的金钱总量，破坏了游戏里的经济平衡性。反复快速刷新的NPC不应该掉落任何有价值量的东西，同时把插件自动拾取的接口屏蔽，因为正常情况下NPC死亡后马上消失，手动根本来不及拾取尸体
一些线上版本的问题
- 临上线前要修改奖励数值。
- 跨部门合作，例如SDK打包工具一般是有个专门的小组负责，但是他们对问题修复的速度较慢，且时长发布更新，经常出现我们打包好后，他们改了sdk的接口，需要我们重新打包。
- 修改后不通知所有人。有一次线上版本做更新，策划偷改了一些配置表内容，但是配错了，测试发现问题后，跟程序查找了很久，花费了很长时间，最后发现时配置问题，延误了发布更新的时间。
- 太过依赖热更手段，频繁修改线上的配置表。但有些配置表需要客户端也更新，有不能频繁发包，于是就造成了前后端信息不一致的问题。
- 更新包未经测试直接发布。有一次主策划自己半夜修改了一些东西，将发版的程序叫来直接发布到了外网，他说自己经过测试了没问题。结果发布后半小时，外网发现了bug，一时间又找不到良好的解决办法，又临时把内容改回去了。
- 开发分支与发布分支混用。尤其是对于开发人员来说，频繁切换两个分支版本也十分麻烦，提交也十分麻烦。最后确定的办法是所有的修改内容都在开发分支进行，反正发布分支要修改的内容最终也需要在开发分支进行，开发分支修改后，策划和程序自己先验收，确认修改效果后，然后同步到发布分支，再由测试同学进行测试，确保修改不会引发新问题。
- 前后端代码分支不在同一个svn目录下，每次切分支，都要先锁库，然后两个前后端主程互相通知到，同时切分支，才能确保切出来的版本内容前后一致。
- 外网GM指令或管理员后台没有限制指定账号才能使用，且使用效果没有限制。有一次为了在外网确认bug，使用了升级指令，导致角色超出了当前服务器玩家最高等级，引起了玩家的不满。
- 通知不到位。突然之间说要上线，或者定好的上线时间没有通知到所有人。例如之前的主策划和运营，定了时间不通知，到了要发布的前一天突然说明天要上线。这么简单低级的错误还真的是有人犯。
- 接受SDK联调的时候，运营只发了一份文档过来，说按文档操作，说不清楚目标和作用。最后还是自己摸索后才知道要干嘛，而且跟文档描述的内容并不一致，很多操作和页面选择都已经发生了变化。这就是不干实事的人，指挥别人做事情的结果。
- 渠道发布环节总是出各种问题，导致不得不换名字，每个渠道用的不同名字和icon，给打包过程带来了很大的复杂度。
- 突然从一个整的版本计划里要抠出几个功能，提前更新出去。测试的工作量是无法减少的，而且还要重新调整测试计划。
- 功能还没完成开发就向玩家分布了更新公告，说明要调整的内容，结果delay后又不断跟玩家解释，增加无谓的压力和耗时。
- 运营自己传包错误，导致渠道包不可用，又要重新打包。
- 版本更新后，玩家对新内容不满意，策划决定临时调整，立即热更出去。或者是前一日才发布，第二天就要开始调整。
- 后端代码修改后未经测试直接发布，导致功能异常。
- 新开服与大的版本内容更新放在了一起。新开服最好是比较稳定的时候，新内容更新出去总摇先跟进下有没有问题。
- 多语言版本的管理混乱，甚至拿开发版本给代理方，结果发现了很多问题，来回的沟通。
- 渠道包打出来后，明明本地安装下启动下，就能看下有没有问题，非要等很长的上传时间，然后再通知到测试去跑。