詳解中大型組織DevOps成熟度模型

大雄45發表於2021-08-13
導讀 DevOps 轉型是一件頗有挑戰性的工作。它並不是一個簡單的工具或者平臺的使用、運維能力提升。特別是在中大型組織中,它涉及到一系列的組織問題。

詳解中大型組織DevOps成熟度模型詳解中大型組織DevOps成熟度模型
DevOps 轉型是一件頗有挑戰性的工作。它並不是一個簡單的工具或者平臺的使用、運維能力提升。特別是在中大型組織中,它涉及到一系列的組織問題。

而傳統的 DevOps 成熟度模型過於撕裂與分散,無法適用於大型組織。DevOps 廠商與雲廠商的 DevOps 成熟度模型過於關注如何賣雲基礎設施,無助於企業進行高效的協作。

為此,我決定在 Ledge 的基礎上,設計上開源的、面向大型組織的 DevOps 能力成熟度模型。它是基於我們所提煉的一系列研發效能模型,抽象而成的成熟度模型。

在設計與劃分時,我們考慮的維度有兩個:

規模化。對於中大型組織而言, DevOps 模型在設計時,要關注於流程化/標準化、工具化/平臺化四個規模化因素。即選取合適的試點團隊,構建組織的 DevOps 能力,再進行規模化推廣。
組織協作性。在中大型組織內原先已經有一系列的 DevOps 相關的工具/平臺,如看板、流水線等。這些工具/平臺需要進行調整,以確保更好的協調性,從而更快的響應業務變化。
所以,在這個規模化的 DevOps 設計與實施,我們總結出了 DevOps 的四大核心能力,又稱為四大基石。
詳解中大型組織DevOps成熟度模型詳解中大型組織DevOps成熟度模型
DevOps Radar

其中,高效協同是四大基石中最重要的一部分,DevOps 的本質所在。

高效協同。協同指的是人與人之前的協同,即業務與技術、技術與技術、技術與測試、測試與運維等。在標準化上,我們關注於:協作設計,從流程上儘可能減少浪費;組織/團隊治理,最佳化團隊與組織結構。在平臺上,我們關注於:需求管理,保障需求過程的概念完整性傳遞,如分析、拆分、協作;指標化改進;即將協同平臺作為度量指標的展示平臺,用於持續性的改進,諸如於技術技術債等。

持續交付。持續交付是指能夠按需快速、安全且可持續地釋出各種型別的更改。在標準化上,我們關注於:服務化架構,即實現類似於微服務架構、服務導向架構的架構化方式,實現技術架構能快速響應業務變化;版本管理,即從原始碼源頭開始對版本進行標準化,透過分支管理、語義化版本等方式實現。在工具上,我們關注於:靈活變更,即透過平臺管理變更與製品;持續部署,則是與變更相關關聯的持續整合與部署。

質量保障。質量保障是指為終端使用者提供高質量的軟體產品。在標準化上,我們關注於:測試策略,即結對質量左移設計測試生命週期,設計測試分層模型進行指標化引導 ;測試方式,定義自動化測試、手動測試的型別、時機、準出標準等。在平臺化上,我們關注於:測試管理,諸如於用例管理與設計、測試資料管理;質量安全,則是針對於程式碼、環境等進行自動化質量與安全相關的掃描。

環境支撐。環境支撐是指用於支撐體系所需要的基礎設施與運維體系。在標準化上,我們關注於:配置管理,即將基礎設施程式碼化後,進行相應的基線配置管理、應用配置等;資源管理,即對環境的管理,以及各環節所需要的資源和環境進行管理。在平臺上,我們關注於:部署管理,即對於釋出環境的管理,以及諸如灰度釋出等高階部署方式的管理;運維自動化,在運維上進行自動化的監控和警告,並支援更好的彈性發布,諸如於高可用性等。

在規劃完 DevOps 子域之後,我們可以根據組織的規模,細分子域以及對應的詳細項。如在協作設計上,可以進一步地對過程協作與角色協作進行設計。如下圖所示:
詳解中大型組織DevOps成熟度模型詳解中大型組織DevOps成熟度模型
大型組織 DevOps 模型

考慮到這是一個成熟度模型,所以我們還需要定義成熟度的級別。通常來說,一個成熟度模型應該是從 1~5,又或者是 0~4 四個級別。

對於規模化的組織來說,我們只需要 4 個級別,即只存在 2~5 個級別。從流程標準化和平臺化,我們已經消滅級別 1 的存在,它們都是不合規的。與此同時,從標準化和平臺化的層面來看,事實上,我們也不存在級別 5,因為它們過於靈活和超前。

所以,它只需要三級模型:

Level 2,規範化。從原始需求的產生到需求的上線,全部遵循組織內定義的規模標準。需求協作的過程透明化,流程明確,流轉自動化;持續交付上,採用組織所定義的實踐,如語義化版本,製品來源與產出可信等;在質量上,採用依據組織定義的模型設計測試策略等;在環境上,平臺能支撐起規範化所需要的設計。

Level 3,平臺標準化與自動化。將規範化的內容,逐一在平臺上進行標準化,即定義多種技術實踐,只能從中二選一,或者三選一。四大基石,都透過這一系列標準來進行自動化。唯一值得商榷的一點是持續交付上,我們需要一個松耦合的架構,才能支撐起單個團隊的快速交付,諸如於微服務架構、外掛化架構等。

Level 4,指標驅動與自動改進。建立一系列的度量模型,對於軟體開發過程進行全面的度量。與此同時,團隊與平臺根據這些定義的對系統和平臺進行最佳化。如在環境支撐上,對於應用狀態的實時監控,實現自動化彈性。

對於第 5 級來說,視不同的組織情況,略有不同。如我們所定義的是:

Level 5,雲研發架構。構建基於雲端開發時的基礎設施架構,諸如於雲研發架構、Serverless、Typeflow、Darklang 等,實現基礎設施的自動化與架構的高度解耦。在質量上,對執行時監控,實現自動化測試編寫,對程式碼進行靜態分析,實現精益測試;在協同上,透過構建領域特定語言,實現需求生成程式碼骨架;在環境上,自動實現灰度釋出等特性。

原文來自: https://www.linuxprobe.com/devops-maturity-model.html

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69955379/viewspace-2786911/,如需轉載,請註明出處,否則將追究法律責任。

相關文章