【51CTO.com快譯】“DevOps”的全稱是“開發和運維”，但這個術語一點也不簡明扼要。開發運維已變得如此臃腫、復雜和有爭議，要是不先定義它，就沒法討論其投資回報率(ROI)。 

正確理解DevOps

想要弄清楚Devops的ROI，可以先這樣來理解DevDps：有武術，有柔術，還有柔道(這是柔術的分支，里約奧運會上出現過的項目)。而軟件開發就好比是武術，敏捷方法是柔術，開發運維則是柔道。

開發運維有六大特征，它們帶來了我們力求衡量的投資回報率：

1. 連續集成(CI)：開發人員和測試人員驗證新代碼的流程。

2. 持續交付(CD)：創建可發布工件的流程。

3. 動態云基礎設施：優化計算資源的基礎設施虛擬化。

4. 測試自動化：執行功能測試和接口測試的腳本。

5. 安全自動化：執行安全檢查的腳本，越來越多地被稱為開發安全運維(DevSecOps)。

6. 監控：不斷衡量環境，積極主動地解決問題。

開發、運維和質量保證(QA)等團隊協同工作，讓開發運維成為可能。人們搞開發運維，并非因為它是潮流、或帶有神秘色彩，而是為了滿足業務目標。坦率地說，許多公司在開發上投入了大筆開支，期望能賺到大筆收入。

[[173416]] 

記牢五個評估指標

想在擁擠不堪的應用程序商店或企業市場中競爭，技術公司就要迅速交付新產品，不斷更新產品，并嚴格確保質量。只有這樣，公司才能獲得舊的“瀑布模式”或基本的敏捷方法無法獲得的投資回報率。那么，開發運維部門應如何衡量其ROI呢?我認為，可以參考以下五個指標：

1. 更短的上市時間

開發運維部門的一些敏捷團隊每天多次發布軟件，而其他團隊發布軟件則沒有這么頻繁。市場形勢和經營戰略決定了發布的步伐。但有時候，公司需要搶在競爭對手之前，盡快將創意變成產品。率先發布，其投資回報可能會高達數十億美元。在這種情況下，我看好奉行開發運維理念的公司。

衡量上市時間很簡單。比較一下瀑布模型下的周期時間和開發運維下的周期時間。在競相進入市場的情況下，你的平均周期可以很好地表明你的團隊能做什么。正如古希臘詩人阿基洛克斯所說：“我們無法上升到我們的期望水平，而是落到我們的訓練水平。”

2. 更少的員工和更高的生產力

你可以從玻璃杯半空或玻璃杯半滿的角度來看待開發運維和人才。悲觀主義者可能會說，開發運維破壞了工作，因為它讓公司能夠用更少的人發布更多的軟件。樂觀主義者可能會說，開發運維讓公司避免雇用不必要的員工。

這兩種觀點都有其道理;無論你削減人員還是從不添加人員，開發運維都能節省資金。可以從運維團隊身上看到最顯著的差異。借助開發運維，同樣數量的人可以管理100臺或1000臺服務器。自動化使規模方面的差異顯得不再重要。

3. 沒有停機

有缺陷的代碼和不堪重負的基礎設施經常導致系統停機，因而每秒可能損失數千美元。當然，只有停機發生，它才是切實的成本。所以，大多數公司等到因停機而損失數百萬美元后才投入于開發運維。我不會怪它們。你知道有多少人擁有備用發電機以防停電嗎?除非你經歷了沒電的三個黑夜，否則不會備有發電機。

持續集成和持續交付(CI/CD)結合自動化測試和安全檢查可生成異常穩定的代碼，從而防止停機。此外，一種基于云的動態基礎設施能夠按需擴展，并自動顧及系統故障，它能減小流量波動的風險。通過自動化分配和重新分配服務器和容器，開發運維消除了原本導致系統崩潰的瓶頸。

同樣重要的是，開發運維通過利用“微服務”來應對停機，微服務是這些年來系統架構領域最重要的技術之一，也是許多開發運維團隊的一種關鍵工具。軟件平臺過去是一種單一整體式系統。如果登錄服務停止工作或變得不堪重負，平臺的其余部分就停止運行。現在，開發運維組織創建了幾十個、甚至幾百個微服務，它們都由API連接起來。如果一個微服務失效，其余微服務可以繼續工作，只要平臺設計正確。因而，微服務可以縮減停機時間，消除令人痛苦的停運。

4. 降低基礎設施成本

微服務不僅更可靠，而且成本低得多。你可以構建應用程序，只在有需要的地方添加額外的計算能力。此外，使用容器，你可以榨取最后一滴效率，從而實現每個實例最大限度地提高資源利用率。結合動態云基礎設施，你可以設置實例庫和容器庫，以便隨著工作負載的增加或減少，資源庫可以自動擴展或縮減。

一個完美的例子是亞馬遜網站。節假日期間，它要處理龐大的流量，因此按需創建額外的服務器實例。它可能發現，Tickle Me Elmo成為人人都想要的熱門玩具，于是它可以為其系統的這一個方面添加更多的計算能力。亞馬遜只把錢花在有必要投入的基礎設施上。

同樣，為了衡量開發運維的投資回報率，要關注長期的變化。在早期(即瀑布開發年代)，你在虛擬機上花了什么?現在你又花了什么?還要考慮到用戶群規模以及你所提供服務的范圍。

5. 提高應用程序的質量和性能

質量和性能是很難衡量的特征。它們影響三種類型的衡量指標：服務單(service ticket)、使用模式和需求信號。你要以不同的方式來衡量這些，具體取決于貴公司。

假設你為內部客戶開發企業應用程序。你在發布后的頭48小時內生成多少服務單?最終用戶如何與新功能進行交互?牢記一點：如果用戶沒有與新功能進行交互，不會生成任何服務單。多少現有用戶下載最新版本、下載速度有多快?

反過來，如果你為外部客戶開發企業應用程序，要關注客戶服務活動、使用模式和銷售活動。如果是面向消費者的應用程序，你可以查看應用程序商店上的評分、使用模式、下載次數和應用程序商店的轉化率。

針對時間不夠用的人

實施開發運維的投資回報率挺復雜。因為開發運維對運維成本和收入方面改善很多，以致于企業很難計算所有好的一面。不過，如果你是時間有限的CTO或CIO，好處很明確。成功標準就是更穩定、更安全、更頻繁發布的代碼。

無論IT達到何種水平，團隊都會得益于開發運維方法帶來的更快速度、更高質量和一致性。這方面根本不存在臃腫、復雜或有爭議的東西。

原文標題：The ROI of DevOps: 5 Key Metrics，作者： Guest Author

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】