《SRE: Google 运维解密》读书分享

从刀耕火种到规范化

【阶段一】第一家实习公司是一家小型创业公司，公司当时的体量只有几个人，整个开发流程非常粗暴：

a. 在本地开发完成后编译打包 b. 通过 ftp 连接服务器，将打包产物上传到云主机 2. 【阶段二】在字节跳动实习做第一个项目，当时存在的现象： a. 测试环境 = 本地开发环境 b. 可以随时上线，合代码不需要 review c. 页面的线上问题发现途径基本上是：用户 -> 运营 -> 产品 -> 研发/测试

举个例子，之前发生过一次事故，原因是前端的打包产物通过云服务器的一个功能以数据块的方式注入到容器中，当时这个功能不可用了一段时间，导致整个页面 504。但因为缺少监控的原因没有第一时间发现，例如 5xx 报错率的提升，页面 PV 下降等，最终问题的发现途径变成了：运营反馈给产品，产品再同步给研发

【阶段三】建立开发上线流程规范，开始养成服务稳定性意识

本地环境、线下环境、产品预发环境的建设，数据上区分线下线上环境
代码 review，卡上线权限
配置监控与报警
...

SRE 的定义

书名为《SRE: Google 运维解密》，那么 SRE 是什么？

SRE 是 Site Reliability Engineering，直译为网站可靠性工程，书中没有进行明确的定义，以个人的理解，用通俗的说法来讲是一系列的方法论，是 Google 软件工程师在系统运维过程中得出的运维方案。（比如早期监控是通过脚本检测的方式来实现，后来逐渐演化为一个新的模型，这个模型使用时间序列信息，发展了一种丰富的时间序列信息操作语言，这个系统称为 Borgmon 监控系统）

当我在 2003 年加入 Google 的时候，我的任务就是领导一个由 7 名软件工程师组成的“生产环境维护组” ...... 当年 7 人的团队已经成长为公司内部 1000 余人的 SRE 团队，但是 SRE 团队的指导理念和工作方式还是基本保持了我最初的想法

—— 第一章介绍

SRE 团队的职责

优化

可用性改进
延迟优化
性能优化
效率优化

变更管理

业务研发的绩效很大程度上通过业务迭代来体现，比如上线了多少需求，页面增加了多少 UV，而 SRE 团队的绩效则是取决于服务的稳定性，业务迭代通常会影响服务可靠性问题，因为大部分的线上问题都是因为上线新版本导致的，这就导致两个业务研发与 SRE 团队产生冲突：是应该多上线还是少上线？

为了解决这个冲突提出了错误预算的概念。错误预算可以理解为余额，比如整个流程可以是：

1、产品管理层拍定这个月的服务可用性 SLO，比如 99.9%，那么错误预算为 0.1%

2、通过监控系统得出服务实际可用性，比如 99.95%

3、如果实际可用性 > SLO，那么就说明还有错误预算，可以发布新版本

—— P31 使用错误预估的目的

监控

监控报警
紧急事务处理

资源

容量规划与管理

基础概念

如果不详细了解服务各种行为的重要性，并且不去度量这些行为的正确性的话，就无法正确运维这个系统，更不要说可靠得运维了。所以，不管是对外服务，还是内部 API，我们都需要制定一个针对用户的服务质量指标，并且努力去达到这个服务目标。

—— P34 第四章服务质量目标

SLI：Service Level Indicator 服务质量指标，一个具体的量化指标
请求延迟
平均
PCT50
PCT95
PCT99
错误率
QPS
资源（CPU、内存、磁盘
利用率吞吐量
可用性 = 机器正常运行时间 / 总时间 or 成功数 / 总请求数

PCT99：将一组数字从小到大排序，第 99% 位置的值为 PCT99。

PCT99 的意义在于，一个服务有的请求可能很快，有的请求很慢，直接取平均值可能掩盖长尾延迟。在实际开发中，QPS 越高，通常延迟也会越大，比如对于一个服务来说晚上是请求高峰量，其他时间都是低峰，导致取平均得到的值比较低

实际案例：

接口QPS

接口PCT99

SLO：Service Level Objective，服务质量目标，SLI 的目标值
可用性高于 99%
平均延迟低于 100ms

SLO 的制定

SLO 的制定与业务相关

不应该是 100%

a. 从理论上来讲不可能 b. 对于用户来说 99.99 和 100 从体验上感知不到明显区别

Avaliability level Allowed unavailability window
	per year	per quarter	per month	per week	per day	per hour
90%	36.5 days	9 days	3 days	16.8 hours	2.4 hours	6 minutes
95%	18.25 days	4.5 days	1.5 days	8.4 hours	1.2 hours	3 minutes
99%	3.65 days	21.6 hours	7.2 hours	1.68 hours	14.4 minutes	36 seconds
99.5%	1.83 days	10.8 hours	3.6 hours	50.4 minutes	7.20 minutes	18 seconds
99.9%	8.76 hours	2.16 hours	43.2 hours	10.1 minutes	1.44 minutes	3.6 seconds
99.95%	4.38 hours	1.08 hours	21.6 hours	5.04 minutes	43.2 minutes	1.8 seconds
99.99%	52.6 minutes	12.96 minutes	4.32 minutes	60.5 seconds	8.64 minutes	0.36 seconds
99.999%	5.26 minutes	1.30 minutes	25.9 minutes	6.05 seconds	0.87 seconds	0.04 seconds
3. 该值应该是去努力达到的，不会超过太多，制定得太低无意义，制定太高浪费机器资源

SLA：Service Level Agreement，服务质量协议，服务用户之间制定的协议，描述达到或者不达到 SLO 的后果（与业务相关）
- 阿里云 ECS SLA
- AWS SLA

监控

实现

收集、处理、汇总，并且显示关于某个系统的实时量化数据。

以 opentsdb 为例子，具体内容为：时间序列数据（time-series）+ 标签（tags）

举个例子，打点名字为 app.home.page，时间区间为 2020.11.12 00:00:00 ~ 2020.11.12 16:00:00，查询得到的结果为

{
    dps: {
        "1605110400": 1.1,
        "1605110430": 1.9,
        "1605110460": 1.0,
        "1605110490": 1.3,
        "1605110520": 1.4,
        ...
    },
    "tags": {
        "method": "home"
        ...
    }
}
复制代码