机动战姬9.30到10.12大灾变事故调查报告，各位亲爱的指挥官，关于这次事故，我们整个技术团队有着不可推卸的责任。这是一份迟来的报告。这份报告发在这里的目的，就是为了公开透明，呈现真相。就像甬温xx追尾，xx爆炸。我们每个人，都有知道事情真相的权利。
同时这份报告，对于我们来说，更是一份总结，再确切一点，这是一份机动战姬研发、运维团队的自我醒觉。这份报告，不带有任何解释或者推卸责任的想法，只是想把最真实的情况，告知给大家。也许大家看完之后，会骂我们傻X，那也是因为我们真的傻X。犯了错误不可怕，可怕的是不能、不敢面对自己的错误，我们宁愿让大家知道最真实的情况，然后在大家的监督中继续前进，努力把这款游戏做到最好。
一开始的开发环境，只有一台服务器，前端服务、数据库都在这台机器上，简单至极。封测完成之后，着手准备内侧的时候，架构和运维团队介入，我们发现，前端API与客户端的交互数据，放在了内存当中，定时与数据库进行同步，这意味着，这款游戏不支持分布式!再通俗一点说，就是不支持通过扩展服务器的数量来分担负载。
面对着极大的发布时间越来越近的压力，我们要求研发团队在非常短的时间内修改程序的逻辑架构，放弃对内存的依赖，实时写入到数据库。完成之后，我们进行了简单的压测之后，就这么上线了。是的，没有进行CodeReview，没有注意代码的质量，就这么上线了……
9月17日，苹果上线，然后我们发现，每一台前端服务器的内存占用率非常的高，这个时候，我们又采取了一个傻X的方法，是的，加服务器……我们再次没有去审查代码，查找原因，只是增加了服务器，为之后产生大问题埋下了伏笔。
9月30日，上线之后第一次更新服务器代码，这是一次版本更新，没有任何技术上的修复，只有新功能，是的，我们又傻X了。面对一片大好的形势，我们的步子迈的大了，真的扯着蛋了。更新完之后，发现了有部分数据开始丢失，然后，我们马上继续傻X，做了一件简单粗暴的事情，简单来说，就是什么数据丢了，就补什么数据。再简单点说，就是假如等级丢了，那么就取出来战姬的等级，然后加3……我们就这么把问题滑过去了，没有重视，再次埋下了第二个伏笔。
10月10日，安卓服务压力大，又增加了一倍的服务器数量，然而并不稳定，玩家数据开始丢失。
10月12日，苹果服务压力大，出现玩家数据丢失。
这个时候，我们终于意识到，该来的终于来了，必须要停下来，真正的面对我们必须要面对的事情了。开始一步步的排查问题：
1. 首先发现，数据库的负载均衡状态不正常，经过确认，所在的云主机网卡包被打满，紧急切换到物理服务器。
2. 切换之后，并没有太大的起色，继续排查，发现从库同步主库数据有比较严重的延迟现象，而主库压力并不大，所以由读写分离方案改为主备方案。
3. 开始检查代码，为什么只有几十个服务器，1W左右的用户在线并发，会把云主机的网卡包打满。经过检查发现，每一个用户登录，连接池都会实例化10几个连接，并且销毁机制存在问题，导致连接越来越多，造成异常。
4. 继续检查代码，为什么会出现用户数据丢失，后来发现，在进行用户数据读取的时候，有一段try catch的异常处理，当连接失败的时候，会返回一个空，这意味着什么?这意味着，如果你在游戏过程中，与服务器交互获取某一部分数据，如果这次连接数据库失败，那么你这部分的数据读出来就是空，然后再写回，那么这段数据就丢失了!获取VIP失败，那么丢失VIP。获取战姬数据失败，那么就丢失战姬……
5. 继续继续检查代码，为什么服务器的内存不稳定，总是在不停的增长。结论就是，在修改支持分布式的时候，去掉了对内存的依赖，可是……只是不去读内存了，但是写入内存还在继续……
以上基本上就是把机动战姬改变成为转圈战姬、灾变战姬、重置战姬、归档战姬的所有原因。经过几天几夜的排查和修复，技术上的问题基本上已经解决了，但是造成的影响，却在一直蔓延。对于我们技术团队来讲，首先对广大的玩家造成了非常大的损失。然后，还有我们整个公司所有的运营和客服同事，他们顶在第一线，替我们挨骂，24小时收集玩家的问题，修复，没有怨言，还在安慰和支持我们技术团队，真的让我们汗颜……
现在我们已经制定了完整的技术流程，优化方案，不会再有任何的侥幸心理。我们会全力以赴的履行好我们的职责，让广大喜爱机动战姬的指挥官能够稳定的进行游戏。也请大家严格的监督我们，在升级战队等级、战姬等级的同时，也请升级我们的等级。
