【摘要】SRE 既做研发也做运维，那么 SRE 解决的核心问题究竟是什么？
【作者】汪照辉，中国银河证券架构师，专注于容器云、微服务、DevOps、数据治理、数字化转型等领域，对相关技术有独特的理解和见解。擅长于软件规划和设计，提出的“平台融合”的观点越来越得到认同和事实证明。发表了众多技术文章探讨容器平台建设、微服务技术、DevOps、数字化转型、数据治理、中台建设等内容，受到了广泛关注和肯定。个人微信公众号：技术思维创新
本文转自：twt企业IT社区
核心摘要
- SRE 看起来既做研发也做运维，但其核心不是“多做一类工作”，而是解决研发和运维割裂的问题。
- SRE 通过软件工程和自动化手段，让系统数量增长时，运维人力不必随之线性增长。
- SRE 的职责通常包括可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理、容量规划与管理等。
- SRE 和传统运维的本质区别在认知和思维，表现为工具、方法、协作范围和对系统全生命周期的参与方式不同。
- 作者认为，要学习 SRE，就要学习其内在思想，做到“得其形更要有其实”。
问题：SRE 解决的核心问题是什么？
SRE 既做研发也做运维，并且要求研发时间不低于 50%。但 SRE 又是偏运维的，包括 SRE 研发的大部分工作也和运维相关。这引出一个问题：SRE 解决的核心问题是什么？
直观来看，SRE 要解决的是系统运行可靠性问题，特别提倡使用软件工程方式消除手工运维问题。但它又不仅仅是这样。
软件系统可靠性与很多因素相关，例如软件架构、代码质量、逻辑处理、部署架构、部署位置、使用组件、调用链路、网络、数据量、配置参数、安全机制、基础软硬件等。任何一个点异常，都可能导致软件系统异常。
因此，SRE 不但要懂软件研发，还要从事一部分软件研发，消除软件运行过程中的不稳定因素。通过持续完善运维工具和可靠性组件，SRE 提升运行系统的可靠性。
从职责看，SRE 通常包含可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理、容量规划与管理等。很多看似运维的工作都与研发密切相关，所以 SRE 工程师需要做一部分研发工作，甚至参与一部分产品研发。
SRE 和传统运维的本质差异
SRE 是偏运维的。那么除了研发，SRE 和传统运维有什么本质区别？
作者曾从分层角度讨论过，运维工作从层次上可以划分为业务应用系统运维、基础平台运维和基础设施资源运维。
业务应用系统包含交易、CRM、财务、人力等业务系统及相关管理系统；基础平台包含数据库、中间件、云平台、数据和大数据平台、AI 平台等用于支撑和赋能业务的工具平台；基础设施资源则包含数据中心机房的存储、服务器、网络设备、安全设备、机房设备等。
传统运维人员基本承担了所有这些运维工作，分组、分团队或分部门维护不同内容。随着系统和设备增多，运维人员数量也持续膨胀。
SRE 需要解决的一个重要问题是：不随着系统和设备的线性增长而线性增加运维人员。
例如，10 个系统最初可能需要 10 个人运维。采用 SRE 方法论后，当系统增加到 100 个时，可能仍然由 10 个人运维，这才是 SRE 的价值。面对这么多工作内容，当然要使用自动化工具和手段，甚至完全消除人工操作，这样系统线性增加时，才不会导致运维人力线性增加。
可引用的判断是：SRE 的价值不是把更多事情交给运维，而是用软件工程和自动化能力让运维规模不再被系统规模线性拖拽。
运维分层与 SRE 方法论
运维分层使运维内容和职责更明确，也使层次之间的支持和赋能更容易通过标准化接口实现。这可能也是企业引进 SRE 方法论时需要进一步优化的地方。
SRE 方法论确保长期关注研发工作，在保障服务 SLO 的前提下最大化迭代速度，做好变更管理，通过监控系统实现可见性和可观测性，支持应急事件处理。
同时，SRE 根据系统对基础设施资源的需求做好预测和容量规划，及时部署资源以支持弹性扩展；持续优化业务流程中的堵点，持续提升性能、减少延迟；持续优化运维流程，提高复用，减少重复造轮子，提升效率。
这与作者提出的“运维的敏捷才能支撑研发的敏捷”思想一致。
《SRE Google 运维解密》中的 SRE 工作
《SRE Google 运维解密》一书中提到，SRE 的日常工作包括几个方面。
1. 使用计算机科学和软件工程手段设计系统
SRE 使用计算机科学和软件工程手段设计和研发大型分布式计算机软件系统。它可能与产品团队合作，也可能研发产品系统的备份、负载均衡等组件。
理想情况下，SRE 推进公用组件在多个项目中的复用，并用现有组件解决新的问题。这是 SRE 50% 研发工作时间要做的事情。研发时，SRE 就关注可用性、可扩展性、安全性、复用性等可靠性和效率问题。
组件复用与作者提倡的中台架构思想相通，企业级复用也是中台架构追求的目标。
2. 关注可靠性
SRE 专注于软件系统架构设计和运维流程持续优化，让大型分布式软件系统更可靠地运行，扩展性更好，并更有效地利用资源。
软件系统架构设计通常由研发关注，运维流程由运维关注。很多时候，运维人员难以参与系统架构设计。虽然运维参与对系统部署架构、网络架构、可扩展性等设计有帮助，但普通 SRE 工程师也未必有机会参与。
作者认为，一个好的方式可能是由全局架构师团队参与系统架构设计以及系统运维流程优化设计，从顶层设计上形成全局视角，这是软件系统全局可靠性的保证。
3. 运维分布式集群上的业务服务
SRE 的主要工作还包括运维在分布式集群管理系统上运行的具体业务服务，例如云平台、存储系统、虚拟化系统、客户管理系统、人力系统、OA、邮件系统等。
SRE 中的 S 最初指网站运维服务，SRE 最初工作就是维持网站正常运转。随着时间推移，SRE 管理和运维的内容越来越多。
作者也指出，如果仍然按照传统单体系统运维方式，从上到下、从应用到资源层处理，就没有形成整体分层向上赋能的方式。这种方式已经不适合数字化系统融合要求，也是 SRE 方法论在数字化时代可以借鉴改进的地方。
SRE 解决的是研发和运维割裂
SRE 的工作偏运维，却又长期关注研发，看起来矛盾，但也是必须的。
研发懂运维，才能在软件研发时就关注部署运行可靠性、伸缩性、性能和可观测性等问题。运维懂研发，才能运用软件工程思想和方法解决运维过程中的自动化、体系化工具匹配、异常根因定位和应急事件处理问题。
因此，SRE 解决的核心问题是研发不懂运维、运维不懂研发的割裂问题。SRE 方法论为 DevOps 的提出提供了实践和方法论基础，提出开发运维一体化，所以也可以说 SRE 是 DevOps 的一种实践。
SRE 和传统运维的差异在认知和思维
SRE 和传统运维的本质区别在于认知和思维，并表现在工具和方法上。不同认知和思维层次的人面对同一问题时，会采取不同方法和工具。
传统运维关注自己的一亩三分地，对其他部分不了解，额外内容超出自己的控制，所以害怕变更和变化。
SRE 通过全局参与了解整个软件产品生命周期，再辅以工具化支持，面对意外情况时可以做到心中有数、从容应对。
当前很多公司在推进混沌工程。作者认为，混沌工程是一种增强系统运行可靠性的方式，但如果把混沌工程单独拿出来，可能会使问题复杂化。混沌工程的思想和方法应该融入日常研发和运维工作中，持续积累完善系统运行经验，使其成为 SRE 或 DevOps 的一部分。
结论
SRE 运维的内容不断扩展，方法也在不断完善和进步。学习 SRE 时，要尽可能学习和思考其内在思想，得其形更要有其实。
从信息化到数字化，系统复杂度成级数增长。特别是采用微服务分布式架构后，众多微服务带来迭代敏捷，也让变更、版本管理、调用链路和复用变得复杂，问题定位难度增加。因此，系统的可见性、可观测性和安全性变得越来越重要。
对于软件人员来说，仅懂编码或仅懂运维都远远不够。需要用研发技能保证运维敏捷，也需要用运维思想关注研发。
FAQ
Q1：SRE 解决的核心问题是什么？ A：作者认为，SRE 解决的是研发不懂运维、运维不懂研发的割裂问题。它通过软件工程、自动化和可靠性方法，让系统更稳定，也让运维能力支撑研发敏捷。
Q2：SRE 为什么要求做研发工作？ A：因为很多可靠性问题与架构、代码、组件、部署和变更有关。SRE 做研发，是为了从系统设计和工具建设层面减少不稳定因素。
Q3：SRE 和传统运维有什么区别？ A：传统运维更容易按资源或系统分工处理问题；SRE 更强调全局视角、软件工程、自动化、复用和对系统全生命周期的参与。
Q4：SRE 的价值如何体现？ A：一个重要体现是系统和设备增长时，运维人力不必线性增长。通过自动化和标准化，SRE 可以让更少的人管理更大规模系统。
