ISBN-9787121297267

description: [hakcettyu's note]

weread: https://weread.qq.com/web/reader/72c323007190dfe972c1295 douban: https://book.douban.com/subject/26875239/

版权信息¶

版权信息¶

内容简介¶

赞誉¶

赞誉¶

译者序¶

前言¶

序言¶

第Ⅰ部分 概览¶

第1章 介绍¶

系统管理员模式¶

Google的解决之道：SRE¶

SRE方法论¶

小结¶

第2章 Google 生产环境：SRE视角¶

硬件¶

管理物理服务器的系统管理软件¶

其他系统软件¶

软件基础设施¶

研发环境¶

莎士比亚搜索：一个示范服务¶

第Ⅱ部分 指导思想¶

第3章 拥抱风险¶

管理风险¶

度量服务的风险¶

服务的风险容忍度¶

使用错误预算的目的¶

第4章 服务质量目标¶

服务质量术语¶

指标在实践中的应用¶

目标在实践中的应用¶

协议在实践中的应用¶

第5章 减少琐事¶

琐事的定义¶

为什么琐事越少越好¶

什么算作工程工作¶

琐事繁多是不是一定不好¶

小结¶

第6章 分布式系统的监控¶

术语定义¶

为什么要监控¶

对监控系统设置合理预期¶

现象与原因¶

黑盒监控与白盒监控¶

4个黄金指标¶

关于长尾问题¶

度量指标时采用合适的精度¶

简化，直到不能再简化¶

将上述理念整合起来¶

监控系统的长期维护¶

小结¶

第7章 Google 的自动化系统的演进¶

自动化的价值¶

自动化对Google SRE的价值¶

自动化的应用案例¶

让自己脱离工作：自动化所有的东西¶

舒缓疼痛：将自动化应用到集群上线中¶

我们意识到，从“Python单元测试发现错误配置”到“Python代码修复错误配置”的演进能够使我们更快解决这些问题。

Borg：仓库规模计算机的诞生¶

日志消息解析：SSH进入每一台机器，用正则表达式过滤日志。

可靠性是最基本的功能¶

建议¶

第8章 发布工程¶

发布工程师的角色¶

发布工程哲学¶

持续构建与部署¶

配置管理¶

小结¶

第9章 简单化¶

软件系统本质上是动态的和不稳定的。[25]只有真空中的软件系统才是永远稳定的。如果我们不再修改代码，就不会引入新的Bug。如果底层硬件或类库永远不变，这些组件也就不会引入Bug。

系统的稳定性与灵活性¶

乏味是一种美德¶

我绝对不放弃我的代码¶

源代码控制系统中的更改反转很容易，数百行的注释代码则会造成干扰和混乱（尤其是当源文件继续演进时）；那些由于功能开关没有启用而没有被执行的代码，就像一个定时炸弹一样等待爆炸

极端地说，当你指望一个Web服务7×24可用时，在某种程度上，每一行新代码都是负担。

“负代码行”作为一个指标¶

最小 API¶

“不是在不能添加更多的时候，而是没有什么可以去掉的时候，才能达到完美。”

模块化¶

发布的简单化¶

小结¶

第Ⅲ部分 具体实践¶

第10章 基于时间序列数据进行有效报警¶

Google的监控系统不仅要分析一些简单的系统指标（比如一台在欧洲Web服务器的平均响应时间），还需要分析更高抽象级别的指标（例如整个欧洲地区Web服务器的响应时间分布情况）

说明长尾，或译长尾效应，最初由《连线》的总编辑克里斯·安德森于2004年发表于自家的杂志中，用来描述诸如亚马逊公司、Netflix和Real.com/Rhapsody之类的网站之商业和经济模式。是指那些原来不受到重视的销量小但种类多的产品或服务由于总量巨大，累积起来的总收益超过主流产品的现象。

长尾效应

这个新模型将收集时间序列信息作为监控系统的首要任务，同时发展了一种丰富的时间序列信息操作语言，通过使用该语言将数据转化为图表和报警取代了以前的探针脚本。

Borgmon的起源¶

应用软件的监控埋点¶

Go语言中的expvar标准库[9]和它的JSON输出格式也提供了类似的API。

监控指标的收集¶

时间序列数据的存储¶

Borg规则计算¶

报警¶

监控系统的分片机制¶

黑盒监控¶

配置文件的维护¶

十年之后¶

第11章 on-call轮值¶

介绍¶

on-call工程师的一天¶

on-call工作平衡¶

安全感¶

避免运维压力过大¶

小结¶

第12章 有效的故障排查手段¶

理论¶

实践¶

神奇的负面结果¶

案例分析¶

使故障排查更简单¶

小结¶

第13章 紧急事件响应¶

当系统出现问题时怎么办¶

测试导致的紧急事故¶

变更部署带来的紧急事故¶

流程导致的严重事故¶

所有的问题都有解决方案¶

向过去学习，而不是重复它¶

小结¶

第14章 紧急事故管理¶

无流程管理的紧急事故¶

对这次无流程管理的事故的剖析¶

紧急事故的流程管理要素¶

一次流程管理良好的事故¶

什么时候对外宣布事故¶

小结¶

第15章 事后总结：从失败中学习¶

Google的事后总结哲学¶

协作和知识共享¶

建立事后总结文化¶

小结以及不断优化¶

第16章 跟踪故障¶

Escalator¶

Outalator¶

第17章 测试可靠性¶

软件测试的类型¶

创造一个构建和测试环境¶

大规模测试¶

小结¶

第18章 SRE部门中的软件工程实践¶

为什么软件工程项目对SRE很重要¶

Auxon 案例分析：项目背景和要解决的问题¶

基于意图的容量规划¶

在SRE团队中培养软件工程风气¶

小结¶

第19章 前端服务器的负载均衡¶

有时候硬件并不能解决问题¶

使用DNS进行负载均衡¶

负载均衡：虚拟IP¶

第20章 数据中心内部的负载均衡系统¶

理想情况¶

识别异常任务：流速控制和跛脚鸭任务¶

利用划分子集限制连接池大小¶

负载均衡策略¶

第21章 应对过载¶

QPS陷阱¶

给每个用户设置限制¶

客户端侧的节流机制¶

重要性¶

资源利用率信号¶

处理过载错误¶

从负载均衡策略的角度看，重试请求和新请求是无法区分的。

第一，我们增加了每次请求重试次数限制，限制重试3次。某个请求如果已经失败3次，我们会将该错误回应给调用者。这里的逻辑是指，如果一个请求已经三次选择了过载的任务，再重试也很可能无济于事，这时整个数据中心可能都处于过载状态。 第二，我们实现了一个每客户端的重试限制。每个客户端都跟踪重试与请求的比例。一个请求在这个比例低于10%的时候才会重试。这里的逻辑是，如果仅仅只有一小部分任务处于过载状态，那么重试数量应该是相对较小的。

连接造成的负载¶

强制要求批处理任务使用某些特定的批处理代理后端任务，这些代理仅仅转发请求，同时将回复转发给客户端。于是，请求路线从“批处理客户端→后端”变为“批处理客户端→批处理代理→后端”。在这种情况下，当大型的批处理任务执行时，只有批处理代理任务会受到影响，而保护了真正的后端任务（也随之保护了其他的高优先级客户端）。这里，批处理代理任务实际充当了保险丝的角色。另外一个使用代理方式的优势是，我们可以减少后端连接的数量，同时提高负载均衡的效率（例如，代理任务可以使用更大的子集数量，同时可以更好地进行负载均衡）。

小结¶

一个常见的错误是认为过载后端应该拒绝和停止接受所有请求。然而，这个假设实际上是与可靠的负载均衡目标相违背的。我们实际上希望客户端可以尽可能地继续接受请求，然后在有可用资源时才处理。某个设计良好的后端程序，基于可靠的负载均衡策略的支持，应该仅仅接受它能处理的请求，而优雅地拒绝其他请求。

第22章 处理连锁故障¶

正反馈循环（positive feedback）

连锁故障产生的原因和如何从设计上避免¶

最常见的连锁故障触发原因是服务器过载。

正在处理的（in-flight）

一个糟糕透顶的场景：由于CPU资源减少，请求处理速度变慢，内存使用率上升，导致GC触发次数增多，导致CPU资源的进一步减少。我们将此称之为“GC死亡螺旋”。

缓存命中率下降

文件描述符（file descriptor）不足可能会导致无法建立网络连接，进而导致健康检查失败。

防止软件服务器过载¶

这里为了描述这个场景，简化了一些细节，[75]但是这里很好地展现了重试是如何摧毁一个系统的。

● 一定要使用随机化的、指数型递增的重试周期。

慢启动和冷缓存¶

例如，如果一个前端需要和后端通信，但是猜错了后端任务，后端不会代理请求给正确的后端，而是通过返回错误使得前端在正确的后端任务上重试它的请求。

连锁故障的触发条件¶

连锁故障的测试¶

遇到错误时使用随机化的指数型延迟进行重试。

解决连锁故障的立即步骤¶

小结¶

第23章 管理关键状态：利用分布式共识来提高可靠性¶

该系统是分布式计算中的一个基本元素，几乎是Google所有服务都依赖的一个底层系统。

CAP理论（参见文献[Fox99]和[Bre12]）论述了一个分布式系统不可能同时满足以下三个要求： ● 每个节点上所见数据是一致的。 ● 每个节点都可以访问数据。 ● 可以承受网络分区问题（参见文献[Gil02]）。

系统工程师和软件工程师都很熟悉传统的ACID数据存储语义（原子性、一致性、隔离性和持久性），但是越来越多的分布式数据存储开始提供另外一套不同的语义，称之为BASE—基本可用、软状态、最终一致性（basically available、soft state、eventual consistency）。

常常是简单的“最后操作为准”）来解决冲突。

时钟漂移

Jeff Shute（参见文献[Shu13]）曾经说过，“我们发现开发者通常花费了大量的时间构建一个极为复杂和容易出错的机制来应对最终一致性下可能过时的数据。我们认为对开发者来说这是一种无法接受的负担，数据一致性的问题应该在数据库层解决。”

使用共识系统的动力：分布式系统协调失败¶

谣言协议

分布式共识是如何工作的¶

拜占庭式问题指的是当某个进程由于程序Bug或者恶意行为发送不正确的消息的问题，这种问题相对来说处理成本更高，同时也更少见。

在不稳定的网络条件下，没有任何一种异步式分布式共识算法可以保证一定能够达成共识。

分布式共识的系统架构模式¶

分布式共识算法是很底层、很原始的：它们仅仅可以让一组节点一次共同接受同一个值，这并不能很好地跟我们的设计任务相对应。

真正使得分布式共识系统有用的是那些高级的系统组件，如数据存储、配置存储、队列、锁机制和领头人选举服务。这些基本的有实际意义的服务是分布式共识算法没有提供的。

TIL

复制状态机

时间戳在分布式系统中问题非常大，因为在多个物理机器上保证时间同步是不可能的。

屏障（barrier）在分布式计算中是一种原语，可以用来阻挡一组进程继续工作，直到某种条件被满足（例如，直到某个计算的第一阶段全部完成时，再继续进行）。

原子性广播是分布式系统的一个原语，意思是整个系统的参与者都可以可靠地接收到消息，并且以同样的顺序来处理这些消息。

分布式共识系统的性能问题¶

系统负载（workload）可能会从多个维度大幅变动，理解负载变动的范围与特点是讨论系统性能的关键

往返周期（RTT）

这种强势领头人在很多共识协议中都适用，在系统需要传递大量消息的时候非常合适。

一旦收到多数参与者的回应（包括提议者自己）后，

“提议者决斗”的状况。在这种状况下，两个提议者不停地打断对方，使得没有一个新的提议可以被成功接收

该系统使用一个原子性的“比较”然后“设置”操作进行状态修改（受原子性寄存器的启发）。

分布式共识系统的部署¶

一般来说，共识系统都要采用“大多数”的法定过程。也就是说，一组2f+1副本组成的共识组可以同时承受f个副本失败而继续运行（如果需要容忍拜占庭式失败，也就是要能够承受副本返回错误结果的情况，则需要3f+1个副本来承受f个副本失败（参看文献[Cas99]））。

理论性的论文常常指出共识系统可以用来构建一个分布式日志，但是却不会讨论如何应对某个崩溃后又恢复的副本（这些副本可能缺少某一段共识信息）或者是某个速度慢的副本。

对分布式共识系统的监控¶

小结¶

每当读者见到领头人选举、关键共享状态，或者分布式锁的时候，一定要想起分布式共识：任何其他的方案都是系统中的一枚定时炸弹，随时可能爆炸。

第24章 分布式周期性任务系统¶

Cron¶

Cron任务和幂等性¶

大规模Cron系统¶

Google Cron系统的构建过程¶

领头人进程是唯一一个主动启动Cron任务的进程。

Paxos 基本上是一个只能新增的日志，在每次状态变化后同步地新增

提供一个例子：如果我们的状态变化存储在日志中的时候是“将某个计数器加1”，那么在1000次迭代之后，可以用一个“将计数器设置为1000”来替代1000条记录。

惊群效应（thundering herd）

小结¶

第25章 数据处理流水线¶

流水线设计模式的起源¶

简单流水线设计模式与大数据¶

一个数据流水线中串联的程序数量多少称为该流水线的深度（depth）。

周期性流水线模式的挑战¶

工作分发不均造成的问题¶

分布式环境中周期性数据流水线的缺点¶

Google Workflow简介¶

Workflow中的执行阶段¶

于是，我们可以在任何一个阶段很容易地实现 Mapping、Shuffling、排序、分割以及合并等操作。

保障业务的持续性¶

小结¶

第26章 数据完整性：读写一致¶

我们可以说数据完整性是指数据存储为了提供一个合理的服务质量，在可访问性和准确性方面必须达到的一个度量标准。但是这种定义是不全面的。

数据完整性的强需求¶

很多云应用程序都是在基于ACID[87]和BASE[88]某种组合的API上不停地演变来满足上述5个要求的。

就像一句流行语说的那样：没有人真的想要备份数据，他们只想恢复数据。

备份与存档最重要的区别就是，备份是可以直接被应用程序重新加载的。

保障数据完整性和可用性：Google SRE的目标¶

从用户的角度来看，仅仅保障数据完整性，而没有保障数据的可用性是没有意义的。

Google SRE保障数据完整性的手段¶

分析校验器为何失败也需要很多精力。造成某项间断性不一致情况的原因可能在几分钟、几小时或者几天之内消失。因此，快速定位校验日志中的问题是非常关键的。成熟的Google服务给on-call工程师提供了非常完备的文档和工具，用来定位问题。例如，Gmail提供给on-call工程师的有： ● 一系列Playbook文章讲述如何应对某种校验失败的报警。 ● 类似BigQuery的查询工具。 ● 数据校验监控台。 一个有效的带外数据校验系统需要下列元素： ● 校验任务的管理。

一个有效的带外数据校验系统需要下列元素： ● 校验任务的管理。 ● 监控、报警和监控台页面。 ● 限速功能。 ● 调试排错工具。 ● 生产应急应对手册。 ● 校验器容易使用的数据校验API。

案例分析¶

SRE的基本理念在数据完整性上的应用¶

小结¶

第27章 可靠地进行产品的大规模发布¶

不需要发布到每个使用者的电脑上。

发布协调工程师¶

建立发布流程¶

起草一个发布检查列表¶

例如，我们大部分的开发都是在主线分支上（mainline）进行的，但是发布版本是在每个发布的分支上进行的。这种方式使得在分支上修复每次发布的Bug更简单。

可靠发布所需要的方法论¶

LCE的发展¶

小结¶

第Ⅳ部分 管理¶

第28章 迅速培养SRE加入on-call¶

新的SRE已经招聘到了，接下来怎么办¶

培训初期：重体系，而非混乱¶

培养反向工程能力和随机应变能力¶

有抱负的on-call工程师的5个特点¶

on-call之后：通过培训的仪式感，以及日后的持续教育¶

小结¶

第29章 处理中断性任务¶

管理运维负载¶

如何决策对中断性任务的处理策略¶

不完美的机器¶

流状态（flow state[10]）是一个软件工程行业内被普遍接受、人尽皆知的理念。

第30章 通过嵌入SRE的方式帮助团队从运维过载中恢复¶

第一阶段：了解服务，了解上下文¶

第二阶段：分享背景知识¶

第三阶段：主导改变¶

小结¶

第31章 SRE与其他团队的沟通与协作¶

这就是SRE的承诺：一个专门负责可靠性的组织，拥有与产品开发团队相同的技能，以量化的方式不断改善。

沟通：生产会议¶

SRE的内部协作¶

SRE内部的协作案例分析：Viceroy¶

SRE与其他部门之间的协作¶

案例分析：将DFP迁移到F1¶

小结¶

第32章 SRE参与模式的演进历程¶

SRE 参与模式：是什么、怎么样以及为什么¶

接手（onboarding）

PRR 模型¶

SRE参与模型¶

PRR：简单PRR模型¶

简单PRR模型的演进：早期参与模型¶

不断发展的服务：框架和SRE平台¶

小结¶

第Ⅴ部分 结束语¶

第33章 其他行业的实践经验¶

有其他行业背景的资深SRE¶

灾难预案与演习¶

事后总结的文化¶

将重复性工作自动化，消除运维负载¶

结构化和理性的决策¶

小结¶

第34章 结语¶

同时，SRE也应该对系统的运作原理、运维方式、故障模式以及应急处理方式非常了解—这些都是在日常工作中学到的。

附录A 系统可用性¶

附录B 生产环境运维过程中的最佳实践¶

监控系统监控系统应该仅仅有下列三种输出：紧急警报某个人必须执行某项操作。工单某个人必须在几天之内执行某种操作。日志没有人会马上看这些日志，但是以后需要的时候可以用来分析。

附录C 事故状态文档示范¶

附录D 事后总结示范¶

所有时区都是UTC

附录E 发布协调检查列表¶

附录F 生产环境会议记录示范¶

参考文献¶

索引¶

关于编著者¶

封面介绍¶