在上一篇文章中，主要講了DevOps轉型的動機、策略和方法，本文將會為大家帶來更多DevOps轉型的落地策略和實踐。

實踐過程

下圖是我們為團隊設計的持續交付流水線，目的是能讓Platform團隊和交付團隊之間的觸點能夠被融入到持續交付流水線中，并且以基礎設施即代碼作為協同媒介，通過自動化的方式實現開發于運維(即基礎設施與軟件系統)的無縫對接。

我們來看看我們給持續交付流水線賦予了哪些能力：

1. 站在交付團隊的視角，我們決定將基礎設施構建，流水線構建、部署等活動都代碼化，與應用代碼放在同一個代碼倉庫中。
2. 交付團隊通過提交我們的基礎設施代碼到倉庫后，自動觸發持續交付工具創建或更新流水線。
3. 接著會自動觸發構建，靜態檢查，測試覆蓋率校測，代碼規范驗證等任務，最終輸出構建產物并將構建產物推送到倉庫。
4. 然后會根據交付團隊對基礎設施和環境的定義到當前要部署的網絡環境中去創建或更改虛擬機、網絡、存儲方式等。
5. ***，當基礎設施創建成功以后，就會去倉庫下載指定版本的構建產物進行最終的部署活動。

但需要注意的是：

1. 為了持續優化交付流程，我們對開發的許多活動進行的數據收集和分析，以報表的形式去分析展示代碼提交頻率，系統和代碼的質量情況，缺陷和構建情況等，幫助團隊找到自己的瓶頸或問題。
2. 幫助團隊能夠實時監控自己應用的運行狀態，設計和查看不同緯度的日志總匯等。

那我們來看看通過什么技術可以實現這樣的持續交付流程：

我們選擇了一種輕量級、低耦合的技術組合Ansible+Jenkins+AWS。我認為其核心是Ansible。

下面我們來看看Ansible可以幫助我們做些什么：

1. 創建和更改AWS中的資源;
2. 自動化部署和基礎設施測試;
3. 建立開發與平臺團隊之間的溝通體系。

考慮到基于yaml語法的Ansible配置簡潔且易讀，所以我們選擇直接用它作為提供給交付團隊的公有DSL模板，利用Ansible Playbook的模塊化思想將開發團隊的職責和平臺團隊的職責很清晰的分離，平臺團隊關注Ansible提供給交付團隊的服務是否滿足需求和DSL模板是否易用，而交付團隊只用關注如何基于公有DSL去定制自己的基礎設施，環境依賴和部署等。

于此同時也滿足了很多開發對于Ansible和AWS的興趣和熱情，更使得之后在交付團隊落地變得更容易。

接下來通過一個實例來看看：

左邊是Platform團隊的倉庫，這個倉庫里面包含了創建基礎設施、環境配置和部署的實現。

右邊是交付團隊的倉庫，其中deployment目錄下，是公有的DSL模板，其中包含多種環境(開發、測試、預生產環境等的獨立配置)，以及一套基于DSL的代碼模板，其中包含創建基礎設施和部署應用這兩部分DSL代碼模板。

接下來，我們來看看它們配合與集成的方式：

他們會在持續集成流水線中被動態組合到一起：

1. 在創建基礎設施和部署的時候會分別拉取基礎設施代碼庫和應用代碼庫。
2. 此時應用代碼為調用入庫，公有基礎設施為功能框架庫，兩者配合，完成環境的創建和應用部署。

在做微服務的團隊，接受度非常高，能夠快速上手，而且甚至有團隊因為自身的一些需求，自己去寫一些Ansible模塊，然后向我們發起pull request。

當然，我們在推廣這套流程的過程中發現，一些實踐能夠幫助我們更快速落地：

1. DevOps團隊的成員由各交付團隊和原運維團隊組成，這樣的組成方式，能夠保證團隊的視角可以關注到整個持續交付過程的每個環節。
2. 交付團隊成員與DevOps團隊成員定期輪崗制，DevOps小組中的文化(如自動化優先)可以蔓延開，讓交付團隊更快適應。
3. 結對、Showcase和培訓，主要目的是知識的傳遞，讓更多地團隊逐步采用新的交付模式，得到更多改進中的反饋。
4. 提供給交付團隊的自服務代碼倉庫對每個人開放，交付團隊被授權優化、新增基礎設施，讓DevOps文化和職責落地到交付流程中。

現在來看，集中式、審批式、被動響應請求的中央運維團隊不再是整個交付流程中的依賴和瓶頸，已基本轉向帶自服務化、審查式、主動優化的去中心化交付團隊：

我們通過技術驅動改進，讓團隊之間的合作方式發生了巨大改變，開發與運維之間的那道墻也漸漸消失，以前被動響應請求的中央運維團隊逐步被平臺團隊所替代，平臺團隊中一部分人會負責基礎設施平臺的發展，負責公有云與企業內部系統的對接、完善安全、災備、提供基礎設施的自服務機制，另一部分人會為產品團隊提供可定制的工作、平臺、并為產品團隊賦能。這時交付團隊開始管理自己的環境、維護流水線、負責生產環境變更。

在推廣和落地自服務持續交付流程的過程中，我們也遇到了很多遺留系統和復雜部署應用的交付團隊，他們無法直接對接這套交付流程。

例如有一個40-50人的團隊，它是基于AEM開發整個公司所有的前端門戶，AEM是Adobe公司的CMS系統，其安裝和部署很復雜，以前都是通過手工安裝和拷貝的方式進行部署，而且他們在開發→測試→部署階段可能會動態擴張多套環境來支持，且每次代碼變更的提交都會對已經安裝的AEM進行修改、配置、重啟等操作。

整個開發和測試流程都很復雜，而且效率很低，出現問題和故障的風險也很大，如果我們直接利用Ansible把AEM的安裝和部署過程都自動化，由于AEM本身部署的復雜性，可以預見以后這部分更新和維護的工作還是很難交由交付團隊自治。所以我們***步要做的就是為其設計新的持續交付流水線，然后在這個流程中去定義和識別兩個團隊的職責和關注重心，***再通過打造高效的自服務使整個交付流程得到改進。

首先我們根據校服團隊提交變更的平率，從低到高依次定義了三條持續集成流水線(如下圖)：

1. 創建和測試基礎設施資源;
2. 配置基礎設施資源和環境;
3. 部署應用程。

因為AEM安裝和更新很復雜，所以我們引入了鏡像技術。基礎設施和基礎設施配置兩條流水線的產物為一個image，應用流水線在部署階段會去檢查是否存在新的環境鏡像，如果存在，就會基于快速創建一個新的AEM環境，然后進行應用代碼的部署。

通過新的自動化持續交付流水線大大加速了AEM團隊的開發和測試速度，也使得整個環境更加可控和易維護。對于交付團隊來說，他們可以自己去維護包括基礎設施、環境變更和應用部署等全生命周期交付活動。

對于Platform團隊來說，只用去考慮鏡像的生命周期管理，如何去優化鏡像的創建速度等，這些可以幫助到更多其它團隊解決類似問題的領域。對于這種特殊情況，我們盡管引入很多與大多數團隊不同的交付流程和技術，但所有的工作和優化都是基于之前打造的自服務持續交付流程、協議和工具平臺之上的，保證了不同的交付團隊與Platform的配合方式的一致性。

實踐啟示

通過在大量交付團隊落地基于自服務的持續交付流程，兩種團隊的職責更加清晰了：

所有好的實踐都必須考慮規模化的問題，如果無法大規模的被接受和落地，再好的實踐也沒用。對于咱們這個轉型的過程，我也給出一個套路：

有了套路，接下來總結一下應用這個套路進行DevOps轉型過程中的一些經驗和思考：

1. 易用的通用DSL模板設計，提供交付與Platform團隊統一的DSL模板(build and update anything)。
2. 構建通用持續交付流水框架，提供給交付團隊定制化流水線的能力，使流水線主要關注點始終在產品的成功交付。
3. 以技術驅動DevOps文化大面積傳播，讓Platform團隊成員走入交付團隊，協作改進、知識傳遞，確保實踐落地。
4. 將一切自動化、自服務化。交付團隊應該被授權優化、新增基礎設施服務，讓DevOps能力和職責在交付團隊落地生根。

***，我提取了5點對我們來說非常重要的策略或是推進方法：

1. 小步快跑，在有大方向的基礎上，需要將每一步改變都設計得足夠小，這樣才能足夠快的去改進。
2. 交付團隊賦能，給每個人都留一扇門，在他意識到要做些事情的時候，可以很快付諸行動。
3. 逐步用基礎設施自服務化替代運維部門的審批流程。 建立持續反饋和改進機制。
4. 以DevOps團隊為杠桿，撬動更大范圍自服務交付。

非常感謝你的耐心閱讀，希望我的文章能夠給你帶來哪怕一點點啟示。有任何問題或是想與我討論的點，歡迎留言。

【本文是51CTO專欄作者“ThoughtWorks”的原創稿件，微信公眾號：思特沃克，轉載請聯系原作者】

戳這里，看該作者更多好文