DevOps (a clipped compound of “development” and “operations”) is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops).

DevOps 是一項軟體工程實踐，意在將軟體的開發和運維統一起來。

The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.

其顯著特徵是倡導在整個軟體構建過程中實現自動化和監控。

DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.

DevOps 追求更短的開發週期、頻繁增量地部署、更可靠的釋出版本，以達成業務目標。

以上是 Wiki 關於 DevOps 的描述，但我們如何解讀？

DevOps 產生的基礎條件

任何一項實踐都有其誕生和適用的土壤。與敏捷的中心實踐持續整合一樣，DevOps 是雲平臺開發交付的最佳實踐。換句話說，是因為雲平臺帶來的兩大變化：

1. 簡化了IT基礎設施運維工作，但是卻增加了管理的伺服器規模。
2. 各個環境一致性的增加（網路、作業系統版本、過去的生產環境 License 限制、準備相同環境的難度，現在都可以用 image/snapshot 解決了），使得開發人員可以使用少量指令碼完成不同環境的部署，甚至控制部署資源的啟動和回收。

兩大變化都導致開發與運維在專業知識上非交叉部分的減少。從而在圍繞著最終業務目標：正確執行的軟體上，有了職責統一的可能性。

但最根本的產生原因，是網際網路應用的引爆式增長。比如 Instagram，10 天內增加了 1000 萬用戶，5 個月內再增加了 6000 萬用戶。

即使是在雲端架構（Instagram 一開始就架設在 AWS 上），沒有一套先進的軟體工程實踐，如此海量使用者的照片上傳、壓縮儲存與訪問，意味著運維工程師團隊必須快速擴張，傳統的招聘和上崗流程，是很難在十天內有任何效果的，在這種情況下，業務就只能望洋興嘆了！

大型技術組織的問題

一句話簡述：就是太大了。千人規模以上的技術組織，在過去業務規模化發展時，沒有像上面 Instagram 這個好例子那樣，通過在幾個層面的簡化或治理來保障規模化之後的整體質量水平：

• 基礎設施是否可擴充套件？
• 架構是否可擴充套件？
• 核心能力是否在組織中共享？
• 避免人工操作的誤差？

當然，欠缺清晰的業務價值主張也是技術組織逐漸變得龐大的原因之一，比如 Instagram，它並沒有在使用者增長 7000 萬之後成為一個龐然大物，依然是一個照片分享應用，這與其明確的價值主張有關，但這個話題不在本文討論。

因此，在技術組織變大的過程中，通常面臨的問題就是：

• 陳舊的技術，大量的債務
• 人員能力參差不齊，團隊經常勞而無果
• 線上質量事故多，業務滿意度低下

實踐驅動不了組織

前文說了，DevOps 是一項軟體工程實踐，對當今而言，它是最為先進的軟體工程實踐之一，意味著在低成本短週期持續釋出可靠的業務版本的能力。

組織不是一個專案，實踐可以改變一個人對結果實現的過程認知，但組織是超越個體的聯結，實踐無法對組織產生任何改變。對組織而言，DevOps 的實施是一項綜合性挑戰。

我們來看看 Wiki 給出的 DevOps 覆蓋範圍描述：

1. Code — code development and review, source code management tools, code merging
2. Build — continuous integration tools, build status
3. Test — continuous testing tools that provide feedback on business risks
4. Package — artifact repository, application pre-deployment staging
5. Release — change management, release approvals, release automation
6. Configure — infrastructure configuration and management, Infrastructure as Code tools
7. Monitor — applications performance monitoring, end–user experience

它要求制定統一的構建部署標準和工具，達到一致的部署環境；對團隊而言，它要求頻繁整合程式碼的工作紀律，編寫自動化測試的能力和儘早修復問題的決心。以及，將一切步驟自動化。

這意味著持續地挑戰組織內現有的標準、流程、工具甚至安全策略（各個部署環境的打通）；也意味著持續地挑戰團隊的既有專案成果、工作方式甚至曾經引以為豪的經驗履歷。

在一場組織層面的變革中，如何更平滑地引入新的技術實踐？

啟動：利用六層變革阻力模型

約束理論（Theory of Constraints）為我們提供了利用變革阻力的六層模型。

改變什麼？

· 第一層阻力：缺乏對問題根源的共識

許多組織在敏捷轉型期間就在自動化測試上跌了大跟頭。就在於對根本問題和根本原因缺乏分析和理解（Systemic root cause analysis）。

為什麼要做自動化測試？當前交付物質量，尤其是交付給測試人員的版本質量究竟如何（Current reality）？

戴明的紅珠實驗表明，在上游環節交付物質量就不合格的情況下，下游無論採取何種辦法都無法提升最終產出物質量。所以，在這個環節上實施自動化測試，是一個錯誤的變革起步點。

變成什麼？

· 第二層阻力：缺乏對可行性方案的共識
· 第三層阻力：缺乏對方案解決問題信心的共識
· 第四層阻力：擔心新解決方案又將產生新的問題

組織如何達成變革的目標，即是通過決策（Decision-making）形成的轉型方案，它應該是根據組織的現狀及根源問題，採取的一系列策略的組合。對每個組織而言，它應該是定製化、有針對性的。

讓變革發生！

· 第五層阻力：缺乏排除阻塞實施方案的清晰路徑

這是最常見也最棘手的阻力：好不容易在中上層達成了共識，通過了方案，去到團隊一看，交付任務都堆積如山呢，如何配合你學習新知識新方法新工具？立即歇菜。

通常這時候，需要一個身經百戰的高手，迅速解決團隊當前的問題將之“鬆綁”，就能夠迅速建立起信心和聲望，使團隊進入新的軌道。

第六層阻力：缺乏跟進

這也是最常見的終極阻力，也是客戶常常報怨“教練”式顧問的原因：我們希望你們能夠自帶專案經理功能，不要什麼事都讓我們去做！

規模化轉型

啟動成功並初步有成效之後，下一步考慮的就是組織的規模化了。通常有兩個方向：

• 垂直縱深：向與試點團隊相同或相似規模、業務、特點的團隊進行復制。
• 水平推廣：針對某項方法、實踐或經驗，在整個組織範圍內全面推廣。

因為涉及到大量的人員及資金的投入，也涉及到組織架構和角色的調整，規模化至今為止，都是一個轉型的業界難題。

經驗總結：

對落地軟體工程實踐的技術組織轉型，規模化成功的關鍵在於，有平臺級工具作為技術實踐的支撐，以降低組織投入的複雜度。對 DevOps 轉型而言，就是需要落地一整套 DevOps 工具平臺及使用標準。

DevOps 工具平臺實施關鍵

一是基礎的基礎：版本管理。作為程式碼的來源，它支撐起了整個構建、部署、測試和釋出的流程。

版本基線管理已經是非常落後的辦法了，相對於 git-flow，我比較推崇的是 Netflix 的 test release product 三個恆定的分支分別支撐開發、釋出、主幹。hotfix 作為線上修復的臨時分支。

• 開發人員平時工作在Test分支上，它的提交可以觸發測試環境的自動部署。
• Release 分支用於每週自動部署，只需要把程式碼提交到 Release 分支上，它會觸發自動化測試及整合測試，後續過程會由某個特定成員或部署團隊啟動，所有的動作都是自動化的。部署完成之後，程式碼會自動 Push 到 Prod 分支上。
• 如果某個特性需要立即釋出而不是通過每週固定釋出流程；開發人員可以向 Prod 分支提交，這次提交會自動觸發 Release 分支的合併並觸發自動部署流程，如果稽核人員通過，它將被立即部署。

二是對系統的架構治理，甚至高階的架構治理，包括語言、框架的選擇規範，模組化重構，等。要充分評估各個系統的債務和收益，決策是否值得持續維護。

缺乏治理和規範的技術組織，很難在一套平臺上支撐所有系統，並且與各種不同技術、系統的對接有可能會變成另一個龐大繁雜的專案，這本身也違背了 DevOps 可以給組織帶來在低成本短週期持續釋出可靠的業務版本的能力的初衷。

最後的忠告

我曾經在超過 6000 人的IT組織裡擔任持續整合雲的產品經理 + 架構師，拆分和重寫了 Jenkins 最關鍵的任務排程、日誌儲存以水平擴充套件其構建效能。

半年交付 beta 版本支撐 800 人開發，一年釋出至穩定版本，支撐越過 4000 人每日數萬次的構建釋出。

隨後作為諮詢專案負責人幫助一家 2000 人規模的組織在兩個月內建立起開源 DevOps 平臺及團隊，支撐試點團隊的開發運維。

DevOps 實施的難點不在於技術，最大的阻力來自於組織過大之後，各項工具的管理、實施分散在各個部門，如果組織層面沒有達成共識和調整集中決策，即使後面市場上出現成熟的 DevOps 商業產品，也很難在組織內有效落地。

這點上，可以參考 20 年前的 ERP 變革對組織決策權的影響，自動化的趨勢已不可阻擋。

原文來自微信公眾號：GitChat技術雜談