一、DevOps是一種文化，不是角色！

軟件無處不在。在如今的世界裏，每個主流公司/組織都和軟件開發息息相關，並且公司需要向軟件一樣運作。更快且更敏捷，同時保證安全性和可靠性，這樣的要求前所未有的強烈。這樣的壓力通常體現為項目被取消或者被暫停。這正是DevOps嘗試解決的問題：如何

企業內部的開發，運維和其他組織協作，達成一系列共同的目標，更快更可靠地向客戶和終端用戶交付軟件？支持DevOps項目的核心技術實踐包括讓開發和運維團隊為軟件交互標準化一系列常見的敏捷流程和工具。這通常包括：

1.自動化的配置管理，測試和應用部署；

2.應用程序和基礎架構代碼的版本控制，助力協作和回滾；

3.CI（持續集成）自動化代碼構建，並且通過更頻繁，風險更低的版本帶來更快的反饋和叠代。

DevOps是文化的轉變，是關於每個人如何以正確的方式參與到工作當中。在軟件定義的世界裏，出現了一系列問題。

我們如何讓某些東西快速進入生產環境？我們怎麽知道使用的是最佳方案呢？我們能多快地使用改進和更新？

DevOps試圖通過盡早地在交互型流程裏涉及到所有人從而讓大家都參與進來。達到DevOps的成功需要首先理解核心業務優勢。企業能夠更快地前進，下線時間更短，並且安全問題更少。

Mike Dilowrth，敏捷和DevOps轉型領導者，最近說：

DevOps是一種文化，不是角色！整個公司都需要參與到DevOps裏才能成功。

DevOps需要高級領導層的支持，也需要和最終產品相關的所有人的參與，而不僅僅是開發和運維部門。

我之前讀過一篇Puppet的白皮書，關於如何構建高效的IT團隊。其中開始部分就提出了一些有意思的理論和實踐，這裏我想分享給大家。

DevOps和行業，公司規模以及技術環境密切相關。至少，在企業中領導過成功DevOps轉型的IT經理們，總結時都認為，DevOps指的是持續學習和改進的過程，而不是某種最終狀態。

二、構建業務用例

和很多IT領導者一樣，你想要的不僅僅是交付前所未有的多的產品和服務，而且還要更快更好地交付——並且沒有可靠性和安全性的問題。DevOps看上去確實會有所幫助！但是……在真正開始之前，你就已經開始讓團隊產生懷疑了。

怎麽才能為DevOps制定清晰，令人信服的場景，可以降低擔憂，並且將懷疑轉化為成功呢？

上面的問題是個良好的開始。構建業務場景是成功的DevOps轉型的重要部分（特別是在大型企業裏）。在一場有名的TED演講裏，Simon Sinek認為偉大領導者和積極變化的催化劑的共同點是：

讓人們信服的不是領導者在幹什麽，而是為什麽要這麽幹。

在構建企業對DevOps轉型的認同方面，也是同樣的道理。簡單宣布“我們要做DevOps”並不會讓大家真正開始。相反，你需要令人信服地回答這樣的問題“為什麽？為什麽是現在？”。你的所有客戶都希望速度更快並且不犧牲系統的可靠性和穩定性——在傳統企業裏這個目標直接自相沖突。開發人員的任務是盡可能快地讓新特性上生產環境。同時，衡量運維團隊的指標是在線時間和系統性能。因此這讓團隊之間變得對立而不是並肩作戰。因此，生產環境的部署一直被延遲和錯誤所困擾，部署發生的頻率比業務實際需要的頻率低很多。

三、讓Dev支持DevOps

更快的部署和反饋回路正是開發人員想要的：代碼可以更快地從他們的筆記本交付到用戶手裏，持續交付帶來快速的叠代和改進。在早期pilot項目裏跟蹤變更時間的改進是個不錯的開始：

1.代碼從開發的筆記本到生產環境需要多久？

2.跟之前的時間相比，有什麽改進麽？（你是不是自動化了更多的構建流程？你有沒有降低需要部署的ticket數量？）

3.現在和以前相比多久需要一次部署？

4.部署有沒有變得更為容易並且更快了呢？

四、讓Ops支持DevOps

當開發人員和運維人員緊密工作時，運維人員會受益。可以從同意使用通用的工具鏈開始，讓兩個組的人采用相同的工具一起工作，在開發中集成，測試和部署基礎架構代碼。這樣可以讓開發人員更為積極地參與到部署和問題定位中，進一步打破以前的障礙，同時提高速度和可靠性。跟蹤運維團隊關心的度量矩陣將給整個團隊帶來好處——包括Dev和QA：

1.在線/下線時間：是不是能夠更好地達到服務級別的要求？下線時間減少了麽？

2.變更失敗率：故障是不是變少了？

3.恢復的平均時間：故障發生時，回滾到已知的最近的好狀態，這樣的回滾時間是不是減少了？

五、從小處著手，持續成長

那麽，如何開始度量這些DevOps的影響，並且支持自己的業務場景呢？從有特定任務和項目的小地方開始。Terri Potts （Raytheon的傑出工程師&軟件技術總監）認為這樣的方案非常高效。

你無法一下子改變整個程序，但是可以讓一些子團隊開始嘗試正確的方向。從外部引入一些人來自動化一些測試或者build，會很有用，同時給團隊一些實際的例子。

Raytheon讓他的一個團隊從每個月兩次集成轉變為一個晚上運行27次，這是自動化了build後的結果。在單個項目裏這是一個很大的成功，這也成為了Portts如何在企業內孵化DevOps的典型示例。

從小處開始，文化轉型也要跟上——不要期望一開始就能讓所有人都信服DevOps。實際中，在特定項目的小型組織內贏得大家的支持，就贏得了會在公司其他地方幫助宣傳DevOps的大使們，這會帶來乘數效應。隨著業務場景的構建，還需要清醒認識到要達成長期DevOps成功的可能會遇到的障礙。

原文鏈接：https://dev.jlelse.eu/devops-is-a-culture-not-a-role-be1bed149b0

微信公眾號：51Reboot運維開發

DevOps是一種文化，不是角色！