SRE

← 上一章：CICD DevOps ｜ 返回总目录 ｜ [下一章 →]

• 产品研发团队和SRE团队一起为服务及用户选择适当的可用性目标，并将确保达成

• 尽力减少“人肉”投入，推动问题解决的自动化

  • SRE不倡导甚至是反对任何不必要的“人力”介入，要尽可能地减少手工操作

  • Google实践的SRE对团队成员可以花费在辛勤劳动上的投入作为硬件规定：不得超过50%

• 通过降低失败成本而提升服务效能

  • SRE的好处未必一定要可靠性提升，实际上，它的好处更在于改进产品开发的输出速度，因为MTTR的降低， 减少了工程师将时间浪费在解决问题之上的精力成本

• 与开发团队共享所有权

  • SRE倾向于关注生产问题而非业务逻辑问题（那是研发人员的任务），但他们也会创建出软件工程工具来解决问题，这些工具能共享给研发团队为其工作提供基础支撑

  • SRE更关注服务的可用性、延迟、性能、效率、变更管理、监控、应急响应和容量规划方面的需求

  • 产品开发和SRE团队应该对技术栈有一个一致的观点——前端、后端、库、存储、内核和物理机

http://www.magedu.com

SRE和DevOps

 对比

DevOps是一套有关运维和产品开发之间全生命周期协作的广泛原则。

SRE是一个工作角色，一组有效的实践，以及激励这些实践的信念。

http://www.magedu.com

什么是SRE？

• 全称为：Site Reliability Engineering，由Google工程副总裁Ben Treynor Sloss首次提出

• “SRE就是让一个软件工程师来主导设计一个新型运维团队的结果。”

  • Google SRE团队主要是两类工程师

    • 软件工程师（50-60%）

    • 具有系统及网络知识的但开发能力稍弱一些的软件工程师（40%-50%）

  • SRE团队的所有成员必须非常愿意，也非常相信用软件工程的方法可以解决复杂的运维问题

    • 对重复性的手工操作有天然的排斥感

    • 有足够的技术能力快速开发出软件系统替代手工操作

• 从本质上来说，SRE就是用软件工程的思维和方法论完成之前由系统管理员团队手动完成的任务，团

• 队成员倾向于通过设计、构建自动化工具来取代人工操作

  • SRE模型成功的关键在于对软件工程的关注，从而避免了传统Ops团队规模随产品规模和流量规模增长而线性成长的局面

  • 因此，SRE团队必须有足够的时间进行编程，Google的SRE团队甚至设立了50%的硬指标

• SRE是一门工程科学 ，旨在帮助组织在其基础设施和应用系统中可持续地达成预设的可靠性目标

http://www.magedu.com

SRE 核心职责

 SRE的核心职责主要体现在以下几个方面

• 可用性改进

• 延迟优化

• 性能优化

• 效率优化

• 变更管理

• 监控

• 紧急事务处理

• 容量规划与管理

• 影响系统可靠性的常见因素

• 人员误操作

• 雪崩效应

• 未经充分、完整测试的版本发布

• 基础设施故障及定期升级维护

http://www.magedu.com

SRE 方法论

• 确保长期关注研发工作

  • Google将SRE团队的运维工作限制在50%以内，余下的工作时间要投入到研发中

  • 无法满足该目标时，采取一些暂时性的措施将运维压力转移回开发团队处理，例如

    • 将生产环境发现的Bug和产生的工单转给研发管理人员去分配

    • 将开发团队成员加入到轮值on-call体系中共同承担轮值压力

  • 这种措施可激励研发团队设计、构建出不需要人工干预、可以自主运行的系统

  • 所有的产品事故都应该有对应的复盘

    • 事故发生、发现、解决的全过程

    • 事故的根因，预防或者优化解决方案

• 在保障服务SLO的前提下最大化迭代速度

  • 产品和运维团队间最主要的矛盾是迭代创新的速度与产品稳定程度之间的矛盾

  • SRE使用“错误预算（error budget）”正面这种矛盾

    • 100%可用并非正确的可靠性目标：任何软件系统都不是，也不应该追求做到100%可靠

    • 基于用户期待的可用性标准建立一个合理的可靠性目标，错误预算=“1-可靠性目标”

    • 产品研发部门和SRE部门可以在这个范围内将预算用于新功能上线等任何与产品创新相关的事务

  • 基于错误预算，可靠性目标不再是“零事故运行”，于是，生产事故也不再是一件坏事，而是创新流程中一个不可避免的环节，产品研发团队和SRE团队通过协作共同管理这些事故

http://www.magedu.com

SRE 方法论（2）

• 监控系统

  • 合理的指标设计和告警策略是提升系统整体可用性的必要手段

  • 监控系统不应该依赖人工来分析告警住处，而是由系统自动完成，仅当需要用户操作时，才发送通知

  • 监控系统应该只有三类输出：紧急警报（需要立即处理）、工单（在给定的时间窗口内处理）和日志（调度和事后分析时使用）

• 应急事件处理

  • A = MTBF/(MTBF + MTTR)

    • MTBF：平均无故障时间

    • MTTR：平均修复时间

  • 通常，人工操作是故障恢复过程最为消耗时间的因素，建设具有“自愈”能力的系统是首要目标

  • 不可避免地需要人工介入时，要有记录有清晰调度步骤和分析方法的“运维手册”指导快速修复

    • 运维手册及其使用要确保on-call的所有成员熟练掌握

    • 日常要有例行的故障应急演练

  • Google SRE的工作重心之一就是运维手册的维护

http://www.magedu.com

SRE 方法论（3）

• 变更管理

  • 大约70%的事故由变更所触发

◼ 最佳实践是要能够自动化地完成以下任务

  - 采用渐进式发布机制

  - 迅速而准确地检测到问题

  - 出现问题时，要能安全、迅速地执行回滚

• 需求预测和容量规划

  • 需求预测和容量规划简单来说就是保障一个业务有足够的资源冗余度去服务预测中的未来需求

  • ◼ 容量对系统可用性来说至关重要，SRE必须主导容量规划的过程及资源部署的过程

  • 一个业务的容量规划要考虑两个方面的因素

    • 自然增长：用户增长、流量增长等导致的资源用量上升

    • 非自然增长：新功能发布、商业推广等

  • 容量规划的步骤

    • 预测模型要能准备预测自然增长

    • 要合理、及时、准备统计各类可能的非自然增长

    • 必须要有周期性的压力测试，以获取系统的准确容量

http://www.magedu.com

SRE 方法论（4）

• 资源部署

  • 部署新资源仅应该在必要的情况下进行

    • 资源通常有较高的成本

    • 部署和配置过程必须要确保能正确执行完毕

  • 新资源的部署与配置是一个相对危险的操作

    • 增加现有容量，通常需要启动新实例甚至是整个集群，这可能会导致大幅修改现有的集群配置

    • 同时还要执行一系列的测试，以确保新上线的资源可以正确地服务用户

• 效率与性能

  • 对于商业组织来讲，必然追求高效地利用各种资源，以降低系统的总体拥有成本

  • 服务的利用率指标与服务的工作方式以及为其置备容量有关，于是，容量配置策略也就事关总体拥有成本

  • 业务在资源层面的需求通常由用户需求（流量）、可用容量和软件的资源使用效率驱动

http://www.magedu.com

接受风险，拥抱风险

 追求极端的可靠性会带来成本的极大上升

◼ 机会成本：限制了新功能的开发速度和将产品交付给用户的速度

◼ 冗余物理服务器/计算资源成本：基础软硬件成本大幅增加

• SRE眼中的可靠性

◼ 寻求快速创新和高效的服务营业务之间的风险平衡，而非简单地将服务在线时间最大化

◼ 努力提高一项服务的可靠性，但不能超过该服务需要的可靠性，或者不能越过太多

 系统可用性评估方式

◼ 基于时间的可用性

• 可用性=系统正常运行时间/(系统正常运行时间+停机时间)

• 基于请求的可用性（请求成功率）

  • 可用性=成功请求总数/总的请求数

http://www.magedu.com

接受风险，拥抱风险（2）

• 确定“可用性目标”

  • 目标应该因服务而异，通常取决于服务提供的功能，以及服务在市场上的定位

  • 确定可用性目标时需要考虑的问题

    • 用户期望的服务水平是什么？

    • 该服务是否直接关系到收入（自身的收入或者客户的收入）？

    • 是有偿服务，还是免费服务？

    • 市场上竞争对手提供的服务水平如何？

    • 该服务是ToB的业务，还是ToC的业务？

  • 成本是决定一项服务的可用性目标的一个关键因素

    • 构建和运维可用性再多一个“9”的系统，收益会增加多少？

    • 额外的收入是否能够抵消为了达到这一可靠水平所付出的成本？

• 设立“错误预算”

  • 错误预算提供了一个明确的、客观的指标来决定服务在一个时间窗口内能接受多少不可靠性

  • 这能够排除SRE与产品研发部门谈判时的政治因素

  • 做法：错误预算=SLO-服务实际在线时间

    • 由产品管理层设定一个SLO，从而确定该服务在指定时间窗口内的预计正常运行时间

    • 由监控系统来判定服务的实际在线时间

http://www.magedu.com

接受风险，拥抱风险（3）

• 产品研发小组和SRE小组的对立

  • 产品研发的绩效很大程度上是通过产品研发速度确立，这会激励员工尽可能快地创建新代码

  • SRE的绩效表现取决于该服务的可靠性，这意味着SRE会对高频率的更新提出抗议

  • 而两个团队间又存在着信息不对称：产品开发更了解编码和发布相关的事项，而SRE更了解服务的可靠性程度

• 需要建立的共识，以帮助确立错误预算

  • 软件对故障的容忍度

    • 投入资源较少，故障率太高，程序过于脆弱；

    • 投入资源太多，运行非常稳定，也未必意味着产品用户会很多

  • 测试

    • 测试不充分，故障可能会频发，甚至出现严重问题，如泄露隐私数据

    • 过于强调测试，可能会失去市场先机

  • 发布频率

    • 每一次的发布都是有风险的；团队应该在减少风险上投入多少时间？

  • 金丝雀测试的持续时间和大小

    • 测试范围多大？

    • 要等多久？

http://www.magedu.com

服务稳定性治理

 SLI/SLO/SLA的制订与落地

 故障预防

 抑制不可控因素

• 故障应急演练

 业务MTTR

 灾备建设

http://www.magedu.com

服务质量术语

• SLI

  • 全称为Service Level Indicator，即服务质量指标

  • 用于评估服务的某项服务质量的一个可量化的角度

    • 性能指标：延迟、吞吐量、处理速率（TPS/QPS）和时效性（Freshness）

    • 可用性指标：可靠性、故障时间/频率、在线时间等

    • 质量指标：准确性、正确性、完整性、覆盖率

  • 大部分服务都将请求延迟 ——处理请求所需要消耗的时长——作为一个关键的SLI

  • 其它常用的SLI包括错误率 （请求处理失败的百分比）、 系统吞吐量 （每秒的请求数量）等

  • 服务可用性 （Availability）是另一个关键的SLI，它代表服务可用时间的百分比

    • 100%的可用性无法实现，但接近100%的可用性指标却是一个可以实现的目标

    • 运行行业通常用9的数量来描述系统的可用程度

http://www.magedu.com

服务质量术语（2）

• SLO

  • 全称为Service Level Objectives，即服务质量目标

  • 用于定义某个SLI的目标值，或者目标范围

    • SLI ≤目标值，例如请求平均延迟低于100ms

    • 范围下限≤ SLI ≤范围上限

  • 选择一个合理的SLO是非常复杂的过程

    • 确立合理的目标值本身很困难，例如QPS由用户请求决定，也就无法为其订立目标值

    • 此时，只能从侧面去为延迟指标订立一个目标值来间接反应QPS

  • SLO又是基于数据驱动做出事关可靠性决策的关键要素，因此，它是SRE工程实践的核心

  • SLO应该以客户为中心，与客户的体验直接相关

    • SLO的核心目的是用于量化客户对产品和服务可靠性的体验

  • 一个好的SLO，应该是SMART的，应该是具体 、 有时限且可衡量的

    • Specific：特有，能明确表达其具体含义

    • Measurable：可测量，有具体数值

    • Achievable：可达成，不能是无法完成的目标

    • Relevant：要反应到用户体验相关

    • Timebound：要尽量只覆盖系统负载较重的时间段，以免被平均值稀释

http://www.magedu.com

服务质量术语（3）

• SLA

  • 全称为Service Level Agreement，即服务质量协议

  • 指的是与用户签订的事关服务质量目标的合约，它描述了达成或未达成SLO的后果

    • 一般会具有一定的法律效力，往往涉及到服务付费、质量承诺和违约责任等

    • SLO往往由业务团队自己设立，而SLA则通常是非技术领域的律师或销售人员所设立

    • 但SLA最好能与业务团队的SLO相一致

  • 有些服务可能并未存一个SLA，但确保其较高服务质量却可能事关其形象，进而影响其业务收入 ◆ 例如公共搜索引擎

http://www.magedu.com

• SRE不应该将监控系统中的所有指标都定义为SLI，只有理解用户对系统的真实需求才能真正决定哪

• 些指标是否有用

• 指标过多会影响对那些真正重要指标的关注，而选择指标过少则会导致某些重要行为被忽略

• 常见的服务，根据它们的相关SLI通常会归类为以下几个大类

◼ 用户可见的服务系统：可用性、延迟，以及吞吐量

• 可用性：是否能够正常处理请求

• 延迟：每个请求花费的时长

• 吞吐量：有多少请求可以被处理

• 存储系统通常强调：延迟、可用性和数据持久性

• 大数据系统：吞吐量和端到端的延迟

• 所有系统：正确性

  • 是否返回了正确的回复，是否读取了正确的数据，或者是否进行了正确的数据操作

  • 正确性是系统健康程度的一个重要指标，但它取决于系统内部数据，而非系统本身，因此通常不是SRE负责的

http://www.magedu.com

故障自愈

 基于“主备”的冗余设计

◼ 存在切换不成功、切换后状态不一致等通病

◼ 要主节点故障导致主备切换后，一般需要尽早跟进问题并修复节点

 基于“负载均衡”的设计

 基于平台的设计

◼ 云平台，包括k8s系统上的自动恢复和扩缩容功能本身就是故障自愈的实现  基于业务架构的设计

◼ 许多分布式自身就能支持自愈机制，且大部分都涉及到了CAP原则

◼ 例如Zookeeper、Etcd等

http://www.magedu.com

灾备建设

• 同机房灾备

  • 通常在同一机房跨机架基于两个以上的服务做主备集群

  • 运维工程师需要了解服务器的真实物理连接和部署拓扑

  • 容灾能力：同一机房内涉及到的单机或单机柜

• 同城双活

  • 将业务部署至同一城市的两个机房中

  • 距离要足够远（不会被同一故障影响），又不太远（方便管理及建立起高速专用线路），50公里以内能确保网络延迟低于3ms

  • 两个机房间的通信链路需要高可用和高容量，需要双线，且应该基于不同的ISP链路

• 异地数据灾备

• 数据成为业务的关键资源时，进行异地灾备，能给影响到全市范围的灾害事件后储备恢复业务的基础

• 两地三中心

  • 两个城市，三个数据中心的灾备方式，可以在城市级的灾害中，快速恢复上线业务，甚至是确保线上业务不离线

  • ◼ 需要从数据底层开始设计，通常的设计是数据库多写，然后互相进行数据同步

  • 需要对业务模块有清晰的认识，尽量降低应用请求的跨机房操作

  • 需要定制专门的数据同步工具，要支持数据路由和多路复制等功能

• 分布式多活

  • 理论上出现故障，系统均能通过切换流量和数据的方式，确保业务继续运行

  • 系统自带数据同步和数据一致性逻辑，通常会基于Raft、Paxos等协议实现，支持全自动的灾备切换

http://www.magedu.com

故障排查

• 故障排查是系统运维工作中的一项关键技能

• 新手们常常不能有效地进行故障排查，是因为这个过程，在理想情况下同时需要两个条件

  • 对通用的故障排查过程的理解（不依靠任何特定的系统）

  • 对发生故障的系统足够了解

    • 理解系统内部运行的原理

    • 理解系统的设计方式和构建原理

• 虽然只依靠通用性的流程和手段也可以处理系统中的一些问题，但这样通常很低效

http://www.magedu.com

故障排查（2）

• 故障排查过程的定义

  • 反复采用“假设—排除”手段的过程

  • 针对某系统的一些观察结果和对该系统运行机制的理论认知，基于收到的问题报告， 不断地提出造成该问题的假设，进而针对这些假设进行测试和排除

• 通过观察系统的监测指标、日志信息和请

• 求跟踪信息了解系统目前的状态，再结合掌握的系统构建原理、运行机制，以及失败模型等提出一些可能导致失败的原因

故障报告定位检查诊断治愈测试/修复要考虑重新定位如果事情有变，需

http://www.magedu.com

故障定级

• 事故等级制度

  • 团队只有知道相关问题的严重程度，才可以按照问题等级投入资源进行优化

• 从SRE团队的角度看，发生一个严重事故时，往往意味着线上业务的稳定性受到了很大冲击

• 这个时候SRE团队会决策接下来的线上运维策略执行收紧原则，开始严格控制变更频率，加强变更评审等方式压制可能继续导致线上稳定性波动的因素

http://www.magedu.com

异常响应流程

• 异常处理环节的设计要求

  • 从SRE的角度来看，异常处理流程应该固化到平台上

http://www.magedu.com

服务器故障排查思路

• 网站服务器崩溃的可能性原因

  • 服务器硬件故障或者系统内核Bug

  • 并发的多线程出现了死锁，或者后端数据库崩溃

  • 存放业务数据变动的磁盘空间耗尽

  • 流量过高，系统超载

    • 服务器硬件配置过低，正常流量增长下的系统超载

    • 正常的短暂性流量突增

    • 遭受攻击，出现异常流量尖峰

  • 触发了应用程序未曾测试出的潜在Bug，例如死循环或内存泄露等导致系统资源耗尽

  • ◼ 系统参数设置不合理，例如fd数量过低，或者是并发连接数上限过低

  • 人为误操作等

http://www.magedu.com

服务器故障排查思路（2）

• 处理流程

  • 优先恢复业务

  • 借助监控、日志和跟踪信息分析问题，排查原因

  • 制订解决方案

  • 完善监控和告警机制

  • 复盘总结，避免重蹈覆辙

  • 完善知识库

• 处理思路

  • 若处于“假死”状态，可以kill并restart业务进程；

  • 分析监控数据，尤其是注意排查宕机前的异常指标数据，比如CPU或内存尖峰等

  • 查看系统日志，获取详细信息

    • 查看/var/log/messages文件，分析宕机前后的系统日志，注意排查错误信息

    • 若启用了kdump，还要分析宕机生成的crash文件

    • 硬件故障相关的日志通常位于/var/log/dmesg

http://www.magedu.com

SRE究竟意味着什么？

 SRE：是一套用确保系统稳定性的体系化实践方法

◼ MTBF：Mean Time Between Failure，平均故障时间间隔，即平均无故障时间 ◼ MTTR：Mean Time To Repair，平均故障修复时长

参考自：https://time.geekbang.org

http://www.magedu.com

关于MTTR

• MTTR的细分指标

  • MTTI：Mean Time To Identify，即平均故障发现时间

    • 从故障发生到SRE团队开始响应之间的时长

    • 该过程可能由用户或客服反馈、舆情监控或者监控告警所触发

  • MTTK：Mean Time to Know，平均故障获知时间

    • 更通俗的说法是，平均故障定位时间

    • 找出故障根因，完成故障定位

  • MTTF：Mean Time To Fix，平均故障修复时间

    • 从定位故障根因开始至业务恢复之间的时长

    • 对应的是解决问题的措施（例如限流、降级、熔断等）及效率

  • MTTV：Mean Time To Verify，平均故障验证时间

    • 故障解决后，借助于用户反馈、监控指标等手段，来确认业务是否真正恢复所消耗的时长

http://www.magedu.com

如何提升系统可用性

• 提升可用性的方式

  • 缩短MTTR指标的时长

  • 拉长MTBF指标的时长

• 措施方向

  • Pre-MTBF阶段

    • 在架构设计层面提升系统可用性，以冗余机制通过故障隔离降低MTTR：主从模式、集群模式、多AZ（Availability Zone）的高可用、单元化、跨地域（Region）容灾、异地多活容灾等

    • 在架构设计层面提升系统韧性：异步、重试、限流、降级、熔断、反压（降低下游效率低进而迫使上游承压）

    • 面向失败设计（Design-for-Failure），实现故障修复自动化

      • ⚫ 常见的失败：导致崩溃的Bug、OMM、系统负载过高导致的夯死、系统级软件的问题，以及混部场景中的作业干扰等 ⚫ 自动化修复是指在故障发性时自动触发事先准备的修复机制

    • 借助于“混沌工程”模拟故障场景，并设计合理的应对举措

  • Post-MTBF阶段

    • 故障复盘，找出不足，落地改进措施

    • 将更好地应对问题的预防机制常态化、例行化，并固化至日常操作流程中

  • MTTR阶段

    • 完善监控系统，提升故障告警的及时性和精准度，必要时可引入AIOps

http://www.magedu.com

如何衡量系统可用性？

• 衡量系统可用性的方式

◼ 时间维度（故障自身的角度）：Availability = Uptime / (Uptime + Downtime)

◼ 请求维度（实际的服务感受角度）：Availability = Successful requests / Total requests

 故障的测量和判定

◼ 衡量指标：即用于进行衡量的角度

◼ 衡量目标：即在特定衡量角度上，用于区隔正常与不正常的临界值或阈值

◼ 持续时长/统计周期：在特定衡量指标上，其值处于不正常区间的时长

• 短暂异常，持续时间较短，通常不被认作故障

• 但频发性的短暂异常，就应该被视为稳定性不佳

• 时间维度的可用性衡量机制无法对此场景进行精确描述

• 请求维度的系统可用性衡量，是从成功请求占比的角度出发，对系统的稳定性进行评估 ◼ 更合理、更严谨

 设定系统稳定性目标时要考虑的要素

• 成本因素：做好ROI评估

• 业务容忍度

• 系统当前的稳定性状况

http://www.magedu.com

SLI和SLO

• 系统稳定性目标：数9衡量

  • SRE强调的稳定性，并非取决于单次请求的成功与否，而是基于大样本来设定一个可接受的目标

  • 这种“确定成功请求的条件，设定目标阈值”的过程，即是在SRE中设定稳定性衡量标准的SLI和SLO的过程

• SLI和SLO

  • SLI：Service Level Indicator，即要监控的指标

  • SLO：Service Level Objective，即各监控指标分别对应的目标

• 系统稳定性建设的关键就在于选定SLI，并分别为之设定合理的SLO

• 常见的指标

  • 系统层面：CPU使用率、Load值、Memory使用率、磁盘使用率、磁盘IO和网络IO等

  • 应用服务器层面：端口存活状态、JVM的GC状况等

  • 应用运行层面：请求返回的状态码、时延、应用层QPS、TPS及连接数等

  • 中间件层面：MySQL、Redis、Kafka和分布式文件存储等各组件的类似于应用运行层面的指标

  • 数据层面：大数量处理平台的批处理或流处理任务，包含呑吐率、及时率和准确率等指标

  • 业务层面：以电商为例，有在线用户数、新注册用户数、下单数、交易数、支付笔数以及业务层面的成功率等指标

http://www.magedu.com

如何选择SLI

• 从众多指标中快速选择SLI的方法：VALET （Volume, Availability, Latency, Error和Ticket）

  • Volume（容量）

    • 服务承诺的最大容量，例如一个应用集群的QPS、TPS、会话数及连接数等等，这些就是容量相关的SLI

    • 对这些指标设定一个日常目标，就是日常的SLO，对大促期间设定一个目标，就是大促的SLO

  • Availability（可用性）

    • 服务是否能够正常响应客户端请求

    • 请求调用的非5xx类响应码的占比，就是衡量可用性的常用指标

  • Latency（延迟）

    • 用于评估是否能够足够快地响应请求，通常用于评估每个请求是否能在规定的时间内完成

    • 该指标与用户访问体验相关

    • 时长通常符合正态分布，因而不应该使用平均值进行衡量，而要使用Histogram或Summary类型的指标

      • ⚫ 同时也应考虑极端情况，例如404的响应时间短到会影响整体分布，或者个别延迟较大的请求会长到影响整体分布

  • Errors（错误率）

    • 常规错误，例如5xx，以及高频度的影响到用户体验的4xx响应

    • 自定义状态码，包括对业务有损的状态码，例如热门商品的高缺货率、例如验证码的高错误率等

  • Tickets（人工介入）

    • 人工介入通常意味着低效

    • 可以为某服务设定一个Tickets总的数量指标

http://www.magedu.com

错误预算

• 如何确保达成SLO？

  • 将容许的犯错空间转换为具体可行的指标（犯错的次数或标准），即错误预算（Error Budget）

  • ◼ 以具有冲击力的方式提示剩余的犯错机会

• 如何应用Error Budget?

  • 稳定性燃尽图

  • 故障定级

    • 可以按错误预算在单次故障中消耗的比例进行定级

◆ 效用：借助于错误预算将故障定级量化

• 稳定性共识机制

  • 剩余错误预算充足或未尽之前，对问题要有充分的容忍度

  • 剩余错误预算消耗过快或即将耗尽之前，SRE有权终止和拒绝任何线上变更

    • ⚫ 避免“带病工作”，并等待下一个预算周期

    • ⚫ 确保运维、运营、产品和开发就此达成一致

• 基于错误预算的告警

  • 制订好告警收敛策略

  • 基于错误预算进行告警

http://www.magedu.com

如何衡量SLO的有效性？

• 根据实际运行结果判定有效性，通常存在三个关键纬度

  • SLO达成情况：可用“达成（Met）”和“未达成（Missed）”标识

  • 人工介入程度（Toil）：泛指大量人工投入、重复、繁琐的低价值事务，可用投入程度高（High）和低（Low） 标识

  • 用户满意度（Customer Satisfaction）：可通过客服投诉、客户访谈或舆情监控等真实渠道获取，可用满意度高（High）和低（Low）来标识

总体处置策略有三种：
1、收紧SLO
2、放宽SLO
3、保持现状

参考自：https://time.geekbang.org

http://www.magedu.com

落地SLO 要考虑的因素

• 确定核心链路

  • 一般来说，分布式在线系统的各服务通常可划分为核心应用和非核心应用两大类

  • 核心应用及其强依赖项组成的调用关系即为核心链路

    • 以电商系统为例，核心应用通常是指电商交易关键路径上的应用，例如首页、详情页、购物车、价格、优惠券、SKU 和支付等

    • 找出核心应用之后，还要确认这些应用的依赖项，核心应用彼此间的依赖构成“强依赖”，对核心应用的依赖即为弱依赖

参考自：https://time.geekbang.org

http://www.magedu.com

落地SLO 要考虑的因素（2）

 设定SLO的原则

• 核心应用的SLO要严格，而非核心应用的可以放宽

• 强依赖之间的核心应用，SLO要一致

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

• 错误预算策略中，任意核心应用的错误预算影响范围都是整个核心链路

  • 若某核心应用错误预算耗尽，原则上，整个链路都要暂停变更操作，直至问题完全解决

• 验证核心链路的SLO的常用方法

  • 全链路压测

    • 判定容量目标能否达成，主要评估QPS和TPS，并确认扩容水位

    • 判定在极端容量场景下，预设的限流、降级、熔断策略是否能正常触发

  • 混沌工程

    • 主动模拟故障场景，测试线上应急机制，提前发现隐患

      • ⚫ 模拟机房断电，测试双活机房或备用机制的流量切换

      • ⚫ 模拟网络丢包或流量满载、磁盘写满、CPU满载、服务器重启、接口延迟、返回异常、线程池满载等

    • 会对线上业务造成影响

      • ⚫ 必须事先在隔离环境中反复演练

      • ⚫ 在模拟的故障超出预估时要能快速进行隔离，快速恢复业务

    • 是SRE稳定性体系建设的高级阶段，要在服务治理、全链路压测、链路跟踪、监控告警和运维自动化建设完善后考虑

http://www.magedu.com

全链路压测

http://www.magedu.com

Thank You!

确保用于研发工作的工作时间比例： 50%

经常度量团队成员的时间分配，确保目标达成确保长期关注研发工作将查找生产环境 Bug 的工单转给研发团队研发时间比例因 “ 人肉 ” 运维工作繁重而无法达成将研发团队成员加入 on-call 轮值时的解决方案督促研发团队设计、构建不需要人工干预，可自主运行的系统在保障服务 SLO 的前提下最大化迭代速度充分利用监控系统监控服务质量
A=MTBF/(MTBF+MTTR ）
基于主备的系统设计基于负载均衡的系统设计故障自愈基于带自愈能力平台（例如 Kubernetes ）的系统设计基于分布式业务架构的设计提升 MTBF
同机房灾备同城双活应急事件处理
SRE 方法论灾备建设异地数据灾备提升系统可靠性的途径两地三中心分布式多活尽可能减少人工操作降低 MTTR
创建有自愈能力的系统持续维护和改进的 “ 运维宝典 ”
不得已的人工操作故障梳理故障演练故障预案混沌工程变更管理需求预测和容量规划资源部署效率与性能

复杂信息系统的运行和维护需要由专业人员（运维）完成运维团队的核心职责在于减少故障的发生对立的岗位职能研发团队的核心职责在于快速构建和发布功能部署新版本的业务应用变更是导致绝大部分生产故障的 “ 罪魁祸首 ” 传统时代修改系统的配置 “ 政治斗争 ” 必然发展为保障各自利益的手段运维制订严苛的发布规范，减少发布、降低故障概率运维团队与开发团队对 “ 风险 ” 的定义不一致研发创造出功能开关调整、增量更新和补丁化机制避开 “ 发布 ” 流程为何需要 SRE 通过雇佣软件工程师，创造软件系统来维护系统运行以代替传统模型中的人工操作对重复性的手工劳动具有天然的排斥感 SRE 团队成员的特点 SRE 的解决之道有足够的技术能力快速开发出软件系统以替代手工操作采用工程化的方式来应对运维问题 Google SRE 要求团队成员必须将 50% 的工作时间用于工成功的关键具开发通过持续、工程化的解决方案，规避随系统规模增长而导致的运维团队的线性增长

若软件工程师职业主要专注于设计和构建软件系统，那么应该有另外一种职业专注于整个软件系统生命周期管理。从其设计一直到部署，历经不断改进，最后顺利退役。

服务质量目标（ SLO ）

Google 的自动化系统的演进

作为生产系统的监管者， on-call 工程师负责处理生产环境中即将或者正在发生的业务事故，以及评审对生产系统的变更请求

on-call 轮值

故障排查过程是一个可以习得的技能，也是一个可以传授的技能

有效的故障排查

过于关注技术问题：遇到事故时，直接开始并陷入技术操作，将导致完全没有时间和精力去思考如何能够通过其他手段缓解当前服务的问题

事后复盘：从失败中学习

事后总结为单个故障提供了详细的信息，但是它们只是整个解决方案中的一部分，只有影响非常大的故障才会进行事后总结，所以小型但是频繁发生的故障经常不会被包含在内

跟踪故障