《在復雜業務體系中DevOps理論及方法的實踐》要點：
本文介紹了在復雜業務體系中DevOps理論及方法的實踐，希望對您有用。如果有疑問，可以聯系我們。

作者簡介

胥峰
《Linux運維最佳實踐》作者、《DevOps：軟件架構師行動指南》譯者
2006年畢業于南京大學,2011年加入盛大游戲,十年運維經驗,曾參與盛大游戲多款大型端游和手游的上線運維,主導統一運維平臺的產品功能設計和實施,擁有工信部認證高級信息系統項目管理師資格.《Linux運維最佳實踐》作者、《DevOps：軟件架構師行動指南》譯者.

前言

本文來自于 GOPS 2017 深圳站的演講“在復雜業務體系中 DevOps 理論及方法的實踐”.分享分為 4 個方面：

• 初識 DevOps；
• 建構組織文化；
• 架構技術體系；
• 案例研究；

1、初識 DevOps

對 DevOps 有這樣一個解釋：“ DevOps 是一套實踐方法,在保證高質量的前提下,縮短從提交對系統的變更到部署到生產環境的時間”,這是引用了我翻譯的這本書里的概念.我們看一下這個概念里有哪些值得注意的關鍵點：

1. 我們在部署系統的時候,質量是非常重要的.我們部署的系統,你不能因為變更的問題導致業務中斷,這是不可接受的問題.
2. 要求交付機制也是高質量的,就是你的交付過程.比如說你交付到測試環境,交付到生產環境里面,也應該是一個高質量的.
3. 在里面規劃了兩個時間周期：一是開發完成的時間；第二是把代碼開發完成到部署到線上的時間.
4. 在這個定義里面強調了 DevOps 是一種以目標作為導向的,它并沒有強調我們采取什么樣的形式的實踐,或者使用什么樣的工具.
5. 目標并不限于 DevOps 用于測試和部署的實踐,它其實是把整個流程都包含在里面.

我們看到在 DevOps 的定義里面,最主要的一點還是講到從代碼開發完成到上線的過程.這也是行業內對 DevOps 理解比較多的一點.

這個圖來自企業 DevOps 白皮書,這是對 DevOps 理解的一個擴展.相對于前面說的那個概念,它講到從開發到部署的過程,但是在這個圖里我們可以看到,它其實是把流程進行了前置和延伸.

比如說計劃、需求、設計,以及后面的運維過程,它都把它納入到 DevOps 流程里面去了.這其實是講一個什么東西呢?一個產品或者一個業務有了想法之后,它就會進行下面這樣的流程,從這個圖里面我們看到,它強調的是價值交付的過程.

從產品和業務來講,它開始有些想法在里面,怎么通過技術手段、流程,快速的把這個想法變成一個產品,變成在實際場景中投放給客戶的產品,這是一個價值流的過程.

只有當你的想法真正投入到里面去的時候,它才產生價值,你做的計劃也好,你做的開發代碼也好,在沒有投放到生產之前,其實對用戶來講是沒有任何意義的.

上面這部分主要是講這個流程,在下面我們可以看到,其實它核心的理論支撐是精益和豐田生產系統.我們在整個流程中需要非常關注的一點就是持續改進的過程,不管我們現在的流程是什么樣的,或者說你已經做到什么地步了,其實都是有一些可以改進的方向,包括這個精益也是告訴我們要持續不斷地做一些改進.

2、建構組織文化

在這里面我想強調一點,不管 DevOps 的定義是什么,它都是一個價值流的交付.從產品或者是業務的想法開始,把它快速地、高質量的交付給用戶.但是在實現 DevOps 的過程中,很重要的一點是文化.不管組織的類型是什么,大部分組織都是懼怕變化的,所以采用 DevOps 這個新方法論可能是極具挑戰的.

在構建組織文化的過程中,需要關注三個主要的原則：溝通、協作、集成.在這里面要強調一點,我們現在各個部門在協作過程中,可能還存在一些部門利益沖突的問題,這也是一個很現實的問題.

另外一個就是我們要倡導一種免責文化,大家都說運維背黑鍋,這個其實是不對的,關鍵的一點是我們是以價值流交付作為一個整體的目標,倡導一種對事不對人的工作態度.

我們在構建組織文化過程中要注意四個方面：

第一是團隊內的協作；

第二是團隊之間的親和性；

第三是要使用一定的工具來加速流程的落地；

第四是伸縮性,隨著組織規模的擴大, DevOps 流程也要做相應的變化,

大家想想在我們的組織內部,是不是有這樣的一些問題,我們在傳統的開發、測試、運維過程中是什么樣的情況?開發把代碼丟給測試去測,測試測好之后,又把這個包丟給運維部署到現場,中間可能有相關的文檔,這本身就是一種筒倉思維的表現.

筒倉思維的英文叫 Silo,它就像是在沙漠里面,或者是大型的場地里面有這樣一個個存儲物品的倉庫,每一個都是獨立、封閉的個體,它們之間是沒有溝通的,它們的利益也都是有沖突的.

這里講一個小故事,我們原來有一個同事是來自國企的,他是做財務的.有一天他跟他的領導說,我們現在很多的工作還是手動的,我們是不是可以引入一些自動化的計算機系統來做這些事情?領導就問他,這樣做有什么好處呢?他說,我們可以節省很多人力.

領導說,節省人力不行,你節省人力了,我這事就沒有人管了.大家有沒有理解這個意思?就是說在體制內,領導比較關注他的權力的分配,而不是說從整體角度提高工作效率.

還有一個與之類似的例子,在上海有一家基金公司,我有個同事去那里應聘,當然級別也比較高,他發現他們在部署的時候還是手工去部署的,有幾個同事專門做部署的工作.

他就想去推動這些自動化部署的工具,但是他的領導說,我們還是要手工去布,這樣的話領導才會重視我這一塊,你全自動化了,把我隱藏起來了,我這個經理就沒用了,這就是很明顯的筒倉思維.

包括我們在運營一些產品或者業務的時候會發現,開發和運維之間互相踢皮球的事情,這也是一種筒倉思維.比如說開發肯定是要求快速上線,而運維要求穩定,大家的利益產生了沖突,這必然會對我們的價值流產生負面的作用.大家可以想想我們生活中或者是在工作里面是否也有這樣的筒倉思維的表現.

我們在構建 DevOps 的過程中,必須要打破這種筒倉,形成合力,讓大家圍繞價值流一致的目的共同努力.

3、架構技術體系

在構建組織文化過程中有三點：溝通、協作、集成.集成肯定是一種自動化集成,而不是說手工對接的過程.這就要求我們在開發、測試和運維整個鏈條里面,在每個環節上要能實現一定程度的自動化,不能說沒有對應的運維自動化系統來對接前面的需求,完全是通過公開的形式去做發布、部署,其實是不符合快速交付這樣一個理念的.

關于自動化運維這一塊,我可以簡單說一下我們盛大游戲是怎么做的.大家知道盛大游戲目前是國內比較領先的游戲發行公司,它創立的時間比較早,在1999年這個公司就成立了,到目前已經有18年的歷史.

它現在面臨的問題,在運營方面主要表現為幾個：一是服務器操作系統異構；另外一個是我們的服務器數量特別多,在高峰期的時候,我們的服務器達到2萬臺的規模.

因為每一個游戲代理過來的時候,游戲的開發商(比如說美國、韓國、日本)服務器的偏好不一樣,面對這樣的挑戰,我們在實現自動化集成的過程中,我們是怎么構建自動化運維平臺的呢?

從這個圖可以看到,我們有一臺中央控制機器,它從 CMDB 里面讀寫數據,根據不同的服務器的類型和操作內容,把這個命令分發到對應的服務器上面去.

我們可以看一下這里面的幾個特點：

第一,我們這個平臺是采用 BS 架構的,不需要在電腦上裝軟件,現在在家里都可以操作,完成這個運維任務；

第二,我們使用的是通用的協議來管理著所有的異構系統,比如說我們在 windows 下面,大家知道以前管理 windows 是比較困難的,現在有很多公司在這一塊也是依靠手工去操作的,這樣會很麻煩,也有可能造成一些遺漏或者是錯誤的過程.

對于 windows 管理,我們也是采用了 SSH 的方法去做,這樣就可以讓所有服務器以相同的方式管理起來,比如說它們的安全策略,公鑰和私鑰的管理,另外還有一些審計,都可以內置在這個操作平臺里面.

關于自動化運維平臺這一塊,還要注意做一些并發的設置,以及超時和重試的機制,都需要考慮到里面去,不能因為一些順序的執行,某臺服務器的故障,或者是連接服務器的問題,導致它無法連接,導致整個任務延遲.

現在我們在做另外一個系統是作業編排系統,如果知道 Ansible ?playbooks 的話,可以看一下它的方式和方法.我們知道 playbooks 是通過聲明一些配置項,然后把它編排起來,把所有的人工分類的步驟做進一個配置里面,讓它順序執行.

比如說我們做游戲維護的時候：

第一步,是先把服務器上的游戲服停掉；

第二步,停數據庫；

第三步,更新程序；

第四步,還要更新數據庫的一些表結構；

第五步,把前面的游戲服務器啟動起來,或者數據庫啟動起來；

通過一些作業編排,就能更大地減少這個運維的重復勞動的過程,它的理念其實是基于場景的自動化運維.我們可以想想在運維過程中有哪些工作可以串聯起來,這樣你就不需要對著一個文本的東西去做,因為你在對著它做的過程中很容易造成遺漏.

比如說你做游戲維護的時候,沒有把前面的關閉,你就直接維護數據庫了,這時候可能會導致玩家數據丟失的情況.通過 playbook 編排系統,就可以避免這個事情,它是固化的,沒有辦法繞過前面的步驟去進行后面的操作.

4、案例研究

剛剛說過,大家在不同的行業里面,在不同的業務里面,它對應的發布方式還不一樣,我相信目前我們在座的,系統里面也有一些人是用手工發布的方法上線.我知道一個比較大的公司,它的部署也是很落后的方式,因為它前面有負載均衡,它布的時候還是要登一些腳本,把負載均衡上的東西剔除,然后再更新,它需要更新多個腳本,這是很浪費時間和精力的過程.

 

看看我們以前面臨的問題.這是我們的某個平臺,主要是支付相關的.大家知道我們除了游戲服務器之外,還有相關的登錄、認證和計費的平臺.我們第一個選取的案例是在支付平臺這邊做的一些 DevOps 實踐.

隨著公司業務的發展,日積月累,你這個模塊可能會越來越多,部署了之后會有測試,測試了之后交給運維,但是測試的模塊名和運維的模塊名可能是不一樣的,這里面存在一個協調的問題.因為有人工協調的過程,不然導致這個部署需要排期,原來部署和測試系統是割裂的,它們之間沒有對應的關系.

?

我們是怎么改進的呢?現在已經做的工作是：

• 第一,我們建立在部署流水線上不同環節的模塊對應關系,首先把它映射好.比如說測試和運維這邊的部署系統,它們之間的對應關系要映射到數據庫里面去,這樣就可以實現從前端出發的部署動作.
• 第二,后端的部署系統,它需要提供對應的功能接口.比如說它需要上游的系統提供一個模塊對應哪些服務器的接口,當上游需要部署某個模塊的時候,它就知道在測試環境里面需要部署哪些服務器,在正式環境,灰度發布的時候需要先部署哪些,再部署哪些.
• 第三,建立對應的授權機制,我們可以把部分模塊的授權前置給開發上線,或者是由運維從內部平臺直接部署上線,取得的效果是非常明顯的.在2016年12月份的時候我們做了一個統計,當時有900多次的部署,其中50%以上通過新平臺自動部署,大約10%的模塊可以由開發自主上線,不涉及到核心功能的,開發簡單測試一下就直接上去了.非核心模塊的部署,我們可以在5分鐘內完成,不再需要一些配置管理員進行上線的排期和編排.

這是我們部署的系統的界面,它會選擇對應的版本,選擇你是灰度發布,還是部署到生產環節里面,這個動作很多情況下已經不需要運維去做了,直接測試完成之后就可以上線了,這時候就把運維的工作解放出來了.

這是我們的部署過程,對于自動部署,銀行和金融機構有要求,開發和運維要分離,我們現在做的是讓開發和測試都可以上線.

我們的底層部署是通過配置一些項目,比如說模塊對應的目錄、配置文件、執行腳本,對應的用戶,這個用戶主要是指啟動程序時的用戶,以及對應的某個模塊在不同的服務器上的IP列表,這些都會在系統里面進行相關的配置,這樣配置之后就可以對前面的系統進行相關調用.

這個案例也告訴我們一點,我們在進行部署設計的時候,暗含了對架構的要求.

這里簡單介紹三點：

• 第一,模塊化,可獨立部署,微服務有一個類似的概念.如果你是一個大一統的體系,你很難集中發布這個東西,你還要協調很多資源,如果你做成模塊化,你自己上線,不影響他人,通過接口去調用,對自動部署是非常有好處的；
• 第二,重試機制.作為一些后端的服務,它在部署的時候,不應該影響前端的調用服務,前端的調用服務必須有一些重試機制,失敗的時候要能夠重連,這應該集成在調用方的架構設計里面,如果沒有重試機制,肯定是會影響業務的,這也沒辦法達到高質量交付的目的；
• 第三,負載均衡與多實例的應用.這里也講到,如果你的某一個功能只有一個模塊,你在部署的時候,不管它的時間窗口是什么,你必然會影響業務,有些請求會丟掉或者是失敗.通過負載均衡和多實例的方法,就可以包括你在部署部分服務器的時候不影響前面調用的結果.

總結

DevOps 的目的是打造持續增量的價值流并杜絕浪費.我曾經有一句話「任何不以消除浪費為目的的 DevOps 實踐都是假的 DevOps」,我們實踐 DevOps 的目的,是實現從一個想法到真正把這個想法形成產品、形成服務,提供給用戶去用的流程.

縮短這個過程的時間,提高這個過程的效率是 DevOps 實踐的一個最重要的目的.我們要讓每一個步驟,每一個過程的價值都是遞增的,而不是說產生等待,或者說產生依賴,比如對配置管理的依賴,對人員的依賴,這都是有悖于這個目的的.

所以我把這句話送給大家：DevOps 的目的,最重要的一點就是加速高質量的交付,提升用戶價值.但是在實踐過程中,我們可以從各個子環節的自動化流程作為一個起點,很多時候你可能沒辦法一次性把整個部署流水線構建那么完美,我們就可以分析是不是在每個子環節里面已經實現了足夠程度的自動化.

比如說自動化發布,現在是不是還是要靠人工去操作,這些是最基本的動作,做好這些之后,你才有能力或者有條件和上下游進行對接.只有完成的每個環節的自動化之后,我們才有可能去構建整個部署流水線.

也就是說我們在落地的時候可以想想整個業務流程里面的痛點,比如說你是部署沒有完成自動化,還是測試沒有完成自動化,導致了這個流水線沒有辦法流傳下去.然后以每個環節的自動化作為一個開始,然后把它們集成起來,就可以實現整個價值流的快速交付.

文章來自微信公眾號：高效運維

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/2724.html