《SRE实战手册》学习笔记

SRE背景

背景：互联网行业不断发展；

目的：提升用户价值交付效率；

措施：积极采用微服务、容器化及其他分布式技术产品，并且积极引入DevOps之类的先进理念；

优势：交付效率提升巨大；

挑战：复杂系统架构的稳定性很难得到保障；

最佳实践：业内稳定性领域的最佳实践是Google SRE；

1、SRE包含哪些工作事项

稳定性规范制定，监控、压测、服务治理、大促稳定性保障、故障应急和管理、组织架构建设；

2、SRE常见的问题与困惑

3、我们所看到的SRE

理念：SRE 到底是什么？我们应该怎么来理解它？有哪些关键点？

实践：到底应该从哪里入手建设 SRE？组织架构应该怎么匹配？

4、稳定性保障的切入点

切入点：稳定性保障的标准化！

跨团队部门沟通：没有共识、统一的稳定性衡量标准；

衡量稳定性的标准：SLO是稳定性保障的共识；

稳定性保障的核心：合理的组织架构可以有效应对各种稳定性问题！

5、DevOps和SRE的区别

DevOps核心是做全栈交付，SRE核心是稳定性保障，关注业务所有活动，两者共性是：都使用软件工程解决问题。

DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频的迭代来满足市场需求，抢占市场(产品的迭代是关乎一整条交付链的事)。

高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，则运维必须开启DevOps来实现全栈交付；

因为不断的迭代交付(也就是俗称的变更)是触发故障，非稳定性根源，而互联网产品/服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生。

如何理解SRE

1、SRE的定义

定义：SRE是一整套稳定性保障的最佳实践体系！

2、SRE认知误区

管理的角度： SRE就是一个具备全栈能力且能解决所有稳定性问题的岗位；

运维的角度：做好监控，快速发现问题、快速定位问题根因；

平台的角度：加强容量规划，学习Google做到完全自动化的弹性伸缩；

其他的角度：SRE传统运维的升级版，把运维自动化做好就行；

3、如何理解SRE

SRE稳定性保障规划图：

SRE是一整套稳定性保障的最佳实践体系，需要高效的跨团队组织协作才能完成。

从体系角度出发，需要将不同的技术结合起来，设置不同的职能岗位，制定让不同角色有效协作的机制，让体系发挥力量。而目前存在的一个痛点是角色和团队之间的协作相对独立，各自为战。

4、SRE根本目的

目的：提升稳定性，保障高效的用户价值交付。

通用衡量指标及计算公式：

提升稳定性的2个措施：提升故障时间间隔，降低故障修复时间，SRE也是以这两个指标为宗旨。

5、MTTR细分指标

6、不同阶段TODO项

Pre-MTBF阶段(无故障阶段)：做好架构设计，提供限流、降级、熔断这些 Design-for-Failure 的服务治理手段，以具备故障快速隔离的条件；

还可以考虑引入混沌工程这样的故障模拟机制，在线上模拟故障，提前发现问题。

Post-MTBF(故障复盘阶段)：上一故障结束开启新MTBF阶段，应该要做故障复盘，总结经验，找到不足，落地改进措施等。

MTTI阶段(故障发现响应阶段)：依赖监控系统及时发现问题，对于复杂度较高和体量非常大的系统，要依赖 AIOps 的能力，提升告警准确率，做出精准的响应。

同时 AIOps 能力在大规模分布式系统中，在 MTTK 阶段也非常关键，因为我们在这个阶段需要确认根因，至少是根因的范围。

7、DevOps和SRE的协同

7.1：DevOps主要以驱动价值交付为主，搭建企业内部功效平台，SRE主要需要协调多团队合作来提高稳定性。如：

• 与开发和业务团队落实降级；
• 在开发和测试团队内推动混沌工程落地；
• 与开发团队定制可用性衡量标准；
• 与开发、测试、devops、产品团队，共同解决代码质量和需求之间的平衡问题；

7.2：SRE解决运维领域的故障目标，DevOps更偏向于为价值导向的效率目标，这是互相成就的一个过程。

在实践SRE过程中，不可避免要使用一些DevOps的技术，方法论，组织文化等，通过这些，达成一致目标。

7.4：DevOps整体的表现倾向于价值交付，与敏捷的价值观贴合；而SRE的侧重点在于保障系统的稳定运行，通过系统稳定性实现价值最大化！

两者有不同，也有交叉，他们不是非此即彼的选项。至于哪种更好，主要看团队的实际情况，产品本身所处的阶段，是另一个重要的考量依据！

7.5：devops目标是提升开发效率和提升交付效率，sre是保证服务稳定。devops针对的是交付产品和开发者，追求交付在产品的质量上的快。

系统可用性:故障≠稳定

业界常说的系统可用性(Availability)”3个9″、”4个9″，和建设SRE的目标强相关。SRE的稳定性目标就是尽量减少系统故障或异常运行状态的发生，提升系统可用的运行时间占比。

1、衡量可用性2种方式

一个是时间维度，一个是请求维度，计算公式如下：

2、衡量稳定性的三要素

衡量指标：如系统请求状态码；

衡量目标：如非5XX占比达到95%；

影响时长：如非5XX占比低于95%持续10分钟；

PS：上述案例只是从请求维度出发，加上时间维度，还有统计周期的因素需要考虑。

3、时长维度:可用性对照表

稳定性只与故障挂钩，粒度不够精细。

经验：故障一定意味着不稳定，但是不稳定，并不意味着一定有故障发生。

4、设定稳定性目标要考虑3个因素

成本因素：追求的指标越高，要求更多的资源冗余，需要综合考虑ROI来做平衡；

业务容忍度：核心业务——99.9%-99.99%；非核心业务——99%%+；

系统当前稳定性情况：合理的标准比更高的标准更重要！

SRE 关注的稳定性是系统整体运行状态，而不仅仅只关注故障状态下的稳定性，在系统运行过程中的任何异常，都会被纳入稳定性的评估范畴中，需要采用多维度的衡量指标和统计方式来评估。

前言

这篇文章是《SRE实战手册》学习笔记的第二篇，理解SRE之后，就要找到切入点来落地。

 

理解SRE中的指标和目标

SRE强调稳定性，一般是看整体的系统情况，也就是常说的”3个9″、”4个9″这样可量化的数字。

这个“确定成功请求条件，设定达成占比目标”的过程，在SRE中就是设定稳定性衡量标准的SLI和SLO的过程。

1、SRE的两个核心

SLI(Service Level Indicator)：服务等级指标，即选择哪些指标来衡量稳定性（状态码为非 5xx 的比例）；

SLO(Service Level Objective)：服务等级目标，指设定的稳定性目标（大于等于 99.99%）；

落地SRE的第一步：选择合适的SLI，设定合理的SLO，SLO是SLI要达成的目标。

监控体系是SRE体系中很重要的组成部分，也是最直观的指标产出展示方式。

2、常见的监控指标

3、选择监控指标的考量点

4、快速识别SLI指标的方法

VALET是5个单词的首字母，分别是Volume、Availability、Latency、Error 和 Ticket。

5、Google-VALET-dashboard

链接：Google的SLI和SLO设定模板

6、如何通过SLO计算系统可用性

系统可用性Availability = Successful request / Total request，常见的计算方式有如下两种：

对系统相关监控指标要分层，识别出我们要保障稳定性的主体（系统、业务或应用）是什么，然后基于这个主体来选择合适的 SLI 指标。

不是所有的指标都是适合做 SLI 指标，它一定要能够直接体现和反映主体的稳定性状态。可以优先选择用户或使用者能感受到的体验类指标，比如时延、可用性、错误率等。

达成稳定性目标的共识机制

知道了SRE的核心是设定目标和指标，但在具体落地过程中，该如何找到切入点呢？反过来看，可以制定一个允许犯错的次数标准，只需要去监控这些错误，就是一个很好的落地切入点。

1、设定错误预算

允许犯错的次数标准在SRE体系中叫做Error Budget，即错误预算。错误预算其实和驾照记分制是一样的，最大的作用就是“提示你还有多少次犯错的机会”。

错误预算的计算方式通过SLO推导得到，参考计算公式：Availability=SLO1&SLO2&SLO3。

2、如何应用错误预算

2.1稳定性燃尽图

特点：尽可能直观的将错误预算表现出来，随时可以看到它的消耗情况。同时加入错误预算消耗告警，如达到80%时开始预警，通过控制各种变更等手段来降低预算消耗频次。

参考：Google的错误预算燃尽图

注意事项：

2.2故障定级机制

判断一个问题是不是故障，除了看影响时长，还有一点就是按照问题消耗的错误预算比例来评估。

通过错误预算来定义故障等级就可以做到量化，一旦可以被量化就意味着可以标准化，有了标准就可以进而推进达成共识。

参考：业内常见的故障定级维度和定义

2.3稳定性共识机制

由于每个人对稳定性的认知不同，因此通过建立稳定性共识机制并且积极推动，也是一种很好的实践方式。

参考：推动稳定性共识机制的2个指导原则

从推行的角度来讲，涉及到跨团队沟通共识机制。建立稳定性共识机制一定是 Top-Down，也就是自上而下，至少要从技术 VP 或 CTO 的角度去推行。

而且当有意见不一致的情况出现时，还要逐步上升，直至 CTO 角度来做决策。一定要自上而下推进周边团队或利益方达成共识。

2.4基于错误预算的告警

监控告警有一点很重要的是告警降噪收敛。即不要被“狼来了”的告警搞定疲惫不堪，要有对应的处理机制。

参考：常见的告警降噪收敛方案

3、如何衡量SLO的有效性

衡量 SLO 及错误预算策略是否有效，就是看实际运行后是否真的能达到我们的期望。见下面三个关键维度：

参考：不同维度不同情况的应对策略

针对上述的几种情况，将这些策略总结起来，主要有如下三种策略：

3.1收紧SLO

原因为目标设定太低，即SLO达成(Met)，但是用户不满意(Low)，常见表现方式为客诉增多或内部吐槽变多；

3.2放宽SLO

原因为目标设定太高，SLO达不成(Missed)，但用户反馈很不错(High)，这样会造成错误预算提前消耗完，导致很多变更暂停，产品延期，甚至会做一些无谓的优化，这时可以适当放宽SLO；

3.3保持现状，对有问题的维度采取针对性的优化

在SLO可以达成的情况下，尽量提升用户价值交付效率，围绕这个终极目标，不断优化自己的SLO和错误预算策略。

落地SLO时要考虑的因素

1、确定核心链路SLO

所谓核心链路，即某个系统为用户提供业务价值的主流程。

以电商系统来说，导购-搜索-商品详情-购物车-下单-支付即为核心链路。

指导原则：先确定核心链路的SLO，然后根据核心链路进行SLO拆解。

1.1确定核心链路

通过全链路跟踪的技术手段来找出所有应用，即呈现出调用关系的系统拓扑图。

常见工具：cat、jaeger、zipkin、pinpoint、skywalking。

1.2确定核心应用

根据业务场景和特点，从繁杂的应用中通过不断讨论和分析来确认核心应用。

以电商系统为例，核心应用一般有index、search、product、order、coupom、payment等。

参考：核心交易链路图

1.3确认强弱依赖

核心应用之间的依赖关系，称之为强依赖，而其它应用之间的依赖关系，我们称之为弱依赖。

其中包含两种关系，一种是核心应用与非核心应用之间的依赖，另一种是非核心应用之间的依赖。

当然，还可以通过其他方式确认强弱依赖关系，比如：是否可以直接熔断等。

2、设定SLO的四大原则

2.1核心应用的SLO要更严格，非核心应用可以放宽。 这么做是为了确保SRE精力能够更多地关注在核心业务上；

2.2强依赖之间的核心应用，SLO要一致。 如下单的 Buy 应用依赖 Coupon 这个促销应用，我们要求下单成功率的 SLO 要 99.95%，就会要求 Coupon 的成功率 SLO 也要达到 99.95%；

2.3核心应用对非核心的弱依赖，有降级、熔断和限流等服务治理手段。 这样做是为了避免由非核心应用的异常而导致核心应用 SLO 不达标；

2.4核心应用错误预算要共享，如果某核心应用错误预算消耗完，那整条链路原则上都要停止变更操作。

可以根据实际情况适当宽松，如果某核心应用自身预算充足，且变更不影响核心链路功能，可以按照自己的节奏继续做变更。

3、如何验证核心链路SLO

3.1容量压测

容量压测的主要作用，就是看 SLO 中的 Volume，也就是容量目标是否可以达成。

另一个作用就是看在极端的容量场景下，验证限流降级熔断等服务治理策略是否可以生效。

3.2Chaos Engineering-混沌工程

混沌工程可以帮助我们做到在线上模拟真实的故障，做线上应急演练，提前发现隐患。

容量压测是模拟线上真实的用户访问行为，混沌工程是模拟故障发生场景，主动产生线上异常和故障。

混沌工程是 SRE 稳定性体系建设的高级阶段，一定是 SRE 体系在服务治理、容量压测、链路跟踪、监控告警、运维自动化等相对基础和必需的部分非常完善的情况下才能考虑。

4、如何选择系统验证的时机

参考：Google的建议

4.1错误预算充足就可以尝试，尽量避开错误预算不足的时间段。因为在正常业务下，我们要完成 SLO 已经有很大的压力了，不能再给系统稳定性增加新的风险。

4.2评估故障模拟带来的影响，比如，是否会损害到公司收益？是否会损害用户体验相关的指标？如果造成的业务影响很大，那就要把引入方案进行粒度细化，分步骤，避免造成不可预估的损失。

4.3选择业务量相对较小的情况下做演练。这样即使出现问题，影响面也可控，而且会有比较充足的时间执行恢复操作，同时在做全链路压测之前，先进行单链路和混合链路演练，只有单链路全部演练通过，才会执行更大规模的多链路和全链路同时演练。

4.4生产系统稳定性在任何时候，都是最高优先级要保证的。不能因为演练导致系统异常或故障，这是不被允许的。所以，一定要选择合适的时机，在有充分准备和预案的情况下实施各类验证工作。

前言

前面介绍了SRE的基础，包括SLI和SLO以及Error Budget(错误预算)。其中：

其实在SRE落地实践过程中，主要是解决如下两种情况的问题：

• 制定的错误预算在周期还没结束前就消耗完了，这意味着稳定性目标未达成；
• 另一种是错误预算在单次问题中被消耗过多，这时候要把这样的问题定性为故障；

这篇文章，主要说明如何通过应对故障来落地SRE。

故障发现：建设On-Call机制

1、MTTR-故障处理流程

2、MTTR各环节所占时长

绝大多数故障，只要能定位问题根因，往往就能快速解决。

故障处理的生命周期中，大部分时间耗费在寻找和定位问题上面。

分布式系统中，往往优先级最高的是线上业务止血（即Design for Failure策略）。通过服务限流、降级、熔断甚至主备切换等手段，来快速恢复线上业务的可用性。

故障处理的核心：提升MTTR每个环节的处理效率，缩短处理时间，这样才能缩短整个MTTR，减少对错误预算的消耗。

3、MTTI：从发现到响应故障

MTTI：故障的平均确认时间。即从故障实际发生的时间点，到出发采取行动去定位前的这段时间。

这个环节，主要做两件事：

1）判断出现的问题是不是故障（主要依赖于监控和告警体系）；

2）确定由谁来响应和召集人进行处理（需要一套明确清晰的决策及消息分发机制）；

这两件事，其实就是SRE中的On-Call机制（一般有专门的NOC岗位来负责响应和召集）。

On-Call机制的核心，就是确保关键角色实时在线，随时应急响应。

4、On-Call机制流程建设

1）确保关键角色在线（轮班的各岗位关键角色，需要有backup）；

2）组织War Room应急组织（常见的有线上消防群&线上监控告警群）；

3）建立合理的消息分发方式（谁值守谁负责，而不是谁最熟悉谁负责）；

4）确保资源投入的升级机制（即值班相关SRE角色有权调动其他资源，甚至故障升级）；

5）与云厂商联合的On-Call机制（对于上云的企业，和云厂商共建故障信息对接群，定时故障演练）；

6）终极方案：针对可能出现的故障，落地故障应急SOP，制定“故障应急处理手册”，这样人人都是SRE。

5、On-Call机制的优势

1）最快最好的熟悉系统的方式；

2）培养和锻炼新人以及backup角色；

3）新人融入团队和承担责任的最佳方式；

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

在MTTR环节中，MTTK、MTTF、MTTV分别对应故障诊断、故障修复与故障确认。

故障处理的最终目标：采取所有手段和行动，一切以恢复线上业务可用为最高优先级。

1、常见的故障蔓延原因

1）故障隔离手段缺失（限流、降级、熔断、弹性扩容）；

2）关键角色和流程机制缺失（信息同步、方案决策、反馈机制）；

3）线上故障灾备演练环节缺失（故障应急SOP、故障应急处理手册）；

2、Google故障指挥体系

3、建立有效的应急响应机制

3.1流程机制

1）故障发生后，On-Call的SRE最开始是IC，有权召集相关角色和资源，快速组织线上消防；

2）如果问题和恢复过程非常明确，IC仍是SRE不做转移，由他指挥每个人要做的事情，优先恢复业务优先；

3）如果问题疑难或影响范围大，SRE可以要求更高级别的角色介入如 SRE主管或总监。一般原则是谁业务受影响最大谁牵头组织。

      这时IC的职责转移给更高级别的主管。如果是全站范围的影响，必要时技术VP或CTO也可以承担IC职责，或授权给某位总监承担；

4）SRE回归到OL的职责上，负责组织和协调具体的执行恢复操作的动作。

3.2反馈机制

1）定时反馈(10-15分钟)，没有进展也要及时反馈；

2）执行操作或变更事先通报，说明变更操作重点和影响范围；

3）尽量减少对执行者的干扰，让执行者能够聚焦；

4）信息要及时同步给客服、PR及商家和其他各类合作方；

5）团队leader收集反馈并传递IC的指令，CL收集信息并在更大范围内同步汇总后的信息，同事传递给外部联系人；

6）除了快速恢复业务，保持信息及时同步和透明也非常关键(便于对用户和其他平台的安抚措施能够快速执行到位)！

注意：信息同步尽量不要用技术术语，尽量以业务画的语言描述，并给到对方大致的预期！

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

故障复盘的核心：从故障中学习和提升！

故障复盘的教训：故障根因往往不止一个，要聚焦到引起故障的原因都是哪些，是否都有改进空间。

故障复盘的心得：解决问题，而不是不断提出新的问题！

1、故障复盘黄金三问

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

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

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

注意事项：对事不对人，不允许出现互相指责和埋怨甩锅。故障复盘的核心是找到原因并加以改进，落地优化。

2、故障判定的三原则

1）健壮性原则：每个组件自身要具备一定的自愈和高可用能力，而非全部由下游依赖放兜底；

2）三方默认无责：对内谁受影响谁改进，对外推进第三方改进(稳定性要做到相对自我可控，而不是完全依赖外部)；

3）分段判定原则：对于原因较复杂或链路较长的故障，建议分阶段评估，不同阶段有不同的措施。这一原则的出发点是要摒弃“故障根因只有一个”的观点。

典型案例：互联网的SRE组织架构

在SRE体系中，高效的的故障应对和管理工作，需要整个技术团队共同参与和投入。

1、互联网典型技术架构

参考：SRE组织架构的构建原则

• 组织架构要与技术架构相匹配(两者是互相补充和促进的作用)；
• SRE是微服务和分布式架构的产物(微服务和分布式技术复杂性对传统的运维模式和理念产生了冲击和变革)；

2、系统架构的演变历程

要引入SRE体系，并做对应的组织架构调整，首先要看技术架构是否朝着服务化和分布式方向演进。

要想在组织内引入并落地SRE体系，原有技术团队的组织架构或协作模式必须要做出一些变革。

3、互联网组织架构示意图

基础设施：传统运维这个角色所具备的能力。

平台服务：包括常见的技术中台(有状态的数据产品研发团队)和业务中台(无状态的具有业务共性的业务研发团队)以及业务前台(H5&前端&移动端产品研发团队)。

技术保障平台：微服务和分布式架构下的运维能力，是整个技术架构能力的体现，而不是单纯的运维能力体现。

工程效能平台：负责效能工具的研发，比如实现 CMDB、运维自动化、持续交付流水线以及部分技术运营报表的实现，为基础运维和应用运维提供效率平台支持(对业务理解及系统集成能力要比较强，但是技术能力要求相对就没那么高)。

稳定性保障平台：负责稳定性保障相关的标准和平台，比如监控、服务治理相关的限流降级、全链路跟踪、容量压测和规划(技术要求和团队建设复杂度较高，需要很多不同领域的专业人员)。

总结：SRE = PE + 工具平台开发 + 稳定性平台开发！

业内经验：高效的SRE组织协作机制

SRE落地经验：以赛带练。

1、什么是以赛带练？

“以赛带练”这个术语最早出自体育赛事中，即通过比赛带动训练(如足球、篮球或田径比赛)。

目的是在真实的高强度竞争态势和压力下，充分暴露出个人和团队的不足及薄弱点，然后在后续的训练中有针对性地改进，这样对于比赛成绩的提升有很大帮助，而不是循规蹈矩地做机械性训练。

2、SRE落地如何以赛带练？

以赛带练的策略放在系统稳定性建设中非常适用。

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

类似的场景，如电商类产品的双十一大促、社交类产品在春晚的抢红包，以及媒体类产品的突发热点新闻等，对于系统的稳定性冲击和挑战非常大。

再或者是极端故障场景，如机房断电、存储故障或核心部件失效。稳定性建设，一定也是针对极端场景下的稳定性建设。

“以赛带练”的目的就是要检验系统稳定性状况到底如何，系统稳定性还有哪些薄弱点。

3、SRE各个角色如何协作？

案例：双十一大促保障！

1）大促项目kickoff（项目启动会）

2）核心链路技术指标拆解及模型评审（用户模型、流量模型、压测模型）

3）稳定性预案评审（前置预案、主动预案、紧急预案、恢复预案）

4）全链路压测及复盘会议（每轮压测结束都需要进行复盘总结和落地TODO项）

通过上述每个环节的工作细节，让不同角色都参与进来！

4、哪些事项可以做到日常化？

除了大促或者极端场景之外，将一些案例落地到日常的工作中，是提升稳定性的进阶工作。场景如下：

1）核心应用变更及新应用上线评审；

2）周期性的技术运营以及汇报工作场景；

概括总结：实践是检验SRE的唯一标准

落地实践，小步快跑胜过考虑太多！

实践需要落实到具体的真实的场景和细节问题上，而不是凭空虚构！

落地SRE要尽可能早的参与到项目中，而非等到线上出问题才考虑引入SRE机制！

SRE 更多的要成为稳定性的监督者和推进者，而不是各种问题的救火队员！

相关书籍

《The Site Reliability Workbook》：兼具普适性和参考性；

《Building Secure&Reliable Systems》：适合进阶阶段阅读；

《Site Reliability Engineering》：SRE落地取得一定成效后阅读；