[[414517]]

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

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

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

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

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

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

DevOps Radar

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

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

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

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

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

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

大型組織 DevOps 模型

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

對于規(guī)模化的組織來說，我們只需要 4 個(gè)級(jí)別，即只存在 2~5 個(gè)級(jí)別。從流程標(biāo)準(zhǔn)化和平臺(tái)化，我們已經(jīng)消滅級(jí)別 1 的存在，它們都是不合規(guī)的。與此同時(shí)，從標(biāo)準(zhǔn)化和平臺(tái)化的層面來看，事實(shí)上，我們也不存在級(jí)別 5，因?yàn)樗鼈冞^于靈活和超前。

所以，它只需要三級(jí)模型：

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

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

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

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

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

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