為何 DevOps 是如今最重要的技術策略 | Linux 中國

很多人初學 DevOps 時，看到它其中一個結果就問這個是如何得來的。其實理解這部分 Devops 的怎樣實現並不重要，重要的是——理解（使用） DevOps 策略的原因——這是做一個行業的領導者還是追隨者的差別。

你可能會聽過些 Devops 的難以置信的成果，例如生產環境非常有彈性，就算是有個“癲狂的猴子Chaos Monkey）跳來跳去將不知道哪個插頭隨便拔下，每天仍可以處理數千個釋出。這是令人印象深刻的，但就其本身而言，這是一個 DevOps 的證據不足的案例，其本質上會被一個反例困擾：DevOps 環境有彈性是因為嚴重的故障還沒有被觀測到。

有很多關於 DevOps 的疑惑，並且許多人還在嘗試弄清楚它的意義。下麵是來自我 LinkedIn Feed 中的某個人的一個案例：

最近我參加一些 #DevOps 的交流會，那裡一些演講人好像在倡導 #敏捷開發是 DevOps 的子集。不知為何，我的理解恰恰相反。

能聽一下你們的想法嗎？你認為敏捷開發和 DevOps 之間是什麼關係呢？

1. DevOps 是敏捷開發的子集

2. 敏捷開發是 DevOps 的子集

3. DevOps 是敏捷開發的擴充套件，從敏捷開髮結束的地方開始

4. DevOps 是敏捷開發的新版本

科技行業的專業人士在那篇 LinkedIn 的帖子上表達了各種各樣的答案，你會怎樣回覆呢？

DevOps 源於精益和敏捷

如果我們從亨利福特的戰略和豐田生產系統對福特車型的改進（的歷史）開始， DevOps 就更有意義了。精益製造就誕生在那段歷史中，人們對精益製作進行了良好的研究。James P. Womack 和 Daniel T. Jones 將精益思維（Lean Thinking）提煉為五個原則：

精益致力於持續消除浪費並增加客戶的價值流動。這很容易識別並明白精益的核心原則：單一流。我們可以做一些遊戲去瞭解為何同一時間移動單個比批次移動要快得多。其中的兩個遊戲是硬幣遊戲和飛機遊戲。在硬幣遊戲中，如果一批 20 個硬幣到顧客手中要用 2 分鐘，顧客等 2 分鐘後能拿到整批硬幣。如果一次只移動一個硬幣，顧客會在 5 秒內得到第一枚硬幣，並會持續獲得硬幣，直到在大約 25 秒後第 20 個硬幣到達。（LCTT 譯註：有相關的影片的）

這是巨大的不同，但是不是生活中的所有事都像硬幣遊戲那樣簡單並可預測的。這就是敏捷的出現的原因。我們當然看到了高效績敏捷團隊的精益原則，但這些團隊需要的不僅僅是精益去做他們要做的事。

為了能夠處理典型的軟體開發任務的不可預見性和變化，敏捷開發的方法論會將重點放在意識、審議、決策和行動上，以便在不斷變化的現實中調整。例如，敏捷框架（如 srcum）透過每日站立會議和衝刺評審會議等儀式提高意識。如果 scrum 團隊意識到新的事實，框架允許並鼓勵他們在必要時及時調整路線。

要使團隊做出這些型別的決策，他們需要高度信任的環境中的自我組織能力。以這種方式工作的高效績敏捷團隊在不斷調整的同時實現快速的價值流，消除錯誤方向上的浪費。

最佳批次大小

要瞭解 DevOps 在軟體開發中的強大功能，這會幫助我們理解批處理大小的經濟學。請考慮以下來自Donald Reinertsen 的產品開發流程原則的U曲線最佳化示例：

U-curve optimization illustration of optimal batch size

這可以類比雜貨店購物來解釋。假設你需要買一些雞蛋，而你住的地方離商店只有 30 分鐘的路程。買一個雞蛋（圖中最左邊）意味著每次要花 30 分鐘的路程，這就是你的交易成本。持有成本可能是雞蛋變質和在你的冰箱中持續地佔用空間。總成本是交易成本加上你的持有成本。這個 U 型曲線解釋了為什麼對大部分人來說，一次買一打雞蛋是他們的最佳批次大小。如果你就住在商店的旁邊，步行到那裡不會花費你任何的時候，你可能每次只會買一小盒雞蛋，以此來節省冰箱的空間並享受新鮮的雞蛋。

這 U 型最佳化曲線可以說明為什麼在成功的敏捷轉換中生產力會顯著提高。考慮敏捷轉換對組織決策的影響。在傳統的分級組織中，決策權是集中的。這會導致較少的人做更大的決策。敏捷方法論會有效地降低組織決策中的交易成本，方法是將決策分散到最被人熟知的認識和資訊的位置：跨越高度信任，自組織的敏捷團隊。

下麵的動畫演示了降低事務成本後，最佳批次大小是如何向左移動。在更頻繁地做出更快的決策方面，你不能低估組織的價值。

U-curve optimization illustration

DevOps 適合哪些地方

自動化是 DevOps 最知名的事情之一。前面的插圖非常詳細地展示了自動化的價值。透過自動化，我們將交易成本降低到接近於零，實質上是可以免費進行測試和部署。這使我們可以利用越來越小的批次工作。較小批次的工作更容易理解、提交、測試、審查和知道何時能完成。這些較小的批次大小也包含較少的差異和風險，使其更易於部署，如果出現問題，可以進行故障排除和恢復。透過自動化與扎實的敏捷實踐相結合，我們可以使我們的功能開發非常接近單件流程，從而快速、持續地為客戶提供價值。

更傳統地說，DevOps 被理解為一種打破開發團隊和運營團隊之間混亂局面的方法。在這個模型中，開發團隊開發新的功能，而運營團隊則保持系統的穩定和平穩執行。摩擦的發生是因為開發過程中的新功能將更改引入到系統中，從而增加了停機的風險，運營團隊並不認為要對此負責，但無論如何都必須處理這一問題。DevOps 不僅僅嘗試讓人們一起工作，更重要的是嘗試在複雜的環境中安全地進行更頻繁的更改。

我們可以看看 Ron Westrum 在有關複雜組織中實現安全性的研究。在研究為什麼有些組織比其他組織更安全時，他發現組織的文化可以預測其安全性。他確定了三種文化：病態的、官僚主義的和生產式的。他發現病態的可以預測其安全性較低，而生產式文化被預測為更安全（例如，在他的主要研究領域中，飛機墜毀或意外住院死亡的數量要少得多）。

Three types of culture identified by Ron Westrum

高效的 DevOps 團隊透過精益和敏捷的實踐實現了一種生成性文化，這表明速度和安全性是互補的，或者說是同一個問題的兩個方面。透過將決策和功能的最佳批次大小減少到非常小，DevOps 實現了更快的資訊流和價值，同時消除了浪費並降低了風險。

與 Westrum 的研究一致，在提高安全性和可靠性的同時，變化也很容易發生。當一個敏捷的 DevOps 團隊被信任做出自己的決定時，我們將獲得 DevOps 目前最為人所知的工具和技術：自動化和持續交付。透過這種自動化，交易成本比以往任何時候都進一步降低，並且實現了近乎單一的精益流程，每天創造數千個決策和釋出的潛力，正如我們在高效績的 DevOps 組織中看到的那樣

流動、反饋、學習

DevOps 並不止於此。我們主要討論了 DevOps 實現了革命性的流程，但透過類似的努力可以進一步放大精益和敏捷實踐，從而實現更快的反饋迴圈和更快的學習。在DevOps手冊 中，作者除了詳細解釋快速流程外， DevOps 如何在整個價值流中實現遙測，從而獲得快速且持續的反饋。此外，利用精益求精的突破和 scrum 的回顧，高效的 DevOps 團隊將不斷推動學習和持續改進深入到他們的組織的基礎，實現軟體產品開發行業的精益製造革命。

從 DevOps 評估開始

利用 DevOps 的第一步是，經過大量研究或在 DevOps 顧問和教練的幫助下，對高效績 DevOps 團隊中始終存在的一系列維度進行評估。評估應確定需要改進的薄弱或不存在的團隊規範。對評估的結果進行評估，以找到具有高成功機會的快速獲勝焦點領域，從而產生高影響力的改進。快速獲勝非常重要，能讓團隊獲取解決更具挑戰性領域所需的動力。團隊應該產生可以快速嘗試的想法，並開始關註 DevOps 轉型。

一段時間後，團隊應重新評估相同的維度，以衡量改進並確立新的高影響力重點領域，並再次採納團隊的新想法。一位好的教練將根據需要進行諮詢、培訓、指導和支援，直到團隊擁有自己的持續改進方案，並透過不斷地重新評估、試驗和學習，在所有維度上實現近乎一致。

在本文的第二部分中，我們將檢視 Drupal 社群中 DevOps 調查的結果，並瞭解最有可能找到快速獲勝的位置。