聊聊服务器维护
大宝(sodme)
程序其版本发布周期也是不太一样的，在网游领域，现在一般每周一次的版本发布已属比较常见，而在IM领域，这个周期可能要稍微长一点。而伴随这种服务中
断的版本维护，带来的是用户对产品短时间的不可用，这个时间当然是越短越好，最好的情况是用户根本察觉不到服务中断而我们已经完成了维护。
所以，这就引出了一个话题，想跟大家聊聊，大家各自负责的产品其维护流程大致是什么样子的，都各自采取了哪些办法来尽量减少非正常服务时间，从而让用户
尽可能少的受打扰，让维护尽可能少的出问题。比如：
1. 维护期间，有没有提供额外的通道，可以让两个版本的程序同时运行？让新版本可以小范围测试，同时又让既有的服务不受干扰。
2. 版本切换时，需要多长时间？这些时间主要消耗在什么地方？有没有办法进行改善？如何改善？
3. 服务器程序有没有提供热更新功能从而达到不用停机而修正BUG？能不能作到对日常功能全覆盖式的热更新？服务器程序有没有使用脚本？使用的何种脚
本？
以上问题，只当是个引子，大家多聊聊，看看有无新的发现，可以改进自己产品的维护流程，提升维护效率，减少用户等待时间，留言时，请最好说明是哪种类型
的服务器，是网游，还是IM，或是其它。
秦一
Lei Gu
3. 热部署一定不单单是一种编程语言可以解决的，在设计开发阶段都需要进行相关的考虑。带来的麻烦事也是不少的。只有电信银行之类真正需要不间断服务的行业才会使用这种成本很高的技术，网游没有这个不也活得好好的，魔兽的维护时间长的要命，也不影响他赚钱。
服务器更新维护最理想的就是实现代码热部署，这个在erlang下很容易实现。但是在国内还没有看到在网游领域的erlang成功案例，但前几天在51job上已经看到有公司在尝试用erlang构建游戏服务端。
秦一
Sparkle
无缝升级的本质问题当然就是中间数据的问题啦，最简单的例子就是session，放在数据库当然能解决啦，只是性能问题而已，不可能用户的移动坐标也放在数据库吧
真的只有电信才会对无缝升级要求非常非常高，所以erlang在这些领域很被看好
但是如果网游，IM可以做到更好的无缝，对用户体验的提升也有帮助
当然最后也就是性价比的问题了
2009/8/4 Lei Gu <jack...@gmail.com>:
大宝(sodme)
时候我们要寻求的是一种平衡，就拿erlang这玩意来说，它本身好可能是非常好，但是，如果真要拿到项目中来实施，除了考虑语言本身的好坏特性之外，
你还需要充分考虑到整个团队对它的驾奴能力、能不能用它在老板要求的时间内作出一个可以跑的、稳定的、可商业运营的东西来。
我说说我们是怎么作的，我认为我们的流程还有很多可以改进的地方，所以，也想听听大家是怎么作的。
1.关于版本维护的时间、流程和效率
a.我们的产品是每周维护一次，每次耗时2小时左右，共计58台服务器。
b.对于有重大程序调整(不含游戏玩法)的版本，除本身的自测外，一般我们会预先在某一两个区先行投放验证版本，无问题后再投放到外服。
c.在版本发布的当天，我们会逐批关闭服务器，逐批投放新版本，一般第一台新版本的服务器会观察运行半小时左右。对于不同版本的客户端登录，我们选择了
简单作法：不关闭暂不维护的服务器，同时提示老版本的新登录客户端目前正处于版本维护期间，暂停新客户端登录。这样可以让已在游戏中的玩家不退出游戏一
直玩到版本维护。
2.关于BUG修正和风险控制
a.在编码和设计阶段，我们就已经为各功能系统提供了系统开关，通过GM指令可以随时关闭一个系统的运行，比如投放的一个新活动玩法。在实际运营过程
中，如果发现问题，则可以马上暂停该系统的运行，从而把损失降到最小；
b.在服务器端和客户端，对频繁修改逻辑提供热更新功能，热更新本身使用lua的reload实现，当某块逻辑出现问题而等不到每周维护版本再修复时，
就可以采用热更新方案临时修正问题。客户端的热更新内容，通过协议从各服务器直接获取。
3.我们还需要改进的地方
a.热更新目前还无法作到全逻辑覆盖，只在某些文件和逻辑处适用；
b.维护时间相对较长，梦幻500组服务器也才1个半小时的维护时间，我们的维护时间还需要继续优化。
c ...
On 8月4日, 下午5时28分, Sparkle <pope...@gmail.com> wrote:
> 维护和更新是两码事，"新老版本数据不兼容"的情况，需要停机很正常，但是有时是做一些bug fix或者数值公式的调整。所以才那么多公司愿意用lua来实现一部分逻辑
>
> 无缝升级的本质问题当然就是中间数据的问题啦，最简单的例子就是session，放在数据库当然能解决啦，只是性能问题而已，不可能用户的移动坐标也放在数据库吧
>
> 真的只有电信才会对无缝升级要求非常非常高，所以erlang在这些领域很被看好
> 但是如果网游，IM可以做到更好的无缝，对用户体验的提升也有帮助
> 当然最后也就是性价比的问题了
>
> 2009/8/4 Lei Gu <jackf...@gmail.com>:
>
> > 1.
> > 新老版本数据不兼容的话，让新老版本同时运行就是一个非常扯淡的事情，如果真的需要，不如单开一组测试服，不过国内玩家都不愿意当小白鼠，测试服大多是没人玩的。
> > 2.
> > 版本切换的时间取决于你的中间状态保存在哪里，我见过中间状态完全存储在数据库和memcached的，版本升级可以做到瞬时切换，新版本服务器启动，前边的网关改一下指向，立刻生效。只有那种策略类，24小时在线概念的游戏才真正需要这个吧，MMORPG之类，基本都没有这么平滑的升级。用户需要的是可预期的维护，你说几点开始维护就几点开始，说维护多久就维护多久。
> > 3.
> > 热部署一定不单单是一种编程语言可以解决的，在设计开发阶段都需要进行相关的考虑。带来的麻烦事也是不少的。只有电信银行之类真正需要不间断服务的行业才会使用这种成本很高的技术，网游没有这个不也活得好好的，魔兽的维护时间长的要命，也不影响他赚钱。
> > 我觉得从运营，运维角度，开发少出故障，易部署的程序和工具就是最好的。运维，运营，客服包括制作团队自己大量的擦屁股的工作都是因为技术人员和策划的不靠谱，不认真，导致的各种问题。技术人员应该极力降低复杂度，而不是引入复杂度。
> > 2009/8/4 秦一 <qinchong...@gmail.com>
>
> >> 服务器更新维护最理想的就是实现代码热部署，这个在erlang下很容易实现。
> >> 但是在国内还没有看到在网游领域的erlang成功案例，但前几天在51job上已经看到有公司在尝试用erlang构建游戏服务端。
>
>
Chaolin Zhang
Lei Gu
大宝(sodme)
看来你们的版本测试情况还是比较好的，可以作到比较稳定的发布版本，在你们的日常开发中，平均也是一周时间投放新内容吗？这些新内容涉及到的代码量和改
动量大不大？我想，如果内容比较多的话，QC可能比较难以在我们编码结束的同时也完成系统测试，一般我们是把各个系统的发布和制作时间进行交叉，一个开
发小组开发的内容，其制作与发布周期可能是两周左右，这样可以多留出一点时间来给QC测试，这是就目前而言。
另外就是新玩法的测试，我们的作法也是先投放到某一个服务器，观察一下，然后策划根据外服运营的实际情况可能再进行一些数值调整，然后再是投放到其它所
有服务器。
还有我比较感兴趣的是你们的热部署所覆盖的“所有脚本和数据表”，这里的“所有脚本”也包括逻辑代码吗，还是只包括使用脚本的数据配置？有没有包括一些
脚本层的动态对象呢？动态对象我们现在是没有考虑其对象的热更新方案的，已经创建的脚本动态对象。
关于运维和客服人员的误操作问题，在我们的实际工作中也会经常遇到，对于一些非常重要的操作，我们一般是不开放给一般的运维人员来作的。另外就是，对
于“删除”这样的操作，在很多系统的数据设计中，我们并不是直接从数据库中把数据抹掉，而只是打上了一个删除标记，这样可以在误删除的时候再把数据恢复
回来。
On 8月5日, 上午9时53分, Lei Gu <jackf...@gmail.com> wrote:
> 我这个人比较愿意提一些反面意见，这里也说说我们的做法吧
> 1.
> 版本维护我们的要求是只修改一个配置文件，执行两三个命令脚本可以搞定所有服务器升级更新。我们大概9个分区，上百组服务器，具体服务器台数就不透露了。官方公布的维护时间两个小时，实际一个小时左右就可以维护完毕，然后QA上去检查检查，没有问题，可能提前半小时就开放了。
>
> 2.
> 关于BUG修正和风险控制，我们做法和大宝类似，以前老有人想通过版本控制来解决，我们觉得还是游戏内的开关最合适的，因为我们面临的问题是十个开发人员十个功能，最后你不确定哪些上线，哪些不上，基于版本控制的方法没法解决这个问题，而且上了线再发现问题，也于事无补。有了模块控制开关，就可以随时决定哪些功能开放还是关闭。
> 我们的动态热部署只局限于所有脚本和数据表，比如物品系统，任务系统，副本系统，NPC，怪物...所有配置全部脚本化，理论上都可以热部署。热部署的关键就是对策划进行规范，系统中的实体，只能添加修改，不能删除，防止出现意外。
>
> 3. 改进的地方
> 我觉得为运维提供的工具，除了考虑易用性，还要考虑如何避免运维的误操作导致重大过失，线上系统对一些硬件信息的监控（比如UPS掉电，机器硬件故障）。部署工具的原则就是不要相信任何人和机器，要能够把人和机器可能产生的影响降到最低。
>
> 2009/8/4 大宝 <sodme....@gmail.com>
liangyaotang
Lei Gu
hi Lei Gu:
看来你们的版本测试情况还是比较好的，可以作到比较稳定的发布版本，在你们的日常开发中，平均也是一周时间投放新内容吗？这些新内容涉及到的代码量和改
动量大不大？我想，如果内容比较多的话，QC可能比较难以在我们编码结束的同时也完成系统测试，一般我们是把各个系统的发布和制作时间进行交叉，一个开
发小组开发的内容，其制作与发布周期可能是两周左右，这样可以多留出一点时间来给QC测试，这是就目前而言。
另外就是新玩法的测试，我们的作法也是先投放到某一个服务器，观察一下，然后策划根据外服运营的实际情况可能再进行一些数值调整，然后再是投放到其它所
有服务器。
还有我比较感兴趣的是你们的热部署所覆盖的“所有脚本和数据表”，这里的“所有脚本”也包括逻辑代码吗，还是只包括使用脚本的数据配置？有没有包括一些
脚本层的动态对象呢？动态对象我们现在是没有考虑其对象的热更新方案的，已经创建的脚本动态对象。
关于运维和客服人员的误操作问题，在我们的实际工作中也会经常遇到，对于一些非常重要的操作，我们一般是不开放给一般的运维人员来作的。另外就是，对
于“删除”这样的操作，在很多系统的数据设计中，我们并不是直接从数据库中把数据抹掉，而只是打上了一个删除标记，这样可以在误删除的时候再把数据恢复
回来。
flywav
你们为什么不先预先编译好执行文件呢？
On 8月5日, 下午12时05分, "liangyaotang" <liangyaot...@gmail.com> wrote:
> 我来说说我参与的前期梦幻西游服务器的维护吧，当时的服务器没现在那么多，大概有300台这样吧，
> 可能现在的做法跟以前有所不同。
> 由于梦幻是时间收费游戏，所以维护的时间越长，降低的收入就越多。
> 曾经有人给我讲过这样一件事，有一次大话西游2的维护时间比较长，丁磊忍不住跳了出来，说你知道一个小时
> 要损失多少钱吗。所以，我们都尽量压缩每周例行的维护时间，目标是1个小时之内。经过相关同事的努力，
> 当时梦幻的维护时间都压缩到了1个小时之内。
> 下面简要说说当时的维护过程（几年前的事情，可能记得不是太清，大概如此）：
> 1、发送停机指令，所有服务器接收这个指令后，关掉相关的进程。（用crontab)
> 2、确认所有服务器停止服务后，负责数据库的同事处理数据库的维护事宜；
> 3、在发送停机指令的同时，我进行代码的合并，把工作版本的代码合并到运行版本的代码，编译代码，上传代码；
> 4、执行指令，把新的代码分发到各个服务器上面去。（sync，因为可以同时上传多台代码，一般都挺快，就是有些网通的机器慢一点）
> 5、检查确认代码都已经上传成功了，等待数据库维护完毕；
> 6、发送开机指令。几分钟内，所有的服务器都开启服务了。
> 以上的过程，如果顺利的话，多数情况下在半个小时内就完成了。
> 补充一下，我们当时的每周维护时间是周二早上8点，这是有好处的。之前是因为大话西游2的维护是周三，所以我我们选择了周二，
> 这样就不会一起进行维护，减少麻烦事情。其次是早上8点，在线的玩家差不多是最少的，影响的玩家少；再次，早上8点的网络是最
> 畅通的。
> 以上是每周例行维护的做法。至于平时游戏出现什么问题，在大多数的情况下，我们是可以进行在线的更新的，就是不停机进行代码的更新。
>
> > 无缝升级的本质问题当然就是中间数据的问题啦，最简单的例子就是session，放在数据库当然能解决啦，只是性能问题而已，不可能用户的移动坐标也放在数据库-吧
>
> > 真的只有电信才会对无缝升级要求非常非常高，所以erlang在这些领域很被看好
> > 但是如果网游，IM可以做到更好的无缝，对用户体验的提升也有帮助
> > 当然最后也就是性价比的问题了
>
> > 2009/8/4 Lei Gu <jackf...@gmail.com>:
>
> > > 1.
> > > 新老版本数据不兼容的话，让新老版本同时运行就是一个非常扯淡的事情，如果真的需要，不如单开一组测试服，不过国内玩家都不愿意当小白鼠，测试服大多是没人玩的-。
> > > 2.
> > > 版本切换的时间取决于你的中间状态保存在哪里，我见过中间状态完全存储在数据库和memcached的，版本升级可以做到瞬时切换，新版本服务器启动，前边的网-关改一下指向，立刻生效。只有那种策略类，24小时在线概念的游戏才真正需要这个吧，MMORPG之类，基本都没有这么平滑的升级。用户需要的是可预期的维护，-你说几点开始维护就几点开始，说维护多久就维护多久。
> > > 3.
> > > 热部署一定不单单是一种编程语言可以解决的，在设计开发阶段都需要进行相关的考虑。带来的麻烦事也是不少的。只有电信银行之类真正需要不间断服务的行业才会使用-这种成本很高的技术，网游没有这个不也活得好好的，魔兽的维护时间长的要命，也不影响他赚钱。
> > > 我觉得从运营，运维角度，开发少出故障，易部署的程序和工具就是最好的。运维，运营，客服包括制作团队自己大量的擦屁股的工作都是因为技术人员和策划的不靠谱，-不认真，导致的各种问题。技术人员应该极力降低复杂度，而不是引入复杂度。
> > > 2009/8/4 秦一 <qinchong...@gmail.com>
>
> > >> 服务器更新维护最理想的就是实现代码热部署，这个在erlang下很容易实现。
> > >> 但是在国内还没有看到在网游领域的erlang成功案例，但前几天在51job上已经看到有公司在尝试用erlang构建游戏服务端。- 隐藏被引用文字 -
>
> - 显示引用的文字 -
liangyaotang
大宝(sodme)
On 8月6日, 上午9时21分, "liangyaotang" <liangyaot...@gmail.com> wrote:
> 首先是，更新的周期短，一个星期更新一次，周一才进行测试，只能在周二才进行代码合并等工作（除非愿意在周一加班)。
> 其次是，合并代码、编译代码、上传代码的时间比较短的，可以在10几分钟内搞定。
> 更重要的是，这样做简单可行，不会出错。
> 其实，没有固定的模式的，按照自己的实际去做就没错了。
>
> 2009-08-06
>
> liangyaotang
liangyaotang
Lei Gu
liangyaotang
flywav
On 8月6日, 下午6时08分, "liangyaotang" <liangyaot...@gmail.com> wrote:
> 有点夸张，不过不离谱，呵呵。
> 脚本的编译而已。不过就算是底层引擎的编译，也很快，时间单位也是以秒计算的。
> 由此可以看出，梦幻的引擎是一个多么轻量化的设计。
>
> 2009-08-06
>
> liangyaotang
>
> 发件人： Lei Gu
> 发送时间： 2009-08-06 17:53:48
> 收件人： dev4server
> 抄送：
> 主题： Re: Re: 聊聊服务器维护
>
> C/C++的项目编译几秒钟，很难想象呀
>
> 2009/8/6 liangyaotang <liangyaot...@gmail.com>
>
> 也不早，至多3年前。其实，编译那些代码，不用几秒钟。
>
> 2009-08-06
>
> liangyaotang
christanxw
On 8月4日, 上午11时56分, Lei Gu <jackf...@gmail.com> wrote:
> 1.
> 新老版本数据不兼容的话，让新老版本同时运行就是一个非常扯淡的事情，如果真的需要，不如单开一组测试服，不过国内玩家都不愿意当小白鼠，测试服大多是没人玩的-。
>
> 2.
> 版本切换的时间取决于你的中间状态保存在哪里，我见过中间状态完全存储在数据库和memcached的，版本升级可以做到瞬时切换，新版本服务器启动，前边的网-关改一下指向，立刻生效。只有那种策略类，24小时在线概念的游戏才真正需要这个吧，MMORPG之类，基本都没有这么平滑的升级。用户需要的是可预期的维护，-你说几点开始维护就几点开始，说维护多久就维护多久。
>
> 3.