《SRE: Google 运维解密》（1-6章）—— 读书笔记
这几天到杭州出差，带了这本运维领域的经典有空的时候刷一下。虽然书本概念偏多，但是可以看出是来源于实际工作中的例子，比起单讲理论或者工具的书来说，对运维领域的工程师有颇大的指导意义。—— 至少这本书展示了运维领域一些有挑战性的工作，让运维工作变得更加有趣一点。
PS. 这本书的电子英文版在可以免费在线阅读，不过要自备梯子：
https://landing.google.com/sre
第一章 介绍
运维操作占时间限制在50%以内
- 必要时让研发团队承担运维压力，同时也会促进团队构建出更加自动化的系统。
- 研发和 SRE 共同承担可用性的责任，（彼此就有必要了解彼此的工作了）。
追求 100% 的可用性是有害的
- 服务的 SLO 可用性在 99.999%和100%之间的差别，只是整个综合系统的噪声，对用户没有实质好处。
- 追求过高的可用性带来的成本上的增加，和时间成本上的损失，会降低业务的迭代速度。
第二章 Google 生产环境
- Google 的软件服务器和物理服务器两个概念有较大不同。我理解是尽可能地虚拟化、容器化的结果。
- 一个典型的服务的架构，基本上每个环节（前端、DNS 服务器、负载均衡、服务后端、数据库、磁盘）都需要高可用。
第三章 拥抱风险
这一章主要讨论了 SLO（服务可用性目标）应该怎么定义和怎么决定数值。
- 怎么定义
可以是按时间，也可以是按成功请求数（Google 的服务大多按请求数定义，因为基本没有 downtime）
- 怎么决定数值
用户期望、对收入的影响等等。还有一个是收益是否能高于成本的投入。
错误预算
我认为这章最重要的一个概念是“错误预算”，就是一个周期内可以允许的故障时间预期。用来平衡研发新功能和提高稳定性的工作量之间取得平衡。在还有较多错误预算的前提下，可以承担更多的风险去发布新功能；而预算接近耗尽时，则应该推动更多的测试和放慢发布的速度。
第四章
解释了 SLI、SLO 和 SLA 之间的差别。
SLI：indicator，服务的某项具体量化指标
SLO：object，服务的某个 SLI 的目标值
SLA：agreement，服务与用户之间的协议，描述没有达到 SLO 之后的后果。
关于指标，不同的指标有不同的标准，有些对波动比较敏感的指标，比如 CPU或延时，适合每10秒收集一次，用柱状图的方式来呈现分布。有些指标比如内存使用量等，则可以按分钟取平均值。
第五章 减少琐事
Google 将琐事定义为重复性的、手工的劳动，特征是被动式的、没有持久价值、与服务同步线性增长的工作。
总的来说，通过时间工单统计，或者 on-call 时间等计算，处理琐事的时间不应该超过50%，用这些时间投入到软件工程和系统工程上，用于消除琐事。
第六章 分布式系统的监控
尽量的简化，让报警尽量接近故障的根源（通过大量白盒监控）。
对于报警规则，可以通过审视一系列的问题来减少误报：
- 是否可以忽略的报警？
- 是否要立即进行某个操作？该操作能否被安全地自动化？——当收到报警时，我应该立即进行某项操作。这项操作应该需要一定的分析过程，如果每次都是机械动作，那应该自动化掉，而不是应该成为紧急报警。
待续……
