随着云原生理念与云原生技术的不断完善和发展，越来越多的行业开始落地实践云原生技术，这对不同岗位的技术从业者产生了不同程度的影响。不管是对 IT 主管还是对一线开发人员和运维人员来说，从业务逻辑到技术选型，整个技术栈都发生了天翻地覆的变化。为了更好地迎接云原生时代的到来，大家有必要深入了解云原生落地实践对不同岗位的影响。
CXO 和 IT 主管
很多企业对技术类 CXO（包括 CTO、CIO、CISO、CDO等，本文均称为 CXO）和技术主管这些技术领导者的能力要求是全面而严苛的，技术领导者不仅要能够兼顾技术管理的各个方面，还要以维持公司业务为核心职责。因此，CXO 和 IT 技术主管既要拥有宽广的技术视野、出色的技术判断力甚至高层架构设计能力，还要具备良好的产品意识，以应对不断变化的内外部环境。
外部环境
作为企业的 CXO 和 IT / 研发主管，这些高层角色首先必须意识到：云原生是云计算发展的必然趋势，云原生重塑了企业数字化转型的基础技术平台，云原生架构是构建现代化企业应用的基础技术架构。无论是对于互联网应用、企业交易类应用、大数据应用，还是对于人工智能类型的负载等来说，云原生架构都非常重要。
其次，对于技术管理者特别关注的问题，比如开源开放、国产化等，CXO 和 IT 主管需要看到，大多数云原生相关技术和标准来源于各主流开源基金会的项目，这些技术和标准构成了开源开放的技术体系。各大云供应商推出的云原生服务也都兼容了相应的技术和标准。开源的云原生技术和产品非常符合企业客户“无厂商锁定”的诉求，当更换云服务提供商（Cloud Service Provider，CSP）或独立软件提供（Independent Software Vendor，ISV）时，企业不用担心会出现技术上无法切换或者迁移成本太高的问题。国产化日益成为国家和企业的刚需。企业需要选择符合国产化标准的云原生产品，包括云原生产品的自主可控能力、贡献的源代码（通常体现在运维、API、组件扩展等方面）、国产化服务器支持等。同时，像中国信息通信研究院、中国电子技术标准化研究院等单位也为企业提供了相关评测，以帮助企业选择符合国产化标准的商业化产品。
内部环境
在企业内部，CXO 和 IT 主管必须结合企业实际情况，利用云原生技术推动企业的技术升级，并实现技术和业务价值。
首先，在战略和组织层面，利用 ACNA（Alibaba Cloud Native Archite-cting）架构设计方法评估和制定企业的云原生战略和实施路径，并使之成为企业整体战略的一部分，以帮助和加速企业的数字化转型。此外，云原生战略与企业中台战略一样，不仅是对技术的一次全面升级，也是对企业 IT 组织结构、组织文化的升级。如今越来越多的企业已经意识到了这一点，以阿里巴巴为例，其不仅早在 10 年前就启动了云原生相关技术和产品的研发，2020 年云栖大会期间关于成立“阿里巴巴云原生技术委员会”的消息，更是让外界看到集团推动阿里巴巴与蚂蚁集团全面云原生化的决心。
其次，由于云原生技术是对企业应用开发方式的全方位重构，CXO 和 IT 主管需要思考如何利用容器、微服务、Serverless、Service Mesh 等技术重写应用，利用 DevOps 重塑企业的研发和运维流程，利用 GitOps、IaC 和声明式架构重新定义企业的流水线和运维方式，利用可观测性和 SLA（Service-Level Agreement，服务等级协议）升级原来的监控系统，利用云原生的以身份为中心的安全体系保障企业安全。
所有的技术升级的目的都是为了给企业带来实际价值，因此 CXO 和 IT 主管利用云原生进行技术升级时，需要关注以下几点。
- 运行成本及 ROI（Return On Investment，投资回报率）。
- 广泛使用 BaaS（Backend as a Service，后端即服务）和弹性所带来的直接成本节约。
- 基于云原生的新技术、新工具、新流程带来的效率提升。
- 稳定性、SLA 提升带来的间接成本优化（风险下降、用户体验改善等）。
架构师 / 咨询人员 / 系统规划人员
对于架构师 / 咨询人员 / 系统规划人员等企业的技术中坚力量来说，云原生技术及架构在架构演进及风险控制、技术选型、构建现代化应用、IT 服务流程重塑、新工具应用、安全规划等工作中产生了深刻的影响。
1. 架构演进及风险控制
云原生架构演进的根本在于改变软件运行的基础设施环境—云平台，让上层的软件架构从“稳态”到“打破原稳态并构建新稳态”。这需要架构师 / 咨询人员 / 系统规划人员谨慎评估企业的组织能力、开发和运维人员的技能水平、开发周期、成本预算、遗留系统集成、业务诉求等，并利用 ACNA 架构方法进行风险控制，以保障云原生架构在企业中平稳实施并持续发挥价值。
2. 技术选型
技术选型涉及两个方面，一方面是选择哪些领域的云原生技术和架构，另一方面是如何在同一领域、多个类似的技术或产品中做取舍。对于前者，建议企业根据云原生架构成熟度模型的评估维度，按架构迭代周期逐步选择与企业诉求和能力相匹配的技术领域（比如，有的企业会选择“容器 + 微服务 + 互联网中间件”构建企业中台）。对于后者，建议企业在开源和开放的基础上，选择有商业化支持（至少有同领域成功商业化实施的案例）的产品和服务，比如云平台提供的微服务、容器等系列服务。
3. 构建现代化应用
基于云原生构建现代化应用，企业可以实现业务敏捷性，以应对瞬息万变的市场挑战，为应用赋予动态扩展和强韧性的能力。企业核心架构师通过重写和重构企业核心软件，将云原生技术和架构迭代过程应用到这些核心软件的新一代研发中，让新应用具备现代化应用的特点。由于企业云原生化会带来应用架构的彻底升级，因此建议尽量选择对系统重写而非重构，从而最大限度地减少对历史技术债务的偿还，同时可以减少系统的遗留包袱，加速新应用的现代化过程。
4. IT 服务流程重塑
企业在升级云原生技术后，整个 IT 服务流程也需要进行云原生升级，其中包括事件管理、问题管理、变更管理、发布管理和配置管理，这些流程本身的定义都是完善的。由于云原生技术定义了新的工具、方法和标准，因此整个升级过程变得更加自动化，处理流程也得到了简化。比如在事件管理流程中，可观测性工具的使用大大减少了监控的负担，因为基于 Kubernetes 的云事件管理可以比较好地覆盖从虚拟主机、容器、PaaS 服务、集成服务到应用层面所有事件的集中采集、存储、分析、告警、关联性分析和可视化展示过程，从而提升服务台以及后续的事件处理效率。
5. 新工具应用
云原生技术体系中关联了大量的新工具，这些工具可以极大地提高云交付、云集成、云运维的效率。如果企业缺少这些工具，会面临自动化程度不足、IT 信息碎片化、运维风险高等问题。因此，架构师 / 咨询人员 / 系统规划人员需要为企业的 CI/CD（持续集成 / 持续交付）过程、微服务实施、PaaS/SaaS 服务的云开通与集成、企业 CMDB（Configuration Management Data Base，配置管理数据库）集成、企业监控集成、账号 / 权限 / 认证集成等场景选择甚至开发适用的工具，以提升企业的运维自动化水平，降低运维风险。
6. 安全规划
在数字化转型的背景下，虽然数字资产的价值得到不断挖掘，但是风险也在不断加大。云原生倡导的 DevSecOps、零信任模型和大量云安全服务，对权限控制、服务级动态隔离、请求级访问控制等安全策略进行了细粒度升级，从而实现了从代码开发到应用运维的端到端流程的安全控制。这个过程要求企业升级安全规划，以实现从云基础设施到应用安全的同步规划。
开发人员
云原生技术与架构对广大技术开发人员（设计、开发、测试等技术人员）的影响非常大，具体体现在以下 6 个方面。
1. 技术栈
从前端到后端的整个技术栈开发人员都将因为采用云原生技术而获益：开发环境逐步从本地 IDE 变成云端 IDE ，并在 IDE 中预集成云服务（比如，使用 Cloud Toolk it，在 IDE 中实现应用部署），使整个代码的编写和调试效率更高；服务于前端的后端（Backend for Frontend） 层因为采用 Serverless 架构和大量的 PaaS 云服务而简化技术栈， 使开发人员从后端运维中解放出来；后端研发人员需要关注会大量用到的技术，比如容器、微服务、Serverless、Service Mesh、PaaS 云服务等。
2. 分布式设计模式
云原生技术体系包含了大量已经存在的分布式设计模式，并将这些设计模式融合到开源产品和云服务中，从而极大地降低了架构师和开发人员的工作强度。比如，微服务以及 ServiceMesh 等可以预置灰度模式、熔断、隔仓、限流、降级、可观测性、服务网关等架构模式。而诸如事件驱动架构模式（Event-Driven Architecture，EDA）、读写分离模式、Serverless 模式、CQRS（Command Query Responsibility Segregation，命令与查询责任分离）模式、BASE（Basically Available，Softstate，Eventual consistent）模式等则需要从应用架构层面引入，无法对应用做到透明。
3. 业务开发
云原生技术和云服务采用得越多，开发人员在非功能特性开发方面所花费的精力就越少，从而有更多的时间和精力关注业务本身的功能性设计。基于 Service Mesh 和 Serverless 开发的应用，开发人员甚至不用关心服务器的运维，不用不断升级依赖软件，不用处理灰度热升和自动回退的复杂性，无须采用在线流量压测来减少集成测试和冒烟测试的工作量。
4. 测试方式
传统的基于预测来设计测试案例的方式，效率太低，解决方法是利用主动故障注入和混沌工程进行疲劳测试，真实地模拟现实世界可能发生的故障。而在线流量录制和回放的 测试方法可以快速形成测试案例并提升回归的有效性。更关键的是，这些测试方法都是直接在生产系统中进行的，没有事先在测试环境中经过测试，像 NetFlix、亚马逊、阿里巴巴等互联网公司都在大量采用这些测试方式，以降低大规模分布式环境带来的故障风险。
5. 软件研发和运维流程
对于从传统瀑布模型到变为敏捷开发方式的企业而言，DevOps 和 DevSecOps 对研发流程的改变更为明显，其不仅要求企业做到安全地持续发布，还要求企业重新定义和规范研发人员接触的研发流程和研发工具，实现开发和运维岗位的一体化，设立专注于提升工程稳定性、效率和质量的岗位，可以说是重新定义了研发和运维的组织、流程和文化。
6. 学习场景
云平台是数字社会的基础设施，是新基建的重要组成部分。很多最先进和最新的 IT 技术、理念都会在云平台上有所体现。这些新技术背后的开源项目以及围绕开源项目的大会、聚会、讨论区、技术博客等，是广大技术人员学习和提升技能的绝佳场所。此外，云计算相关的技术媒体往往会提供大量云原生领域的新技术和新解决方案，开发人员通过学习可以拓宽视野，提升技术能力。（这些技术媒体通常会提供在线文档、直播、视频录像、技术文章、博客等资源。）
运维人员
包括 SRE（Site Reliability Engineer，网站可靠性工程师）在内的运维人员，作为软件成功运行的保障者，也会受到云原生技术和架构的深刻影响，特别是在技术栈、运维工具、 监控和错误处理、SLA 管理、AIOps 等方面，具体说明如下。
1. 技术栈
运维人员的技术栈改变，一方面是由于运维的软件采用了云原生技术栈构建而被动引起的，另一方面则是基于主动利用云原生技术和工具构建新的集成、监控、自动化、自愈、性能管理、高可用管理、安全管理、SLA 管理、IT 资产管理、事件管理、配置管理、变更管理、发布管理、补丁管理等工作和流程而带来的。这里典型的应用场景是利用 Kubernetes Operator 实施自动化的资源创建、交付和实例迁移操作。
2. 运维工具
云原生架构特别强调通过 IaC 和声明式运维来实现运维过程的高度自动化，即使是在拥有几百上千台机器的复杂分布式系统中，也可以自动化处理部署、升级、回滚、配置变更、扩 / 缩容等操作。而 GitOps 作为 IaC 的一个核心落地理念，不仅包含了对系统目标态的描述，而且贯穿了整个变更过程，既符合 DevOps 的透明化原则，也具备声明式运维的优点。
3. 监控和错误处理
从用户反馈和发现系统指标异常到采取多种运维手段确认、分析并解决问题和故障，是日常错误处理的重要工作范畴。可观测性强调了一次业务的执行能够从多个分布式服务、容器、虚拟主机、网络、BaaS 服务中获得日志、度量和追踪信息，从而提高监控能力和错误处理效率。云原生技术不需要运维人员从多个分布式节点收集和关联这些信息，而是由 Prometheus 和 Grafana 帮助完成多维度信息的关联性分析、告警和可视化展示。
4. SLA 管理
有了度量指标信息后，我们可以结合调用关系中得到的依赖关系，对业务服务和 PaaS 组件进行 SLA 管理，进而对全局的服务和 IT资产进行 SLA 管理。在没有类似于 Service Mesh 和可观测性这些基础设施和能力的情况下，传统的监控系统只能尽量从不同格式的日志中去获取这些度量指标信息。如果软件没有打印度量指标信息，监控系统就无法获取；同时，由于缺乏全链路的依赖关系，SLA 管理不能做到上下游的关联分析，从而导致系统不能第一时间感知某个服务或组件是否达成其 SLO（Service Level Objective，服务等级目标）。这些问题在云原生系统中得到了很好的解决，进而可以帮助运维人员提升系统的 SLA 管理水平。
5. AIOps
AIOps 是指在运维中利用机器学习和人工智能技术主动分析和预防故障，同时加快故障处理速度。当在大量业务服务和技术组件中实施可观测性操作后，系统将会产生大量的日志、度量和追踪数据，通过实时的机器学习和人工智能技术对这些数据进行分析，可以辅助变更前后异常检测、多个事件的关联性分析和“假阳性”消除、根因分析、自动化异常节点摘除和应急恢复等操作。
软件交付工程师 / 系统集成工程师
作为软件交付链条中的重要角色，软件交付工程师和系统集成工程师也会因为应用了云原生技术相关的软件，而改变工作方式。
1. 标准化交付
交付过程中最大的困难之一，就是不同的客户具有不同的 IaaS 环境，包括不同的服务器或虚拟主机技术、网络环境、存储产品、操作系统和基础软件库等。IaaS 环境的不同不仅使得交付软件产生了不同的版本，而且在不同的交付阶段也会发生变化，这又进一步提高了交付管理的复杂度。容器和不可变基础设施不仅能够屏蔽 IaaS 组件的不同，而且在容器的运行环境发生变化时，可以通过不同的镜像形成不同的配置版本，而不是原地修改升级的方式（这种方式会丢失版本的配置信息，或者使不同版本的配置变得难以管理），从而标准化软件的交付过程，隔离 IaaS 层的频繁变化对上层应用配置变化的“传染”，以达到提升软件交付效率的目的。
2. 自动化交付
软件集成和交付的另外一个难点在于，需要提供相应的软件配置、安装或部署手册（相关人员需要学习这些手册），然后适配标准部署与不同环境部署之间的差异。在这个过程中，安装脚本只是辅助性工作，因为它并不需要知道手册中的知识。云原生 OAM（Operation Administration and Maintenance，操作维护管理）通过 YAML 文件从应用的角度对软件的运行环境、构成以及运维特征进行元数据级别的描述，同时描述软件部署的终态以及可以适配的配置变化。脚本是可以读取和理解 YAML 文件的。同时，我们可以看到，同一个软件在典型场景中的部署是可以被标准化、开源以及共享的（比如，Redis 在阿里云 ECS 上的部署过程）。这不仅可以自动化常用软件的交付过程，而且可以共享典型环境的交付经验，从而提升交付水平。
3. 云交付和云集成
云计算为软件提供了一个新的运行场所，以及一种新的交付形式。同时，云计算也是一个软件交付的 POC（Proof of Concept，验证性测试）场所。软件与云的集成成为一种新的软件集成模式，形成了新的 CSI（Cloud System Integration，云集成商）。系统先与部署在公有云中的软件进行小范围集成，然后通过云原生交付工具将公有云中的环境一键式地复制到私有云环境中。这在简化集成复杂性的同时，降低了集成和交付的成本。
4. 持续交付
软件的持续交付是 DevOps 过程中的必要环节。通过影响范围小且频繁的交付，DevOps 可以使软件的交付过程变得更加自动化、版本化，可以重复且自动地执行升级和回退操作。持续交付可以保证软件始终有一个最新且可用的版本，即一旦代码或配置发生了变更，就可以立即生成新的版本并校验这一新版本的可用性，从而提升软件的交付效率。
5. 广泛的工具链和知识体系
云原生技术体系是开源的，拥有广泛应用的开源组件产品和开放的知识体系。通过这些产品和知识，软件集成工程师和软件交付工程师可以快速学到最新的云原生技术，获得最合适的云原生工具链，并在自己的环境中进行快速验证。不仅如此，企业通过互联网渠道获得所用产品的基础技术知识，也能在一定程度上降低软件交付过程中的培训成本。
从数据库管理员到数据库架构师
数据库管理员（Data Base Administrator，DBA）在传统商业数据库和开源数据库产品体系中扮演着举足轻重的角色。他们是保证整个软件系统稳定性的关键一环。云原生技术和产品的发展，也深刻地影响了数据库管理员。他们的工作方式正在发生巨大的转变，关注重点从底层系统建设逐步转向业务系统架构设计、从基础稳定性逐步转向业务结构优化、从如何用好数据库软件逐步转向如何用好云原生产品体系等。与此同时，企业对于运维对象、运维平台、技术能力的要求也发生了巨大的变化。
1. 运维对象
随着云原生架构的不断演进，曾经遥不可及的 DaaS（Database as a Service，数据库即服务）已成为现实。云数据库提供了开箱即用的 PaaS 化服务，并通过云原生资源池化技术提供了计算资源池、存储资源池等丰富的云原生数据库产品。这使得数据库管理员的运维 对象从主机、网络、数据库转变为数据库服务。数据库管理员不再需要关注从 IDC（Internet Data Center，互联网数据中心）到主机资源的交付。这些基础服务都会由云平台完成。云平台将发挥供应链的规模化效益和虚拟化技术，提供远低于自建 IDC 成本的优质服务。在云计算时代，数据库管理员借助云计算的 IaaS 化服务能力，在日常工作中卸下了基础资源运维的工作负担，从而可以有更多精力关注数据库服务对业务的支撑能力，将运维对象的重心转向数据库服务。
2. 运维平台
在商业数据库时代，数据库管理员的基础能力是用好单一的数据库产品，建设基础运维平台，实现数据安全、服务高可用、备份恢复、性能监控、问题诊断等基础功能。即使是在开源数据库时代，大多数公司的数据库管理员也是围绕着上面所列举的几个方面，或从零自研或基于开源运维组件进行定制化修改，这耗费了大量的人力、物力资源，而且很难获得持续的运维能力。一旦有核心运维人员流失，企业很有可能会出现平台难以为继的局面。而在云原生架构下，数据库 PaaS 平台提供了丰富的运维能力支持，因此数据库管理员不再需要从零开始建设运维平台，从面向基础组件的运维转向面向数据库服务的运维，得以基于云平台提供的丰富 OpenAPI 实现业务支持能力的定制化开发，将如何为业务提供稳定的数据库服务支持作为运维平台的首要目标。同时，伴随云平台基础能力的逐步提升， 新技术借助 OpenAPI 体系的优势，使得面向数据库服务的运维平台能力能够得到持续提升。因此，我们需要意识到，只有转变运维平台建设的目标，才能够充分发挥云原生架构平台化的优势。
3. 技术能力
云原生时代丰富的云服务带来的技术和架构优势，将传统数据库管理员从基础问题中解放了出来。企业更需要具备基于云服务进行业务数据架构设计能力的架构师，而非传统意义上的运维数据库管理员。因此，数据库管理员需要尽快完成转型。在云原生架构下，过去很多需要数据库管理员花费很大精力去解决的问题都迎刃而解。典型的例子是数据安全问题，数据安全向来是数据库管理员工作的重中之重，他们将巨大的精力都投入磁盘容灾、机房容灾、数据备份等数据安全保障工作中。云原生时代的多 AZ（Availability Zone，可用区域）以及分布式存储架构，在解决数据安全问题方面具有天然优势。再比如容量规划问题，数据库容量规划一直是一个很难把握的难点。在业务模型发生变化的时期，如在大促等场景中，很容易出现系统容量不足的问题。云原生系统借助资源池化技术，发挥云原生存储计算分离架构的弹性能力优势，可以将扩展周期从原来的“天”级别大幅缩短为“秒”级别；共享存储技术更是可以在秒级别实现读节点拉起，实现系统读容量的扩展。相信在不久的将来，伴随 CPU 池化、内存池化、多点可写技术的突破，数据库容量弹性能力将更加强大。
另外，SQL 优化一直是数据库管理员日常工作中很重要的一部分。指导业务开发人员编写符合数据库特性的 SQL 一直占据着数据库管理员很大的工作比例。在云原生时代，云原生的自动优化系统基于机器学习和专家经验实现数据库自感知、自修复、自优化、自运维及自安全的云服务，可以帮助数据库管理员降低数据库管理的复杂度、消除人工操作引发的服务故障，从而有效保障数据库服务的稳定性、安全性及高效性。
在云原生时代，云服务在很大程度上解放了数据库管理员，同时也要求数据库管理员尽快完成个人能力的转型，加速从数据库管理员向数据库架构师的转变，从而更加深入地参与到业务系统的架构设计中，帮助开发人员用好云数据库的特性。
结语
云原生技术从业务流程、技术选型、技术栈等诸多方面影响着相关技术角色的日常工作，而云原生技术所带来的影响还远不止上述这些。在云原生已成为未来必然趋势的大环境下，不同岗位的技术从业者也要遵循云原生所强调的专注业务并不断演进，学习和接纳云原生的理念与技术，从而通过云原生技术和产品更好地释放云计算的价值，更好地支持相关业务的发展。
