《停機(jī)維護(hù)時長縮短5倍，全靠這3個秘訣》要點：

本文介紹了停機(jī)維護(hù)時長縮短5倍，全靠這3個秘訣，希望對您有用。如果有疑問，可以聯(lián)系我們。作者：朱志武

騰訊游戲高級運維工程師,騰訊學(xué)院講師.2013年入職騰訊,專注游戲的運維工作,關(guān)注用戶體驗以及對運維工作的知識沉淀.

只需3步,看我們是如何把一款國內(nèi)排名前3的端游停機(jī)維護(hù)時間從1.5小時優(yōu)化到0.3小時.

1、背景介紹

端游的停機(jī)維護(hù)是游戲的業(yè)務(wù)運維負(fù)責(zé),定期的停機(jī)維護(hù)本身是枯燥的.

為了不那么寂寞,我們有著一顆“每次都比上一次好一點”的心.每次維護(hù)后都輸出總結(jié),總結(jié)踩過的坑,思考可以提升的點.

就這樣,經(jīng)過數(shù)十次的維護(hù)變更,我們把停機(jī)維護(hù)的維護(hù)時間從1.5小時優(yōu)化到0.3小時.同時總結(jié)了一套提升停機(jī)維護(hù)效率的經(jīng)驗.

這個經(jīng)驗不僅僅適用端游的停機(jī)維護(hù),同樣適用手游、Web、ERP等環(huán)境的停機(jī)維護(hù)和變更.

2、停機(jī)優(yōu)化(1.5小時→0.3小時)

接下來將從“流程優(yōu)化”和“重命名式更新方式”兩個維度來解讀.

2.1 流程優(yōu)化

以前我們游戲的停機(jī)維護(hù)時間差不多是1.5小時,后來我們對著維護(hù)的CHECKLIST,在思考:

這一步為什么要放在停機(jī)的關(guān)鍵路徑里,我能否把他放到停機(jī)前10分鐘完成呢?

或者是我能否推遲到開服后再去做一些檢查項呢?

Checklist是停機(jī)維護(hù)前梳理的本次停機(jī)維護(hù)操作的事項,執(zhí)行時嚴(yán)格按照次序執(zhí)行,最簡單的Checklist是基于EXCEL,好一點是把Checklist線上化,再好一點是有一套自由編排的停機(jī)維護(hù)系統(tǒng),流程走到那一步時自動執(zhí)行對應(yīng)的操作.

2.1.1 剖析停機(jī)關(guān)鍵路徑

剖析原來停機(jī)期間的關(guān)鍵步驟,以節(jié)省停機(jī)時間為目的,將可以提前做的事情(如提前變更配置)和延后做的事情(如版本校驗)脫離出停機(jī)流程.

以下是流程優(yōu)化前后停機(jī)關(guān)鍵路徑的變化

來看一個動畫版的,更生動一些

可以看到之前很多在停機(jī)關(guān)鍵路徑的步驟分離到停機(jī)前關(guān)鍵路徑和停機(jī)后關(guān)鍵路徑.

就是這樣一個小的手術(shù),我們來看看每個環(huán)節(jié)都節(jié)省了多少時間.

2.1.2 收益對比

以下是我們梳理的每個環(huán)節(jié)節(jié)省的停機(jī)時間

總的來看,通過流程優(yōu)化,我們把原來的停機(jī)維護(hù)時間從 1.5小時優(yōu)化成0.5小時.

經(jīng)過流程優(yōu)化之后,發(fā)現(xiàn)停機(jī)維護(hù)還需要半小時,還能不能再快一些呢?

2.2 重命名式更新

我們原來的服務(wù)器補(bǔ)丁更新方式是類似cp的方式,這種方式會真的復(fù)制十幾 G的游戲資源文件,非?？植?

除了慢以外,幾千臺服務(wù)器并發(fā)執(zhí)行時,經(jīng)常有幾百臺因為I/0問題,無法及時響應(yīng)執(zhí)行結(jié)果.

2.2.1 為什么不用mv的方式呢?

眾所周知,在操作系統(tǒng)中,對目錄名的修改(MOVE)只是在文件系統(tǒng)中改個名而已,數(shù)據(jù)塊本身不會修改.

而對目錄或文件的復(fù)制(COPY)會切切實實的修改對應(yīng)的數(shù)據(jù)塊,會耗用很大的I/O資源.

要知其所以然,所以我們要再深入一些.

2.2.1.1 Linux平臺對目錄的MV 和 CP的差別

我們先來做一個對10G文件cp和mv的耗時測試,算了下差不多是3萬倍.

為什么相差這么大呢? 這個要說說Linux的文件系統(tǒng).

對于cp來說,inode和對應(yīng)的data blocks都會重新創(chuàng)建,而mv僅在目錄中修改對應(yīng)的名稱而已,inode不會變.

(注：ls –i可以查看文件的inode,上圖可以看到cp會改變inode,mv不會.)

原因是目錄中保存inode和文件名的對應(yīng)關(guān)系(詳見Wikipedia的Inode).

于是我用組合命令展示這個對應(yīng)關(guān)系的結(jié)構(gòu)應(yīng)該是這樣的:

反正有時間,接著在展開一下.剛剛我們在查看目錄時發(fā)現(xiàn)有. 和 .. 文件(Linux中目錄也看作是文件),目錄的硬鏈接數(shù)和這個也有關(guān)系.

ls 命令的-l參數(shù)結(jié)果中有一項是硬鏈接數(shù)：

這個在stat中找到(詳細(xì)在Wikipedia的Hard link ).

由于指向同一個文件的所有硬鏈接inode號是一樣,我們通過實驗來論證這一點.

簡單看,你創(chuàng)建一個目錄,他的硬鏈接數(shù)是2,在這個目錄下創(chuàng)建1級子目錄,該目錄的硬鏈接會+1 ,看起來是一個目錄的硬鏈接是一級子目錄數(shù)量+2.(小聲說,這個是我猜的,沒找到官網(wǎng)說明.)

另外這個是在不允許目錄創(chuàng)建硬鏈接的前提下,Wikipedia的Hard link提到現(xiàn)代的操作系統(tǒng)不允許目錄創(chuàng)建軟鏈接,但UNIX System V是可以的).

說完目錄是inode 和 文件名的對應(yīng)表后,我們再擴(kuò)展1個小知識.

如何刪除文件名是亂碼的文件?

那我們可以找到它對應(yīng)的inode號,然后用find刪除他.

好吧,這里只是簡單概述,大家想深入的話,可以了解Linux的文件系統(tǒng).

擴(kuò)展閱讀：

(1) debugfs恢復(fù)linux下刪除文件(debugfs配合dd命令)

(2) inode在內(nèi)核中定義的structure

(3) 硬盤的結(jié)構(gòu)原理

2.2.1.2 ?Windows平臺對目錄的MV和CP的差別

Windows平臺也非常類似,以NTFS文件系統(tǒng)為例.

NTFS文件系統(tǒng)中,目錄的名字存儲在MFT(主文件表)中的File Name Attribute (FN)里,所以在同一個文件系統(tǒng)(通俗的講,就是分區(qū),D盤、E盤)內(nèi),修改目錄的名字不會進(jìn)行真正數(shù)據(jù)區(qū)的變動,秒級可以完成.

說完兩個平臺里對目錄改名在文件系統(tǒng)中的變化后,我們來看看在停機(jī)維護(hù)中如何利用這個特性呢.

2.2.2 停機(jī)維護(hù)前的準(zhǔn)備操作

停機(jī)維護(hù)前,把當(dāng)前運行的業(yè)務(wù)目錄CURRENT rsync同步到臨時目錄OLD,再把更新補(bǔ)丁覆蓋到臨時目錄OLD,之后改名為NEW(就是明天要發(fā)布的版本目錄).

2.2.3 停機(jī)維護(hù)時的重命名操作

停機(jī)維護(hù)時,只需一個重命名的操作.

把業(yè)務(wù)目錄CURRENT改名為OLD,NEW改為CURRENT.

So easy!

動畫版的,可能更容易理解.

2.2.4 效率提升8倍

停機(jī)維護(hù)時單臺服務(wù)端補(bǔ)丁的更新只需要1秒,原來可是需要20分鐘.

由于幾千臺服務(wù)器更新存在3分鐘左右的隊列時間,所以實際的服務(wù)端補(bǔ)丁更新時間從25分鐘降到了3分鐘,效率提升了8倍.

3、方法論沉淀

漂亮的搞定問題后,我們需要靜下來思考,是否能有方法論可以沉淀.

流程優(yōu)化,我們在游戲運營規(guī)范里要說明,讓業(yè)務(wù)運維詳盡分析你的停機(jī)維護(hù)CHECKLIST,去思考這些步驟為什么一定要在停機(jī)時完成,能否變通的把他放到停機(jī)前完成,又或是停機(jī)后.

“重命名式更新”,我們在游戲運營規(guī)范里要說明,你的更新方式是否是最優(yōu)的,耗時最少的.能否在更新前就已經(jīng)準(zhǔn)備好.

我們不能一味的只是完成停機(jī)維護(hù)操作本身,否則難以體現(xiàn)運維的價值.我們不要做搬運工.

停機(jī)優(yōu)化,通過“流程優(yōu)化”和“重命名式更新”,我們把停機(jī)維護(hù)的時間從1.5小時蛻變成0.3小時.相信你也可以,趕緊行動吧!

文章出處：高效運維

總結(jié)

以上是生活随笔為你收集整理的php性能提升5倍的秘诀,停机维护时长缩短5倍，全靠这3个秘诀的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。