测试，测试，还是测试

　　前面提到了针对SDK的测试，事实上少三此次为公测进行了长达一个半月近乎疯狂的测试。举例说，针对压力测试，我们不仅做了机器人模拟来测游戏服务端承载，甚至连登录、充值、游戏内嵌页面访问等所有涉及平台服务的环境，都做了集中并发测试。我们那时的口号是，任何人通过任何方式把任何服务器压挂掉，有奖!

　　版本预留，有备无患

　　产品大推，我们一方面要减少版本更新，以避免更新带来的dau损失。但同时，我们又必须保证及时更新，以在游戏内容被用户消耗完前，给予用户新的追求。我们无法预料游戏当前的内容够不够，用户玩游戏的进度，永远超乎开发者的想象。我们能做的，就是在公测开启前就备好一个资料片，在线上一定比例的游戏用户开始感到厌倦时，立即更新上线，以维护运营数据稳定，并为后续的优化和新增内容争取时间。

　　其实还有很多，再说下去恐怕这篇文章就要写成书了，以上仅为抛砖引玉。总之，经过种种准备，《少年三国志》到公测那天，已经万事俱备，只欠导量了。

　　公测两周开近200组服，0事故，我们做到了

　　前面说的是公测前的准备，就像出征前的粮饷筹备和战斗训练。而真正的战场，却是在公测开启之后。用户的引导、问题的应对、数据的保证以及后续方向的明确，这是真正开服后要做的事。

　　近乎夸张的团队人员配置

　　也许多年前你曾经历过30人运营的端游，但你应该没听过30人运营的手游。《少年三国志》此次计划的体量，已经超过了当年大多数的端游，而我们又把服务和用户体验放到了第一位，所以在公测前，几乎抽调了所有人手，组成了一个30人的运营团队。

　　30人的运营，有那么多事情做吗?

　　公测首月每天24小时处理客服提报的事件，百度贴吧游戏相关问题每帖必回;同时维护七八个渠道论坛，并保证这些社区的活跃活动;一家家应用商店优化产品描述、小编推荐，每天支持超过1000张广告素材，优化渠道导量;新闻软文的撰写，微信公众号的运营;十来个500人Q群维护，加之用户调研，意见整理;每天10余组服的导量监控，开服配置;几十个开服活动随时分析和优化，同时每周再更新几十个循环活动;版本的优化案，数据分析报告……

　　30个人，昼夜两班，忙到飞起。而通过集中的人力铺入，极大的保障了《少年三国志》的宣传效果、服务质量，极大的提高了用户的满意度。

　　近乎偏执的开服数据坚持

　　从页游时代，开服就是游戏运营的核心节奏控制环节。导量多了，服务器承载不了，造成卡顿流失;导量少了，互动玩不起来，服务器生态受损流失;开服快了，玩家觉得你洗用户跟不上节奏;开服慢了，想去新服重新发展的玩家失去等待的耐心……

　　为了保证每个服务器都达到最好的开服效果，我们随时观测新服的在线人数，不近上限不开新服，临近刷新点就算破了上限也要挺挺再开新服。根据新近开的服的生态状况，在有效时限内，酌情补量。

　　从没想过提前按导量预估定好开服表万事大吉，让我们到现在开了300多组服务器，每组服的生态都相对健康，而执行如此麻烦的开服策略，没出现过一次失误。

　　分析、调优，每天的功课

　　《少年三国志》做了强大的数据后台，不仅能随时看常规的运营指标数据，还能看到核心的追求点的参与情况和纬度填充进度。

　　数据分析、玩家反馈，加之用户调研、用户回访，不断找出产品问题，通过活动临时调整生态，并协助研发团队通过版本彻底解决问题。同时这些分析，也为投放、合作团队提供支持。

　　虽然看过无数篇文章指出单纯通过数据无法指导做出好游戏，但其实数据真正的意义，在于帮助找出最关键的问题，并对应对行为进行验证，这比盲目的靠猜来做应对，还是靠谱多了。

　　虽然标题是0事故始末，不知不觉却是写成了整个《少年三国志》公测前的准备和公测后的应对。这些不仅仅是为减少事故，绝大多数是为了产品更加稳定和持久。在游戏发行过程中，少犯两次大错，绝对胜过一个版本做对，如果对每次事故的后果和更新的效果做比对，大抵都会得出这么个结论。所以再次强调，S级产品发行靠的是硬实力，稳定是第一生产力。

　　——from少年三国志运营负责人：毛豆