作者：Alan Koch
翻譯：袁思思（微信公眾號：博雲）
來源：DZone
原文連結：https://dzone.com/articles/what-devops-is-and-is-not

DevOps很難定義，因為有很多原因。它看著像什麼，怎麼工作的，IT行業裡各種各樣角色有不同視角和不同的觀點。DevOps影響著IT中的每個人，但是它用不同的形式影響著每個角色，他們對它有不同的描述。

DevOps不是什麼

仍然很難給它定義，因為人們對它有不少誤解。因此，在我們試著給DevOps定義前，先花點時間來擊破這些最常見的誤解。

DevOps不是一個新工具

當DevOps社群建立了很多很酷的新工具的時候，許多DevOps建議不能沒有工具。使用Puppet、Docker、Jenkins或者其他工具，並不意味著你正在“做DevOps”。工具不是DevOps，它們只是讓它變得可能。

DevOps不是一個新團隊

“DevOps”這個名稱表明了它連線了IT中的Dev和Ops部分。在它們之間增加其他組將對實現最終目的產生反效果。建立一個DevOps團隊，通過程序和工具進行實驗，建議開發和運維如何一起協作是一個偉大的開始——只要那個團隊是開發或運維，而不是處於他們之間。

DevOps不是一個新角色

許多公司在網上做廣告找“DevOps 工程師”，這說明他們並不理解他們需要的是什麼。DevOps 包含了一個IT組織中所有的的事，一個DevOps 工程師是個“一人樂隊”，需要做所有的事。所有的事！

DevOps不是大量的知識

沒有中央集權也沒有DevOps 標準。並沒有唯一的“正確的方法”來實現DevOps 。

DevOps是什麼

DevOps手冊的作者 Gene Kim說道：

DevOps以及它產生的技術，架構和文化實踐代表了許多哲學和管理運作的融合（包括）：精益，約束理論，豐田生產系統，恢復工程，學習組織，安全文化，人力因素，高度信任的管理文化，服務型領導，組織變更管理和敏捷方法。

換句話說，DevOps的偉大實踐來自於許多不同的領域，並且在IT組織內執行，為了提升IT的效能。

雖然DevOps 從許多非常成熟的學科中吸取經驗，但是DevOps 潮流是最近才興起的。DevOps術語出現在09年，標誌著這個快速增長潮流的開始。與敏捷術語相比，它早在01年就出現了，說明敏捷潮流出現比它早2倍。

這股年輕的潮流是它難以定義的另一個原因。DevOps 社群增長和學習迅速。實踐也正在發展演化，工具趨於成熟，並且每個加入其中的組織都貢獻了關於DevOps 的經驗和知識。

Gene Kim的三個方法

GK已經通過這股潮流的簡短歷史，清楚的描述了DevOps。他的2013年短篇小說The Phoenix Project描述了一個虛構的IT組織，使用DevOps 原理解決了一些棘手的問題。他的2016年手冊The DevOps Handbook 給剛進入DevOps領域的企業提供了詳細的指導，基於上百家已經使用DevOps的企業實踐經驗。

這兩本書都基於和圍繞他的“三個方法”。GK的三個方法是DevOps的主要部分，提供一種路標來理解和執行DevOps。他們是：

1. 流程
2. 反饋
3. 持續學習

1. 流程

第一個方法包括專注於IT組織內活動的流程和不斷優化，讓流程變得更順暢和快速。流程的關鍵之一，就是我們需要處理流程的價值（軟體的形式），從我們的開發團隊到在生產操作中使用。這包含的概念就像持續交付和優化開發管道。

精益的來講，第一個方法包括理解你的 “價值流程”，鑑定和為順暢流程除去障礙，並且為了流程的增長速度採取自動化。

2. 反饋

第二個方法建立在第一個之上，通過優化反饋的從右到左的流程。這包括基本的反饋——開發團隊觀察他們的軟體在生產中執行的如何，實際的終端使用者使用的怎麼樣。它也包括任何和所有型別的反饋，和其中所有涉及到的角色。

第二個方法的意圖是為人們提供清晰的可見性，做任何任務他們都可以進入工作質量中，並對他人產生的影響，都在IT內部和在大多數客戶，使用者和組織上。這不僅包括確保提供反饋，也縮短和優化反饋環路，因此人們能儘可能快和自動的收到反饋。

3. 持續學習

通過流程和反饋的完善，第三種方法利用持續學習和持續改進成熟的模式。

也許有人會問，諸如：“我們可以從所做的和收到的反饋中學習到什麼？”或者“我們如何使用那些知識來提高IT組織的效能？”

最後，這個學習超越了我們的基礎工作，並且包括實驗來發現新的和創新的方法，來更好的滿足客戶、使用者及組織的需求。例如，在“假設驅動開發”中，我們假設軟體功能是使用者和客戶需要的，然後建立軟體實驗來測試假設，丟棄失敗的實驗和建立在工作之上。

第三中辦法涉及到一個文化轉型，在我們類似失敗中：擁抱失敗的意願可以看做是一個學習的機會！不論它是一個意料之外的執行故障，還是一個我們經過實驗的發展，我們看到失敗既是好的，因為我們從中得到了學習，它讓我們變得更好。

自動化你所能的一切

一個DevOps關鍵原則是：“自動化你所能的一切。”這個原則非常重要，因為自動化對IT廠商的能力來實現流程（第一個方式），快速反饋迴路（第二個方式）和高效能（當第三種方法持續學習和持續改進奏效了）的核心。自動化可以從多種方式來增強DevOps效能：

• 增長速度。自動化活動比手工快得多。如果一個活動可以自動化，那麼沒人可以比自動化做的更快。
• 減少人為錯誤。工具不會像人那樣犯錯。工具一旦被配置好，驗證也是正確的，它之後每次執行任務就不會出錯。
• 一致性。任何工具的定義都是一致的。工具可以用來檢查和核實活動內的一致性，那個不是自動化的。
• 降低風險。因為工具不會犯錯，並且可以用來檢查手工活動，部署它們可以降低不可避免的風險。

高效能組織會自動化他們能自動化的一切；這也是他們如此高效能的原因。

DevOps長期衝突解決的核心

每個IT組織有2個同時要做的重點：

• 創新。通過開發和部署新的成熟的IT服務和應用，緊跟和客戶及使用者的變更需求。
• 穩定。確保客戶和使用者能使用那些IT服務和應用，並且保障他們的資料和資訊保安。

這兩個重點，彼此本質上是互相沖突的，因為部署變更到生產環境中，是最常見的中斷原因和其他操作問題。更糟的是，這些衝突的優先順序在IT廠商內導致摩擦和其他障礙，因為開發通常創新優先，而運營是穩定優先。

DevOps不是說開發和運維（和質量和安全）必須合作。它也通過同時能夠創新和穩定，解決核心的長期衝突。DevOps時間和工具確保整個IT組織的穩定和可預見性，在創新和開發程序的時候，通過特殊的集中於穩定。通過允許IT團隊移動更快和部署不會危及安全和穩定，來加速創新。

學以致用

你的IT廠商已經在DevOps旅程的第一步了（至少），因為DevOps不是意味著扔掉所有東西和返工。不如說它意味著看看如何做，做什麼，並且使用特殊的工具和技術讓工作流程順暢，提高反饋，開始持續學習和提高。

識別什麼有害，從其他人那學習修復問題，做一個提高。你看，你已經在DevOps程序上了。