原文地址:http://www.drdobbs.com/architecture-and-design/getting-devops-right-the-lay-of-the-land/240062639，作者Scott W. Ambler。
對於不同的利益相關人DevOps含義不同，但是基本組成部分是相同的。
在過去的1，2年，媒體上有很多關於DevOps的爭論。有關DevOps的聲音越來越雜亂，導致聽眾也越來越困惑。DevOps提供了針對IT市場的敬業精神和生產力一個潛在增長點。但是，與在它之前的所有運動一樣，誤解和誤用DevOps是非常危險的。本文章以及隨後的系列文章，將提供有條理的嚴肅的建議來解開這些困惑。
讓我們先從一些定義開始。首先，在本文章中我會用兩種方式表述詞條“產品”。當我使用IT短語“釋出產品”時，如果上下文與商業產品有關，我也隱含了“釋出到市場”。當我使用單詞“產品”時，意味著運營和支援（有時也被稱為“help desk”）的結合。一些組織認為運營和支援是兩個概念，但其它組織結合了這兩個概念。”DevOps”是開發（development）和運營（operations）兩個單片語成的混合詞。在該上下文中的開發包括瞭解決方案被髮布到產品環境之前發生的所有活動，即專案初始化時明確初始概念一直到可以部署。DevOps上下文中的運營包括了部署之後的所有活動。即“與產品相關的東西”（production stuff），包括了對所部署的解決方案的運營和支援。
定義DevOps詞條，說起來容易做起來難，這是因為需要綜合考慮多個視角，即主要的DevOps利益相關者的視角。你的談話物件不同，DevOps是什麼的定義的回答也不相同。DevOps的利益相關者以及他們的視角如下：
*開發人員，尤其是有經驗的敏捷開發人員，認為DevOps是交付產品的一個持續的流程，有可能一天數次。
*運營專家往往認為DevOps提倡與開發團隊建立更有效的關係，不僅包括整個開發生命週期，也包括解決方案被部署到產品環境的過程。有經驗的運營人員也意識到他們內部過程往往基於ITIL或ITSM，需要被精簡以便更好的與開發團隊協作。
*支援專家（有時也被稱為help desk專家）對DevOps的認識與運營專家類似，但稍微有點區別：他們想和開發團隊一起工作來保證解決方案被髮布到產品環境前他們的需求能被正確理解和滿足。他們也想確保有一個流程，一旦當解決方案被使用後，能夠處理需求更改（包括缺陷）。
*高階管理團隊認為DevOps是可以通過簡化所有人一起工作的方式從而提高IT部門整體效率的一種成果。
規範DevOps
現在來看看規範DevOps。圖1展示了採用規範DevOps前以及規範DevOps努力想達到的效果的對比圖。目前在很多組織中，開發團隊和運營團隊間儘管有流程和組織級障礙存在，但仍努力達到有效協作。
開發團隊的部署並無規律-“快速”的團隊一年進行1到2次釋出，偶爾為發現的產品問題打個補丁。
運營團隊反而推進變更請求，包括缺陷報告，返回給開發組織。這兩個組織一起協作就可以保證這些活動是成功的，但仍有一個明顯的地方可以提高。規範DevOps通過增加開發，運營和支援人員之間的協作這一策略來提高這一點。向開發團隊引入持續交付實踐，向IT引入新的組織級架構；採用商業智慧工藝和技術來支援開發智慧和運營智慧，即支援改進的IT管理。不規範的DevOps和規範的DevOps的不同之處在於，規範的方式以整體視角來考慮所有DevOps利益相關者的渴望，而不僅僅關注於一個視角。
圖1：縮小DevOps差距
要想成功實踐DevOps，你需要在5個方面實現提高：人，準則，實踐，產品及流程。這些問題以從高到低的優先順序順序排列。人及他們相互互動的方式是任何IT努力達到成功的決定因素。而規範DevOps清楚的需要人們重新思考他們的技能，如何定義自己的角色，如何一起工作。IT組織採用DevOps需要重新思考他們所做的決定的底層準則。例如，採用與業務更緊密互動的準則將激勵他們採用更頻繁的釋出產品的方式。組織需要採用諸如持續整合，持續部署，運營智慧，協作支援等實踐。如果他們決定採用DevOps，有更多新鮮的事情需要去做。新的產品，包括開發工具，商業智慧工具，以及運營監控工具等需要被採用。最終，流程框架（比如規範敏捷交付，DAD），將DevOps策略變為開發流程，還有ITIL或ITSM的更新版也需要考慮是否使用。
誤解
組織執行DevOps似乎有著普遍的方式。我擔心這樣的觀點，即“雲=DevOps”，這種觀點似乎越來越受歡迎。採用雲技術可以早點接觸到DevOps的一些方面，但只是5個方面的其中之一（即產品方面）。相似的，一些廠商的工具驅動的訊息工具，以及一些開源社群（的產品）也令人不安，新的工具僅僅是DevOps大局觀的一部分而已。第三個誤解之前有提到過，即過於關注於一個DevOps利息相關人的視角。特別常見的是過於關注開發過程，因為效果顯而易見，特別是持續交付實踐可以帶來潛在的更高效的提高。該問題是僅關注了5個方面的實踐部分。
這些誤解，確定會導致他們遇到問題，在之後的文章中會詳細討論這些問題的解決之道。
Scott Ambler 在IBM Rational工作了6年時間，在這裡他幫助客戶採用及適應敏捷技術。現在是該領域的諮詢師。他也是Dr.Dobb’s的長期撰稿人。