DevOps就是轉向基於產品的管理。實際上，這意味著專案不再有“結束日期”，而團隊則通過提供功能不斷提供價值。實現這一目標的一個重要部分是整合價值流中的團隊，從開發到運營; 一些組織甚至包括業務利益相關者。在DevOps模型中，軟體是作為產品進行維護，跟蹤業務持續交付和不斷實現價值指標。

一家傳統軟體公司很少釋出其旗艦產品 - 每隔幾年就很少釋出。每個版本都可以包含數百個新功能和改進。由於版本很少釋出，因此使用者可能會不耐煩地等待每個新版本，並在最終獲得時時感激不盡。

但是，當發現錯誤並且功能無法按預期工作時，會導致失望。在巨大壓力和巨大動盪的情況下，緊急釋出並投入生產（常規釋出過程匆匆忙忙，通常會跳過測試），產品中還有更多的錯誤。這樣的過程重複進行，導致更多沮喪，壓力和失望。更糟糕的是，由於懷疑，不確定性以及IT部門提供價值的能力的不信任，新的商業機會被遺漏或忽視。（banq注：無充分市場競爭的環境會導致甲方效率降低，組織部門被IT扼殺！）

有沒有更好的方法？

對於採取DevOps軟體開發和交付方法的公司來說，這種做法已成為過去。新版本經常釋出：通常是每週或每天。錯誤很快得到修復。熱情和自信地尋求新的商機。通過快速迭代釋出，修改和改進新功能。一個案例表明，該公司能夠每11秒提供一個新的軟體功能。

您更喜歡這些軟體團隊中的哪一個？哪些公司將在其行業的數字化轉型中獲勝？

與傳統的軟體開發方法（通常稱為階段門或瀑布）相比，DevOps為組織提供了戰略優勢，領導力在轉型過程中發揮著重要作用。事實上，Gartner預測，到2020年尚未改變其團隊能力的CIO將會被取代。

數字化轉型的承諾與挑戰

對於希望獲得市場份額並更快地交付價值（甚至只是更安全，更安全地交付軟體）的組織，DevOps承諾速度和穩定性。4它已成為現代組織中數字化轉型的一個突出現象，它使用軟體為銀行，零售甚至製造業等行業的客戶創造價值。DevOps結合了軟體開發和交付的活動，以提高向客戶提供新軟體功能的速度。這可以提高客戶滿意度和盈利能力，這是組織層面的重要成果。它還可以帶來重要的團隊級成果，例如不同部門（如開發人員，測試人員和IT運營部門）之間的更好協作以及改善的工作與生活平衡。

執行成功的DevOps轉換並非沒有挑戰。組織和軟體產品的成熟度和實施方式各不相同，因此難以跨團隊和組織設計和部署轉型工作。最重要的是，要讓DevOps真正實現價值，它必須包括的不僅僅是工具和自動化 - 所以簡單地購買和安裝解決方案是不夠的。如此處所述，DevOps包括文化，流程和技術。事實上，成功案例比比皆是：Kaiser Permanente，Capital One，Target，Starbucks和ING等公司採用了DevOps方法，允許他們在幾秒鐘內為關鍵應用程式提供軟體。

DevOps增強了從應用程式到基礎架構配置的自動化。持續交付支援自動化，通過快速反饋週期加快產品上市速度和敏捷軟體開發。由於這種現象在實踐中相對較新，從業者報告了與領導力和文化轉型，實施持續交付管道以及在團隊環境中整合協作文化等問題的鬥爭。

拋棄傳統專案管理

DevOps方法的特點是軟體交付的處理方式發生了變化：從一個獨立的專案轉變為一個持續的產品。傳統的軟體交付方式（以前稱為階段門或瀑布）是在專案管理的幫助下進行的。在這個正規化中，專案通常“結束”的標誌是：新軟體的第一個主要版本或主要增量版本釋出。一般而言，專案團隊在新版本釋出後解散，然後執行系統的責任被“拋到牆上”甩給運維團隊。運營團隊負責進一步的變更和事件管理。這導致了幾個問題：

•開發人員不負責執行他們構建的系統，因此不瞭解在建立和執行系統時是否出現權衡，尤其是軟體的可擴充套件性和可靠性。這可能導致在未來的軟體版本中出現相同的問題，即使操作團隊很好地理解它們。

•運營團隊負責維護高度可靠和穩定的系統。每個新的軟體部署線都會引入變化，從而導致不穩定。

•生產環境（包括開發人員和業務）上游的利益相關者（即開發流程的早期階段）在第一次完整發布之前無法收到有關效能的任何反饋。並非軟體中的所有功能都能提供價值，加快對開發團隊和業務的反饋可以加快迭代速度以優化軟體。這會導致浪費時間和資源，而這些功能最終無法帶來價值。例如，微軟的研究表明，只有三分之一的精心設計的功能為客戶帶來了價值。

相比之下，DevOps要求轉向基於產品的管理。實際上，這意味著專案不再有“結束日期”。

DevOps的最新研究與實踐

行業中最大的挑戰之一是缺乏DevOps的正式定義。許多從業者認為這是故意的，因為它允許團隊和組織採用適合他們的定義。此外，他們指出，對敏捷的正式定義（在敏捷宣言中編碼）並沒有解決定義蔓延的問題，並且當一個組織說它“變得敏捷”時，由此產生的混淆真正意味著什麼困擾著整個行業。這種缺乏理解可能具有挑戰性，因此我們提供一些共同的定義供參考。

1. •“DevOps是一種軟體開發和交付方法，可以提高速度和穩定性，同時為組織提供價值。” 
2. •“DevOps，無論是在運營工程師接受開發任務的情況下還是在開發人員在運營領域工作的情況下，都是努力使這兩個學科更加接近。” 
3. •“DevOps，'開發'和'運營'的複合體，是一種專為高速度而設計的軟體開發和交付方法。” 

將其結為CALMS：文化，自動化，精益，測量和共享，以下是每個元件的簡要定義：

• 文化。融合相互信任，學習和持續改進的意願，不斷的資訊流，對開發人員和運營之間的變革和實驗的開放態度。
• 自動化。實現具有高度自動化的部署管道（最值得注意的是持續整合/持續交付）和全面的測試自動化。
• 精益。應用精益原則，例如最小化正在進行的工作，以及縮短和放大反饋迴路，以識別和最小化價值流中斷，從而提高效率。
• 測量。監控關鍵系統指標，例如業務或交易指標和其他關鍵績效指標。
• 分享。在組織和跨組織邊界共享知識。團隊成員應該相互學習經驗並積極溝通。

CALMS的解釋

本文使用CALMS的五個核心元素作為框架。

1.文化

作為DevOps團隊的一員，需要 在跨職能團隊環境中建立協作文化。在理想狀態下，DevOps使用所謂的跨職能團隊，這意味著由開發人員，測試人員，質量保證專業人員和IT運營工程師組成的團隊共同合作開發和交付軟體。通過這種方式，他們熟悉彼此的工作和挑戰（描述這一點的常用詞語是“有同理心”），這有助於他們建立和維護更好的軟體。例如，因為他們看到了維護運營專業人員遇到的可擴充套件和可靠基礎架構所面臨的挑戰，開發人員與運營人員合作編寫了更具可擴充套件性和可靠性的代

 

2.自動化

接下來的原則， 自動化，需要一整套的DevOps工具。以下是可用的自動化工具的幾個例子：

 

構建

•構建。用於軟體開發和服務生命週期的工具，包括編譯程式碼，管理依賴關係，建立文件，進行測試以及在不同階段部署應用程式。

• 持續整合。不斷測試新的軟體元件。

 

釋出

•釋出自動化。將軟體元件從所有環境中的開發打包並部署到生產中。

•版本控制。管理對程式的更改並收集其他資訊。版本控制是配置管理的一個元件。

•測試自動化。使用軟體執行測試和重複活動。

 

部署

• 配置管理。藉助在開發階段複製生產系統，減少生產配置和配置維護。

•持續交付。旨在實現不間斷部署的原則，實踐和模式的組合。

 

運維

•記錄。跟蹤對於應用程式管理至關重要; 一切都必須記錄下來。

•監測。在客戶注意到之前識別基礎設施問題。監控儲存，網路流量，記憶體消耗等

 

持續整合和交付降低了釋出軟體的成本和風險。他們通過將自動化和良好實踐相結合，以一致，可靠和可重複的方式執行工作（例如測試和構建），從而在軟體交付過程中實現快速反饋並建立質量。這有助於團隊更快，更可靠地交付功能，從而為組織實現更快的價值交付。效能最高的團隊能夠比低績效團隊更頻繁地部署46倍，交付時間縮短2,555倍。故障率降低了7倍，並且能夠比效能較低的同行快恢復2,604倍。

精益

“構建質量” 是DevOps的一個關鍵原則，也是精益中的一個原則。應用於DevOps，這意味著團隊尋找機會去除浪費，利用反饋迴圈並優化自動化。

我們來看一個例子。DevOps團隊的規模和產品責任各不相同。在某些模型中，單個團隊執行所有軟體開發和交付活動，包括開發，測試，交付和維護。他們最終負責軟體產品的完整軟體交付生命週期（並且可能負責多個產品），為業務帶來價值。精益流程允許在整個開發和交付過程中快速迭代和反饋，以提高質量並構建更快，更可靠的系統。示例包括小批量工作以實現快速流過開發流程，限制正在進行的工作，修復發現時與最後發生的錯誤，並在安全輸入上“向左移動”。

這些做法聽起來很熟悉; 類似的做法推動了製造業的質量和價值。（有關精益製造一個偉大的故事，看看這個美國生活的插曲561 11，其中討論了NUMMI（新聯合汽車製造股份有限公司），在Fremont，CA豐田和通用的合資公司）

 

測量

測量是DevOps的另一個核心方面。監控和觀察系統的能力很重要，因為軟體開發和交付基本上處理的是無形的庫存，這些庫存以無法觀察到的複雜方式進行互動。（這與NUMMI案例中描述的傳統物理製造系統（如汽車裝配線）形成鮮明對比。）

通過有效的監控，團隊能夠在整個軟體交付生命週期中跟蹤，觀察，測量和除錯他們的系統。應該注意的是，度量標準也是質量保證的工具，應該利用來自多個來源的測量。

 

分享

知識和資訊的共享使DevOps團隊成功，並有助於擴大他們的成功。通過在團隊內，整個組織內以及整個行業內共享實踐 - 包括成功和失敗 - ，團隊從其他人的學習中受益，並更快地提高。雖然其他人已經指出可以在任何領域和任何方法中進行共享，但DevOps已將此作為一種文化規範，並且許多業內人士報告說，該領域比以前的技術工作更具協作性。

內部協作可能包括工作陰影或工作交換：開發人員參與操作和維護活動（例如，開發人員甚至可能“接收尋呼機”），運維工程師輪流進入開發和測試角色，學習設計和測試的基本元件工作。在許多情況下，所有跨職能團隊成員都參加同一會議，這為他們提供了共享的背景。跨行業共享經常在會議上進行，數十個DevOpsDays和其他社群組織的活動在世界各地蓬勃發展。

這些原則的應用可以帶來更好的結果：對於個人（在減少職業倦怠和更高的工作滿意度方面），對於團隊（在更好的軟體交付結果和更好的團隊文化中看到）和組織（從改善績效等方面看到的組織）盈利能力，生產力，客戶滿意度和效率.