【作者】汪照辉，架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。
云原生PaaS逐渐成为企业的关键基础设施，支撑着企业云原生应用的敏捷响应、可扩展性、弹性、自愈性和可观测性等能力。云原生PaaS平台的运维和运营有别于传统系统和工具的运维运营，它不但要向下管理基础设施资源，实现资源弹性，向上支撑应用运行、运维和运营，实现业务弹性，还需要提供高可用性、可见可观测性、可靠性、实时的数据统计分析辅助决策等能力，以及工具、组件和平台的持续迭代和演进。因此，传统的系统运维方式和思想已经远不足以满足云原生PaaS的运维运营要求，需要基于SRE等的思想来构建SRE团队和运维运营方法体系，以支撑当前数字化和转型所需的敏捷、可靠、安全、数据驱动等需求。
在多年的云原生PaaS建设和运营过程中，我也一直在思考如何能更好的建设云原生PaaS、如何支撑应用研发运维和PaaS平台运营运维，也在学习和实践DevOps、SRE、平台工程等思想和方法。总的来说，不管是厂商还是客户，都在关注工具平台的建设，而有意无意地忽略了平台和工具体系的有效维护和管理，以及运维团队的建设。DevOps做成了效能平台，SRE被直接忽略，平台工程成了研发平台，基本上没有运维什么事。这样导致运维能力难以提升，研发团队依旧不懂运维，运维不懂研发，Dev & Ops割裂的情况并没有多少改变。
1、认识SRE
2、应用管理
3、多租户和访问控制
租户是租用云计算资源的用户，云需要支持众多用户同时访问和使用云计算资源，因此有了多租户的概念。租户可能是家公司、社会组织、团队、个人等，因此租户往往是带组织架构的用户。云原生PaaS需要在平台域内（云操作系统内）提供统一的访问控制，不能一个组件一套访问控制策略，比如说，日志一套权限体系，监控告警一套权限体系，服务治理一套权限体系等等。这也是目前众多自称PaaS平台的厂商普遍存在的问题，各个组件的权限和访问控制都没有打通，各自为政，表现出的不是一个平台，而是拼凑的大杂烩。另外需要强调的是，也不是当前IAM的单点登录，这种实现过于low了，云原生PaaS需要摒弃这种过时的设计思想。
4、资源管理和调度管理
资源管理包括资源池与资源弹性管理、资源的分配与使用监控、资源碎片管理与优化、资源调度与策略优化等。资源池化是为了更好实现资源共享和复用，通过资源容量自动扩缩容实现资源弹性，应对特殊情境下的资源需求。资源弹性往往需要底层IaaS或虚拟化的支持，通过自动化节点创建、添加和删除等支持资源的弹性扩缩容。不管资源池（计算、存储、网络资源等）中资源的大小，最终会落到每个节点，因此节点的资源配比就是一个决定资源利用率的一个很关键因素。不合理的资源配比等会导致大量的资源碎片，无法有效利用资源。另外，云原生PaaS运维运营过程中，资源分配率往往很高使用率却很低且不均衡，这是因为租户往往不知道服务具体的资源需求，会往尽可能多申请和分配资源量。公有云按量计费无所谓，私有云则导致整体资源利用率低而造成浪费。资源超分虽会提升资源利用率，但因为每个租户的认知和配置策略不一样，会带来额外的资源争抢问题，存在潜在的热点竞争导致请求超时等，因此尽可能不要超分。若想要避免资源争抢并且想提升资源利用率，由专业SRE团队来部署、运维应用可能是一个比较好的方法。通过PaaS平台有效协同研发和运维，实践DevOps理念，同时以专业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，这可以更好跟踪进出集群请求。
6、敏捷变更和稳定运行
云原生很重要的一个特点是敏捷、速度。但敏捷并不意味着不稳定、不可靠。在通过CICD等工具实现敏捷迭代和敏捷变更的同时，可以通过高可用部署、负载分发、流量控制、数据备份和恢复、健康检查、故障自愈等机制实现业务稳定性和可靠性。不过云原生分布式特性也导致整个部署管理相对要复杂很多，非常考验运维人员的技术能力和意识，因此专业的SRE是不可或缺的。提高可靠性的方式有很多，我比较不推荐拿混沌工程瞎折腾，一个很重要的因素是很多人对混沌工程的理解有偏差。如果你把混沌工程放到整个云原生体系或整个IT体系中去考虑，你的认知可能就会不一样。
7、应急管理和应急响应
虽然意外可能是偶然的，但应急管理和响应依然是IT治理关键的内容之一。紧急情况下能够实现快速切换、灾难恢复，甚至通过自动化的运维工具做到无缝转移是非常重要的能力。不同层级故障的高可用保障和应急处理策略也是不一样的，比如说普通应用与关键应用、单一组件和共享组件、应用故障与数据中心故障等，其影响范围不一样，应急举措和响应级别也不同。云原生PaaS是重要的基础设施，其分布式特性增加了维护的复杂度和难度，需尽可能通过自动化的工具完成切换，避免单点，或做限流降级、或路由切换、或弹性伸缩、或灾备恢复，都需要全链路高可用、灾备等机制，这往往需要全栈式SRE的支持。
在云原生体系中，如何协调研发、SRE和传统运维之间的职责，是一个很重要的问题。SRE可以侧重于平台运维运营和应用的部署、运维，为业务运营提供完整的数据驱动支撑，为研发提供应用部署和运行必需的平台和工具，为传统运维研发必要的自动化工具和平台。SRE如同云原生PaaS，承担着承上启下职责，也是传统研发和运维之间的变速器，带动研发和运维持续的提升。构建SRE可以说是在云原生体系中，支持企业IT转型的重要举措之一。
总的来说，云原生PaaS平台是企业承上启下核心的支撑平台，其建设和运维对相关人员的要求已不同于过往，需要考虑专业的SRE团队的建设和运维方式转型。SRE需具备敏感的技术感悟力，是懂开发、懂运维、懂架构、懂应用、懂基础设施的全栈式人才，具备全局的思维和意识，这样才能以业务应用为中心构建PaaS能力，运维和运营好应用、资源和平台。
如有任何问题，可点击文末阅读原文，到社区原文下留言探讨 觉得本文有用，请转发、点赞或点击“在看”，让更多同行看到
资料/文章推荐：
欢迎关注社区 "运维" 技术主题 ，将会不断更新优质资料、文章，您也可以前往提出疑难问题，与同行切磋交流。地址：https://www.talkwithtrend.com/Topic/4549
长按二维码关注公众号
*本公众号所发布内容仅代表作者观点，不代表社区立场
