本文来自微信公众号“twt企业IT社区”，【作者】汪照辉，架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。。
本文写作的初衷源于笔者云原生实践遇到的各种服务毫无架构思想的设计，促使笔者考虑用SRE等思想和方法解决云原生PaaS平台运维运营中存在的资源浪费、服务管理和治理、组件持续建设和维护、敏捷和应急响应等问题。本文对此进行了系统性的阐述，希望能够能够引发更多同行读者的思考和分享。
云原生PaaS逐渐成为企业的关键基础设施，支撑着企业云原生应用的敏捷响应、可扩展性、弹性、自愈性和可观测性等能力。云原生PaaS平台的运维和运营有别于传统系统和工具的运维运营，它不但要向下管理基础设施资源，实现资源弹性，向上支撑应用运行、运维和运营，实现业务弹性，还需要提供高可用性、可见可观测性、可靠性、实时的数据统计分析辅助决策等能力，以及工具、组件和平台的持续迭代和演进。因此，传统的系统运维方式和思想已经远不足以满足云原生PaaS的运维运营要求，需要基于SRE等的思想来构建SRE团队和运维运营方法体系，以支撑当前数字化和转型所需的敏捷、可靠、安全、数据驱动等需求。
在多年的云原生PaaS建设和运营过程中，我也一直在思考如何能更好的建设云原生PaaS、如何支撑应用研发运维和PaaS平台运营运维，也在学习和实践DevOps、SRE、平台工程等思想和方法。总的来说，不管是厂商还是客户，都在关注工具平台的建设，而有意无意地忽略了平台和工具体系的有效维护和管理，以及运维团队的建设。DevOps做成了效能平台，SRE被直接忽略，平台工程成了研发平台，基本上没有运维什么事。这样导致运维能力难以提升，研发团队依旧不懂运维，运维不懂研发，Dev&Ops割裂的情况并没有多少改变。
我前一段问了一个来面试架构师的同学一个问题，一个不懂基础设施的人如何能够做好应用架构设计？可能很多自称架构师的人还真没有思考过这个问题。特别在云原生架构中，应用架构和部署架构密切相关，需要基于云原生体系架构来设计云应用架构，而不是先设计应用架构再考虑部署。这几年在云原生实践中也经常遇到各种服务毫无架构思想的设计，所以也促使我考虑用SRE等的思想和方法解决云原生PaaS平台运维运营中存在的资源浪费、服务管理和治理、组件持续建设和维护、敏捷和应急响应等问题。
1、认识SRE
SRE首先是人，不管你称为站点可靠性工程师或系统可靠性工程师都可以，他保障系统的可靠运行，敏捷响应。敏捷和可靠稳定并不矛盾，国内“敏态和稳态运维”曲解了云原生运维的理念。SRE是既懂开发也懂运维和架构的全栈式人才，不是随便一个人员就可以称为SRE，其价值远高于大部分的研发人员。其次，SRE是一种实现系统可靠性的思想和方法等。不过你无需照搬Google SRE的做法，需要找到适合自身实际的方法。
2、应用管理
云原生PaaS的核心是“应用管理”，即云原生应用的开发、部署、运行、运维等。平台围绕应用管理来构建相应的多租户和访问控制、资源管理、服务治理、API管理、调度管理、可用性和可靠性、可观测性、应急管理、中间件服务等能力。所有这些能力都是服务于业务应用。在跟厂商聊的时候，“应用”的概念可能也理解也不一样，很多自称以“应用为中心”本质上还是以“容器”为中心，容器是一种资源，所以本质上还是以资源为中心，没有理解PaaS真正的需求。这里的“应用”指的是业务应用，一切服务于业务，平台支撑业务应用，应用支撑业务数字化运营。因此，PaaS不是简单的容器化+Kubernetes。云原生PaaS本质上是一种云原生操作系统，向下管理调度CPU、内存、GPU、存储、网络等资源，向上支撑工具、组件和各种应用。
3、多租户和访问控制
租户是租用云计算资源的用户，云需要支持众多用户同时访问和使用云计算资源，因此有了多租户的概念。租户可能是家公司、社会组织、团队、个人等，因此租户往往是带组织架构的用户。云原生PaaS需要在平台域内（云操作系统内）提供统一的访问控制，不能一个组件一套访问控制策略，比如说，日志一套权限体系，监控告警一套权限体系，服务治理一套权限体系等等。这也是目前众多自称PaaS平台的厂商普遍存在的问题，各个组件的权限和访问控制都没有打通，各自为政，表现出的不是一个平台，而是拼凑的大杂烩。另外需要强调的是，也不是当前IAM的单点登录，这种实现过于low了，云原生PaaS需要摒弃这种过时的设计思想。
云原生PaaS可以基于角色实现各个组件统一的访问控制，实现组件无缝集成。这当然有不少的工作量，但也是目前必须解决的问题。基础平台和组件的建设和维护，往往需要专业的人员。传统运维人员和方式难以自行研发和维护，企业无论从研发运维效率或者自主可控等方面都需要考虑建设自己专业的SRE团队。
4、资源管理和调度管理
资源管理包括资源池与资源弹性管理、资源的分配与使用监控、资源碎片管理与优化、资源调度与策略优化等。资源池化是为了更好实现资源共享和复用，通过资源容量自动扩缩容实现资源弹性，应对特殊情境下的资源需求。资源弹性往往需要底层IaaS或虚拟化的支持，通过自动化节点创建、添加和删除等支持资源的弹性扩缩容。不管资源池（计算、存储、网络资源等）中资源的大小，最终会落到每个节点，因此节点的资源配比就是一个决定资源利用率的一个很关键因素。不合理的资源配比等会导致大量的资源碎片，无法有效利用资源。另外，云原生PaaS运维运营过程中，资源分配率往往很高使用率却很低且不均衡，这是因为租户往往不知道服务具体的资源需求，会往尽可能多申请和分配资源量。公有云按量计费无所谓，私有云则导致整体资源利用率低而造成浪费。资源超分虽会提升资源利用率，但因为每个租户的认知和配置策略不一样，会带来额外的资源争抢问题，存在潜在的热点竞争导致请求超时等，因此尽可能不要超分。若想要避免资源争抢并且想提升资源利用率，由专业SRE团队来部署、运维应用可能是一个比较好的方法。通过PaaS平台有效协同研发和运维，实践DevOps理念，同时以专业SRE提升部署运维效率，提升资源利用率等，同时可以通过研发轮换来提升研发对基础设施的理解和对运维的认知，从而可以更好的提升研发的质量和效率。
Kubernetes默认调度策略难以支持实际需求。特别单指标调度策略会导致大量资源碎片，因此需要扩展Kubernetes scheduler，实现多指标动态调度。这需要基于场景进行扩展研发或者和厂商合作研发，离不开SRE的深度参与。
5、服务治理和API管理
云原生PaaS以应用管理为中心，应用的服务的管理和治理则非常关键和非常核心。服务的部署管理、注册发现、路由限流、弹性扩展、故障恢复、灰度升级、蓝绿切换、日志监控等等，有多少租户和租户用户，有多少应用服务等资产，分配使用了多少资源，应用服务的运行状况是什么，有哪些漏洞和风险等等，所有应用部署、运行和运维的可操作能力和资产、资源、运行状况、安全状况等的可见可观测信息都需要能敏捷、可靠支撑。整个云原生PaaS平台需要围绕应用构建完整的应用和服务管理和治理能力。这其中有非常多的细节问题需要处理，比如说，云原生网络是用Underlay还是Overlay，不同的网络模式在性能、管理复杂度等方面是不同的；还有服务注册，是用注册发现中心工具如Eureka、Consul、Nacos还是直接用Kubernetes，跨集群注册发现、Overlay网路模式服务注册发现等不同的方式决定了应用设计实现和管理治理的差异。这里需要强调的是，SpringCloud体系和Kubernetes体系是不同的，实际中由于研发人员认知的问题往往混在一起，也导致了云原生服务治理的复杂性。
服务治理和API管理可以说是一体两面，服务往往需要对外暴露接口，不管是NodePort、Ingress或loadbalancer等，往往会涉及跨集群或多集群、跨网络域访问调用、应用系统间协同复用等问题。集群内部可用用ServiceMesh代理东西流量请求的管理治理，而集群外部链路则通常需要API网关和API管理工具实现南北流量的管理治理，完成API管理、API认证授权访问控制、路由分发、熔断限流、服务编排等能力。同时可以兼顾容器服务和非容器服务的路由管理等需求。这也是我一直推荐的两层服务治理理念。不同的工具和模式选择服务治理的实现也有不同，比如说，可以在集群级Ingress实现网关的能力或实现Kubernetes Gateway API，这可以更好跟踪进出集群请求。
正是由于现实业务应用需求的复杂性从而也导致云原生PaaS需支持的服务治理的高复杂度。因此往往需要很多的持续工具研发和自动化运维迭代工作，这就需要运维人员具备研发能力，持续提升平台的自动化能力和可观测性能力，持续的数据统计分析展示和辅助决策能力，具备资产部署态势、应用运行态势、云原生安全态势、资源分配使用态势等实时态势感知和敏捷响应能力。持续的工具研发和运维需要专业的SRE团队，专业的应用运维和资源运营也离不开SRE，提升研发的能力和意识更需要建设SRE团队。
6、敏捷变更和稳定运行
云原生很重要的一个特点是敏捷、速度。但敏捷并不意味着不稳定、不可靠。在通过CICD等工具实现敏捷迭代和敏捷变更的同时，可以通过高可用部署、负载分发、流量控制、数据备份和恢复、健康检查、故障自愈等机制实现业务稳定性和可靠性。不过云原生分布式特性也导致整个部署管理相对要复杂很多，非常考验运维人员的技术能力和意识，因此专业的SRE是不可或缺的。提高可靠性的方式有很多，我比较不推荐拿混沌工程瞎折腾，一个很重要的因素是很多人对混沌工程的理解有偏差。如果你把混沌工程放到整个云原生体系或整个IT体系中去考虑，你的认知可能就会不一样。
云原生追求敏捷，但其分布式架构和多层次封装会带来链路增长、响应延迟，额外增加很多不稳定和风险点，和云原生的敏捷、可靠的目标是有矛盾的，因此需要额外的高可用、集群化、多实例、消除多余业务节点、优化加速等机制来保障。这些都需要深度的实践和研究，也和场景相关，靠厂商难以实现或成本高昂，都需要内部SRE的长期努力和积累。
7、应急管理和应急响应
虽然意外可能是偶然的，但应急管理和响应依然是IT治理关键的内容之一。紧急情况下能够实现快速切换、灾难恢复，甚至通过自动化的运维工具做到无缝转移是非常重要的能力。不同层级故障的高可用保障和应急处理策略也是不一样的，比如说普通应用与关键应用、单一组件和共享组件、应用故障与数据中心故障等，其影响范围不一样，应急举措和响应级别也不同。云原生PaaS是重要的基础设施，其分布式特性增加了维护的复杂度和难度，需尽可能通过自动化的工具完成切换，避免单点，或做限流降级、或路由切换、或弹性伸缩、或灾备恢复，都需要全链路高可用、灾备等机制，这往往需要全栈式SRE的支持。
在云原生体系中，如何协调研发、SRE和传统运维之间的职责，是一个很重要的问题。SRE可以侧重于平台运维运营和应用的部署、运维，为业务运营提供完整的数据驱动支撑，为研发提供应用部署和运行必需的平台和工具，为传统运维研发必要的自动化工具和平台。SRE如同云原生PaaS，承担着承上启下职责，也是传统研发和运维之间的变速器，带动研发和运维持续的提升。构建SRE可以说是在云原生体系中，支持企业IT转型的重要举措之一。
总的来说，云原生PaaS平台是企业承上启下核心的支撑平台，其建设和运维对相关人员的要求已不同于过往，需要考虑专业的SRE团队的建设和运维方式转型。SRE需具备敏感的技术感悟力，是懂开发、懂运维、懂架构、懂应用、懂基础设施的全栈式人才，具备全局的思维和意识，这样才能以业务应用为中心构建PaaS能力，运维和运营好应用、资源和平台。
