DevOps是一個複雜的多維話題。這是上下文相關的。那些試圖瞭解和實施DevOps的人將他們的角色和文化觀點帶入了流程。意見和專業知識的多樣性可能是重要的優勢。但是，這也可能導致開發DevOps共識產生摩擦和爭論。按我的個人經歷，在團隊裡，想要推動DevOps發展和落地是很痛苦的，特別是在小團隊裡，因為這將是一場顛覆的變革。你可以噴我，但我不賠錢。
為什麼需要DevOps達成共識？
需要共識，因為DevOps不僅是一回事。這是一整套解決廣泛問題的想法。任何共同解決問題的團隊必須首先同意：
- 我們要解決什麼問題？
- 解決指定問題的最佳工具是什麼？
- 我們如何衡量改進（或缺乏改進）？
想要使用DevOps回答這些問題的企業和團隊必須首先就以下兩個問題的答案達成共識：
1、什麼是DevOps？
2、我們如何使用它來改善軟件交付？
每個企業想要完善或升級自身的運維體系，都必須問自己這些問題才能開始使用DevOps，並且每個企業的答案都不同。進行自我詢問和回答的過程可以知道什麼有效，什麼無效，以及可以採取哪些措施來促進有效的變革。
首先，DevOps討論
正在考慮DevOps的企業應首先討論什麼是DevOps以及如何使用它。有很多關於DevOps的學習資源（有關更多示例，請找度娘或者關注並私聊我）如果你承擔著促進討論的任務，那麼你很幸運，有許多有效的方法可以引導對話。你的第一步是研究。對基本概念的理解將使你能夠將其介紹給各種各樣的利益相關者。
“領導對話”並不一定意味著“向同事介紹DevOps。”要達成DevOps共識，你的首要任務是打下基礎，然後讓討論有效地進行。作為協作的“發現”會話，第一次對話將更加有效。對話負責人往往更有效地作為教練和裁判，而不是教育者。介紹基本思想，然後通過聆聽和提問來促進對話。
如果你準備在DevOps上做演示，我建議你在簡介的開頭限制使用“ DevOps”一詞。這個詞可能充滿了成見，特別是如果你的聽眾對DevOps接觸很少。重點關注基本原則，重點在於如何將其用於解決特定問題。嘗試避免和阻止對DevOps的簡化定義。你會聽到類似的聲音：
1、DevOps就是自動化
2、DevOps確實是過程改進
3、DevOps工程師是配置管理方面的專家
這些是快速形成意見的示例，但並未完全理解DevOps的廣度和深度。DevOps涉及自動化，流程改進和配置管理等等。使用嚴格規定的處理方式，不應將DevOps視為正統觀念。應該將其視為用於實現業務目標的一組工具。
隨著對話的進行，記錄關鍵問題。最關心的業務是什麼？列出這些問題的優先順序。該過程將使小組專注於最關鍵的業務挑戰。一旦達成共識，即可將DevOps評估為解決這些問題的工具。
如果你的企業正在考慮對DevOps進行大規模戰略採用，則你的DevOps共識討論將需要跨多部門的領導團隊參與：
- 執行管理（首席執行官，首席財務官，CSO（安全），CIO / CTO）
- IT運維管理
- 軟件開發管理
- 項目管理
這些角色各自具有獨特的視角。確保代表每個角色，並有機會表達關切和提出問題，這一點至關重要。公開的討論將使這個跨職能團隊可以考慮所建議方法的折衷方案，並平衡所有角色之間的關注點。該團隊應該在工作會議上一起學習DevOps，以開發對你的企業有意義的DevOps定義。
那麼，什麼是DevOps？
DevOps不僅是一回事，因此很難編寫一個單一的，包含所有內容的單句定義。DevOps有很多東西，而且這些東西還可以解釋。這並不意味著嘗試定義DevOps是徒勞的。恰恰相反，DevOps建立在一些非常成熟的概念上。這些想法和原則為DevOps的實施方式提供了依據，但它們並不是通往“ DevOps必殺技”的路線圖。它們是指南，是思考問題和解決方案的方式。
在團隊中達成DevOps共識的第一步是以通俗易懂的語言向同事介紹這些基本思想。為了使討論首先圍繞目標而進行，然後再討論方法，請以這些基本思想為重點開始介紹。
以下是一些DevOps的首要原則，可幫助你達成DevOps共識：
簡短的反饋循環：敏捷使用諸如站立式的儀式來確保開發人員和利益相關者之間的定期溝通。DevOps還強調縮短和放大反饋迴路。
精益IT：精益IT的原理主要集中於消除生產中的浪費。DevOps是在控制過量生產和提高生產流程效率方面發揮了作用。
約束理論：約束理論提供了一種通過識別和“打破”（消除）約束的連續過程來提高吞吐量的方法。約束定義為多步驟生產過程中的任何“瓶頸”步驟，其中工作變慢並開始積壓。敏捷實踐將工作流程可視化，有助於揭示工作障礙。DevOps將這種想法從軟件開發生命週期擴展到整個軟件交付生命週期。
價值流圖：所有服務都是通過不同複雜的過程生產的。一個人很少了解複雜的過程。每個步驟（在製造中稱為“工作站”）通常由具有專門技能的員工來處理。軟件開發工作站包括開發，測試，部署和維護。
理想情況下，創建價值流圖是一個協作過程。每個團隊匯聚一堂，講述他們在生產中的故事，這將有助於達成DevOps共識。整個故事源於價值流圖的過程。此練習通常會暴露整個過程的效率低下。DevOps使用“價值流圖”將生產工作與戰略性企業目標保持一致。
持續改進：持續改進是一種尋求並消除過程中效率低下的科學實踐。持續改進團隊不斷評估生產團隊的過程和結果。關於約束或其他低效率如何影響生產的理論得到了發展。然後，團隊對流程進行細微的更改，並測量改進（或缺少改進）的過程。這個過程永無止境，一直在尋找消除浪費和提高生產率的機會。DevOps從業人員使用
持續改進作為一種整體測量和改進軟件交付過程的方法。你將學到的大多數關於DevOps的知識都植根於這些基本概念中的一個或多個。在DevOps討論中採用“自下而上”的方法將使人們對第一個原則產生共同的共識。共同的理解是下一步的強大平臺：弄清楚如何使DevOps適應企業的獨特需求。
企業如何適應DevOps？
你已經向跨職能團隊介紹了DevOps的基礎知識。你已經共同確定了最重要的業務目標和挑戰。現在，你準備好將它們配對，並開始談論DevOps如何解決這些挑戰，並且你正在逐步達成DevOps共識。對話已準備好從抽象過渡到方法，最後過渡到實施計劃。這仍然是一項複雜的工作，因此，此時最好的方法是“分而治之”。
DevOps可以分為三個主要領域：
- 文化/人
- 處理
- 技術
這些領域之間當然存在一定的相互依存關係，但是可以由不同的利益相關者分別並行地解決它們。前面列出的每個角色都將在這些主要領域中佔有一席之地。但是，每個人都有一個自然的重點領域。
DevOps文化
“ DevOps”始於開發和運營部門之間關係的功能失調狀態。開發人員想要快速行動，運營部門需要放慢進度以保持穩定性。在這種體制下，雙方不能同時獲勝。
DevOps旨在將軟件交付中的開發，運營，安全性和其他利益相關者召集在一起，共同承擔使命。開發人員應讚賞並瞭解他們生產的軟件的操作要求。運營需要了解開發路線圖，以便為新版本做好準備。在整個過程中，安全人員必須坐在桌子旁。軟件交付的全部目的是向客戶交付業務價值，這最終由執行管理層代表。
在向DevOps的文化轉變中，每個人都可以發揮作用。但是，高級管理人員應最終負責轉變後的消息傳遞。高管人員的交流可以領導高層的變革。
DevOps流程
DevOps的過程部分基於敏捷軟件開發方法。如果你的組織已經使用敏捷，那麼你將處於領先地位。你可能會發現一些敏捷實踐應該改變的領域，以適應更大的DevOps實踐。如果你不練習敏捷，那麼這是開始你的DevOps旅程的好地方。關於DevOps的一個常見問題是：“可以在沒有敏捷的情況下實踐DevOps嗎？”簡而言之，是的，但是，如果將DevOps作為敏捷實踐的更大一部分來實施，你的工作回報將會更大。
持續改進也是一個主要主題。IT運維和開發人員可以與項目管理和業務分析師合作，以識別軟件交付所涉及的所有流程中效率低下和浪費的領域。價值流映射在此領域可能會有所幫助，以可視化整個端到端過程。
技術
DevOps方法論的技術領域集中於一個主題：自動化。任何可以自動化的東西都必須自動化。這包括持續集成，基礎架構即代碼，自動化部署，測試，用戶接受度等等。正如工業革命期間的自動化改變了行業和製造業一樣，軟件交付的自動化從根本上改變了軟件交付的過程。
自動化任務使它們更具可重複性和可靠性。自動化測試是自動化帶來巨大價值的一個領域。當關鍵時間早於發佈日期時，測試通常會延遲，有時會完全跳過。自動化的測試過程使其可重複，並降低了成本。儘早進行測試的過程通常被稱為“左移”，如將質量轉移到軟件交付過程中的最早步驟。
自動化還改善了一個關鍵指標：速度 。速度本質上是軟件發佈的頻率。較小的頻繁發佈要比較大的不頻繁發佈要好。這與另一個精益原則有關：小批量。當功能作為小更改的一部分發布時，它們的風險就較小。回滾和重新處理小的更改並不像回滾巨大，複雜的版本那樣具有破壞性。
IT運維和軟件開發團隊最有能力專注於DevOps的技術領域。
DEVOPS如何落地？
DevOps可以提供工具來應對與軟件交付相關的許多業務挑戰。首先，組建利益相關者跨職能團隊。圍繞一小部分你認為可以用來解決DevOps的業務挑戰，建立DevOps共識。這些挑戰很可能屬於DevOps支柱中的一個或多個支柱：文化，流程和技術。確定一個關鍵挑戰，然後在最適合它的DevOps支柱的背景下進行構架。現在你可以考慮實施了。
關於實施，請從小做起。DevOps的改編是一項持續改進工作。採取科學的方法。不要嘗試一次更改太多，否則會混淆實驗。在問題，工具和表明改進的指標上達成一致。在這種情況下，“失敗”不是災難。正在學習。繼續嘗試進行一些小的更改，直到你看到要改進的目標為止。有了耐心，持久性和專注力，DevOps可能是適合你企業的工具箱。
