大宝(sodme)的Blog

长久以来，中国人对西方社会特别是西方社会高科技产品的膜拜，一直让我觉得是理所应当的事。因为，人家的东西确实好用、耐用、有用，不象国产的东西：质量差、不安全、土气。比如，sony的随身听，apple的mac和iphone，甚至包括未被收购前IBM的thinkpad。

如果有人问我，“大宝，让你感觉最快乐的事是什么”，我会说：“一场大战役之后独自一人静静读书的时候，特别是，读到一本好书，好到书中的每一句话都能让我发起法喜、感同身受的程度”。当然，这样的好书可能并不经常有，更多的时候我会把一些经典的书拿来反复读、反复感悟，得出一些新的感想后再不断的用到实践中。

就我所知道的情况，目前国内网游企业普遍的作法是，将研发与运营团队分设为两个独立部门，研发者全力投入只作研发、改BUG，而运营团队只负责客服、运维、部分的数据分析以及问题反馈等工作。

可能，我在骨子里就是一个充满了自我否定、自我批判的人，这种自我批判包含在很多具体的层面：

无论是在网上，还是在自己的身边，我们都会遇到一些刚刚入门的新手，也都会被问一些比较初级的问题，这没什么好奇怪的，每个人都是从新手走过来的，我自己也是。只要我知道答案的问题，一般情况下，我都会乐意去解答。

BK说，在国内，中国的民族网游永远有机会，原因之一就是国外产品根本搞不定国内的“流氓”玩家群体，搞不定形形色色在游戏中使用外挂、利用BUG获利的人。话虽偏激了一点，但中国玩家根深蒂固的外挂使用习惯还是让几乎所有网游产品伤透了脑筋，特别是，那些市场表现良好的产品，更是外挂制作者重点跟进的对象。可以说，反外挂与外挂的斗争，将一直是一个持续的斗智斗勇过程，在这个过程中，没有输家也没有赢家，看的就是谁能耗过谁。

通常情况下，一说到“优化”，大家最直觉的反应就是“性能优化”，而我这里要总结的“合服优化”，将不仅仅包括性能优化，它更广泛的意义上还包括流程、质量优化。

通常，我们对作一件事的极致追求都是“又快又好的把事作完”，这里面，有两个关键词：快、好。“快”字，当然很好理解，就是指的速度；而一个“好”字却蕴含了无尽奥妙，作到什么样的程度才算是“好”？所有的事情，是不是都有同一个标准可以称之为“好”？对不起，没有。何种程度才叫“好”，更多的情况下，它是作事者的一种个人体验、对自己个人能力的综合评估之后得到的自己可以达到的目标追求。

在合服这件事上，要作到“好”的程度，我认为它最起码应该作到以下几点：
1. 确保玩家数据万无一失，不出任何差错
2. 确保技术实现方案稳定、可靠，易实施
3. 确保在以上两个条件满足的情况下，尽可能的高效率

是的，我把效率放到了最后，这可能让很多人匪夷所思。本来为了追求更高的效率，我还可以把合服过程作得更BT，但是，我学会了适可而止，我为什么可以适可而止？因为，我很清楚自己的目标。

那么，我作了哪些优化呢？
1. SQL语句本身执行的优化(这是技术细节的优化，目的在于尽可能高的提高速度)
2. 将脚本与配置完全独立(这是流程的优化，目的在于为合服过程提供唯一的安全关键点的入口检测)
3. 尽可能全的一个人控制关键流程、重要步骤，对他人的操作结果要进行反复确认，特别是，他的操作可能会带来数据删除、修改等恶性结果之前(这是团队协作方面的优化，不要指望人人都很有责任感和职业精神)
4. 好记性不如烂笔头，尽可能多的预演、预测试

就象我们曾经无数次强调的不要过度设计，不要过分卖弄技巧，不要过于书本化与理论化，以前，我们总是本能的反对反对，而现在，我明白了，当一个人他没有足够的能力、知识和经验去把握一件事情的“度”的时候，所谓的不要这样、不要那样的要求，对于他，都无异于对牛弹琴。

所以，对于新人而言，最重要的，还是在于自己的学习能力、经验积累，只有在实战中不断的学习、思考、总结，才能不断的提高。请注意，我说的实战，不仅仅是指写几行代码就可以了，而是指更深入的运营一款实实在在的商业产品，关注它在运营中产生的所有问题，始终保持顽强斗志去逐个解决它们。这，才是真正的实战，也才是不浪费生命的真正有价值的实战！

经过一天多的观察，周四合服完成的混沌学园大区目前运行正常，未发现合服引出的问题，我实现了自己的目标：零错误。

混沌学园2000万个角色，是飞飞发展四、五年来的积累，这个区里的每位玩家，都堪称“资深的元老级”，每个服的职业排行榜内大多数都是120级的人物。我们很明白这群玩家对我们意味着什么，在新飞飞沉心研发的几年中，若不是有这群玩家的在线，产品的命运和前途可能将改写。

此次的合服，在技术上我作出了两个大的决策：
1. 不建中心服务器，而只建中心数据库；
2. 合服过程的测试采用迭代测试，先反复测小区再测大区，每次外服合之前都先在内部预合一次作测试。

这两个决策保证了合服工作的稳定和顺利进行，这也是在前两次转档过程中所积累出来的经验。不建中心服务器，这一点极大降低了由于建立中心服务器所带来的技术风险和不可知因素，尽管有了中心服务器我们可以开发更多的全服全区功能，但那仍然属于暂时不会列在计划内开发的内容，所以，为了不可预期的需求就没必要提前担负不可知的风险，特别是，在这样的一个承前启后的产品运营阶段。

至于第二点，迭代测试，这也是我们迭代研发思想的延伸，并不是什么新鲜玩意，其根本的目的，还是在于如何用更少的时间更快的发现问题、解决问题、验证问题。游戏测试，按理说应该是一个对专业技术要求非常高，甚至要求不低于游戏研发的专业领域，但是，非常可惜的是，直到目前，国内的游戏测试，还是处于一种类玩家型的黑盒和功能测试的水平，远没有达到自动化、高效率的程度，这不仅在于测试人员的技术水平，同时也跟程序人员的研发水平，以及产品设计人员的设计经验密切相关。但是，既然我们知道了有问题，就应该想办法去改善，就应该想办法从每个人自己的角度去改进，而不是听之任之，更不是频繁抱怨，不断让自己痛苦呻吟却不思任何改进，这，不是一种职业的态度。

我把职业化看成是一个从业者最基本的素质要求，我也努力让自己尽可能更高的职业化。职业化的内含是什么？我觉得：
1. 对事负责，而不是对人负责；
2. 对结果负责，而不是对过程负责；
3. 承担责任，而不是只知抱怨、推托或龟缩；
4. 精益求精，不断改进，而不是得过且过、草率应付。

在波澜不惊中，8月7日下午15点左右完成新飞飞的首批合服，经过合服之后的服务器，其人气活跃度一跃成为全服前三。

其实，有关合服的准备工作，是早在公测之前就已经在作了，只是后来因为五月份的公测，中间暂停了一下，直到七月份之后才恢复重新开始这块的工作。

这次合服，涉及到两个问题：一是新中心数据库架构的启用；二是老架构下各数据表的梳理与转换。相比之下，较复杂的工作在于各个数据表内容的详尽梳理(总计有48个数据表)，大体上这些数据表的处理规则有这三种情况：
1. 含id和name的单个字段处理(可以使用sql语句直接处理)；
2. 含id和name的拼接起来的字符串字段处理(需要借助bash脚本对导出的数据处理然后更新旧数据)；
3. 合在一起后，在逻辑上互相有冲突的表(比如占了同一个坐标位置的一些玩法，以及原服排行的一些玩法等，需要根据具体规则决定数据的取舍)

在所有的脚本和SQL语句中，最复杂的逻辑，是角色槽位的处理问题。由于同个账号可能分在不同的区建立很多角色，而同一个区内最多只有三个在用的角色槽位，所以，我们最终是采用这样的规则来处理：
将同账号下，各区在用的角色，按等级进行排序，取等级前三名的角色为新服下该账号的在用角色，其余不用角色置为删除状态，玩家可以恢复删除状态的角色(既有功能)

我借用SQL语句和两个临时表完成了以上的逻辑，大致作法是：
1. 把id，角色状态，账号，等级等信息按同账号等级排序重新导入到另一个有单独自增id的临时表中
2. 另建一个用于统计各账号下角色个数，最小自增id，最大自增id的临时表，然后就可以根据这个自增id的情况进行筛选了

本次合服，积累了一些新的经验：
1. 把表结构和数据分开导，有利于在建好结构后作中间优化
2. 要反复对比双方的表结构是否一致，包括字段顺序，这可能影响数据导入正确性(比如使用insert into new_tbl select * from old_tbl时，如果字段顺序有问题这条语句就会使数据出现混乱)
3. 自测的方法：使用sql语句的批量对比，可以作到尽可能多的数据一致性确认(只改变id字段的数据表，可以用一条简单的对比确认SQL语句就可以确定静态数据有无问题)
4. 要尽可能作到”一键式合服，脚本化操作“，有利于最高程度提升效率
5. 使用迭代测试，先使用小数据量进行测试，这样易修改易重复进行，确定小数据量没问题后再提升测试级别进行更大数据量级别的测试
6. awk本身只支持到32数值精度，要处理64位精度的大正整数，需要安装gawk

本次合服将持续到8月底，涉及的服务器将有58台，不到最后一刻都不算最终完成，仍需异常谨慎和仔细。

PS，新飞飞网站上的合服专题已经上线：
http://ff.163.com/2009/hefu/index.html