本期我们就以Google经典运维体系理念——SRE为例，通过对SRE的主旨内容剖析，梳理SRE与运维开发之间的联系，同时通过典型SRE落地案例详解，与大家一同探讨SRE在金融行业的落地经验。
01. SRE主旨内容概览
1）什么是SRE
首先我们来看看SRE的几个定义：
分别来看，起源于Goole的SRE相对于它的组织来说，定义得是较为契合的，首先Google具备较强实力的人才储备，其次，经过了大量的内部实践，是经得起考验的，同时由内而外的推动使得这一体系的落地情况也比较全面。但对于国内企业来说， 全能型的人才稀缺以及传统理念的固化让这一定义显得并不是那么的完善。
站在国内企业自身的角度来看，我们更倾向于第三种：从实践角度看 SRE 的关键点，就一个词：体系化，我们需要用全局视角才能更透彻的理解它。SRE实际上是需要多个团队、多个岗位分别去承担不同职能，并且各个团队之间能够相互协作合力，同时对外与业务团队、产品团队连接，构建工具去实现日常的运维和运营。
2）SRE与DevOps关系
本质上来讲SRE与DevOps没有很大差别，都是伴随着分布式、云原生、容器化、微服务等技术所衍生出来的一些理念，我们可以理解为DevOps是SRE核心理念的普适版。相比起来，DevOps比较抽象，而SRE是Google将DevOps具体实践后所提炼出来的理论体系。
3）SRE指导思想与关键概念
SRE具备以下几个指导思想：
- 拥抱风险：不确定性始终存在，我的目标是通过一系列的方法，去减少风险。
- 服务质量目标：透过具体指标反应运维水准，反过来约束失误可靠性。
- 减少琐事：减少日常重复、人工介入的工作，与自动化联动。
- 分布式系统监控：全局可观测性建立。
- 自动化系统：与减少琐事对应，增强自动化能力。
- 发布工程：在确保稳定性的基础上，尽可能快的进行发布，满足业务需求。
- 尽可能简单化：工具、工作尽可能简单。
围绕以上指导思想，我们可以将SRE的一些关键概念串联起来，从而对SRE体系有更明确的认知。
关键概念上，主要分为四个层面：
- 指标层：具体描述与SRE相关的指标
- 标准层：SRE相关系列标准
- 工具层：核心常用工具
- 体系层：围绕SRE建立的流程制度与体系
4）SRE岗位/团队的主要工作
了解了SRE整个体系的工作方式与方法以后，SRE具体团队在做什么样的内容呢？主要分以下三个板块：
- 参与运维架构标准制定：包括一些技术组件如何选择、日志规范如何设计、以及其他系统的规范和标准的制定。
- 运维产品开发：当标准梳理清楚之后，在运维日常工作方面，将琐事提炼为产品需求、规划能力，从而以产品为中心提升自动化，同时需要注意各个工具之间如何融合打通，避免烟囱式的建设。
- 日常技术运营：在标准化、平台化之后，针对运维日常工作进行改进和优化。
在这个过程中，我们可以下一个论断，即：运维模式/体系的下一站是SRE，而运维技术的下一站是AIOps。
5）SRE方法论
方法论层面，主要有以下几个重要点：
- 确保长期关注研发工作：Google将SRE团队的运维工作限制在50%以内。
- 监控系统：一个监控系统应该只有三类输出：紧急警报（立即执行）/工单（短期内执行）/日志（被动关注）。
- 变更管理：渐进式发布、迅速而准确地检测问题、安全迅速回退
- 资源部署：资源的部署是变更管理与容量规划的结合物
- 在保障服务SLO的前提下最大化迭代速度：系统总是不稳定，通过引进“错误预算”的概念，解决研发团队和SRE团队之间的组织架构冲突。
- 应急事件处理：以MTTR为核心，不靠万能工程师，靠运维手+on-call人员常规性解决
- 需求预测和容量规划：保障一个业务有足够的容量和冗余度去服务预测中的未来需求
- 效率与性能：SRE也必须承担起任何有关利用率的讨论及改进。
02. SRE运维平台与运维开发
1）运维管理平台：实现SRE运维开发的底座
SRE反复强调运维组织需要大量的参与到运维工具开发中去，来实现SRE的转型。而做工具的开发，传统企业与互联网公司会有较大的区别。
- 对于大型的互联网企业而言，由于具备较强的开发能力，企业可以基于开源去打造各类工具，同时也可以不基于平台，或者基于弱平台去做各个工具的打通。
- 而对于传统企业来说，是比较难以去从零开始打造一个新的平台的，同时不同的开源工具之间的打通也比较难以靠自身去实现。
因此对于大多数企业来说，要实现SRE运维开发，需要一个统一的底座——具备通用能力、通用开发框架，同时提供统一的资源纳管，以及资源驱动等能力，借助统一底座，下层资源统一纳管实现数据打通和能力扩展，上层通用能力框架实现工具开发，可控生长，建立基于平台的完整运维开发体系。
其中包括几个典型的场景：
CMDB——SRE运维管理体系的基石，建立消费驱动的，可视、可用、可信、可靠的运维高质量CMDB，支撑运维开发转型。
可观测性——助力SRE实现全链路追踪与问题根因定位。构建trace、log、metric关联分析链路，依赖于平台，实现数据的统一处理。
自动化编排引擎——SRE自动化运维的抓手，自动化场景的建设需要底层引擎的支撑，调用基本能力构建上层自动化体系，支撑SRE工具能力拓展。
03. SRE在金融行业落地探讨
1）落地案例分析
以国内某大型银行SRE实践为例，其SRE落地进程有以下几个重要关键点：
① 确定SRE落地的核心理念：
符合长期战略，改善运维手动、重复性工作，建立SRE团队提升运维价值。
② 组建SRE试点团队：
包含团队负责人，轮值团队经理，业务核心技术成员，其他部门协助人员，从不同的团队中抽调相应人员，保证每位人员都清楚的认知SRE的建设目标，力出一孔。
③ SRE工作模式：采取平战结合模式。
- 平时建设（即日常模式）：解决运维日常问题，保证系统可用性、可靠性、稳定性，减少出故障的时间和概率，保障运维质量。
- 战时应急（即应急模式）：建立快速处理机制，SRE团队开展故障处置，第一时间恢复生产。
战时应急依赖于平时建设的工具、自动化能力、问题总结等，形成平战结合的工作模式。
④ SRE团队OKR：
团队OKR的制定与工作模式紧密配合，通过平战结合的模式，实现全景业务系统可感可见，应急处置可管可控，业务指标可计可析。同时SRE团队建立三会机制，即周例会、月例会、专题会，保证日常工作与专项事宜的快速处理。
目前来看该行的SRE实践是比较成功的，其核心在于SRE团队的组建，一方面需要有开发人员介入，核心业务人员要懂开发，懂架构，具备运维开发能力。另一方面需要具备组织能力，SRE建设目标分解到各个团队中，人员之间实现能力的融合，从而形成体系化的组织，推进整体SRE进程。
除此之外我们对众多企业SRE进程和落地实践也进行了详细的深入分析，包含农业银行、腾讯、美图等，如您感兴趣，欢迎点击了解详情！
2）经验探讨
① SRE是否适合在金融行业落地？
SRE是一个体系化的过程，从组织架构、到文化宣贯、到工具构建、到人员能力配备都具备以后，才能形成完整的SRE体系。
- 在中大型银行来说式比较适合的，中大型银行未来运维通常都会向着分布式、微服务、容器以及云架构方向去发展，同时运维团队规模比较大，拥有足够的团队和资金支撑SRE落地。
- 对于中小型银行来说，通常会以传统架构为主，有的单位会建设一部分云资源。如果说短期内企业并没有短期内进行容器化、分布式的建设规划的话，落地SRE是比较困难的。
我们建议可以先针对其中某一方向，例如工具向平台化层面去靠拢，同时如果还有富余的精力的话可以考虑进行一部分运维开发能力的建设，除此之外组织能力也可以适当培养，从而一步一步向SRE迈进，而不是一步登天。
② 如果要落地，需要注意哪些事项？
主要有3个重点：
- 标准规范制定：标准化、规范化是体系建立的第一步，运维的标准规范需要与开发与业务达成一致。
- 具备软件开发能力：能够把运维诉求变成运维产品，然后把运维产品，最终落地成为具体的工具、系统。
- 组织变革：SRE是运维与开发的能力结合，需要一部分懂开发的运维人员，也需要一部分理解运维体系的开发人员，运维与开发需要相互理解，从而将彼此诉求融入到自己的工作中。
