自从《少年三国志》Appstore上线第10天爬上畅销榜前三，公测20天流水破亿以来，多次被问到，少三投了多少硬广，哪些渠道有效，活动是怎么做的，留存上采取了什么措施……却一个人也没问过，一星期砸掉那么多钱怕不怕？这中间万一宕机怎么办？是怎么保障稳定运营的？……
是行业的浮躁导致看待问题的表面，还是手游发行已成熟到不需思考这些基础问题的境界，无从知晓。但在公测仅20天《少年三国志》单凭国内市场就能突破1亿流水的今天，在已经开了300余组服务器的今天，我回想最多的不是目标达成时的惊喜，而是无法释怀的12日凌晨一场虚惊时的绝望。
如果真要总结《少年三国志》的经验，我只想说，稳定胜过一切，要把产品推到S级的位置，拼的是硬实力。
少年三国志
凭什么敢双端同步公测，集中包量式投放？
《少年三国志》之前，没有如此大规模集中广告投放的手游。20余家电视台、数十条火车线路和火车站、几乎所有游戏媒体、几百个手机应用、多家视频贴片……集中在一天爆发，持续两周高密度曝光。iOS、安卓版本同步公测，近50家安卓应用商店同步集中最优位置推荐，甚至包含了多个开屏广告和应用商店的系统消息推送。
这些令人激动的资源背后，意味着，第一天预计40多万的新增用户量，要开差不多12组服务器，哪怕一小时宕机就是几十万的广告费损失；如果出现重大bug需要Appstore重新提交版本更新，那么等待苹果审核的3-7天中，几千万广告费全打了水漂；如果安卓版本兼容适配出了问题，那么几十家渠道的推荐资源立即停止……
如此高风险的公测方案背后，是两年三款成功产品的经验教训沉淀，是数十条的用户不可见的保障功能开发，是数百条的产品上线检查项，是多次用户测试和数据验证，是高效的sdk接入和服务器管理方案，是长达一个半月的疯狂风险排查……
少年三国志
数据说话，凭什么申请如此高额预算
《少年三国志》制定公测计划前，进行了3次目标明确、验证严谨的面向用户测试，以对产品进行充分调优，对最终品质进行有效判断：通过游族用户小范围精英测试，验证核心玩法的接受度和产品运行的稳定性；通过删档测试，验证和优化产品玩法体验，保证留存；通过收费内测，验证和调优产品数值体验，保证商业化数据。从第一次精英测试，到我们敲定公测节点，将近4个月时间。
1月初，产品经过了近1个月的内测调优，各方面的运营数据指标均达到A级标准，且数据相当稳定。这样的数据表现，让我们有十足的自信——这款产品一定能做成，我们只需要做一套漂亮的公测方案来试探能做到多高。到了此时，我们才确认公测档期和初步的市场预算规模，以及为了让推广效应最大化，确定了iOS、安卓同步大推的策略。
SuperSdk，让1周接入近50家渠道成为现实
确定公测节点时，离正式公测只有1个多月的时间。我们决定iOS、安卓同步大推，也就意味着在1个月内，我们必须接好几十家渠道的SDK。
此时，通过几款产品发行积累起来的SuperSDK发挥了巨大的作用。《萌江湖》时代接入、调通一家SDK要3天的往事历历在目，而到了《少年三国志》，凭借集成式的SuperSDK，近40家SDK接通只用了一周多的时间，同时还支持CPS分包功能。
SDK接通之后，为了确保稳定，我们不仅对每个分包的SDK功能进行了测试，还对重点分包进行了上百台安卓适配机型的真机测试加更多机型的云测试，对外发包0故障。
稳定公测，9项技术准备保驾护航
曾经在朋友圈发过一句话：系统、适配、SDK、混服、自更新、CPS、IDFA…来分享下都在哪几步栽过。结果得到最多的回复是：可以问问谁第一次搞没有每步都栽过~
栽过，才会有对策。捡最重点的说，一共9项：
1）前后端代码均可热更新，随时修复bug
2）多条自更新CDN线路随机切换减少更新中断
3）多个自更新包自动合并，避免错过更新的用户重复加载资源
4）支持多种不同的混服模式，且可以灵活后台配置，满足国内外不同渠道开服要求
5）支持多服齐开循环推荐，以分散集中用户涌入压力并保证每个服务器导量充足
6）客户端错误自动收集，随时发现解决问题
7）GM后台资源配置预警，避免操作失误
8）GM后台大量定时及复制发布功能，减少操作工作量，降低出错率
9）数十个可配置活动，随时调整服务器生态
就是12号的凌晨，离大规模广告导量仅有8小时的时间，我们发现了一个100%可重现的闪退bug，经过排查，这个bug是SDK问题导致的。谁都知道更新SDK意味着整包更新，整包更新意味着3-7天的提审，而这中间，是不可能撤掉已经买了的广告位的。就当所有人陷入绝望的时候，我们预埋的热更新机制，把问题解决了。多做任何一条技术准备，都是可能在关键时刻救命的。
提审，Appstore一次性审核通过背后的秘密
几乎每个做iOS应用的团队，都遇到过几次Appstore提审被打回的经历，而每次被打回，都意味着一周以上的修改及再次审核的周期。而广告投放，却是需要事先定好节点的。所以大量的厂商为了保证投放安全，甚至会在提审通过后才开始定资源，导致至少1个月的空白等待。
游族网络把Appstore审核规范结合历史产品审核不过的经历，做成了一份完善的检查清单，从研发的版本规范、服务器配置、充值配置、广告监控等等到运营的icon/截图/视频制作要求、ASO设置、版权声明等，提审前只要逐项检查验收，就能规避90%以上可能被苹果打回的问题。
《少年三国志》这次严格按规范提交审核，第一次就审核通过，节省了大量的时间。
测试，测试，还是测试
前面提到了针对SDK的测试，事实上少三此次为公测进行了长达一个半月近乎疯狂的测试。举例说，针对压力测试，我们不仅做了机器人模拟来测游戏服务端承载，甚至连登录、充值、游戏内嵌页面访问等所有涉及平台服务的环境，都做了集中并发测试。我们那时的口号是，任何人通过任何方式把任何服务器压挂掉，有奖！
版本预留，有备无患
产品大推，我们一方面要减少版本更新，以避免更新带来的dau损失。但同时，我们又必须保证及时更新，以在游戏内容被用户消耗完前，给予用户新的追求。我们无法预料游戏当前的内容够不够，用户玩游戏的进度，永远超乎开发者的想象。我们能做的，就是在公测开启前就备好一个资料片，在线上一定比例的游戏用户开始感到厌倦时，立即更新上线，以维护运营数据稳定，并为后续的优化和新增内容争取时间。
其实还有很多，再说下去恐怕这篇文章就要写成书了，以上仅为抛砖引玉。总之，经过种种准备，《少年三国志》到公测那天，已经万事俱备，只欠导量了。
公测两周开近200组服，0事故，我们做到了
前面说的是公测前的准备，就像出征前的粮饷筹备和战斗训练。而真正的战场，却是在公测开启之后。用户的引导、问题的应对、数据的保证以及后续方向的明确，这是真正开服后要做的事。
近乎夸张的团队人员配置
也许多年前你曾经历过30人运营的端游，但你应该没听过30人运营的手游。《少年三国志》此次计划的体量，已经超过了当年大多数的端游，而我们又把服务和用户体验放到了第一位，所以在公测前，几乎抽调了所有人手，组成了一个30人的运营团队。
30人的运营，有那么多事情做吗？
公测首月每天24小时处理客服提报的事件，百度贴吧游戏相关问题每帖必回；同时维护七八个渠道论坛，并保证这些社区的活跃活动；一家家应用商店优化产品描述、小编推荐，每天支持超过1000张广告素材，优化渠道导量；新闻软文的撰写，微信公众号的运营；十来个500人Q群维护，加之用户调研，意见整理；每天10余组服的导量监控，开服配置；几十个开服活动随时分析和优化，同时每周再更新几十个循环活动；版本的优化案，数据分析报告……
30个人，昼夜两班，忙到飞起。而通过集中的人力铺入，极大的保障了《少年三国志》的宣传效果、服务质量，极大的提高了用户的满意度。
近乎偏执的开服数据坚持
从页游时代，开服就是游戏运营的核心节奏控制环节。导量多了，服务器承载不了，造成卡顿流失；导量少了，互动玩不起来，服务器生态受损流失；开服快了，玩家觉得你洗用户跟不上节奏；开服慢了，想去新服重新发展的玩家失去等待的耐心……
为了保证每个服务器都达到最好的开服效果，我们随时观测新服的在线人数，不近上限不开新服，临近刷新点就算破了上限也要挺挺再开新服。根据新近开的服的生态状况，在有效时限内，酌情补量。
从没想过提前按导量预估定好开服表万事大吉，让我们到现在开了300多组服务器，每组服的生态都相对健康，而执行如此麻烦的开服策略，没出现过一次失误。
分析、调优，每天的功课
《少年三国志》做了强大的数据后台，不仅能随时看常规的运营指标数据，还能看到核心的追求点的参与情况和纬度填充进度。
数据分析、玩家反馈，加之用户调研、用户回访，不断找出产品问题，通过活动临时调整生态，并协助研发团队通过版本彻底解决问题。同时这些分析，也为投放、合作团队提供支持。
虽然看过无数篇文章指出单纯通过数据无法指导做出好游戏，但其实数据真正的意义，在于帮助找出最关键的问题，并对应对行为进行验证，这比盲目的靠猜来做应对，还是靠谱多了。
虽然标题是0事故始末，不知不觉却是写成了整个《少年三国志》公测前的准备和公测后的应对。这些不仅仅是为减少事故，绝大多数是为了产品更加稳定和持久。在游戏发行过程中，少犯两次大错，绝对胜过一个版本做对，如果对每次事故的后果和更新的效果做比对，大抵都会得出这么个结论。所以再次强调，S级产品发行靠的是硬实力，稳定是第一生产力。
——from少年三国志运营负责人：毛豆