3.SRE.操作手册：基础篇

SRE的根基起码应该包括：SLO、监控、告警、减少琐事和简单化。

SLO（服务质量目标）：用于描述服务可靠性的程度。

SRE的职责并不只是将“所有工作”都自动化，并保持“on-call”状态。

一.入门

系统成熟度级别划分：

1.一个处于开发中的绿地应用，目前还没做过任何生产部署。

2.一个生产系统，在出现问题时，你的监控可以给你发送一些告警。但是，你还没有正式的服务目标，没有错误预算的概念，不过你有的是：一个没有明确的目标，即正常运行时间为100%。

3.一个处于运行中的生产系统，你有一个小于100%的SLO目标。但是，相关团队并没有对他的重要性达成共识，也不知道该怎样利用它来持续改进，换言之，一个没有牙齿的SLO。

为了能够应用基于错误预算的可靠性工程方法，需要达到以下境界：

1.建立一组SLO，组织里的所有利益干系人都认可它适用于对应的产品

2.取得了负责确保该服务落实SLO目标的人员们的认可，他们认为在正常情况下SLO应该可以达成

3.该组织已经承诺，错误预算将会用于决策和优先级排序。这份承诺正式地（官方的）被记录在错误预算策略文档里

4.该组织具备一个持续优化SLO的流程

面向SLI的度量：

服务质量指标（SLI）：是你所提供的服务质量的指标。

通常建议：将SLI视为两个数字的比率，良好事件数量/事件总数。例如：

成功的HTTP请求数/总HTTP请求数（成功率）

100ms内完成的gRPC调用数/gRPC调用总数

这种形式的SLI具有一些特别有用的属性。SLI的范围从0%~100%，0%表示无效，100%表示没有任何损失。SLO就是目标的百分比数值，错误预算是用100%-SLO。

首次尝试设定SLI和SLO的时候，也没必要强求一步到位，最重要的目标是能够落地，并且真的开始进行度量了，同时建立起一个有助于你持续改进的反馈循环。

从简单易行的方面下手：

1.挑选一个应用程序，为之定义SLO。如果你的产品包含了许多应用程序，其他的可以随后加入

2.清晰的识别出在各种情况下”用户“是谁。这些人的满意度是你将要优化的方向

3.识别出这些用户常见的与系统交互的方式，即常见任务和关键活动

4.绘制高阶系统架构图，画出那些关键组件、请求流、数据流和重要的依赖关系。将这些组件按下文的类型清单分门别类

组件类型：

1.请求驱动

一个发起互动的用户-发出某些类型的请求，并等待返回结果。

例如：用户通过浏览器与HTTP服务进行互动

2.流水线

一个处理系统-接收输入的信息记录，在完成了处理加工以后，将输出结果存放到其它位置。

例如：一个做优化的系统，定期从关系型数据库中读取数据，并将其写入分布式哈希表；一个视频处理服务，可将视频从一种格式转换为另一种格式

3.存储

一个接收数据（例如：字节、记录、文件、视频）的系统，以后数据可以被检索和取回

SLI从规范到实现：

1.对于第一波SLI，尽量选择那些花费最少工程工作量的东西。对于任何一个SLI都需要具备充足的信息：对于可用性，你需要成功/失败的状态等，通常监控仪表板中可能已经提供了某些信息。

2.为了改进SLO目标，需要有一个信息员，它能够提供用户对服务的满意度，它的范围可以更广：

a.对于故障事件，你可以从公共论坛、支持工单以及客服热线电话等信息源，进行手工统计，得出服务中断次数

b.尝试评估和分析在社交媒体上，用户们的情绪

c.在系统中加入定期的用户满意度调查程序

d.进行面对面的用户访谈调查和采样

3.改进SLO质量，对于手工统计的服务故障次数，如果有支持工单系统的话，也要将其纳入统计范围

4.基于SLO和错误预算的决策，在SLO无法正常达成的时候，应该采取的对策是什么（即错误预算即将耗尽的时候）？在错误预算耗尽时，在错误预算策略文档中应该包含相关措施的描述。策略中通常的描述是：停止特性发布，直到服务重新返回SLO，否则部分/全部技术人员将投入到修复可靠性相关的缺陷上。在极端条件下，在从高层获得批准后，还可以对外宣布团队进入紧急状态，所有的外部请求都会被延期，知道达到退出紧急状态的SLO目标之内了。这些行为包括：改善监控、改善测试、消除潜在的危险性依赖关系，或者通过系统重构消除那些已知的故障类型

最终：

如果服务运行犹如行云流水一般，那就只需要一些微小的监管。此时你就应该将服务移转入较少手动干预支持的等级。你可能只需要持续的对相关事件做出必要的响应，以及进行高阶监管，每天再也不需要对产品给与深入关注了，因此，你就可以专注到其他的更需要SRE支持的系统。