第一部分
第一章
SRE(site reliability engineering): 设计和研发大型、分不出计算机系统。有时和研发团队工作，其他时候开发基础组件，推广这些基础组件在多个项目中复用。
SRE关注的焦点在可靠性（reliability）,可靠性指的是在指定环境下成功执行某个功能指定时间的概率。
SRE花50%时间在真实的开发工作上。这样既保障了SRE有足够的运维经验，也有足够的时间和精力去进行真正有创造性的、自主的研发工作。
SRE职责通常有：可用性改进，延迟优化，性能优化，效率优化，变更管理，监控，容量规划和管理
-
监控系统： 警报信息应该由系统自动分析，并只有三类输出
- 紧急警报alert: 收到警报的人员需要立即执行某种操作
- 工单ticket: 收到ticker的人员可以在几天内执行某种操作
- 日志logging: 日志用于调试和事后分析
-
变更管理：可以自动化的完成以下几个项目
- 渐进式发布机制
- 迅速而准确地检测到问题的发生
- 出现问题时，安全迅速的回滚
第三章 拥抱风险
服务可用性=成功请求数/总请求数
由于产品研发和SRE基于不同的指标进行绩效评估，所以组员共同定义一个基于SLO的季度错误预算，通常做法如下：
- 产品管理层顶一个一个SLO, 确定一项服务在每个季度预计的正常运行时间
- 实际在线时间由一个中立的第三方-监控系统来预算
- 两者的差值就是这个季度剩余的错误预算
- 只有仍有剩余的错误预算就可以发布新版本
使用错误预算的好处
- 可以通过这个调节发布新版本的速度， 产品开发指导预算还剩多少，可以控制自己的风险
- SRE可以有权停止新版本的发布
第四章 服务质量目标
SLI(service level indicator):服务质量指标， 如响应时间，准确性
SLO(service levelo objective):服务质量目标，即SLI的预期值，如响应时间10ms
SLA(service level agreement):服务质量协议,包含SLI/SLO等一系列明确或不明确的协议， 描述了达到或没有达到SLO之后的明确后果
SLI
基于服务性质的不同，会选择不同的指标，通常四五个具有代表性的指标就可以对系统监控程度做出评估和关注
标准化一些常见的SLI
- 汇总间隔： 每分钟一次
- 范围： 集群中全部任务
- 度量频率： 每10s一次
- 获取：黑盒监控任务通过HTTP GET请求获取
SLO
SLO应该具体指出如何被度量以及有效条件
SLO可以在系统运维时提供决策
SLO 也可以建立用户预期，避免用户对服务过度依赖（google chubby服务会在有错误预算的时候有一安排一次可控的故障，找出对其不合理依赖的上游服务）
第五章 减少琐事
何为琐事
- 手动性的，重复性的，可以被自动化的
- 突然出现的、应对性的工作，而非主动安排的
- 没有持久价值的
- 与服务规模线性增长的
何为工程工作
- 创新的、需要主管判断的
- 着重通过设计来解决问题
- 符合长期战略的
第六章 分布式系统的监控
为何监控
- 报警
- 不同条件的比较（不同时间范围比较）
- 分析长期趋势
4个监控黄金指标
- 延迟:服务处理某个请求所需要的时间，区分成功请求和失败请求
- 流量:对于web服务来说同时是每秒HTTP请求数量，对于流媒体系统来说科目是I/O速率
- 错误:请求失败的速率
- 饱和度(saturation):服务容量有多满。如内存、I/O
第二部分
SRE的终极责任是确保服务可以正常运转
第10章 基于时间序列数据进行有效报警
监控系统既要从服务质量目标层面进行报警，也应该保持足够的粒度，可以追踪到具体某个组件
应用软件保留HTTP接口提供全部监控变量值，Borgmon安装配置定时抓取，将数据保存在内存中，并定时落盘。
这些数据都是类似(timestamp, value)格式存储在一个按时间排序的链表中，该链表称为time series
当Borgmon计算完成一条报警规则结果为true时会产生一条警报
每条报警规则都指定了一个最小持续时间值，只有当警报持续时间超过这个值得时间才会发送警报，这个周期至少被设置为两个计算周期。
Borgmon会将报警信息发送到报警管理服务Altermanager，其负责将警报发送到合适的渠道，另外也管理
- 报警信息的去重
- 根据保荐信息将多个警报信息合并
探针程序是一个检查检查测试模型和一些高级time-series创建功能的混合体，既可以探测到前端，也可以探测到负载均衡后面的服务
第11章 on-call轮值
on-call工程师可以承诺分钟级别执行生产系统的维护需求
SRE不会超过25%的时间用来on-call，另外50%花在软件工程上，其余25%用来处理其余运维工作
第12章 有效的故障排查手段
故障排查依赖于两个要素
- 对于通用故障排查过程的理解
- 对于发生故障的系统的足够了解
对于排查的过程我们定义为反复采用假设-排除的过程
优化排查过程
- 服务增加可观察项，如增加白盒测试指标，利用结构化的日志
- 利用成熟的观察性好的组件来设计系统
第14章 紧急事件管理
明确职责可以让每个人更加独立自主解决问题
通常分为4种角色
- incident command事故总控: 负责组建事务处理团队，按优先级分配任务
- operation work 事务处理团队：唯一能对事故系统做修改的团队
- communication 发言人： 公众发言人，负责向其他人发送周期性通知，及时更新处理状态
- planning 规划负责人：为事务处理团队提供支持，如填写Bug报告记录系统，安排职责交接记录
对外宣布事故的标准，满足如下一条应该实及时宣布
- 是否需要引入第二个团队
- 是否影响到最终用户
- 分析一小时后仍未得到解决
第15章 事后总结：从失败中学习
事后总结
- 是一个全公司的学习机会
- 对事不对人
- 假设参与事件的人在当时拥有的信息下做了正确的举动
事后总结是一个团队协作的过程，大家都可以来完善。
事后总结包括正式的评审和发布过程，评审条件包括
- 关键的灾难数据是否被收集和保存
- 影响评估是否完整
- 根源问题调查是否深入
- 是否及时解决了根源问题，排期优先级是否合理
- 事故处理过程是否共享给了所有相关部门
建立事后总结文化
- 每周一次的本周最佳事后总结
- 组织事后阅读俱乐部，共同讨论一篇有趣或有影响力的事后总结
- 再现事故现场，故障处理分角色扮演
事后总结纳入个人绩效考核以及管理层积极参与和认可，可加强事后总结机制
第23章 利用分布式共识来提高可靠性
CAP理论
- Consistency: 每次读取要么获得最新的数据，要么获得错误
- Availability: 每次都能获得一个非错误响应，但不保证返回的最新的数据
- Partition tolerance: 尽管任意数量的消息被节点间的网络丢失或延迟，系统任继续运行
CA：不能容忍网络错误或节点错误，需要非常严格的全体一致的协议，如2 phase commit
CP：只需要保证大多数节点的一致性协议，少数落后的节点会变成不可用状态, 如Paxos算法
AP：这样的系统不能达成一致性，会出现数据冲突
常见的分布式共识问题
- 领头人选举
- 获取小组成员信息
- 分布式锁和租约机制
- 分布式队列
- 以及任何需要在多个进程共同维护一致的关键状态的机制
Paxos概要
Paxos基于提案(proposal)的,每个提案都对应一个序号，保证了系统的所有操作严格有序， 如果提案被大多数节点接受即成功，反之失败
- 第一阶段： 提案者proposer发送一个序列化给数个接受者acceptor,每个acceptor尽在 没有接受过带有更高序列号的提案的情况下接受这个提案
- 第二阶段: proposer接收到大多数节点的同意回复时，便发送一个带有值得提交信息commit message来尝试提交这个提案
复制状态机replicated state machine(RSM)
RSM是一个能在多个进程用同样顺序执行同样一组操作的系统
- 操作按共识算法来全局排序
- 使用关东窗口协议sliding window protocol来同步成员之间的状态消息
分布式共识系统的部署
副本的数量： 一组2f+1副本可同时承受f个副本失败而继续运行
因为慢的副本也需要参与冲裁过程所以系统能够承受的失败和落后的副本数量越多，那么整体的系统 性能也就越好
副本之间的距离增加，网络往返时间也会增加，系统承受失败的程度也会增加(网络同时出问题的概率会变小)
向一个采取大多数法定仲裁 追过程系统增加新副本可能会降低系统的可用性
第24章 分布式周期任务系统
为了提升Cron的可靠性，我们将实际进程和物理机器分开，运行一个服务，仅通过知名该服务的资源要求以及英国运行的数据中心即可。 运行一个任务等于想数据中心分发器发送一个RPC
采用Paxos共识算法保证多个副本的状态一致，使用一个单独的领头人副本，仅该副本可以修改共享状态和启动Cron任务
任务启动前和启动后均会同步通知到其他的副本，这样每个副本知道任务的启动状态
任务的启动过程中可能会发生多次RPC调用，为了能够判断RPC是否成功，需要满足其一：
- 所有需要在选举过后继续的外部操作必须是幂等的，这样可在选举过后重新进行该操作
- 可以通过查询外部系统确定某项操作是否进行成功
第28章 迅速培养SRE加入on-call
培训初期：着重于体系
先培训经常会用到的、系统的抽象概念，可以考虑将系统按功能进行分组
提供一个学习检查列表：列出最有用的文档以及一些服务的基本知识，并提供一些简单的问题以便自检
分配一个初始项目，给他们提供足够多的基础知识，同时让他们能为服务做一点小的但有意义的贡献
培养方向功能的能力和随机应变能力
通过对系统工作原理的基本理解、同时愿意深入研究调试工具、RPC框架，来理解系统中数据流动
第29章 处理中断性任务
决策：如何能用最低人力成本来满足最低响应时间
让SRE尽可能的待在流状态(flow state)里, 这种状态可以提升生产力、创造力