什么是SRE？SRE需要具备什么能力？

对于SRE一词，想必大家已经不陌生了，满世界都在讲SRE，但是SRE到底是个什么角色？负责哪些工作呢？今天来给大家解惑一下。

SRE最早是由Google提出的概念，其大概的意思就是：以标准化、自动化、可扩展驱动维护，用软件开发解决运维难题。这个岗位面世的时候，其根本要解决的问题就是打破传统研发人员快速迭代而引发的业务不稳定性，用以保证业务维护侧重的服务质量以及稳定性之间的平衡。

不同公司的SRE定位是不同的，可能某些公司的运维岗位也是SRE，因此，不能以偏概全，国内的SRE基本是以岗位来区分的，比如，有负责网络的SRE，有负责DBA的SRE，有专门负责业务的SRE，还有什么安全SRE等等。就谷歌所提到的SRE的理解来讲，基本都是以服务质量稳定为基线的维护工程师，只是对于SRE的要求是苛刻的，下面是我的个人理解：

• 第一：技能全面，比如网络、操作系统、监控、CICD、研发等，对于研发能力，可能不需要你精通，但是你需要具备可以使用一门语言完成某个功能的设计、开发与迭代。
• 第二：打破传统运维思想壁垒，以产品角度思维贯穿整个业务架构服务质量为前提的沟通协调能力。
• 第三：始终以软件工程解决问题为方向的规划之路。
• 第四：很强的Trouble Shooting与思考、抽象能力，这三个能力在SRE工作当中是至关重要的，是时间与实践积累的最终成果。

综上所述，国内现在的SRE，大致可以分成俩个层级，PasS-SRE和业务SRE，前者主要是维护平台基建服务质量为主的SRE，后者主要是维护业务服务质量稳定性为主的SRE，业务SRE比较像业务运维。

上面的定义只适合大厂，对于还没有传播SRE文化，SRE的岗位是比较模糊的，其定位可能就是一个运维开发工程师，要解决的问题也是全面的、多元化的。在推广SRE文化以及建设SRE工作守则的时候，需要对当前的业务架构、技术架构有全面的了解，并合理的对基建做好设计、规划、调整，这样，SRE文化才会被更好的推行下去。

下面的都是由网上整理而来，因为SRE的工作范围是由谷歌最早提出以及实践过的，所以，他的工作范围就如下所示，万变不离其宗，在这里其实有一个很核心的关键点，那就是基建的稳定性决定了SRE的工作效率，因此，我们在建设SRE文化与工作职责的时候，也要把基建的一些因素考虑进去。

---

以下为《SRE谷歌运维解密》一书当中已经提到了关键点：

• 可观测性系统
• 故障响应
• 测试与部署
• 容量规划
• 自动化软件开发
• 用户支持
• Oncall
• 制定可交付的SLI/SLO/SLA
• 故障复盘

可观测性系统

在任何有一定规模的企业内部，一旦推行起来整个SRE的运维模式，那么对于可观测性系统的建设将变得尤为重要，而在整个可观测性系统中，通常我们会分为如下三个方面：

• 指标监控：即各种指标监控，比如基础资源指标，服务性能指标，业务的调用指标。
• 日志：各种设备以及服务的运行日志监控。
• 调用链：业务层面的调用链分析，通常在分布式系统中帮助运营、开发以及运维人员快速识别整体调用的瓶颈点

一整套的可观测系统，它能确保你洞察系统，跟踪系统的健康状态、可用性以及系统内部发生的事情。

对于整个可观测系统的建设，需要注意如下两点：

• 确定质量标准是什么，并确保系统持续逼近或保持在质量标准极限范围内
• 系统地关注这项工作—而不应该只是随机地查看一下系统

在整个企业级可观测系统中，我认为至少应该包括如下几个特征：

• 完备指标采集：可以对接企业内大部分的设备与技术栈相应的监控指标；同时，支持常见设备的监控指标体系，可以快速接入监控设备和指标，避免所有设备监控都是从头构建；对于日志数据的采集支持

• 海量设备支持：企业IT系统数量和规模越来越大，因此监控系统比以前需要监控海量设备监控。

• 监控数据存储和分析：监控数据是运维分析、运维自动化和智能化的基础，因此海量监控数据存储以及基于监控数据的可视化分析是一个监控系统的基本能力。

可观测系统是整个运维体系的基础，它需要提供整个运维体系的数据化支持。

因此，一个企业级的可观测性系统应该是平台化的。一方面可以通过配置或者开发实现更多 运维指标的接入；另一方面，亦可对接更多的专业运维工具，整合并打通多元的运维数据，为更多运维场景提供数据服务。从整体上，可观测性系统为企业运维提供了一个数据基础，让我们对事故响应以及容量预测等方面更多使用数据而非凭借以往经验和拍脑袋做出决策。

故障响应

如果有什么东西出了故障，该如何提醒大家并做出回应？工具可以帮助解决这个问题，因为它可以定义提醒人类的规则。

故障响应是建立在使用可观测性系统构建的数据之上，并借助反馈循环，来帮助我们加强对服务的监控。

故障响应通常包含如下几个动作:

• 关注: 不论是主动发现瓶颈点或异常点，还是通过可观测性系统被动暴露瓶颈点，我们都应该进行主动关注
• 交流: 及时将观察到风险点通知到相关方，并告知影响面以及相关的补救措施
• 恢复: 三方达成一致后，根据补救措施进行修复相关风险点和异常点

需要注意的是，如果在前期整个可观测性系统能够做好，通常故障应当始于一个简单的告警信息或一个报障电话，因此，通常情况下，可观测系统做的足够好仅能起到追溯和排查的作用，但是无法起到及时发现的作用，此时就需要依赖于各个观测数据进行计算和评估告警，以及时将相关的告警通知到相关人，以暴露风险点。

告警只是整个故障响应的第一个环节，解决的是故障如何发现的问题，而大多数的故障响应工作都是关于定义处理策略和提供培训的，以便人们在收到警报时知道该怎么做，通常这部分更多的是过去历史经验和运维经历的总结和沉淀，包括经验的一些抽象和工具化沉淀，以保证故障响应的效率和普遍化(即不依赖人为经验)。

而对于整个告警系统来说，需