一图搞清楚SRE的工作内容

目录

SRE是什么？

系统稳定性衡量指标

SRE的目的是什么？

SRE稳定性保障规划

如何衡量系统的可用性

SRE的切入点

错误预算（Error Budget）

落地SLO还需要考虑的因素

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

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

故障复盘：黄金三问与判定三原则

互联网典型的SRE组织架构

---

SRE是什么？

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

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

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

系统稳定性衡量指标

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

1. MTBF，Mean Time Between Failure，平均故障时间间隔

2. MTTR，Mean Time To Repair， 故障平均修复时间

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

• MTTI：发现问题的时间

• MTTK：找到问题原因的时间

• MTTF：解决问题的时间

• MTTV：验证问题是否已解决的时间

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

1. 提升 MTBF，也就是减少故障发生次数，提升故障发生间隔时长；

2. 降低 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

负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA 或者是某个 SRE 来承担都可以，但是要求沟通表达能力要比较好。

Operations Lead，运维指挥，简称 OL

负责指挥或指导各种故障预案的执行和业务恢复

Incident Responders，简称 IR

就是所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，比如具体执行的 SRE、网络和系统运维、业务开发、平台开发、网络或系统运维、DBA，甚至是 QA 等。

客服、PR 以及商家和其它各类合作代表

对客户进行必要的安抚措施

故障响应流程机制

3.沟通反馈机制

以团队为单位，每隔 10～15 分钟做一次反馈，反馈当前处理进展以及下一步 Action，没有进展也是进展，也要及时反馈。

故障复盘：黄金三问与判定三原则

黄金三问

• 第一问：故障原因有哪些？

• 第二问：我们做什么，怎么做才能确保下次不会再出现类似故障？

• 第三问：当时如果我们做了什么，可以用更短的时间恢复业务？

故障判定的三原则

1. 健壮性原则。

这个原则是说每个部件自身要具备一定的自愈能力，比如主备、集群、限流、降级和重试等等。

2. 第三方默认无责。

如果使用到了第三方的服务，如公有云的各类服务，包括 IaaS、PaaS、CDN 以及视频等等，我们的原则就是默认第三方无责。

3. 分段判定原则。

这个原则主要应用在情况比较复杂的场景。当发生衍生故障，或者故障蔓延的原因与触发原因不同时，我们会将一次故障分段判断。

“故障是系统运行的常态，正常才是特殊状态”。

所以，你无论作为什么角色，一定要以一颗平常心来对待故障，能做到这个程度不容易，这就需要我们更加辩证地看待故障，我们一定要做到鼓励改进，而不是处罚错误。

互联网典型的SRE组织架构

先看看蘑菇街的技术架构图。

基础设施层（IaaS）

主要是以资源为主，包括 IDC、服务器、虚拟机、存储以及网络等部分。这里基础设施层和所需的运维能力，其实就是我们常说的传统运维这个角色所要具备的能力。但是这一层现在对于绝大多数的公司，无论在资源层面还是在能力层面，都有很大的可替代性。如果能够依托云的能力，不管是公有云还是私有云，这一部分传统运维的能力在绝大部分公司，基本就不需要了。

技术中台

主要包括我们使用到的各种分布式部件，如缓存、消息、数据库、对象存储以及大数据等产品，这一层最大的特点就是“有状态” ，也就是要存储数据的产品。

技术中台的很多部件相对比较标准和通用，而且在公有云上也相对比较成熟了，比如数据库和缓存，对于绝大部分公司是可以直接选择对应的公有云产品的。

业务中台

将具有业务共性的产品能力提炼出来，比如用户、商品、交易、支付、风控以及优惠等等，上面支撑的是业务前台应用

业务前台

如果以阿里的产品体系来举例，可以类比为淘宝、天猫、盒马、聚划算这样的业务产品。

无论这些业务前台的形态是什么样，但是都会利用到中台这些共享能力。这两层就是微服务化形态的业务应用了，这些应用最大的特点就是“无状态”，有状态的数据都会沉淀到刚才提到的技术中台的产品中。

接入层

四层负载均衡：跟业务逻辑不相关，所以通常会跟基础设施层放在一起，由传统运维负责。

七层负载均衡：七层负载需要做很多业务层面的规则配置，所以通常会跟中台和前台一起运维，由SRE负责。

SRE主要负责运维业务中台与业务前台两部分。

SRE组织架构是怎样的呢？

第一，组织架构要与技术架构相匹配

技术架构实现组织目标，组织架构服务并促成技术架构的实现。

第二，SRE 是微服务和分布式架构的产物

需要建立一套完备的技术保障体系。

• 技术保障平台

这部分的能力一定基于技术中台的能力之上生长出来的，是技术中台的一部分，如果脱离了这个架构体系，这个技术保障体系是没有任何意义的。

• 工具平台团队

负责效能工具的研发，比如实现 CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现，为基础运维和应用运维提供效率平台支持。

• 稳定性平台团队

负责稳定性保障相关的标准和平台，比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划。

最终的SRE组织架构图。

SRE 并不是一个单纯的岗位定义，它是由多个不同角色组合而成的一个团队。

SRE =  工具平台开发 + 稳定性平台开发。

SRE组织架构如何高效协作？

• 以赛带练

通过比赛带动训练。选择类似的真实且具备高压效果的场景，来充分暴露我们的稳定性存在哪些问题和薄弱点，然后有针对性地进行改进。

类似的场景，比如说极端的海量用户访问，像电商类产品的双十一大促、社交类产品在春晚的抢红包，以及媒体类产品的突发热点新闻等等，用户瞬时访问的流量是极大的，对于系统的稳定性冲击和挑战也就非常大。再或者，是极端的故障场景，比如机房断电、存储故障或核心部件失效等等。所以，我们讲稳定性建设，一定也是针对极端场景下的稳定性建设。

如果在自己的团队来落地“以赛带练”的话，一定要先考虑自己的业务系统应对的极端场景到底是什么，然后基于这些场景去设计和规划。