在複雜業務體系中DevOps理論及方法的實踐
作者簡介
胥峰
《Linux運維最佳實踐》作者、《DevOps：軟體架構師行動指南》譯者
2006年畢業於南京大學，2011年加入盛大遊戲，十年運維經驗，曾參與盛大遊戲多款大型端遊和手遊的上線運維，主導統一運維平臺的產品功能設計和實施，擁有工信部認證高階資訊系統專案管理師資格。《Linux運維最佳實踐》作者、《DevOps：軟體架構師行動指南》譯者。
前言
本文來自於 GOPS 2017 深圳站的演講“在複雜業務體系中 DevOps 理論及方法的實踐”。分享分為 4 個方面：
- 初識 DevOps；
- 建構組織文化；
- 架構技術體系；
- 案例研究；
1、初識 DevOps
對 DevOps 有這樣一個解釋：“ DevOps 是一套實踐方法，在保證高質量的前提下，縮短從提交對系統的變更到部署到生產環境的時間”，這是引用了我翻譯的這本書裡的概念。我們看一下這個概念裡有哪些值得注意的關鍵點：
- 我們在部署系統的時候，質量是非常重要的。我們部署的系統，你不能因為變更的問題導致業務中斷，這是不可接受的問題。
- 要求交付機制也是高質量的，就是你的交付過程。比如說你交付到測試環境，交付到生產環境裡面，也應該是一個高質量的。
- 在裡面規劃了兩個時間週期：一是開發完成的時間；第二是把程式碼開發完成到部署到線上的時間。
- 在這個定義裡面強調了 DevOps 是一種以目標作為導向的，它並沒有強調我們採取什麼樣的形式的實踐，或者使用什麼樣的工具。
- 目標並不限於 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 的目的，最重要的一點就是加速高質量的交付，提升使用者價值。但是在實踐過程中，我們可以從各個子環節的自動化流程作為一個起點，很多時候你可能沒辦法一次性把整個部署流水線構建那麼完美，我們就可以分析是不是在每個子環節裡面已經實現了足夠程度的自動化。
比如說自動化釋出，現在是不是還是要靠人工去操作，這些是最基本的動作，做好這些之後，你才有能力或者有條件和上下游進行對接。只有完成的每個環節的自動化之後，我們才有可能去構建整個部署流水線。
也就是說我們在落地的時候可以想想整個業務流程裡面的痛點，比如說你是部署沒有完成自動化，還是測試沒有完成自動化，導致了這個流水線沒有辦法流傳下去。然後以每個環節的自動化作為一個開始，然後把它們整合起來，就可以實現整個價值流的快速交付。
文章來自微信公眾號：高效運維