笔记 | 关于 SRE 在金融行业落地的探讨

2022 年 8 月 22 日
广东
本文字数：4133 字
阅读完需：约 14 分钟

【文末可下载资料】

上期直播我们为大家详细介绍了分布式系统环境下，银行运维所面临的挑战与难题，分布式运维建设模式，以及分布式系统下运维工具的落地建议（直播笔记 | 分布式系统大势所趋，银行运维如何与时俱进？）。但工具的建设并不意味着运维的成功转型升级，运维体系的建设需要有科学的指导思想以及体系化的建设理念。

本期我们就以 Google 经典运维体系理念——SRE 为例，通过对 SRE 的主旨内容剖析，梳理 SRE 与运维开发之间的联系，同时通过典型 SRE 落地案例详解，与大家一同探讨 SRE 在金融行业的落地经验。

直播回放：

本次直播设有审核，待审核通过后即可观看

Tips：如您不方便查看回放，可阅读以下总结文章，全文约 3000 字，预计阅读时间 5-7 分钟

SRE 主旨内容概览

什么是 SRE

首先我们来看看 SRE 的几个定义：

分别来看，起源于 Goole 的 SRE 相对于它的组织来说，定义得是较为契合的，首先 Google 具备较强实力的人才储备，其次，经过了大量的内部实践，是经得起考验的，同时由内而外的推动使得这一体系的落地情况也比较全面。但对于国内企业来说，全能型的人才稀缺以及传统理念的固化让这一定义显得并不是那么的完善。

站在国内企业自身的角度来看，我们更倾向于第三种：从实践角度看 SRE 的关键点，就一个词：体系化，我们需要用全局视角才能更透彻的理解它。SRE 实际上是需要多个团队、多个岗位分别去承担不同职能，并且各个团队之间能够相互协作合力，同时对外与业务团队、产品团队连接，构建工具去实现日常的运维和运营。

SRE 与 DevOps 关系

本质上来讲 SRE 与 DevOps 没有很大差别，都是伴随着分布式、云原生、容器化、微服务等技术所衍生出来的一些理念，我们可以理解为 DevOps 是 SRE 核心理念的普适版。相比起来，DevOps 比较抽象，而 SRE 是 Google 将 DevOps 具体实践后所提炼出来的理论体系。

SRE 指导思想与关键概念

SRE 具备以下几个指导思想：

拥抱风险：
不确定性始终存在，我的目标是通过一系列的方法，去减少风险。
服务质量目标：
透过具体指标反应运维水准，反过来约束失误可靠性。
减少琐事：
减少日常重复、人工介入的工作，与自动化联动。
分布式系统监控：
全局可观测性建立。
自动化系统：
与减少琐事对应，增强自动化能力。
发布工程：
在确保稳定性的基础上，尽可能快的进行发布，满足业务需求。
尽可能简单化：
工具、工作尽可能简单。

围绕以上指导思想，我们可以将 SRE 的一些关键概念串联起来，从而对 SRE 体系有更明确的认知。

关键概念上，主要分为四个层面

指标层：具体描述与 SRE 相关的指标
标准层：SRE 相关系列标准
工具层：核心常用工具
体系层：围绕 SRE 建立的流程制度与体系

SRE 岗位/团队的主要工作

了解了 SRE 整个体系的工作方式与方法以后，SRE 具体团队在做什么样的内容呢？主要分以下三个板块：

参与运维架构标准制定：
包括一些技术组件如何选择、日志规范如何设计、以及其他系统的规范和标准的制定。
运维产品开发：
当标准梳理清楚之后，在运维日常工作方面，将琐事提炼为产品需求、规划能力，从而以产品为中心提升自动化，同时需要注意各个工具之间如何融合打通，避免烟囱式的建设。
日常技术运营：
在标准化、平台化之后，针对运维日常工作进行改进和优化。

在这个过程中，我们可以下一个论断，即：运维模式/体系的下一站是 SRE，而运维技术的下一站是 AIOps。

SRE 方法论

方法论层面，主要有以下几个重要点：

确保长期关注研发工作：
Google 将 SRE 团队的运维工作限制在 50%以内。
监控系统：
一个监控系统应该只有三类输出：紧急警报（立即执行）/工单（短期内执行）/日志（被动关注）。
变更管理：
渐进式发布、迅速而准确地检测问题、安全迅速回退
资源部署：
资源的部署是变更管理与容量规划的结合物
在保障服务 SLO 的前提下最大化迭代速度：
系统总是不稳定，通过引进“错误预算”的概念，解决研发团队和 SRE 团队之间的组织架构冲突。
应急事件处理：
以 MTTR 为核心，不靠万能工程师，靠运维手+on-call 人员常规性解决
需求预测和容量规划：
保障一个业务有足够的容量和冗余度去服务预测中的未来需求
效率与性能：
SRE 也必须承担起任何有关利用率的讨论及改进。

另外还有针对 SRE 的建设目的与建设方式等内容的分析，查看完整回放了解更多详情！

点此查看回放：完整回放

SRE 运维平台与运维开发

运维管理平台：实现 SRE 运维开发的底座

SRE 反复强调运维组织需要大量的参与到运维工具开发中去，来实现 SRE 的转型。而做工具的开发，传统企业与互联网公司会有较大的区别。

对于大型的互联网企业而言，由于具备较强的开发能力，企业可以基于开源去打造各类工具，同时也可以不基于平台，或者基于弱平台去做各个工具的打通。
而对于传统企业来说，是比较难以去从零开始打造一个新的平台的，同时不同的开源工具之间的打通也比较难以靠自身去实现。

因此对于大多数企业来说，要实现 SRE 运维开发，需要一个统一的底座——具备通用能力、通用开发框架，同时提供统一的资源纳管，以及资源驱动等能力，借助统一底座，下层资源统一纳管实现数据打通和能力扩展，上层通用能力框架实现工具开发，可控生长，建立基于平台的完整运维开发体系。

其中包括几个典型的场景：

CMDB——SRE 运维管理体系的基石，建立消费驱动的，可视、可用、可信、可靠的运维高质量 CMDB，支撑运维开发转型。

可观测性——助力 SRE 实现全链路追踪与问题根因定位。构建 trace、log、metric 关联分析链路，依赖于平台，实现数据的统一处理。

自动化编排引擎——SRE 自动化运维的抓手，自动化场景的建设需要底层引擎的支撑，调用基本能力构建上层自动化体系，支撑 SRE 工具能力拓展。

SRE 在金融行业落地探讨

落地案例分析

以国内某大型银行 SRE 实践为例，其 SRE 落地进程有以下几个重要关键点：

1.确定 SRE 落地的核心理念：

符合长期战略，改善运维手动、重复性工作，建立 SRE 团队提升运维价值。

2.组建 SRE 试点团队：

包含团队负责人，轮值团队经理，业务核心技术成员，其他部门协助人员，从不同的团队中抽调相应人员，保证每位人员都清楚的认知 SRE 的建设目标，力出一孔。

3.SRE 工作模式：采取平战结合模式。

平时建设（即日常模式）：解决运维日常问题，保证系统可用性、可靠性、稳定性，减少出故障的时间和概率，保障运维质量。
战时应急（即应急模式）：建立快速处理机制，SRE 团队开展故障处置，第一时间恢复生产。

战时应急依赖于平时建设的工具、自动化能力、问题总结等，形成平战结合的工作模式。

4.SRE 团队 OKR：

团队 OKR 的制定与工作模式紧密配合，通过平战结合的模式，实现全景业务系统可感可见，应急处置可管可控，业务指标可计可析。同时 SRE 团队建立三会机制，即周例会、月例会、专题会，保证日常工作与专项事宜的快速处理。

目前来看该行的 SRE 实践是比较成功的，其核心在于 SRE 团队的组建，一方面需要有开发人员介入，核心业务人员要懂开发，懂架构，具备运维开发能力。另一方面需要具备组织能力，SRE 建设目标分解到各个团队中，人员之间实现能力的融合，从而形成体系化的组织，推进整体 SRE 进程。

除此之外我们对众多企业 SRE 进程和落地实践也进行了详细的深入分析，包含农业银行、腾讯、美图等，如您感兴趣，欢迎点击了解详情！

点此查看回放：完整回放

经验探讨

SRE 是否适合在金融行业落地？

SRE 是一个体系化的过程，从组织架构、到文化宣贯、到工具构建、到人员能力配备都具备以后，才能形成完整的 SRE 体系。

在中大型银行来说式比较适合的，中大型银行未来运维通常都会向着分布式、微服务、容器以及云架构方向去发展，同时运维团队规模比较大，拥有足够的团队和资金支撑 SRE 落地。
对于中小型银行来说，通常会以传统架构为主，有的单位会建设一部分云资源。如果说短期内企业并没有短期内进行容器化、分布式的建设规划的话，落地 SRE 是比较困难的。

我们建议可以先针对其中某一方向，例如工具向平台化层面去靠拢，同时如果还有富余的精力的话可以考虑进行一部分运维开发能力的建设，除此之外组织能力也可以适当培养，从而一步一步向 SRE 迈进，而不是一步登天。

如果要落地，需要注意哪些事项？

主要有 3 个重点：

标准规范制定：标准化、规范化是体系建立的第一步，运维的标准规范需要与开发与业务达成一致。

具备软件开发能力：能够把运维诉求变成运维产品，然后把运维产品，最终落地成为具体的工具、系统。

组织变革：SRE 是运维与开发的能力结合，需要一部分懂开发的运维人员，也需要一部分理解运维体系的开发人员，运维与开发需要相互理解，从而将彼此诉求融入到自己的工作中。

想要下载完整 PPT 资料？点击→：内容中心

想要免费体验产品？点击→：申请试用