ICS35.240

CCSL78

YD

中華人民共和國通信行業標準

YD/TXXXX—XXXX

云原生能力成熟度模型

第2部分：業務應用

Cloudnativecapabilitymaturitymodel—Part2:Application

（報批稿）

XXXX-XX-XX發布XXXX-XX-XX實施

中華人民共和國工業和信息化部發布

YD/TXXXXX—XXXX

前言

本文件按照GB/T1.1-2020《標準化工作導則第1部分：標準化文件的結構和起草規則》的規定起

草。

本文件是云原生能力成熟度系列標準之一。該標準的結構和名稱預計如下：

-第1部分：技術平臺。

-第2部分：業務應用。

-第3部分：安全架構。

-第4部分：電信行業IT業務系統。

-第5部分：中間件平臺服務。

請注意本文件的某些內容可能涉及專利。本文件的發布機構不承擔識別這些專利的責任。

本文件由中國通信標準化協會提出并歸口。

本文件起草單位：中國信息通信研究院、阿里云計算有限公司、騰訊科技（深圳）有限公司、騰訊

云計算（北京）有限責任公司、華為技術有限公司、杭州諧云科技有限公司、上海安暢網絡科技股份有

限公司、螞蟻科技集團股份有限公司、中國電信集團有限公司、中國移動通信集團有限公司

本文件主要起草人：閆丹、劉如明、栗蔚、陳屹力、鄒文浩、朱松、厲啟鵬、任秀森、張琦、高巍、

才振功、徐運元、方佳偉、鄭然、馬洪喜、陳曉露、張瑋、俞仁杰、郭旸、胡建華、陶捷、陳鵬翔、李

雪、白國濤、陳航、王勇、蘇龍華、朱祥磊。

II

YD/TXXXXX—XXXX

引言

伴隨著云原生日益成熟，容器、微服務、服務網格等云原生技術逐步在企業業務應用研發建設中落

地應用。為評估基于云原生構建的企業業務應用能力成熟度水平，促進云原生技術廣泛落地，開展云原

生能力成熟度模型標準化活動勢在必行。《云原生能力成熟度模型》擬由5部分構成。

-第1部分：技術架構。目的在于規范云原生技術架構和服務能力，指導服務提供商和用戶建設云

原生技術平臺。

-第2部分：業務應用。目的在于指導用戶基于云原生的業務應用系統建設路徑，幫助用戶提升云

原生應用水平。

-第3部分：安全架構。目的在于規范云原生安全架構和服務能力，指導服務提供商和用戶提高云

原生平臺和應用的安全水平。

-第4部分：電信行業IT業務系統。目的在于指導電信行業用戶基于云原生的IT業務系統的建設路

徑，幫助電信行業用戶提升云原生應用水平。

-第5部分：中間件平臺服務。目的在于規范中間件平臺服務能力，指導服務提供商和用戶建設中

間件平臺服務。

III

YD/TXXXXX—XXXX

云原生能力成熟度模型第2部分：業務應用

1范圍

本文件規定了基于云原生構建的業務應用的能力成熟度評估模型，從基礎設施域、應用研發域、

服務治理域等三個方面評估云原生業務應用在彈性、高可用、自愈性、可觀測性以及自動化等方面的

云原生能力成熟度。

本文件適用于企業在基于云原生構建業務應用過程中，對業務應用的云原生化程度進行評估，也適

用于為企業提供業務應用向云原生轉型的參考和指引。

2規范性引用文件

下列文件對于本文件的應用是必不可少的。凡是注日期的引用文件，僅注日期的版本適用于本文件。

凡是不注日期的引用文件，其最新版本（包括所有的修改單）適用于本文件。

ISO/IECTS23167:2020信息技術云計算通用技術（InformationtechnologyCloudcomputing

Commontechnologiesandtechniques）

3術語和定義

GB/T11457-2006、ISO/IECTS23167:2020界定的以及下列術語和定義適用于本文件。

3.1

云原生應用程序cloudnativeapplication

明確設計為在云服務中運行并利用云服務的功能和環境的應用程序。

[來源：ISO/IECTS23167:2020，3.6]

3.2

云原生cloudnative

面向云應用設計的一種思想理念，充分發揮云效能的最佳實踐路徑，幫助企業構建彈性可靠、松耦

合、易管理、可觀測的應用系統，提升交付效率，降低運維復雜度。

3.3

云原生業務應用cloudnativebussinessapplication

用于幫助企業解決業務需求云原生應用程序（3.2），具備彈性、高可用、自愈性、可觀測性以及

自動化等特性，以下簡稱云原生應用。

3.4

容器container

一種進程級的虛擬化隔離技術。

3.5

1

YD/TXXXXX—XXXX

服務器無感知serverless

將基礎設施資源抽象成按需使用的服務，用戶只需關注應用邏輯，而無需管理復雜的基礎設施運維

工作的設計模式。

3.6

彈性elasticity

云原生應用按照業務需求靈活進行規模化的擴容和縮容能力，包括基礎設施資源層面與應用實例

層面。

3.7

高可用highavailability

通過應用容災、數據備份等手段，以減少服務中斷時間為目的，保證云原生應用的可靠性和可維護

性。

3.8

自愈性selfhealing

云原生應用通過故障自動發現、預判分析和故障應對等流程，實現對于異常或故障后自我恢復的能

力。

3.9

可觀測性oberservability

通過日志、監控、鏈路跟蹤等交叉分析，進行云原生業務應用更加深入地服務健康度量，從而實現

分布式應用架構下故障排錯、剖析以及依賴分析能力。

3.10

自動化automatic

云原生應用運維自動化以及交付部署自動化。

4云原生業務應用成熟度模型

4.1概述

云原生業務應用成熟度模型從企業業務應用基礎設施域、應用研發域以及服務治理域等三個能力

域二十個過程域綜合評估企業業務應用在彈性、高可用、自愈性、可觀測性以及自動化等五個維度的云

原生能力成熟度水平。

——基礎設施域：評估企業業務應用底層計算、存儲以及網絡等基礎設施資源的云原生化程度以及

基礎設施層運維方式和能力；

——應用研發域：從架構設計、開發構建、測試管理以及部署發布等企業業務應用研發關鍵環節能

力水平；

2

YD/TXXXXX—XXXX

——服務治理域：從企業業務應用發布上線后，評估云原生業務應用在應用層面運維運營支撐能力

水平。

4.2云原生業務應用特性成熟度評估方法

云原生業務應用特性包括彈性、高可用、自愈性、可觀測性以及自動化等，其成熟度評估以及對應

能力域與過程域成熟度等級綜合計算，具體對應關系如表1所示：

表1云原生業務應用特性成熟度

云原生業務應用特性

能力域過程域

彈性高可用自愈性可觀測性自動化

基礎設施資源√√√

基礎設施域（I1）

（I）基礎設施運維√√

（I2）

架構設計（D1）√√

應用研發域開發構建（D2）√√

（D）測試管理（D3）√

部署發布（D4）√√

注冊發現（G1）√√√√

流量管理（G2）√√√√

服務容錯（G3）√√√

服務降級（G4）√√

服務治理域

故障注入（G5）√√√√

（G）

鏈路跟蹤（G6）√√√

應用監控（G7）√√√√

日志管理（G8）√√√√

配置管理（G9）√√√

根據云原生業務應用特性成熟度對照表（表1），云原生業務應用特性成熟度計算方法如下：

——彈性能力成熟度=(I1+D1+D2+D4+G1+G2+G5+G6+G7+G8)/10

——高可用能力成熟度=(I1+D1+G1+G2+G3+G5+G7+G8+G9)/9

——自愈性能力成熟度=(I1+G1+G2+G3+G4+G5+G9)/7

——可觀測性能力成熟度=(I2+G6+G7+G8)/4

——自動化能力成熟度=(I1+I2+D2+D3+D4+G1+G2+G3+G4+G5+G6+G7+G8+G9)/14

4.3云原生業務應用綜合成熟度評估方法

云原生業務應用綜合成熟度根據基礎設施域、應用研發域以及服務治理域成熟度綜合計算，共分為

五級，具體如表2所示：

3

YD/TXXXXX—XXXX

表2云原生業務應用綜合成熟度等級定義

級別英文中文定義

1級InitialLevel初始級未實現任何云化改造，完全基于傳統應用架構

基礎設施層基本完成云化改造，但仍基于傳統應

2級FundamentalLevel基礎級

用架構，應用服務具備有限的彈性和容災能力

基礎設施層完成云化改造，應用架構層服務化改

3級ComprehensiveLevel全面級造持續進行，應用具備一定的彈性和高可用，實

現多維度的應用監控

基礎設施層探索服務器無感知化改造，應用架構

4級ExcellentLevel優秀級層服務化，應用具備彈性、高可用，基本實現服務

自愈，可觀測以及自動化

基礎設施層逐步實現服務器無感知化，應用架構

5級FabulousLevel卓越級層持續演進，應用全面實現彈性、高可用、服務自

愈、可觀測以及自動化和智能化交付

云原生業務應用綜合成熟度計算方法如下：

云原生業務應用綜合成熟度=∑（彈性能力成熟度+高可用成熟度+自愈性成熟度+可觀測性成熟

度+自動化成熟度）/5

或

云原生業務應用綜合成熟度=∑（∑I/2+∑D/4+∑G/9）/3

5基礎設施域能力要求

5.1基礎設施資源

基礎設施資源是指云原生應用所托管在的底層基礎設施資源部署形態，其能力要求如表3所示。

表3基礎設施資源能力要求

級別基礎設施資源

1應用系統可直接部署在未進行任何形式云化的物理機上。

2應用系統應以部署在云化的資源池上為主，基礎設施資源實現按需使用。

在2級基礎上，支持以下能力要求：

31）應用系統應以容器化部署方式為主；

2）應實現不同團隊共用基礎設施資源情況下，實現租戶級應用隔離。

在3級基礎上，支持以下能力要求：

1）應用系統應以部署在容器云上為主；

42）應用系統應支持部署于異構基礎設施資源上；

3）應支持跨云的基礎設施資源互通和應用遷移；

4）應支持容器鏡像自動化構建及版本管理能力；

4

YD/TXXXXX—XXXX

5）應采用不可變基礎設施；

6）應采用基礎設施即代碼能力，即通過代碼實現基礎設施資源的配置和管理；

7）可實現百節點容器規模的擴縮容，且擴縮容時間宜控制在3分鐘內。

在4級基礎上，支持以下能力要求：

51）可在部分業務場景下應用服務器無感知化架構；

2）可實現千節點容器規模的擴縮容，且擴縮容時間宜控制在3分鐘內。

5.2基礎設施運維

基礎設施運維是指云原生應用底層基礎設施的運維方式，其能力要求如表4所示。

表4基礎設施運維能力要求

級別基礎設施運維

1基礎設施運維可以運維人員手動運維方式進行。

1）應支持腳本化運維；

2

2）應支持以手動方式實現基礎設施資源擴縮容。

1）應支持自動化方式實現基礎設施資源擴縮容；

3

2）基礎設施運維層應具備統一的運維視圖。

在3級基礎上，支持以下能力要求：

1）應具備基礎設施資源的自動化運維平臺，例如自動化巡檢、自動化配置下發及自動化配

4

置管理等；

2）應實現故障預警。

在4級基礎上，支持以下能力要求：

1）應用運維與基礎設施運維關注點應分離，業務項目團隊不再關注基礎設施資源的運維，

更關注應用構建、發布、保障等；

52）應支持異構資源下統一的運維配置；

3）應支持基礎設施變更版本記錄且可追溯；

4）應實現基礎設施資源故障自愈；

5）應支持基礎設施資源的智能化運維。

6應用研發域能力要求

6.1架構設計

架構設計是指云原生應用架構設計模式，其能力要求如表5所示。

表5架構設計能力要求

級別架構設計

1）應用系統可采用單體架構；

12）不可實現基于進程模型的水平擴展；

3）組件間可存在共享狀態。

1）應用系統應采用分布式架構；

22）應用設計基于進程模型；

3）應支持應用的水平擴展。

5

YD/TXXXXX—XXXX

在2級基礎上，支持以下能力要求：

1）應支持守護進程與應用分離，實現應用服務的按需啟動和中止；

2）應將所依賴的其它組件當作資源使用，降低強依賴組件數量；應支持通過穩定端口綁定

提供服務；

3

3）應支持日志信息通過事件流輸出；

4）進程間不應有共享狀態；

5）降低業務邏輯和非業務邏輯能力耦合，支持業務應用的按需啟動和中止；

6）應用架構設計應充分考慮特性開關，可靈活線上提供或屏蔽應用功能。

在3級基礎上，支持以下能力要求：

1）可實現基于彈性視角的架構設計，例如彈性依賴、鏡像復制與實例化運行等；

4

2）對應用所依賴的組件進行內部零信任處理，服務間請求應進行鑒權；

3）應實現服務快速啟動和優雅中止。

在4級基礎上，支持以下能力要求：

51）利用云的能力，實現云原生的演進式架構設計；

2）可充分利用云原生的生態，使用云相關服務。

6.2開發構建

開發構構建過程域共包括版本管理、集成構建、依賴管理、開發環境準備、開發體驗等5個維度，

具體能力要求如表6所示。

--版本管理：對云原生應用系統的版本信息等進行管理的能力；

--集成構建：云原生應用系統的集成構建方式；

--依賴管理：云原生應用系統所依賴的組件或庫的管理方式；

--開發環境管理：云原生應用所使用開發環境的管理能力；

--開發體驗：云原生應用系統開發環境的體驗滿意度。

表6開發構建能力要求

級別版本管理集成構建依賴管理開發環境管理開發體驗

1）可以手工方

1）無顯式聲明

1）無法基于可式搭建所開發組

的組件或庫的依

自執行包進行構件的運行環境和

賴關系；

建，例如使用WAR依賴，無法實現

1）應將應用源2）應用所依賴

而非JAR等；開發環境的快速

代碼納入版本管的庫可不在包

2）運行時可根構建與可重復；應用開發難以完

理；內，需要在運行

1據需要依賴額外2）開發環境與全進行本機開

2）多個應用可時準備；

中間件，例如Web線上環境可不等發、測試與調試。

共用一份基準代3）所依賴的系

容器；價，如只能通過

碼。統組件可能會因

3）可以人工方本地修改再上傳

為系統環境變化

式進行代碼的編線上環境的方

而受到影響，例

譯構建。式，在線進行開

如Curl。

發和調試；

6

YD/TXXXXX—XXXX

3）不支持不同

的運行環境區

分。

在1級基礎上，支

1）應支持基于

持以下能力要

架構設計和測試

求：

策略，通過本地

1）應用組件的1）應支持自動

IDE或Editor，在

依賴信息作為應化、可重復的搭

1）基于可自執本地進行組件的

用源代碼的一部建所開發組件依

行包進行構建和應用開發、測試

分，應納入版本賴的環境；

制品管理；與調試，但需要

管理，實現同步2）應支持區分

2）運行時應無應支持通過顯式本地安裝啟動或

變更；不同的運行環

需依賴額外的第方式聲明組件或遠程調用所依賴

22）配置信息與境，例如開發環

三方庫；庫的依賴關系。的跨進程組件；

應用源代碼分境、測試環境、

3）制品應有專2）難以獨立開

離，配置信息應UAT環境、生產環

門的制品庫統一發、調試和測試

納入版本管理；境等；

管理。單一應用組件，

3）部署和發布3）開發環境可

過程中可本機啟

腳本應納入版本與線上環境存在

動并運行系統內

管理。差異。

的其它相關應用

4）一份基準代

組件，或實際調

碼應僅對應一個

用遠程組件。

應用；

在2級基礎上，支1）應支持基于

持以下能力要良好的架構設計

在2級基礎上，支1）基于直接鏡

求：和測試策略，通

持以下能力要像（例如容器鏡

在2級基礎上，支1）應支持通過過本地IDE或

求：像）而非基礎鏡

持以下能力要Docker或等效的Editor，在較少

1）應用所依賴像（例如VM鏡像）

求：多容器管理工的環境依賴下進

的系統環境定義進行構建和制品

1）應用所依賴具，面向組件快行組件的應用開

代碼作為應用源管理；

的庫在構建時應速搭建并啟動所發、測試與調試，

代碼的一部分，2）配置信息應

被打入包內，所開發組件的環境所有其它跨進程

應共同納入版本通過配置管理服

依賴的系統工具和依賴；組件依賴均通過

3化管理，實現同務器讀取，并通

（如gradle、2）應支持通過容器實例運行；

步變更；過全局變量進行

curl等）應當被配置管理，基于2）應支持在開

2）代碼庫管理加載；

包含在應用之直接鏡像生成的發、調試以及非

應具備精細化的4）應通過制品

中；不可變容器，自端到端的測試

權限管理能力；庫實現制品研發

2）實現通過統動化搭建不同的時，無需啟動并

3）實現應用版流程關鍵業務信

一的依賴倉庫管運行環境；運行全部系統內

本管理關聯代息的元數據信息

理應用的依賴。3）可基本實現的應用組件，能

碼、鏡像、分支管理及溯源。

開發環境與線上夠在單一應用組

等版本。

環境的組件級等件開發時通過測

價。試替身，契約測

7

YD/TXXXXX—XXXX

試等方式有效隔

離組件依賴干

擾。

在3級基礎上，支

持以下能力要

在3級基礎上，支

求：

持以下能力要

1）應支持基于

求：

在3級基礎上，支本地IDE或

1）流水線配置在3級基礎上，支

持以下能力要Editor，實現基

信息應納入版本持以下能力要

求：于本地容器集群

管理，實現自動求：

在3級基礎上，1）1）能夠通過K8s環境下的開發、

化變更；1）應支持所依

應支持定義結構或等效的容器編測試與調試；

2）部署和發布賴的組件、庫以

化構建腳本；排工具，面向服2）應支持在保

4的其它相關信息及系統環境均包

2）應通過制品庫務實施環境準證單一組件開

應納入版本管含在直接鏡像

實現制品的組件備；發、調試、測試效

理，例如多組件中；

依賴查看。2）基本實現開能的情況下，按

間的版本依賴2）依賴庫應有

發環境與線上環需利用本地容器

等；依賴的準入機

境的運行時等集群啟動相關的

3）應用應僅維制。

價。其它系統組件，

護一份基準代

實現更多快速的

碼，但可對應多

集成或局部端到

份部署環境。

端調試和測試能

力。

在4級基礎上，支在4級基礎上，支

在4級基礎上，支持以下能力：持以下能力要

持以下能力要1）高度的自動求：

求：化和彈性，可以1）應支持純云

1）實現構建方在云上通過切換環境下開發，本

式服務化，可按配置，按需快速地無需安裝任何

需提供接口或用搭建或銷毀不同應用依賴，本地

5同4級能力要求戶界面，將構建同4級能力要求的開發或測試環除了所使用的開

能力賦予整個研境，極大的解決發客戶端以外，

發團隊資源受限問題；可以實現本地資

2）研發團隊可2）實現開發環源和環境依賴最

以按場景實現構境與線上環境的小化；

建過程可視化編高度一致（只是2）在部分場景

排配置、資源和可下，可實現低代

訪問性的區別）碼、無代碼開發。

6.3測試管理

測試管理過程域共包括測試環境管理、測試實踐、缺陷預防、質量分析等4個維度，具體能力要求

如表7所示。

--測試環境管理：指對云原生應用系統的測試環境的管理能力；

8

YD/TXXXXX—XXXX

--測試實踐：指云原生應用系統的測試實踐方式；

--缺陷預防：指云原生應用系統測試環境以及生產環境下缺陷的管理和預防措施；

--質量分析：指云原生應用服務質量數據管理和分析能力。

表7測試管理能力要求

級別測試環境管理測試實踐缺陷預防質量分析

測試環境可通過手動可通過人工方式實施

測試實踐可以手動方可通過人工方式收集

1方式管理，且固定不缺陷數據收集和統

式進行功能性測試。質量數據。

可協調。計。

1）應支持自動化的

應支持自動創建測試缺陷數據收集和統

環境，但更多依賴提計；

應支持自動化的功能應支持自動化的質量

2前預定的物理環境，2）宜具備缺陷管理

測試和非功能測試。數據收集。

或通過基礎鏡像進行和分析實踐能力，初

構建。步具備缺陷預防的準

入條件。

在2級基礎上，支持以

下能力要求：

1）應實現自動化測

試即代碼，可用于環

境部署的自動化驗在2級基礎上，支持以

證；下能力要求：

應支持通過直接鏡像

2）應支持以自動化1）應支持分析進程在2級基礎上，應支持

在較少依賴預定義環

3方式實現更加完善的間故障、訪問延遲、基于統一的日志平臺

境的情況下，進行測

非功能測試需求，包資源受限等缺陷；數據進行質量分析。

試環境構建。

括但不限于長穩測2）應具備以上故障

試、壓力測試、安全的缺陷注入能力。

測試、兼容性測試等；

3）測試過程應能夠

隔離抗干擾，保證穩

定的測試效果。

在3級基礎上，支持以

在3級基礎上，支持以

下能力要求：

下能力要求：

1）應支持按需進行在3級基礎上，支持以

1）應支持完善的調

的大規模自動化功能下能力要求：

用鏈路監控和預警；

在3級基礎上，應支持測試和非功能測試；1）應支持定位分析

2）應支持全鏈路日

4測試環境水平擴展和2）應具備相對完善規模化引發的缺陷；

志的手動及自動化數

垂直擴展的能力。的全鏈路壓測方案、2）應支持快速復刻

據分析；

多維度支持系統的可生產缺陷并進行定位

3）應支持云服務資

靠性測試；分析。

源消費情況的監控和

3）應支持利用集群

預警

特性進行組織級測試

9

YD/TXXXXX—XXXX

策略設計，如引入性

能工程、手動的混沌

工程。

在4級基礎上，支持以

下能力要求：在4級基礎上，支持以在4級基礎上，支持以

1）應支持針對運維下能力要求：下能力要求：

在4級基礎上，應支持

和部署的自動化驗證1）應支持缺陷自動1）應支持基于風險

按資源需求自動化構

測試；發現。管理需求的線上監控

建和銷毀測試環境，

2）應支持基于云原2）應支持多維度已和預警；

5如根據混沌工程的實

生特性的質量風險干知缺陷的混沌實驗；2）應支持完善的自

驗范圍，不同的服務

預測試，如云服務穩3）應支持基于代碼動化指標收集和數據

特性、不同的流量需

定性測試，云服務災的歷史缺陷進行代碼分析，具備持續觀測

求等。

備預案等；缺陷預防。能力。

3）可支持對IT系統

的混沌工程。

6.4部署發布

部署發布是指云原生應用部署發布的方式和策略，其能力要求如表8所示。

表8部署發布能力要求

級別部署發布

11）部署和發布可手動或部分自動化；

2）可在生產環境進行直接進行變更或操作。

2應支持實現較高程度的自動化部署，部署時應用組件可實現不可變。

31）應支持自動化發布能力，以直接鏡像為制品（而非基礎鏡像）進行部署和彈性擴容，實

現進一步的不可變；

2）生產環境可存在少量可控的直接變更或操作。

4在3級基礎上，支持以下能力要求：

1）部署和發布動作可基于全程可視的方式自動完成，過程中可實現動作的終止和回退；

2）支持灰度發布；

3）不應在生產環境存在直接變更或操作，徹底實現實例不可變。

5在4級基礎上，應實現不停機發布。

7服務治理域能力要求

7.1注冊發現

注冊發現是指云原生應用中服務的注冊和發現方式，其能力要求如表9所示。

10

YD/TXXXXX—XXXX

表9注冊發現能力要求

級別注冊發現

11級不要求系統具備注冊發現能力

2服務注冊發現機制可由客戶端完成。

31）服務注冊發現機制應由服務端完成；

2）服務應定時獲取服務狀態，進行健康檢查；

3）應實現服務注冊與發現組件的高可用。

4在3級基礎上，支持以下能力要求：

1）應實現跨語言的服務發現，如通過DNS解析發現服務等，；

2）宜實現服務狀態變化分鐘級發現。

5在4級基礎上，實現服務狀態變化在秒級發現。

7.2流量管理

流量管理是指對云原生應用系統南北向以及東西向流量控制和負載均衡策略管理，具體要求如表

10所示。

表10流量管理能力要求

級別流量管理

11）應實現對應用服務入口服務南北向限流；

2）應支持通過負載均衡實現服務南北向流量分配。

21）應實現對服務入口及內部單一服務節點限流；

2）應實現服務動態流量控制。

3在2級基礎上，支持以下能力要求：

1）應實現對服務多節點統一限流；

2）發現并