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

正確理解DevOps

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

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

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

2. 持續(xù)交付(CD)：創(chuàng)建可發(fā)布工件的流程。

3. 動態(tài)云基礎設施：優(yōu)化計算資源的基礎設施虛擬化。

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

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

6. 監(jiān)控：不斷衡量環(huán)境，積極主動地解決問題。

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

[[173416]] 

記牢五個評估指標

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

1. 更短的上市時間

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

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

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

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

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

3. 沒有停機

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

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

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

4. 降低基礎設施成本

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

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

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

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

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

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

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

針對時間不夠用的人

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

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

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

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