DevOps-SRE岗位到底是什么？

关注

原创最新推荐文章于 2026-09-21 16:05:05 发布 2.1k 阅读 AI 写同款· GEO 优化 ›

全栈、DevOps、SRE：三大技术岗位的定位、区别与选择指南在软件工程实践中，岗位名称常常被模糊化使用，尤其在全栈工程师、DevOps与SRE之间，职责边界和技能要求存在大量重叠，却也各有侧重。理解这些角色的本质，需要从岗位背后的核心目标出发：全栈关注业务交付的端到端闭环能力，DevOps致力于打通代码提交到生产发布的自动化流程，而SRE则用软件工程的方法保障系统长期稳定运行。三者共同构成了现代研发团队从交付效率到运行可靠性的完整支撑体系，在CI/CD、监控告警、故障响应等场景中协同发挥作用。无论是个人规划职业方向，还是团队设计组织架构，厘清这三类岗位的定位差异、技阅读详情

DevOps-SRE网站可靠性保障图

SRE是什么？

谈到网站的可靠性保障就离不开一个词SRE，它的全称是Site Reliability Engineer (网站可靠性工程师)。

SRE不单单是一个岗位，而是一个体系化的工程。我们需要学习各项技术，诸如：容量评估、故障演练、服务降级、服务限流、异常熔断、监控告警等等，然后将这些技术有机地结合起来，形成一套稳定的体系。同时需要与开发团队、运维团队、测试团队、效能团队等等，进行高效的跨团队组织协作，并最终提高系统的稳定性。

SRE的概念最早是Google提出来的，他们出了一本书《Site Reliability Engineering》，描述了这个套体系化工程是如何高效协同工作的。

系统稳定性衡量指标

我们要提高系统的稳定性，就要制定衡量系统稳定性的相关指标，系统的稳定性指标主要有以下两个：

MTBF，Mean Time Between Failure，平均故障时间间隔
MTTR，Mean Time To Repair，故障平均修复时间

MTTR又可以分为四个小指标，分别是：

MTTI：发现问题的时间
MTTK：找到问题原因的时间
MTTF：解决问题的时间
MTTV：验证问题是否已解决的时间

我们要想提升稳定性，就会有两个方向：

提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长；
降低 MTTR，故障不可避免，那就提升故障处理效率，减少故障影响时长

SRE的目的是什么？

减少故障，提升 MTBF；同时，提升故障处理效率，降低 MTTR。

SRE稳定性保障规划

从上图可以看到针对于网站的可靠性保障我们可以做到的几个方面：故障预防、故障发现、故障定位、故障恢复、故障改进；其目的是提升MTBF，降低MTTR。

如何衡量系统的可用性？

衡量系统可用性的 2 种方式

时间维度：Availability = Uptime / (Uptime + Downtime)
请求维度：Availability = Successful request / Total request

测量和判断方法

时间维度

衡量指标：比如状态码

衡量目标：达到什么目标是正常，达不到就是异常

影响时长：比如持续超过 12 小时

请求维度

衡量指标：请求成功率

衡量目标：成功率达到 95% 才算系统运行正常

统计周期：比如一天、一周、一个月等等

上图为系统稳定性的几个9以及对应的描述。

对于系统稳定性到底定“几个9”？应从三方面考虑

成本因素
业务容忍度
系统当前的稳定性状况

SRE切入点

在一个系统中，我们该如何切入SRE可靠性保障工程呢？

先了解两个概念：

SLI，Service Level Indicator：服务等级指标
SLO，Service Level Objective：服务等级目标

SLI就用来判断系统稳定性的指标，比如接口请求状态码是非500的比例

SLO就SLI要达成的目标，比如接口请求状态码是非500的比例要达到99.95%

SRE应该如何选择SLI？

两个原则

原则一：选择能够标识一个主体是否稳定的指标，如果不是这个主体本身的指标，或者不能标识主体稳定性的，就要排除在外。
原则二：针对电商这类有用户界面的业务系统，优先选择与用户体验强相关或用户可以明显感知的指标。

VALET方法

Google推荐使用的方法。

Volume- 容量

服务承诺的最大容量是多少

Availablity- 可用性

代表服务是否正常

Latency- 时延

错误率有多少？

Errors- 错误率

错误率有多少？

Tickets- 人工介入

是否需要人工介入？

如何通过 SLO 计算可用性？

非常简单，比如我们选择了三个SLO：

SLO1：99.95% 状态码成功率

SLO2：90% Latency <= 80ms

SLO3：99% Latency <= 200ms

那么可用性就是：

Availability（可用性） = SLO1 & SLO2 & SLO3

错误预算（Error Budget）

什么是错误预算呢？其实就是可以犯错误的次数。我们要落地SLO，应该先将其转换为Error Budget。

如何计算错误预算？

假设在 4 周的时间，这个应用所有的请求次数是 4,653,680，按照给出的 SLO 反向推导，就可以得到容许的错误次数，这就是错误预算。

例如：99.95%Availability，则错误预算就等于4,653,680 * 0.05%=23268

在SRE实践中如何应用错误预算？

稳定性燃尽图

制定好错误预算后SRE需要严格遵守它，所以我们需要把错误预算尽可能直观地表现出来，随时可以看到它的消耗情况。当你和团队成员能够时刻看到还有多少犯错的机会时，对生产系统的敬畏心理也会大大增强。而且当错误预算消耗到一定比例，如 80% 或 90% 时，就要开始预警，控制各种变更，或者投入精力去解决影响稳定性的问题。

设定四个自然周内看看错误预算还剩下多少来评定这个周期的稳定性要求是否达标。

故障定级

将故障等级设置为 P0~P4 这么 5 个级别，P0 为最高，P4 为最低。

稳定性共识机制

当错误预算处于不同状态时，一般都会采取哪些常见措施呢？

第一，剩余预算充足或未消耗完之前，对问题的发生要有容忍度。

第二，剩余预算消耗过快或即将消耗完之前，SRE 有权中止和拒绝任何线上变更。

基于错误预算的告警

第一个，相同相似告警，合并后发送，比如同一应用集群内同一时间内，同一异常告警，就先合并，对外只发送一条，这种比较简单直接。

第二个，基于错误预算来做告警，也就是说我们只关注对稳定性造成影响的告警，比如我们前面提到的，当单次问题消耗的错误预算达到 20% 或 30% 等某一阈值时，就意味着问题非常严重了，这种告警信息一旦收到，就要马上做出响应。这样告警数量不多，既达到了收敛效果，又非常精准。

如何衡量 SLO 的有效性？

SLO 达成情况。我们用达成（Met），或未达成（Missed）来表示。
“人肉”投入程度。英文表示为 Toil，这里用形象一点的“人肉”投入作为它的译意，泛指需要大量人工投入、重复、繁琐且没有太多价值的事情。我们用投入程度高（High）和低（Low）来表示。
用户满意度。英文就是 Customer Satisfaction，可以理解为用户感受和体验如何。这个信息可以通过真实和虚拟渠道获得。真实渠道如客服投诉、客户访谈和舆情监控获取；虚拟渠道如真机模拟拨测。我们用满意度高（High）和低（Low）来表示。

总共 3 个维度，每个维度有 2 种情况，组合起来就是 8 种情况。

落地SLO还需要考虑的因素

1.梳理出系统的核心核心链路以及核心应用，以及这些应用之间的强弱关系。

针对核心和非核心应用，以及强弱依赖关系，我们在设定 SLO 时的要求也是不同的，具体来说，可以采取下面 4 个原则。

第一，核心应用的 SLO 要更严格，非核心应用可以放宽。

第二，强依赖之间的核心应用，SLO 要一致。

第三，弱依赖中，核心应用对非核心的依赖，要有降级、熔断和限流等服务治理手段。

第四，Error Budget 策略，核心应用的错误预算要共享，就是如果某个核心应用错误预算消耗完，SLO 没有达成，那整条链路，原则上是要全部暂停操作的

2.通过容量压测和混沌工程来验证核心链路的SLO是否达成。

故障发现：如何建设On-Call的流程机制

1.确保关键角色在线。

关键角色是指整个产品体系中的所有关键角色。

2.组织 War Room 应急组织。

有专门处理故障的“消防群”（暗含着灭火的意思），会将这些关键角色纳入其中，当有故障发生时会第一时间在消防群通报，这时对应的 On-Call 同事就要第一时间最高优先级响应呼叫（Page）。如果是工作日，对于严重故障，会立刻组织成立 War Room，责任人会马上聚到一起；如果是非工作时间，则会通过电话会议的方式拉起虚拟 War Room。

3.建立合理的呼叫方式。

使用固定的 On-Call 手机，建立手机与所有 On-Call 系统的对应关系，比如这个手机号码对应交易核心应用，另一个号码对应 IDC 机房运维等等。这样我们在 On-Call 时就不再找具体的哪个人，而是手机在谁手中，谁就承担 On-Call 职责。除非问题迟迟得不到解决，或者遇到了疑难杂症，这种时候再呼叫其他同事参与进来。

4.确保资源投入的升级机制。

要给到运维和 SRE 授权，当他发现问题不是自己或现有 On-Call 人员能解决的时候，他有权调动其他必要资源投入。

5.与云厂商联合的 On-Call。

做好与云厂商之间的协作磨合，联合故障演练，必要的授权等等

故障处理：一切以恢复业务为最高优先级

故障响应有两个方面：技术方面和流程方面，这里主要讲一下流程方面该如何应对

流程主要有：

1.War Room（应急作战指挥室）：真实的会议室办公或者虚拟群组

2.关键角色分工

Incident Commander，故障指挥官，简称为 IC

这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行。

Communication Lead，沟通引导，简称 CL