如何推進DevOps轉型？

在敏捷已經被大多數人接受的當下，DevOps成為了下一個軟體工程領域最具熱度的話題。這裡我們就是要討論一下，應該以何種方式才能更好推廣DevOps。

隨著國內軟體開發敏捷化的推進，DevOps已經被越來越多的企業所關注，但是隨著對DevOps的瞭解的逐漸加深，很多企業都在思考：要不要開始DevOps，面對企業現狀應該怎麼做？我要投入多少？

其實目前我國很多企業都是在進行初期的敏捷探索，完全談不上企業級敏捷管理，但是又由於市場與業務所帶來的壓力讓他們都向開始進行DevOps轉型，這時DevOps的推進就使很多企業感覺無從下手，今天我們就討論一下，如何才能在最小的風險下，投入最少的成本做到一個較高程度的DevOps。

這裡我們先分析一下DevOps是什麼。大部分人對DevOps的解釋都是從這個單詞直譯過來的就是開發運維一體化，其實這樣理解很片面。其實我們不難從Patrick提出DevOps的過程得出結論，DevOps的精準解釋應該是透過敏捷的軟體開發與敏捷的運維管理相結合達到業務的快速、靈活響應，也就是DevOps = Dev Agile + Ops Agile。那麼我們在重新組合整理下，DevOps就是敏捷管理與軟體的持續交付。

敏捷管理這裡就不過多闡述了，我們主要說一下持續交付。下面我們看一下持續交付改進框架100-to-100。

這個框架說明了我們需要在持續交付上進行哪些改進，才能做到從100天釋出1次（瀑布式開發）轉變成1天釋出100次（DevOps）。

首先我們為我們的後續話題引入一個定理：康威定理。

康威定理中一條與軟體行業息息相關的定律，我們可以這樣解讀：企業內組織架構會直接對映到你的軟體產品上。也就是說你的組織架構決定了你的溝通方式，同時都會直接體現在你的軟體產品上。

從100-to-100框架上我們不難看出，框架中的多個模型都與了=康威定理中組織架構與系統架構有關係：組織架構即團隊模型，組織之間的溝通方式決定了分支模型，技術架構即系統架構，系統架構也影響著你的基礎設施以及你的部署模型。這裡我發現，當我們對康威定理中關聯緊密的模型進行改進的時候，企業面臨的改動與風險要遠遠高於關聯不緊密的模型。比如對測試模型的改進對企業的影響遠遠小於對團隊模型的改進。因此我們這裡引入康威定理，幫助我們分析DevOps實施的最佳方式。

DevOps的推進無外乎激進型與循序漸進型，激進型就是全面實現DevOps轉型，從敏捷管理到持續交付框架改進同時進行，這種方式需要有雄厚的資金實力，較強的市場掌控力以及超強的技術實力，而且即便具備了這些要素這個過程也是困難重重，所以這種方式的特點是：風險大，轉型週期相對較短。

循序漸進也就意味著要從對企業影響最小的方面入手，逐漸構建企業DevOps體系。這種方式的特點是：風險小，轉型週期較長。

首先我們應該從構建自己的兩個核心DevOps能力開始：自動化與指令碼化：

自動化：指的是依託於工具幫助企業減少軟體研發過程中的手工干預，在版本管理，測試，部署，釋出等等環節實現自動化。

指令碼化：讓你的測試指令碼化，讓你的資料庫管理指令碼化，還有就是DevOps的核心能力基礎架構即程式碼（Infrastructure as Code）， 即環境指令碼化。

在企業不具備這兩種核心能力時，不管是敏捷的推廣還是DevOps的實踐，收益都會減少很多，因此企業需要在一開始就持續構建這兩個能力，以便為企業的DevOps轉型鋪平道路。同時這兩個能力的建設對企業來說影響最小，也是最容易推行的。

其實這裡對於這兩種能力的建設我們可以藉助一個非常好的工具：Docker。Docker能極大的簡化我們的持續交付模型改進過程。下面這張圖展示的就是Docker能在100-to-100框架中可以幫到企業的改進點：

因此如果你想更快更好的實現DevOps，容器化絕對是你的首選。關於Docker的更多介紹您可以掃描文章下方的二維碼關注我們的公眾號。

此時也可以在原始碼的分支管理模型中進行改進，我們應該拋棄傳統的集中式原始碼管理方式，嘗試使用Git作為新的原始碼管理方式，因為這樣可以幫助我們的團隊構建面向使用者故事的交付體系。下面這張圖即使了我們應該怎樣改進我們的分支模型，以及能達到的效果：

當然對於沒有實現100-to-100的框架時，我們可以將分支管理模型中的分支粒度加大，變成 軟體版本+PR+質量門禁的方式。這樣一來分支即版本，對分支的質量使用自動化及指令碼化進行內建，最終達到軟體版本的統一自動化管理。

當我們實現了自動化建設，並且指令碼化能力初具規模時我們就需要對康威定理中緊密關聯的模型進行改進了，也就是團隊模型，技術架構以及部署模型。

對於這些模型我們就需要從粒度與解耦兩個維度進行持續改進。

粒度是由使用者的業務靈活響應程度來決定的，你的業務對靈活響應的速度要求越快，那麼你的組織架構與系統架構的粒度就應該越小，同時當你的粒度降低的時，你的過程管理也會變得更加簡單。當你要適應業務靈活響應的需要時會發現，組織架構及系統架構的內在耦合性阻止了粒度的降低，因此你就需要解耦。在DevOps實踐過程中對於業務的響應速度直接依賴於系統結構，系統結構粒度越小，耦合性越低，響應速度才能越快。同時根據康威定理，系統結構的粒度的降低，也讓我們對組織結構的調整越順利。

所以對於國內的大多數企業來說，首先實現自動化與指令碼化是實現DevOps的基礎，在此之上根據市場及業務的實際需要規劃我們的技術架構，由此調整我們的團隊模型，同時藉助容器幫助團隊快速實現轉型，是一種最好的DevOps實踐方式。

作者：薄濤

LEANSOFT諮詢服務總監，認證 Scrum Master，曾為多個行業的100多家客戶實施過微軟Team Foundation Server，包括：中國農業銀行，興業銀行，中關村銀行，華為，上海通用，上海匯眾，百威英博，斯倫貝謝，世紀互聯，金士頓(臺灣)等。