SRE解决的核心问题究竟是什么？

【摘要】SRE 既做研发也做运维，那么SRE 解决的核心问题究竟是什么？

【作者】汪照辉，中国银河证券架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。个人微信公众号：技术思维创新

本文转自：twt企业IT社区

SRE 既做研发也做运维，并且要求研发的时间不低于 50% ，但 SRE 是偏运维的，包括 SRE 研发的大部分工作也是和运维相关的。这也让我有了个疑问， SRE 解决的核心问题是什么？

直观地来看， SRE 要解决的是系统运行的可靠性问题，特别提倡使用软件工程的方式来消除手工运维的问题，但似乎又不仅仅是这样。软件系统可靠性跟众多的因素相关，比如说软件架构、代码质量、逻辑处理、部署架构、部署位置、使用组件、调用链路、网络、数据量、配置参数、安全机制、基础软硬件等，任何一个点的异常都可能会导致软件系统异常。因此 SRE 不但要懂软件研发，还要从事软件研发，消除软件运行过程中存在的不稳定因素。通过持续完善运维工具、可靠性组件等提升运行系统的可靠性。另外，从 SRE 职责来看，通常包含可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理、容量规划与管理等。很多看似运维的工作都跟研发密切相关，所以， SRE 工程师要做一部分研发工作，甚至一部分产品的研发工作。

SRE 是偏运维的，那么除了研发， SRE 和传统运维有什么本质的区别？我曾经从分层角度讨论过，运维的工作从层次上可以划分为业务应用系统运维、基础平台运维和基础设施资源运维（图 1 ）。

业务应用系统包含交易、 CRM 、财务、人力等业务系统及业务相关的管理系统等；基础平台包含如数据库、中间件、云平台、数据和大数据平台、 AI 平台等在内的工具平台，用于支撑赋能业务；基础设施资源则包含数据中心机房的存储、服务器、网络设备、安全设备、机房设备等。传统运维人员基本上承担了所有这些运维工作，分组分团队或分部门维护着不同的内容。随着系统和设备的增多，运维人员数量也持续膨胀。SRE 需要解决的一个很重要问题是：不随着系统和设备的线性增长而线性增加运维人员。比如说，10 个系统最初可能 10 个人来运维，用 SRE 方法论，当系统增加到 100 个时，可能还是 10 个人来运维，这才是 SRE 的价值。这么多的工作内容如何处理？当然是用自动化的工具和手段，甚至需要完全消除人工的操作，这样才能在系统线性增加时，不会导致运维人力的线性增加。

运维的分层使运维的内容和职责更明确，也使层次之间的支持和赋能衔接更容易通过标准化接口来实现。这可能也是企业在引进 SRE 方法论的时候需要进一步优化 SRE 的地方。SRE 方法论确保长期关注研发工作，在保障服务 SLO 的前提下最大化迭代速度，做好变更管理，通过监控系统实现可见性和可观测性，支持应急事件的处理；根据系统对基础设施资源的需求做好需求预测和容量规划，及时部署资源以支持弹性扩展；同时持续优化业务流程中的堵点，持续提升性能，减少延迟，持续优化运维流程，提高复用，减少重复造轮子，提升效率。这和我提出的 “ 运维的敏捷才能支撑研发的敏捷 ” 思想相一致。

《 SRE Google 运维解密》一书中提到 SRE 的日常工作包括几个方面：

一是 SRE 使用计算机科学和软件工程手段设计和研发大型分布式计算机软件系统。或与产品团队合作，或研发产品系统的备份、负载均衡等组件；理想情况下，推进公用组件在多个项目中的复用，以及用现有的组件解决遇到的新的问题。这是 SRE 50% 的研发工作时间要做的事情。研发的时候就关注可用性、可扩展性、安全性、复用性等可靠性和效率等问题。组件的复用其实和我们所提倡的中台架构思想是相通的，企业级的复用就是中台架构所追求的。

二是 SRE 关注可靠性。SRE 专注于软件系统架构设计、运维流程的持续优化，让这些大型分布式软件系统更可靠的运行，扩展性更好，更有效的利用资源等。软件系统架构设计是研发关注的，运维流程是运维关注的，很多时候运维人员是难以参与到系统架构设计的，虽然说运维的参与对于系统部署架构、网络架构、可扩展性等的设计会有帮助，但普通的 SRE 工程师是很难有机会参与的。人都不喜欢别人对自己指手画脚。一个好的方式可能是由全局架构师团队参与系统架构设计以及系统运维流程的优化设计，从顶层设计上能有个全局视角。这是软件系统全局可靠性的保证。

第三， SRE 主要工作是运维在分布式集群管理系统上运行的具体业务服务，比如说云平台、存储系统、虚拟化系统、客户管理系统、人力系统、 OA 、邮件系统等等。SRE 中的 S 最初指的是网站的运维服务， SRE 最初的工作就是维持网站的正常运转。随着时间的推移，其管理运维的内容越来越多。不过这其实还是按照传统单体系统运维的方式，从上到下，从应用到资源层，没有形成整体分层向上赋能的方式。这种方式已经不适合数字化系统融合的要求。这也是 SRE 方法论在数字化时代可以借鉴改进的地方。

SRE 的工作偏运维却又长期关注研发，看起来是矛盾的，不过却也是必须的。研发懂运维才能在软件研发的时候就关注部署运行可靠性、伸缩性、性能、可观测性等问题；运维懂研发才能运用软件工程的思想和方法解决运维过程遇到的自动化、体系化工具匹配，快速找到异常根因，面对应急事件时能快速定位处理等。所以 SRE 解决的核心问题是研发不懂运维、运维不懂研发的割裂问题。SRE 的方法论为 DevOps 的提出提供了实践和方法论基础，提出了开发运维一体化，所以也说 SRE 是 DevOps 的一种实践。

SRE 和传统运维的本质区别在于认知和思维，表现在工具和方法上。不同认知和思维层次的人在面对同一个问题时所采取的方法和采用的工具是不一样。传统运维关注的是自己的一亩三分地，对别的部分不了解，额外的内容超出了自己的控制，所以害怕变更和变化。SRE 通过全局的参与对整个软件产品的生命周期过程都是了解的，再辅以工具化的支持，在面对意外情况时，做到心中有数，从容应对。当前很多公司在推混沌工程，其实就是一种增强系统运行可靠性的方式。但是如果把混沌工程单独拿出来，可能会使问题复杂化，混沌工程的思想和方法应该融入到日常的研发和运维工作中，持续积累完善系统运行的他山之石可攻玉。将他山之石可攻玉也作为研发和运维的支撑工具。使其成为 SRE 或者 DevOps 的一部分。

SRE 运维的内容不断地扩展，其方法也在不断地完善和进步。我们在学习 SRE 的时候，要尽可能去学习和思考其内在的思想，得其形更要有其实。从信息化到数字化，系统的复杂度成级数增长，特别采用微服务分布式架构，众多的微服务虽然带来了迭代敏捷，也使变更和版本管理、调用链路和复用复杂化，使问题定位难度增加，所以系统的可见性和可观测性、安全性等变得越来越重要。对于一个软件人员来说，仅懂编码或仅懂运维是远远不够的。需要用研发的技能来保证运维的敏捷，用运维的思想来关注研发。