首次全面解析云原生成熟度模型：解决企业「诊断难、规划难、选型难」问题

从“上云”到“云上”原生，云原生提供了最优用云路径，云原生的技术价值已被广泛认可。当前行业用户全面转型云原生已是大势所趋，用户侧云原生平台建设和应用云原生化改造进程正在加速。

然而，云原生复杂的技术栈和传统IT的历史包袱给用户带来了巨大挑战，针对平台建设和应用改造的能力要求缺少统一规范成为企业转型的最大障碍。在用户侧，企业执行层面存在“三难”问题，即诊断难、规划难、选型难，需求和供给不能精准对应，缺少权威建设指南；在技术供给侧，技术迭代加速，产品能力构建缺少行业“灯塔”，技术押宝的风险掣肘发展。

正因如此，想要推动云原生技术的规模化应用，云原生产业仍需打通供需最后“一公里”。在此背景下，中国信通院联合业界20余家单位近 40 名专家、历时 1 年，完成了国内首个云原生能力成熟度模型标准体系的编撰，并完成首批评估工作。阿里云是国内首个通过云原生能力成熟度模型测评的企业，并在最终信通院公布的测评结果中获得国内唯一全域（资源管理域、运维保障域、研发测试域、应用服务域）最高等级认证。

总体介绍

云原生的趋势

首先我们先总体介绍一下云原生成熟度相关标准的产生背景，以及当前云原生的发展趋势，包括技术架构、业务应用和架构安全三个方面去做详细的标准解读，以及对阿里云测评结果的分析。

过去几年，云原生技术得到了高速发展，云原生技术能够给企业带来应用开发效率的大幅提升。IDC 预测，到 2024 年，由于采用了微服务、容器动态编排和 DevOps 等技术，新增的生产级云原生应用在新增应用的占比，将从 2020 年的 10% 增加到 60%；到 2024 年，数字经济的发展将孕育超过 5 亿个新应用和服务。这与过去 40 年间出现的应用数量相当。同时到 2025 年，超过一半的中国五百强企业将成为软件生产商，超过 90% 的应用程序为云原生应用程序。到 2025 年，三分之二的企业将每天发布新版本的软件产品，这都是云原生技术发展能够给企业带来的直观的改变。

云原生技术已大规模进入企业生产环境

在去年信通院发布的《中国云原生用户调查 2021》中，我们也看到，有接近半数的企业客户已经把容器技术应用在核心生产环境中。在微服务领域，超过八成的用户已经采用或计划采用微服务架构进行应用开发。微服务已经成为了应用开发的架构优选；在 Serverless 领域，它作为云原生领域一个新兴的技术演进方向，目前已在核心业务中使用，Serverless 的用户也已经接近了两成，已开始和计划使用 Serverless 技术的用户超过七成，市场的潜力是非常大的。

云原生技术价值已被认可，规模化应用仍有瓶颈

在这种情况下，大量的企业客户一方面认同云原生技术能够带来的价值提升，比如说提升资源利用率，提升弹性伸缩效率，提升交付效率，提升系统运维效率等等。并且从趋势来看，2021 年对于这些价值的认同点相较 2020 年得到了大幅提升。也就是说，企业客户对于云原生价值的认同感是大幅度的提升。

但是同时我们也看到，企业客户对于云原生技术选型存在的顾虑，也在一定程度上增加了，主要包括大规模应用云原生技术时，对于安全性、可靠性、性能和业务连续性方面的顾虑。同时对于高速发展的技术栈带来的过度复杂、学习成本高的问题，也是企业客户非常关注的点。

云原生产业供需仍需打通最后「一公里」

所以我们可以看到，包括我们在跟很多客户去做沟通的时候，也看到企业客户在面对云原生技术的时候，通常处于一个比较纠结的状态。一方面寄希望企业的 IT 架构能够享受技术发展的红利，实现降本增效。但是同时又因为复杂的技术，或者是对于自己的技术人员以及相关技术的控制力不足，可能带来的一系列问题有非常大的顾虑。我们简单把这些顾虑分成供给侧和需求侧两端来看，在企业客户执行面确实存在诊断难、规划难、选型难等问题。

站在技术供给的角度来看，技术发展及产品的发展脉络是很难把握的。因为云原生技术它不像中间件或者是虚拟化技术已经发展了很长一段时间，云原生技术经过了六年的高速发展，其中也是经历了非常多技术路线的改变。在这个过程中，用户对于发展脉络其实是比较难把握的。同时用户的需求又是比较多变的，缺少一个主线，同时还包含了技术押宝的风险比较高。
在用户需求侧整体的架构规划缺乏标准的参照。比如当用户在设计业务系统架构时，其实没有一个很好的权威说明怎么去应用云原生技术。同时在建设路径方面，也不够清晰，技术路线庞杂也比较难筛选，支撑架构的技术水平缺乏对比。现实需求和供应商能力不能精准对应需求侧的困难等。

所以站在供给和需求两端来看，我们其实是缺少一个行业权威建设云原生的指南，能够给到企业客户在规划自身 IT 架构原生化的过程中，有一步一步演进的操作指南。这个指南需要解决什么呢？解决用户侧实际问题为导引，并且以行业技术发展的趋势为指引，来实现用户云原生化的快速和高效落地。所以基于一系列问题，阿里云云原生应用平台团队在2020 年初推出了《云原生架构白皮书》，并于今年全新升级了 2022 版。

全新升级！《云原生架构白皮书 2022 版》重磅发布

《云原生架构白皮书》是把阿里巴巴过去多年在云原生领域的实践和推进的经验进行了总结和抽象，并且我们在《云原生架构白皮书》中也提出了云原生架构成熟度模型，我们提出的模型主要包含了服务化能力、弹性能力、无服务器化程度、可观测性、韧性能力、自动化能力这六个指标维度。并且每个指标维度给出了 0 到 3 分的发展阶段的评分。客户可以基于这样的一个维度，对于自身的 IT 架构系统进行一个比较详细的评分，并且基于总分能够整体地来定级。我们包含了零级、基础级、发展级和成熟级，基于整体的云原生成熟度模型，可以有助于企业站在一个全局的视角看自己的 IT 架构云原生化的成熟度情况。

阿里云-云原生架构成熟度模型（2020）

信通院从 2016 年开始，也开始做云原生相关的行标和白皮书的制定。目前已经覆盖了像容器、微服务、Serverless 等相对比较完整的云原生评估体系。但是我们可以看到，过去的行标是一个点状分布的，并不能很好地站在整体的视角去评估整个企业在落地过程中的一个成熟度表现情况。所以在这种情况下，在 2020 年初，信通院牵头拉着三十多家企业一起去共同制定了云原生能力成熟度评估体系。

这个体系发展到现阶段总共包含了三部分内容。第一块是技术架构的成熟度，第二块是业务应用的成熟度，第三块是架构安全的成熟度。在建立整个成熟度体系的过程中，也是参考了之前由阿里云云原生应用平台团队推出的成熟度模型，并且这个标准还在发展中。目前已经进行了新一轮的开会讨论，可能还会新增第五部分应该是云原生中间件的成熟度标准。

信通院云原生标准化工作总览

云原生能力成熟度体系是联接供需双方的重要纽带

我们来详细看一下信通院的这套云原生成熟度的体系是怎么来建设的。它的核心目的其实就是为了连接供需双方，加固云原生能力。我们可以看到，在下图中把它简称为 TAS 三层结构：

在 T 这块就是我们所说的技术架构成熟度模型，主要是面向供给侧。我们所谓的供给侧主要包含了云原生技术服务商，比如说阿里云或者面对于大客户内部的企业平台的 IT 部门。

在需求侧我们有业务应用的成熟度，用 A 来表示。需求侧主要是企业的业务线，或者阿里云的业务型企业客户。

同时还有一个负责架构安全的成熟度评估模型，这个是供给侧、需求侧都需要去参考的一个架构安全的成熟度评估体系（S）。

这套体系建立好以后，我们给企业客户能够带来的价值是什么呢？第一是多维度的把脉，能够准确定位企业云原生化的改造阶段。第二，进行差异化的分析，详细诊断企业当前云原生能力的建设短板。第三个就是能够基于企业当前的发展阶段定制化地去做提升，明确输出企业未来能力、改进方向和计划。

CNMM-TAS（云原生成熟度体系）：能力魔方和特性雷达

再来详细拆解一下云原生成熟度这套体系，这其中包含一个体系、三个视角和 5 个特性。

所谓的一个体系，就是上文中提到的三角关系：我们的应用服务域、技术架构域以及架构安全域。三个视角主要是包含了业务应用一个建设视角，着眼于业务应用拆分解耦，充分融合底层架构技术实现的应用韧性，它主要是面向应用架构的合理性视角。

第二个视角是 IT 技术架构平台的视角，着眼于服务全局的技术架构、技术路线和全景能力规划。

第三个视角就是系统安全的视角。安全能力建设视角着眼于新形态技术架构下的端到端的安全防护的能力构建。

基于这样的三个视角，我们再把它通过五个特性去做特性雷达的详细阐述。五个特性主要包含了弹性、自动化、可观测、自愈与高可用。这五个特性也是后续我们在制定相关的测试用例和评分标准的时候主要参考的五个维度。

云原生技术架构成熟度

接下来，我们针对云原生能力成熟度模型里最重要的技术架构成熟度，做一个详细的拆解。可以看到，云原生技术架构成熟度模型的第一部分是技术架构。涵盖了四个能力域、12 个过程域、46 个能力子项，以及最终在测评的时候，有 476 个细分的能力要求。通过这样一个测评，能够帮助用户快速对照定位技术架构水平，并根据自身业务需求，结合模型的高阶能力，定制技术与架构的演进方向。

可以详细看一下这四个领域：从底往上，首先是偏向 IaaS 层资源管理域。资源管理又包含了融合、调度、存储、计算、网络环境等相关一系列成熟度的标准评估。向上是运维保障域，基础运维、可观测、高可用是运维保障域最重要的三个测评点。

向上是研发测试域，对应的有研发支撑和测试支撑；再往上是 PaaS 层应用服务域。主要包含了应用编排部署、应用治理和应用中间件等。基于四个能力域的详细定义，我们把最终的测评结果分为初始级、基础级、全面级、优秀级和卓越级五个成熟度等级。

先来看初始级。初始级的定义主要是技术架构局部范围开始尝试云原生化应用，并取得初步成效。这里面主要突出的一个特征就是容器化。基础级的定义是技术架构在局部范围内进行深入的云原生化应用，取得了比较良好的一个效果，突出的特征就是云原生平台化。全面级的定义是技术架构在更大范围内的、体系化地应用云原生技术，具备关键技术模块的相关能力，突出的特征就是体系化。也就是云原生技术在企业内部的体系化落地。

优秀级的定义主要是技术架构全面云原生化，各技术模块高度云原生化，架构的弹性、自动化和自愈能力已有全面提升，突出的特征就是规模化。卓越级的定义是技术架构已完成全面云原生化改造，且每个技术模块功能已经相当完善，能够很好的支撑上层应用，突出的特征就是智能化。

目前，云原生技术架构成熟度模型参与测评的企业非常多。阿里云是第一批、也是第一家通过测评的企业。

因为整体目前相关的标准的最终定稿还没有发布。所以说现在给大家看到的这个标准，实际上是我们修订过的版本，而且也不一定是最终版。所以大家先在这里大概有一个整体的了解就可以了。

阿里云整体测评结果

阿里云是信通院推出技术架构成熟度体系以后，首家完整通过所有四个云原生能力域、12 个过程域、46 个子项、476 个细分能力要求的厂商，全方位考察了阿里云云原生产品的服务丰富度与产品能力，最终产生了将近 400 页的测评报告，对每一个能力子项都有非常详细的测评记录，阿里云是国内唯一全域获得最高等级认证的企业。

来源：信通院公开企业测评结果

云原生架构安全成熟度

云原生安全挑战和发展趋势

随着云原生技术架构的演进成熟，在企业应用进行云原生化改造的同时，安全问题也随之而出。我们知道，基于传统的安全架构已经不适用于云原生环境，同时应用侧的容器形态也为架构带来了更多的攻击面，敏捷、弹性等云原生特征对传统安全技术也带来了新的挑战。为此，无论是云服务商还是企业用户，都迫切的需要构建自身的云原生的安全防护体系。

在国内，信通院也是最早的一批关注并且投入到云原生安全调研的权威研究机构。在今年关于云原生用户的调查报告显示，大部分的企业用户已经认识到了云原生安全能力建设的重要性。而安全性尤其是容器和微服务相关安全问题，也连续两年成为了企业客户在云上关切的最为核心的问题。

在海外，以云原生安全为背景的安全防护实践已经有一段时间的积累。我们可以看到除了政府层面的合规标准的发布外，企业在云上的安全预算也在逐年递增。据今年的云安全调查报告显示，今年企业在安全上的投入占比超过整个企业在云上预算的 20%。

在企业对云原生安全迫切需求的前提下，以云原生安全为背景，也涌现了大量优秀的开源项目。我们可以看到 CNCF 社区也出现了很多安全相关的优秀的开源项目。另外 CNCF 也在今年发布 V2 版本的云原生安全白皮书。通过上面对云原生安全挑战和趋势的分析，可以看到，尤其在国内我们需要一个权威机构定制专业化的安全标准，来帮助指导和规范云服务商和企业客户构建云原生环境下全方位端到端的安全防护体系。下面介绍一下这次云原生安全标准化工作的历史演进。

云原生安全标准化研究持续推进

阿里云是首批参与标准定制，并且首批通过云原生安全测评的服务商。2020 年 10 月，在信通院主办的云原生产业大会上，阿里云以及主要的安全厂商作为首批成员，成立了云原生安全工作组。从 2020 年 4 月开始，信通院联合业界二十余家单位的近 40 名专家，历时一年完成了国内首个云原生安全成熟度模型标准的编纂，为企业云原生安全能力建设提供了自检标尺和建设指南。同年，信通院联合 18 家企业发布了《云原生架构安全白皮书》。阿里云也是全程参与了白皮书的研讨和定制流程。

云原生架构安全能力成熟度评估模型

整个标准体系涵盖了五大能力域，包括基础设施安全、基础架构安全、应用安全、研发运营安全以及安全运维五大能力域，15 个能力子项，46 个实践项，以及近 400 个细分能力的要求。阿里云参与了所有五大能力域的所有细分子项评测。下面的表格是关于此次五大能力域下各个能力子项的细分展示。

本次参与评测的阿里云产品，包括容器服务、容器镜像服务、云安全中心、Web 应用防火墙等二十余款云原生产品，全方位考察了阿里云在云安全产品能力上的丰富度。

基础设施安全域

阿里云在计算、存储、网络等云基础设施上构建了非常坚实的平台底座能力。在计算安全方向，云安全中心和容器镜像服务支持漏洞的自动化检测、告警溯源以及攻击分析。同时也支持镜像漏洞的自动化智能修复能力。同时我们还支持像多 OS 、混合云架构的基线扫描，以及丰富的策略配置能力。在网络安全方向，云防火墙服务支持多重的边界防护，以及基于流量学习结果自适应的智能策略推荐下发能力。

在存储安全方向，容器服务的备份中心可以支持应用数据的异地备份以及快速恢复。而 ACK One也提供了多云/混合云场景下两地三中心的备份容灾能力。同时，ACK 还支持基于软硬一体的机密计算技术，帮助实现内存维度的信息保护。

基础架构安全域

在网络侧，容器服务和云安全中心提供了 Pod 维度东西向的策略控制以及智能阻断的能力。同时还支持集群网络拓扑的可视化展示。而 ASM 网格服务也提供了Service Mesh 框架下全链路的流量加密、观测、监控以及 7 层访问控制能力。

在编排和组件安全方向，ACK 容器服务可以支持多维度的、自动化的安全巡检能力，帮助发现集群应用潜在的风险，并提供加固建议。使用托管的节点池还可以实现集群节点 CVE 的自动化修复能力。同时在访问控制上，ACK 集群的 RSA 功能还可以支持集群应用侧 Pod 维度的云上资源权限隔离。

在镜像安全方向，ACR 容器镜像服务企业版提供了云原生的交付链功能，可以结合镜像的完整性校验等产品化能力，构建企业级的供应链 DevSecOps 能力。在运行时安全方向，云安全中心可以容器维度的 Runtime 的危险实时检测告警，以及智能处理，来帮助企业抵御容器逃逸，像敏感文件操作、异常连接等多种容器内攻击的行为。

应用安全域

云原生应用安全域包含了企业应用侧防护的方方面面。我们可以使用云防火墙和 web 应用防火墙等服务，实现企业应用南北向以及东西向的攻击防护和细粒度访问控制，同时我们也支持 API 漏洞，包括注入攻击和敏感数据泄露的检测分析以及自动修复建议。

在微服务安全方向，MSE 微服务引擎可以通过云原生的网关，结合云防火墙等服务来保证微服务网络通信的安全。同时在提供丰富的微服务治理能力的同时，我们也提供了安全监控，以及应用代码层的防护能力。在 Serverless 安全方向，函数计算服务支持存储网络等函数资源的细粒度的访问控制和租户隔离，同时还支持函数资源、流量的实时监控以及完备的审计。

研发运营安全域

首先是研发运营域，阿里云安全团队对平台内部的研发运营流程有严格的安全审计和管理，包括对云产品的定制化的需求管理，以及对制品安全的自动化扫描、完整性校验以及身份溯源。在安全设计上，也支持系统化的建模，以及内部标准化的安全设计规范，以及相应的技术栈。在测试安全方向，我们内部也有完善的 DevSecOps 流程来实现无需人工干预的风险识别以及运营。