[[196812]]

軟件無處不在。在如今的世界里，每個主流公司/組織都和軟件開發息息相關，并且公司需要向軟件一樣運作。更快且更敏捷，同時保證安全性和可靠性，這樣的要求***的強烈。這樣的壓力通常體現為項目被取消或者被暫停。這正是DevOps嘗試解決的問題：如何讓企業內部的開發，運維和其他組織協作，達成一系列共同的目標，更快更可靠地向客戶和終端用戶交付軟件?支持DevOps項目的核心技術實踐包括讓開發和運維團隊為軟件交互標準化一系列常見的敏捷流程和工具。這通常包括：

• 自動化的配置管理，測試和應用部署;
• 應用程序和基礎架構代碼的版本控制，助力協作和回滾;
• 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項目里跟蹤變更時間的改進是個不錯的開始：

• 代碼從開發的筆記本到生產環境需要多久?
• 跟之前的時間相比，有什么改進么?(你是不是自動化了更多的構建流程?你有沒有降低需要部署的ticket數量?)
• 現在和以前相比多久需要一次部署?
• 部署有沒有變得更為容易并且更快了呢?

讓Ops支持DevOps

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

• 在線/下線時間：是不是能夠更好地達到服務級別的要求?下線時間減少了么?
• 變更失敗率：故障是不是變少了?
• 恢復的平均時間：故障發生時，回滾到已知的最近的好狀態，這樣的回滾時間是不是減少了?

從小處著手，持續成長

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

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

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

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