停机维护时长缩短5倍，全靠这3个秘诀

《停机维护时长缩短5倍，全靠这3个秘诀》要点：
本文介绍了停机维护时长缩短5倍，全靠这3个秘诀，希望对您有用。如果有疑问，可以联系我们。

作者：朱志武

腾讯游戏高级运维工程师,腾讯学院讲师.2013年入职腾讯,专注游戏的运维工作,关注用户体验以及对运维工作的知识沉淀.

只需3步,看我们是如何把一款国内排名前3的端游停机维护时间从1.5小时优化到0.3小时.

1、背景介绍

端游的停机维护是游戏的业务运维负责,定期的停机维护本身是枯燥的.

为了不那么寂寞,我们有着一颗“每次都比上一次好一点”的心.每次维护后都输出总结,总结踩过的坑,思考可以提升的点.

就这样,经过数十次的维护变更,我们把停机维护的维护时间从1.5小时优化到0.3小时.同时总结了一套提升停机维护效率的经验.

这个经验不仅仅适用端游的停机维护,同样适用手游、Web、ERP等环境的停机维护和变更.

2、停机优化(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倍.

 

3、方法论沉淀

漂亮的搞定问题后,我们需要静下来思考,是否能有方法论可以沉淀.

流程优化,我们在游戏运营规范里要说明,让业务运维详尽分析你的停机维护CHECKLIST,去思考这些步骤为什么一定要在停机时完成,能否变通的把他放到停机前完成,又或是停机后.

“重命名式更新”,我们在游戏运营规范里要说明,你的更新方式是否是最优的,耗时最少的.能否在更新前就已经准备好.

我们不能一味的只是完成停机维护操作本身,否则难以体现运维的价值.我们不要做搬运工.

停机优化,通过“流程优化”和“重命名式更新”,我们把停机维护的时间从1.5小时蜕变成0.3小时.相信你也可以,赶紧行动吧!

文章出处：高效运维

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4477.html