第四章 服务质量目标
如果不详细了解服务中各种行为的重要程度，并且不去度量这些行为的正确性的话，就无法正确运维这个系统，更不要说可靠低运维了。那么，不管是对外服务，还是内部API，我们都需要制定一个针对用户的服务质量目标，并且努力去达到这个质量目标。
服务质量指标（SLI）
服务质量目标（SLO）
服务质量协议（SLA）
这三项分别指该服务最重要的一些基础指标、这些指标的预期值，以及当指标不符合预期时的应对计划。
服务质量术语
指标
SLI 是指服务质量指标（indicator）——该服务的某项服务质量的一个具体量化指标。
大部分服务都将请求延迟——处理请求所消耗的时间——作为一个关键的 SLI。其他常见的 SLI 包括错误率（请求处理失败的百分比）、系统吞吐量（每秒请求数量）等。这些度量通常是汇总过的：在某一个度量时间范围内将原始数据收集起来，计算速率、平均值、百分比等汇总数据。
可用性（availability）是另外一个 SRE 重视的 SLI，代表服务可用时间的百分比。该指标通常利用 "格式正确的请求处理成功的比例" 来定义，有时也称为服务产出（yield）。对数据存储系统来说，持久性（durability）——数据能够完成保存的时间——也是一个重要指标。
目标
SLO 是服务质量目标：服务的某个 SLI 的目标值，或者目标范围。（SLI < 目标值 或 范围下限 < SLI < 范围上限）
选择一个合适的 SLO 是非常复杂的过程。
- 无法确定一个具体的值
- 多个 SLO 是息息相关的（比如 QPS 和 延迟）
好处：SLO的选择和公布可以帮助设立用户对服务质量的预期。该策略可以应对那些没有根据的抱怨——"服务太慢了"
协议
：指服务于用户之间的一个明确的，或者不明确的协议，描述了在达到或没有达到SLO之后的后果。这些后果可以是财务方面的——退款或者罚款——也可能是其他类型的。
指标在实践中的应用
运维人员和最终用户各关心什么
一般来说，四五个具有代表性的指标对系统健康程度的评估和关注就足够了。
常见的服务，根据它们的相关 SLI通常会归类为以下几个大类。
- 用户可见的服务系统（是否能正常处理请求？每个请求花费的时间是多少？多少请求可以被处理？）
- 存储系统通常强调：延迟、可用性和数据持久性。（读写需要多少时间？是否可以随时访问数据？数据是否一段时间内还能被读取？）
- 大数据系统，例如数据处理流水线系统，一般来说关系吞吐量和端到端延迟。（处理了多少数据？数据从输入到产出需要多少时间？）
- 所有的系统都应该关注：正确性。是否返回了正确的回复，是否读取了正确的数据，或者进行了正确的数据分析操作。
指标的收集
Borgmon
Prometheus
日志分析系统
指标的标准化
- 汇总间隔：每一分钟汇总一次
- 汇总范围：集群中的全部任务
- 度量频率：每10秒一次
- 包含哪些请求：从黑盒监控任务发来的 HTTP GET请求
- 数据如何获取：通过监控系统获取服务器端信息得到
- 数据访问延迟：从收到请求到最后一个字节被发出
目标在实践中的应用
目标的定义
SLO 应该具体指出它们是如何被度量的
目标的选择
-
不要仅以目前的状态为基础选择目标
-
保持简单
-
避免绝对值
-
SLO越少越好
控制手段
- 监控并且度量系统的SLI
- 比较SLI和SLO，以决定是否需要执行操作
- 如果需要执行操作，则要决定究竟什么操作需要被执行，以便满足目标
- 执行这些操作
第五章 减少琐事
琐事的定义：运维服务中手动性的、重复性的，可以被自动化的，战术性，没有持久价值的工作。而且，琐事与服务呈线性关系的增长。
什么算工程工作
（engineering）是一种新颖的、本质上需要主观判断的工作。它是符合长期战略的，会对你的服务进行长久性的改善的工作。工程工作通常是有创新性和创造性的，着重通过设计来解决问题，解决方案越通用越好。
典型的SRE活动分为以下几类：
- 软件工程
- 系统工程：配置生产系统，修改现存配置，或者用一种通过一次性工作产生持久的改进的方法来书写系统文档
- 流程负担（overhead）：与运维服务不直接相关的行政工作。例如招聘、人力资源书面工作、团队/公司会议、任务系统的定期清理工作、工作总结、同行评价和自我评价，以及培训课程等。
第六章 分布式系统的监控
术语定义
监控
：收集、处理、汇总，并且显示关于某个系统的实时量化数据，例如请求的数量和类型，错误的数量和类型，以及处理用时，应用服务器的存活时间等。
警报
分类：工单、email警报、紧急警报（page）
根源问题（root cause）
指系统（软件或流程）中的某种缺陷。这个缺陷如果被修复，就可以保证这种问题不会再以同样的方式发生。
节点或机器
这两个术语可以互换
为什么要监控
分析长期趋势
：数据库目前的数据量，以及增长速度。
跨时间范围的比较，或者是观察实验组与控制组之间的区别
报警
：需要立刻修复
临时性的回溯分析
有没有其他的现象同时发生
对监控系统设置合理预期
监控系统信噪比应该很高，发出紧急警报的组件需要非常简单而且可靠。产生警报的监控系统规则应该非常容易理解，同时代表一个清晰的故障场景。
4个黄金指标
延迟，流量，错误和饱和度（saturation）
饱和度：服务容量有多 '满'
设计监控系统
- 那些最能反映真实故障的规则应该越简单越好，可预测性强，非常可靠
- 那些不常用的数据收集、汇总，以及警报配置应该定时删除
- 收集到的信息，但是没有暴露给任何监控台，或者被任何警报规则使用的应该定时删除
在为监控系统和警报系统增加新规则时，回答下列问题可以帮助减少误报：
- 该规则是否能够检测到一个目前检测不到的、紧急的、有操作性的，并且即将发生或者已经发生的用户可见故障?
- 是否可以忽略这条警报？什么情况可能会导致用户忽略这条警报，如何避免？
- 这条警报是否确实显示了用户正在受到影响？是否存在用户没有受到影响也可以触发这条规则的情况？例如测试环境和系统维护状态下发出的警报是否应该被过滤掉。
- 收到警报后，是否要进行某个操作？是否需要立即执行该操作，还是可以等到第二天早上再进行？该操作是否可以被安全地自动化？该操作的效果是长期的，还是短期的？
- 是否也会有其他人收到相关的紧急警报，这些紧急警报是否是不必要的?
以上这些问题其实反映了在应对紧急警报上的一些深层次的理念：
- 每当收到紧急警报时，应该立即需要我进行某种操作。每天只能进入紧急状态几次，太多就会导致“狼来了”效应。
- 每个紧急警报都应该是可以具体操作的。
- 每个紧急警报的回复都应该需要某种智力分析过程。如果某个紧急警报只是需要一个固定的机械动作，那么它就不应该成为紧急警报。
- 每个紧急警报都应该是关于某个新问题的，不应该彼此重叠
监控系统的长期维护
在现代生产环境中，监控系统需要跟随不断演变的软件一起变化，软件经常重构，负载特性和性能目标也经常变化。
小结
健康的监控和警报系统应该是非常简单、易于理解的。紧急警报应该关注于现象，针对原因的一些启发性分析应该作为调试过程的补充，而不应该进行报警。监控的技术栈层面越高，监控现象越容易，但是监控某些子系统(如数据库) 的饱和度和性能参数可能要在该子系统内部直接进行。E-mail 警报的价值通常极为有限，很容易变成噪声。我们应该倾向于构建一个良好的监控台页面，直接显示所有的非紧急的异常情况。
第七章 谷歌的自动化系统的演进
自动化的价值
一致性，平台性，修复速度更快，行动速度更快，节省时间
自动化的演进
- 没有自动化
- 手动将数据库主进程在多个位置之间转移
- 外部维护的系统特定的自动化系统
- SRE 在主目录中保存一份故障转移脚本
- 外部维护的通用的自动化系统
- SRE 将数据库支持添加到每个人都在使用的 "通用故障转移" 脚本中
- 内部维护的系统特定的自动化
- 数据库自己发布故障转移脚本
- 不需要任何自动化的系统
- 数据库注意到问题发生，在无须人工干预的情况下进行故障转移
第八章 发布工程
发布工程（release engineering）是软件工程内部一个较新、发展较快的学科。简单来说，这个学科专注于构建和交付软件。发布工程师通常对源代码管理、编译器、构建配置语言、自动化构建工具、包管理器和安装器等非常了解。他们的技能横跨多个领域：开发、配置管理、测试集成、系统管理，甚至用户支持。
发布工程哲学
自服务模型
发布研发团队可以自己掌控和执行自己的发布流程
追求速度
密闭性
构建工具必须确保一致性和可重复性
谷歌按照之前的源代码版本，加入一些后来提交的改动来构建新的发布来解决这个问题，这种方式被称为摘樱桃（cherry picking）。构建工具自身也是放置在与被构建的程序同一个源代码仓库之中的。
强调策略和流程
- 批准源代码改动一一通过源代码仓库中的配置文件决定
- 指定发布流程中需要执行的具体动作
- 创建新的发布版本
- 批准初始的集成请求(也就是一个以某个源代码仓库版本为基础的构建请求)，以及后续的 cherry picking 请求
- 实际部署某个发布版本
- 修改某个项目的构建配置文件
第九章 简单化
软件系统本质上是动态的和不稳定的。我们的工作最终是在系统的灵活性和稳定性上维持平衡。
因为工程师也是人，他们经常对于自己编写的代码形成一种情感依附。（如果以后需要这个代码怎么办？先注释掉，以后用的使用再取消注释掉？为什么不增加一个功能开关？）。这些都是糟糕的建议。数百行的注释代码会造成干扰和混乱。