[[414517]]

DevOps 轉(zhuǎn)型是一件頗有挑戰(zhàn)性的工作。它并不是一個簡單的工具或者平臺的使用、運維能力提升。特別是在中大型組織中，它涉及到一系列的組織問題。

而傳統(tǒng)的 DevOps 成熟度模型過于撕裂與分散，無法適用于大型組織。DevOps 廠商與云廠商的 DevOps 成熟度模型過于關(guān)注如何賣云基礎(chǔ)設(shè)施，無助于企業(yè)進行高效的協(xié)作。

為此，我決定在 Ledge 的基礎(chǔ)上，設(shè)計上開源的、面向大型組織的 DevOps 能力成熟度模型。它是基于我們所提煉的一系列研發(fā)效能模型，抽象而成的成熟度模型。

在設(shè)計與劃分時，我們考慮的維度有兩個：

• 規(guī)?；?。對于中大型組織而言， DevOps 模型在設(shè)計時，要關(guān)注于流程化/標準化、工具化/平臺化四個規(guī)?；蛩?。即選取合適的試點團隊，構(gòu)建組織的 DevOps 能力，再進行規(guī)模化推廣。
• 組織協(xié)作性。在中大型組織內(nèi)原先已經(jīng)有一系列的 DevOps 相關(guān)的工具/平臺，如看板、流水線等。這些工具/平臺需要進行調(diào)整，以確保更好的協(xié)調(diào)性，從而更快的響應業(yè)務變化。

所以，在這個規(guī)?；?DevOps 設(shè)計與實施，我們總結(jié)出了 DevOps 的四大核心能力，又稱為四大基石。

DevOps Radar

其中，高效協(xié)同是四大基石中最重要的一部分，DevOps 的本質(zhì)所在。

高效協(xié)同。協(xié)同指的是人與人之前的協(xié)同，即業(yè)務與技術(shù)、技術(shù)與技術(shù)、技術(shù)與測試、測試與運維等。在標準化上，我們關(guān)注于：協(xié)作設(shè)計，從流程上盡可能減少浪費;組織/團隊治理，優(yōu)化團隊與組織結(jié)構(gòu)。在平臺上，我們關(guān)注于：需求管理，保障需求過程的概念完整性傳遞，如分析、拆分、協(xié)作;指標化改進;即將協(xié)同平臺作為度量指標的展示平臺，用于持續(xù)性的改進，諸如于技術(shù)技術(shù)債等。

持續(xù)交付。持續(xù)交付是指能夠按需快速、安全且可持續(xù)地發(fā)布各種類型的更改。在標準化上，我們關(guān)注于：服務化架構(gòu)，即實現(xiàn)類似于微服務架構(gòu)、服務導向架構(gòu)的架構(gòu)化方式，實現(xiàn)技術(shù)架構(gòu)能快速響應業(yè)務變化;版本管理，即從源碼源頭開始對版本進行標準化，通過分支管理、語義化版本等方式實現(xiàn)。在工具上，我們關(guān)注于：靈活變更，即通過平臺管理變更與制品;持續(xù)部署，則是與變更相關(guān)關(guān)聯(lián)的持續(xù)集成與部署。

質(zhì)量保障。質(zhì)量保障是指為最終用戶提供高質(zhì)量的軟件產(chǎn)品。在標準化上，我們關(guān)注于：測試策略，即結(jié)對質(zhì)量左移設(shè)計測試生命周期，設(shè)計測試分層模型進行指標化引導 ;測試方式，定義自動化測試、手動測試的類型、時機、準出標準等。在平臺化上，我們關(guān)注于：測試管理，諸如于用例管理與設(shè)計、測試數(shù)據(jù)管理;質(zhì)量安全，則是針對于代碼、環(huán)境等進行自動化質(zhì)量與安全相關(guān)的掃描。

環(huán)境支撐。環(huán)境支撐是指用于支撐體系所需要的基礎(chǔ)設(shè)施與運維體系。在標準化上，我們關(guān)注于：配置管理，即將基礎(chǔ)設(shè)施代碼化后，進行相應的基線配置管理、應用配置等;資源管理，即對環(huán)境的管理，以及各環(huán)節(jié)所需要的資源和環(huán)境進行管理。在平臺上，我們關(guān)注于：部署管理，即對于發(fā)布環(huán)境的管理，以及諸如灰度發(fā)布等高級部署方式的管理;運維自動化，在運維上進行自動化的監(jiān)控和警告，并支持更好的彈性發(fā)布，諸如于高可用性等。

在規(guī)劃完 DevOps 子域之后，我們可以根據(jù)組織的規(guī)模，細分子域以及對應的詳細項。如在協(xié)作設(shè)計上，可以進一步地對過程協(xié)作與角色協(xié)作進行設(shè)計。如下圖所示：

大型組織 DevOps 模型

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

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

所以，它只需要三級模型：

Level 2，規(guī)范化。從原始需求的產(chǎn)生到需求的上線，全部遵循組織內(nèi)定義的規(guī)模標準。需求協(xié)作的過程透明化，流程明確，流轉(zhuǎn)自動化;持續(xù)交付上，采用組織所定義的實踐，如語義化版本，制品來源與產(chǎn)出可信等;在質(zhì)量上，采用依據(jù)組織定義的模型設(shè)計測試策略等;在環(huán)境上，平臺能支撐起規(guī)范化所需要的設(shè)計。

Level 3，平臺標準化與自動化。將規(guī)范化的內(nèi)容，逐一在平臺上進行標準化，即定義多種技術(shù)實踐，只能從中二選一，或者三選一。四大基石，都通過這一系列標準來進行自動化。唯一值得商榷的一點是持續(xù)交付上，我們需要一個松耦合的架構(gòu)，才能支撐起單個團隊的快速交付，諸如于微服務架構(gòu)、插件化架構(gòu)等。

Level 4，指標驅(qū)動與自動改進。建立一系列的度量模型，對于軟件開發(fā)過程進行全面的度量。與此同時，團隊與平臺根據(jù)這些定義的對系統(tǒng)和平臺進行優(yōu)化。如在環(huán)境支撐上，對于應用狀態(tài)的實時監(jiān)控，實現(xiàn)自動化彈性。

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

Level 5，云研發(fā)架構(gòu)。構(gòu)建基于云端開發(fā)時的基礎(chǔ)設(shè)施架構(gòu)，諸如于云研發(fā)架構(gòu)、Serverless、Typeflow、Darklang 等，實現(xiàn)基礎(chǔ)設(shè)施的自動化與架構(gòu)的高度解耦。在質(zhì)量上，對運行時監(jiān)控，實現(xiàn)自動化測試編寫，對代碼進行靜態(tài)分析，實現(xiàn)精益測試;在協(xié)同上，通過構(gòu)建領(lǐng)域特定語言，實現(xiàn)需求生成代碼骨架;在環(huán)境上，自動實現(xiàn)灰度發(fā)布等特性。

本文轉(zhuǎn)載自微信公眾號「phodal」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系phodal公眾號。