YD/T 4409.2-2023

3 术语和定义 GB/T 11457-2006、ISO/IEC TS 23167:2020界定的以及下列术语和定义适用于本文件。

1 云原生应用程序 cloud native application 明确设计为在云服务中运行并利用云服务的功能和环境的应用程序。 [来源：ISO/IEC TS 23167:2020，3.6] 3。

2 云原生 cloud native 面向云应用设计的一种思想理念，充分发挥云效能的最佳实践路径，帮助企业构建弹性可靠、松耦合、易管理、可观测的应用系统，提升交付效率，降低运维复杂度。

3 云原生业务应用 cloud native bussiness application 用于帮助企业解决业务需求云原生应用程序（3.2），具备弹性、高可用、自愈性、可观测性以及自动化等特性，以下简称云原生应用。

4 容器 container 一种进程级的虚拟化隔离技术。

5 std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 2 服务器无感知 serverless 将基础设施资源抽象成按需使用的服务，用户只需关注应用逻辑，而无需管理复杂的基础设施运维工作的设计模式。

6 弹性 elasticity 云原生应用按照业务需求灵活进行规模化的扩容和缩容能力，包括基础设施资源层面与应用实例层面。

7 高可用 high availability 通过应用容灾、数据备份等手段，以减少服务中断时间为目的，保证云原生应用的可靠性和可维护性。

8 自愈性 self healing 云原生应用通过故障自动发现、预判分析和故障应对等流程，实现对于异常或故障后自我恢复的能力。

9 可观测性 oberservability 通过日志、监控、链路跟踪等交叉分析，进行云原生业务应用更加深入地服务健康度量，从而实现分布式应用架构下故障排错、剖析以及依赖分析能力。

10 自动化 automatic 云原生应用运维自动化以及交付部署自动化。

4 云原生业务应用成熟度模型 4。

1 概述云原生业务应用成熟度模型从企业业务应用基础设施域、应用研发域以及服务治理域等三个能力域二十个过程域综合评估企业业务应用在弹性、高可用、自愈性、可观测性以及自动化等五个维度的云原生能力成熟度水平。

——基础设施域：评估企业业务应用底层计算、存储以及网络等基础设施资源的云原生化程度以及基础设施层运维方式和能力；

——应用研发域：从架构设计、开发构建、测试管理以及部署发布等企业业务应用研发关键环节能力水平； std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 3 ——服务治理域：从企业业务应用发布上线后，评估云原生业务应用在应用层面运维运营支撑能力水平。

2 云原生业务应用特性成熟度评估方法云原生业务应用特性包括弹性、高可用、自愈性、可观测性以及自动化等，其成熟度评估以及对应能力域与过程域成熟度等级综合计算，具体对应关系如表1所示： 表 1 云原生业务应用特性成熟度能力域过程域云原生业务应用特性弹性高可用自愈性可观测性自动化基础设施域 （I） 基础设施资源 （I1） √ √ √ 基础设施运维 （I2） √ √ 应用研发域 （D） 架构设计（D1） √ √ 开发构建（D2） √ √ 测试管理（D3） √ 部署发布（D4） √ √ 服务治理域 （G） 注册发现（G1） √ √ √ √ 流量管理（G2） √ √ √ √ 服务容错（G3） √ √ √ 服务降级（G4） √ √ 故障注入（G5） √ √ √ √ 链路跟踪（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所示： std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 4 表 2 云原生业务应用综合成熟度等级定义级别英文中文定义 1级 Initial Level 初始级未实现任何云化改造，完全基于传统应用架构 2级 Fundamental Level 基础级基础设施层基本完成云化改造，但仍基于传统应用架构，应用服务具备有限的弹性和容灾能力 3级 Comprehensive Level 全面级基础设施层完成云化改造，应用架构层服务化改造持续进行，应用具备一定的弹性和高可用，实现多维度的应用监控 4级 Excellent Level 优秀级基础设施层探索服务器无感知化改造，应用架构层服务化，应用具备弹性、高可用，基本实现服务自愈，可观测以及自动化 5级 Fabulous Level 卓越级基础设施层逐步实现服务器无感知化，应用架构层持续演进，应用全面实现弹性、高可用、服务自愈、可观测以及自动化和智能化交付云原生业务应用综合成熟度计算方法如下： 云原生业务应用综合成熟度= ∑（弹性能力成熟度+高可用成熟度+自愈性成熟度+可观测性成熟度+自动化成熟度）/5 或云原生业务应用综合成熟度= ∑（∑I/2+∑D/4+∑G/9）/3 5 基础设施域能力要求 5。

1 基础设施资源基础设施资源是指云原生应用所托管在的底层基础设施资源部署形态，其能力要求如表3所示。 表 3 基础设施资源能力要求级别基础设施资源 1 应用系统可直接部署在未进行任何形式云化的物理机上。

2 应用系统应以部署在云化的资源池上为主，基础设施资源实现按需使用。 3 在2级基础上，支持以下能力要求： 1）应用系统应以容器化部署方式为主； 2）应实现不同团队共用基础设施资源情况下，实现租户级应用隔离。 4 在3级基础上，支持以下能力要求： 1）应用系统应以部署在容器云上为主； 2）应用系统应支持部署于异构基础设施资源上； 3）应支持跨云的基础设施资源互通和应用迁移； 4）应支持容器镜像自动化构建及版本管理能力； std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 5 5）应采用不可变基础设施； 6）应采用基础设施即代码能力，即通过代码实现基础设施资源的配置和管理； 7）可实现百节点容器规模的扩缩容，且扩缩容时间宜控制在3分钟内。 5 在4级基础上，支持以下能力要求： 1）可在部分业务场景下应用服务器无感知化架构； 2）可实现千节点容器规模的扩缩容，且扩缩容时间宜控制在3分钟内。

2 基础设施运维基础设施运维是指云原生应用底层基础设施的运维方式，其能力要求如表4所示。 表 4 基础设施运维能力要求级别基础设施运维 1 基础设施运维可以运维人员手动运维方式进行。 2 1）应支持脚本化运维； 2）应支持以手动方式实现基础设施资源扩缩容。 3 1）应支持自动化方式实现基础设施资源扩缩容； 2）基础设施运维层应具备统一的运维视图。 4 在3级基础上，支持以下能力要求： 1）应具备基础设施资源的自动化运维平台，例如自动化巡检、自动化配置下发及自动化配置管理等； 2）应实现故障预警。 5 在4级基础上，支持以下能力要求： 1）应用运维与基础设施运维关注点应分离，业务项目团队不再关注基础设施资源的运维， 更关注应用构建、发布、保障等； 2）应支持异构资源下统一的运维配置； 3）应支持基础设施变更版本记录且可追溯； 4）应实现基础设施资源故障自愈； 5）应支持基础设施资源的智能化运维。

6 应用研发域能力要求 6。

1 架构设计架构设计是指云原生应用架构设计模式，其能力要求如表5所示。 表 5 架构设计能力要求级别架构设计 1 1）应用系统可采用单体架构； 2）不可实现基于进程模型的水平扩展； 3）组件间可存在共享状态。 2 1）应用系统应采用分布式架构； 2）应用设计基于进程模型； 3）应支持应用的水平扩展。 std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 6 3 在2级基础上，支持以下能力要求： 1）应支持守护进程与应用分离，实现应用服务的按需启动和中止； 2）应将所依赖的其它组件当作资源使用，降低强依赖组件数量；应支持通过稳定端口绑定提供服务； 3）应支持日志信息通过事件流输出； 4）进程间不应有共享状态； 5）降低业务逻辑和非业务逻辑能力耦合，支持业务应用的按需启动和中止； 6）应用架构设计应充分考虑特性开关，可灵活线上提供或屏蔽应用功能。 4 在3级基础上，支持以下能力要求： 1）可实现基于弹性视角的架构设计，例如弹性依赖、镜像复制与实例化运行等； 2）对应用所依赖的组件进行内部零信任处理，服务间请求应进行鉴权； 3）应实现服务快速启动和优雅中止。 5 在4级基础上，支持以下能力要求： 1）利用云的能力，实现云原生的演进式架构设计； 2）可充分利用云原生的生态，使用云相关服务。

2 开发构建开发构构建过程域共包括版本管理、集成构建、依赖管理、开发环境准备、开发体验等5个维度， 具体能力要求如表6所示。 -- 版本管理：对云原生应用系统的版本信息等进行管理的能力； -- 集成构建：云原生应用系统的集成构建方式； -- 依赖管理：云原生应用系统所依赖的组件或库的管理方式； -- 开发环境管理：云原生应用所使用开发环境的管理能力； -- 开发体验：云原生应用系统开发环境的体验满意度。 表 6 开发构建能力要求级别版本管理集成构建依赖管理开发环境管理开发体验 1 1）应将应用源代码纳入版本管理； 2）多个应用可共用一份基准代码。 1）无法基于可自执行包进行构建，例如使用WAR 而非JAR等； 2）运行时可根据需要依赖额外中间件，例如Web 容器； 3）可以人工方式进行代码的编译构建。 1）无显式声明的组件或库的依赖关系； 2）应用所依赖的库可不在包内，需要在运行时准备； 3）所依赖的系统组件可能会因为系统环境变化而受到影响，例如Curl。 1）可以手工方式搭建所开发组件的运行环境和依赖，无法实现开发环境的快速构建与可重复； 2）开发环境与线上环境可不等价，如只能通过本地修改再上传线上环境的方式，在线进行开发和调试； 应用开发难以完全进行本机开发、测试与调试。 std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 7 3）不支持不同的运行环境区分。 2 在1级基础上，支持以下能力要求： 1）应用组件的依赖信息作为应用源代码的一部分，应纳入版本管理，实现同步变更； 2）配置信息与应用源代码分离，配置信息应纳入版本管理； 3）部署和发布脚本应纳入版本管理。 4）一份基准代码应仅对应一个应用； 1）基于可自执行包进行构建和制品管理； 2）运行时应无需依赖额外的第三方库； 3）制品应有专门的制品库统一管理。 应支持通过显式方式声明组件或库的依赖关系。 1）应支持自动化、可重复的搭建所开发组件依赖的环境； 2）应支持区分不同的运行环境，例如开发环境、测试环境、 UAT环境、生产环境等； 3）开发环境可与线上环境存在差异。 1）应支持基于架构设计和测试策略，通过本地 IDE或Editor，在本地进行组件的应用开发、测试与调试，但需要本地安装启动或远程调用所依赖的跨进程组件； 2）难以独立开发、调试和测试单一应用组件， 过程中可本机启动并运行系统内的其它相关应用组件，或实际调用远程组件。 3 在2级基础上，支持以下能力要求： 1）应用所依赖的系统环境定义代码作为应用源代码的一部分， 应共同纳入版本化管理，实现同步变更； 2）代码库管理应具备精细化的权限管理能力； 3）实现应用版本管理关联代码、镜像、分支等版本。 1）基于直接镜像（例如容器镜像）而非基础镜像（例如VM镜像） 进行构建和制品管理； 2）配置信息应通过配置管理服务器读取，并通过全局变量进行加载； 4）应通过制品库实现制品研发流程关键业务信息的元数据信息管理及溯源。 在2级基础上，支持以下能力要求： 1）应用所依赖的库在构建时应被打入包内，所依赖的系统工具 （如gradle 、 curl等）应当被包含在应用之中； 2）实现通过统一的依赖仓库管理应用的依赖。 在2级基础上，支持以下能力要求： 1）应支持通过 Docker或等效的多容器管理工具，面向组件快速搭建并启动所开发组件的环境和依赖； 2）应支持通过配置管理，基于直接镜像生成的不可变容器，自动化搭建不同的运行环境； 3）可基本实现开发环境与线上环境的组件级等价。 1）应支持基于良好的架构设计和测试策略，通过本地IDE 或 Editor，在较少的环境依赖下进行组件的应用开发、测试与调试， 所有其它跨进程组件依赖均通过容器实例运行； 2）应支持在开发、调试以及非端到端的测试时，无需启动并运行全部系统内的应用组件，能够在单一应用组件开发时通过测试替身，契约测 std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 8 试等方式有效隔离组件依赖干扰。 4 在3级基础上，支持以下能力要求： 1）流水线配置信息应纳入版本管理，实现自动化变更； 2）部署和发布的其它相关信息应纳入版本管理，例如多组件间的版本依赖等； 3）应用应仅维护一份基准代码，但可对应多份部署环境。 在3级基础上，1） 应支持定义结构化构建脚本； 2）应通过制品库实现制品的组件依赖查看。 在3级基础上，支持以下能力要求： 1）应支持所依赖的组件、库以及系统环境均包含在直接镜像中； 2）依赖库应有依赖的准入机制。 在3级基础上，支持以下能力要求： 1）能够通过K8s 或等效的容器编排工具，面向服务实施环境准备； 2）基本实现开发环境与线上环境的运行时等价。 在3级基础上，支持以下能力要求： 1）应支持基于本地 IDE 或 Editor，实现基于本地容器集群环境下的开发、 测试与调试； 2）应支持在保证单一组件开发、调试、测试效能的情况下，按需利用本地容器集群启动相关的其它系统组件， 实现更多快速的集成或局部端到端调试和测试能力。 5 同4级能力要求在4级基础上，支持以下能力要求： 1）实现构建方式服务化，可按需提供接口或用户界面，将构建能力赋予整个研发团队 2）研发团队可以按场景实现构建过程可视化编排同4级能力要求在4级基础上，支持以下能力： 1）高度的自动化和弹性，可以在云上通过切换配置，按需快速搭建或销毁不同的开发或测试环境，极大的解决资源受限问题； 2）实现开发环境与线上环境的高度一致（只是配置、资源和可访问性的区别） 在4级基础上，支持以下能力要求： 1）应支持纯云环境下开发，本地无需安装任何应用依赖，本地除了所使用的开发客户端以外， 可以实现本地资源和环境依赖最小化； 2）在部分场景下，可实现低代码、无代码开发。

3 测试管理测试管理过程域共包括测试环境管理、测试实践、缺陷预防、质量分析等4个维度，具体能力要求如表7所示。 -- 测试环境管理：指对云原生应用系统的测试环境的管理能力； std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 9 -- 测试实践：指云原生应用系统的测试实践方式； -- 缺陷预防：指云原生应用系统测试环境以及生产环境下缺陷的管理和预防措施； -- 质量分析：指云原生应用服务质量数据管理和分析能力。 表 7 测试管理能力要求级别测试环境管理测试实践缺陷预防质量分析 1 测试环境可通过手动方式管理，且固定不可协调。 测试实践可以手动方式进行功能性测试。 可通过人工方式实施缺陷数据收集和统计。 可通过人工方式收集质量数据。

2 应支持自动创建测试环境，但更多依赖提前预定的物理环境， 或通过基础镜像进行构建。 应支持自动化的功能测试和非功能测试。 1）应支持自动化的缺陷数据收集和统计； 2）宜具备缺陷管理和分析实践能力，初步具备缺陷预防的准入条件。 应支持自动化的质量数据收集。

3 应支持通过直接镜像在较少依赖预定义环境的情况下，进行测试环境构建。 在2级基础上，支持以下能力要求： 1）应实现自动化测试即代码，可用于环境部署的自动化验证； 2）应支持以自动化方式实现更加完善的非功能测试需求，包括但不限于长稳测试、压力测试、安全测试、兼容性测试等； 3）测试过程应能够隔离抗干扰，保证稳定的测试效果。 在2级基础上，支持以下能力要求： 1）应支持分析进程间故障、访问延迟、 资源受限等缺陷； 2）应具备以上故障的缺陷注入能力。 在2级基础上，应支持基于统一的日志平台数据进行质量分析。 4 在3级基础上，应支持测试环境水平扩展和垂直扩展的能力。 在3级基础上，支持以下能力要求： 1）应支持按需进行的大规模自动化功能测试和非功能测试； 2）应具备相对完善的全链路压测方案、 多维度支持系统的可靠性测试； 3）应支持利用集群特性进行组织级测试在3级基础上，支持以下能力要求： 1）应支持定位分析规模化引发的缺陷； 2）应支持快速复刻生产缺陷并进行定位分析。 在3级基础上，支持以下能力要求： 1）应支持完善的调用链路监控和预警； 2）应支持全链路日志的手动及自动化数据分析； 3）应支持云服务资源消费情况的监控和预警 std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 10 策略设计，如引入性能工程、手动的混沌工程。 5 在4级基础上，应支持按资源需求自动化构建和销毁测试环境， 如根据混沌工程的实验范围，不同的服务特性、不同的流量需求等。 在4级基础上，支持以下能力要求： 1）应支持针对运维和部署的自动化验证测试； 2）应支持基于云原生特性的质量风险干预测试，如云服务稳定性测试，云服务灾备预案等； 3）可支持对IT系统的混沌工程。 在4级基础上，支持以下能力要求： 1）应支持缺陷自动发现。 2）应支持多维度已知缺陷的混沌实验； 3）应支持基于代码的历史缺陷进行代码缺陷预防。 在4级基础上，支持以下能力要求： 1）应支持基于风险管理需求的线上监控和预警； 2）应支持完善的自动化指标收集和数据分析，具备持续观测能力。

4 部署发布部署发布是指云原生应用部署发布的方式和策略，其能力要求如表8所示。 表 8 部署发布能力要求级别部署发布 1 1）部署和发布可手动或部分自动化； 2）可在生产环境进行直接进行变更或操作。

2 应支持实现较高程度的自动化部署，部署时应用组件可实现不可变。 3 1）应支持自动化发布能力，以直接镜像为制品（而非基础镜像）进行部署和弹性扩容，实现进一步的不可变； 2）生产环境可存在少量可控的直接变更或操作。 4 在3级基础上，支持以下能力要求： 1）部署和发布动作可基于全程可视的方式自动完成，过程中可实现动作的终止和回退； 2）支持灰度发布； 3）不应在生产环境存在直接变更或操作，彻底实现实例不可变。 5 在4级基础上，应实现不停机发布。

7 服务治理域能力要求 7。

1 注册发现注册发现是指云原生应用中服务的注册和发现方式，其能力要求如表9所示。 std.miit.go std.miit.go std.miit.go YD/T XXXXX—XXXX 11 表 9 注册发现能力要求级别注册发现 1 1级不要求系统具备注册发现能力 2 服务注册发现机制可由客户端完成。 3 1）服务注册发现机制应由服务端完成； 2）服务应定时获取服务状态，进行健康检查； 3）应实现服务注册与发现组件的高可用。 4 在3级基础上，支持以下能力要求： 1）应实现跨语言的服务发现，如通过DNS解析发现服务等，； 2）宜实现服务状态变化分钟级发现。 5 在4级基础上，实现服务状态变化在秒级发现。