停机优化 - 保持游戏DAU的4个技巧
停机优化 - 保持游戏DAU的4个技巧
以游戏运维的视角，从“更新优化（让玩家快速进入游戏）”的角度来解读保持游戏DAU的技巧。更新优化
首先介绍停机优化，看我们是如何把一款国内排名前3的端游停机维护时间从1.5小时优化到0.3小时。
一、背景介绍
端游停机维护是游戏的业务运维负责，定期的停机维护本身是枯燥的。为了不那么寂寞，我们有着一颗“每次都比上一次好一点”的心。每次维护后都输出总结，总结踩过的坑，思考可以提升的点。 就这样，经过数十次的维护变更，我们把停机维护的维护时间从1.5小时优化到0.3小时。同时总结了一套提升停机维护效率的经验。
这个经验不仅仅适用端游停机维护，同样适用手游、Web、ERP等环境的停机维护和变更。
二、停机优化（1.5小时→0.3小时）
接下来将从“流程优化”和“重命名式更新方式”来两个维度解读。
2.1 流程优化
以前我们游戏的停机维护时间差不多是1.5小时，后来我们对着维护的CHECKLIST，在思考，这一步为什么要放在停机的关键路径里，我能否把他放到停机前10分钟完成呢？或者是我能否推迟到开服后再去做一些检查项呢？
Checklist是停机维护前梳理的本次停机维护操作的事项，执行时严格按照次序执行，最简单的Checklist是基于EXCEL，好一点是把Checklist线上化，再好一点是有一套自由编排的停机维护系统，流程走到那一步时自动执行对应的操作。
2.1.1 剖析停机关键路径
剖析原来停机期间的关键步骤，以节省停机时间为目的，将可以提前做的事情（如提前变更配置）和延后做的事情（如版本校验）脱离出停机流程。
以下是流程优化前后停机关键路径的变化
来看一个动画版的，更生动一些
可以看到之前很多在停机关键路径的步骤分离到停机前关键路径 和 停机后关键路径。
就是这样一个小的手术，我们来看看每个环节都节省了多少时间。
2.1.2 收益对比
以下是我们梳理的每个环节节省的停机时间
总的来看，通过流程优化，我们把原来的停机维护时间从 1.5小时优化成0.5小时。
经过流程优化之后，发现停机维护还需要半小时，还能不能再快一些呢？
2.2 重命名式更新
我们原来的服务器补丁更新方式是类似cp的方式，这种方式会真的复制十几 G的游戏资源文件，非常恐怖。除了慢以外，几千台服务器并发执行时，经常有几百台因为I/0问题，无法及时响应执行结果。
2.2.1 为什么不用mv的方式呢？
众所周知，在操作系统中，对目录名的修改（MOVE）只是在文件系统中改个名而已，数据块本身不会修改。而对目录或文件的复制（COPY）会切切实实的修改对应的数据块，会耗用很大的I/O资源。 要知其所以然，所以我们要再深入一些。
2.2.1.1 Linux平台对目录的MV 和 CP的差别
我们先来做一个对10G文件cp和mv的耗时测试，算了下差不多是3万倍
为什么相差这么大呢？ 这个要说说的Linux的文件系统。
对于cp来说，inode和对应的data blocks都会重新创建，而mv仅在目录中修改对应的名称而已，inode不会变。
（注：ls –i可以查看文件的inode，上图可以看到cp会改变inode，mv不会）
原因是目录中保存inode和文件名的对应关系。（详见Wikipedia的Inode）
于是我用组合命令展示这个对应关系的结构应该是这样的
来看看专业文档（ file system internals）中的图是怎么样的
反正有时间，接着在展开一下。刚刚我们在查看目录时发现有. 和 .. 文件（Linux中目录也看作是文件），目录的硬链接数和这个也有关系。
ls 命令的-l参数结果中有一项是硬链接数
这个在stat中找到（详细在Wikipedia的Hard link ）
由于指向同一个文件的所有硬链接inode号是一样，我们通过实验来论证这一点。
简单看，你创建一个目录，他的硬链接数是2，在这个目录下创建1级子目录，该目录的硬链接会+1 ，看起来是一个目录的硬链接是一级子目录数量+2.（小声说，这个是我猜的，没找到官网说明。另外这个是在不允许目录创建硬链接的前提下，Wikipedia的Hard link提到现代的操作系统不允许目录创建软链接，但UNIX System V是可以的）
说完目录是inode 和 文件名的对应表后，我们再扩展1个小知识。
如何删除文件名是乱码的文件？
那我们可以找到它对应的inode号，然后用find删除他
好吧，这里只是简单概述，大家想深入的话，可以了解Linux的文件系统。
扩展阅读：
(1) debugfs恢复linux下删除文件（debugfs配合dd命令）
(2) inode在内核中定义的structure
(3) 硬盘的结构原理
2.2.1.2 Windows平台对目录的MV和CP的差别
Windows平台也非常类似，以NTFS文件系统为例。
“NTFS文件系统中，目录的名字存储在MFT(主文件表)中的File Name Attribute (FN)里，所以在同一个文件系统（通俗的讲，就是分区，D盘、E盘）内，修改目录的名字不会进行真正数据区的变动，秒级可以完成。
说完两个平台里对目录改名在文件系统中的变化后，我们来看看在停机维护中如何利用这个特性呢。
2.2.2 停机维护前的准备操作
停机维护前，把当前运行的业务目录CURRENT rsync同步到临时目录OLD，再把更新补丁覆盖到临时目录OLD，之后改名为NEW（就是明天要发布的版本目录）
2.2.3 停机维护时的重命名操作
停机维护时，只需一个重命名的操作。
把业务目录CURRENT改名为OLD，NEW改为CURRENT。
So easy！
动画版的，可能更容易理解
2.2.4 效率提升8倍
停机维护时单台服务端补丁的更新只需要1秒.原来可是需要20分钟。
由于几千台服务器更新存在3分钟左右的队列时间。所以实际的服务端补丁更新时间从25分钟降到了3分钟，效率提升了8倍。
三、方法论沉淀
漂亮的搞定问题后，我们需要静下来思考，是否能有方法论可以沉淀。
“流程优化”，我们在游戏运营规范里要说明，让业务运维详尽分析你的停机维护CHECKLIST，去思考这些步骤为什么一定要在停机时完成，能否变通的把他放到停机前完成，又或是停机后。
“重命名式更新”，我们在游戏运营规范里要说明，你的更新方式是否是最优的，耗时最少的。能否在更新前就已经准备好。
我们不能一味的只是完成停机维护操作本身，否则难以体现运维的价值。我们不要做搬运工。
停机优化，通过“流程优化”和“重命名式更新”，我们把停机维护的时间从1.5小时蜕变成0.3小时。不过，你以为仅仅这些就可以保持游戏的DAU（每日活跃人数）了吗？
仔细想想，玩家他要更新客户端啊，这部分的用户体验我们也要考虑，为了DAU.
预知后事如何，请听下回分解。
后事预告
1、预下载
让玩家在停机发布日无需下载补丁包，这是多么爽的体验。
2、特权加速
升级的差异化服务，全新的升级体系，让大R玩家的升级体验更棒！
3、跨版本升级
玩家2个月未升级客户端？让他坐上直通车，直达最新版本。
朱志武 腾讯游戏高级运维工程师
2013年入职腾讯，一直负责游戏的运维工作。关注用户体验以及对运维工作的知识沉淀，爱好骑行、街舞、钓鱼。