《停機維護時長縮短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.fzlkiss.com/jiaocheng/4477.html