最近看了《SRE Google 运维解密》这本书，收获了不少知识。也摘录一些知识点放在这里。

服务质量术语 (p38)

• SLI 服务质量指标，该服务的某项服务质量的一个具体量化指标，如失败率、吞吐量。
• SLO 服务质量目标，某个SLI的目标值，或者目标范围。SLO的定义是SLI ≤ 目标值，或者 范围下限 ≤ SLI ≤ 范围上限。
• SLA 服务质量协议，服务于用户之间的一个明确的或者不明确的协议，描述了达到或者没有达到SLO之后的后果。

统计谬误 (p43)

查看某一SLI，倾向于分析其百分比分布，而非其算数平均值。长尾效应比算数平均更有特点。

4个黄金指标 (p60)

• 延迟 服务处理某个请求所需的时间。同时需要区分请求是否成功，因为有些时候失败的请求耗时会更低，比如HTTP 404。
• 流量 使用系统中某个高层次的指标针对系统负载需求所进行的度量。对于Web服务来说，该指标通常是每秒HTTP请求数。
• 错误 请求失败的速率。
• 饱和度 服务容量有多“满”。通常是系统中目前最为受限的某种资源的某个SLI。

什么时候宣布故障 (p166)

当满足下面任一条件时，故障应该被及时宣布

• 需要引入第二个团队来帮助处理问题。
• 这次故障最终会影响用户。
• 在集中分析一小时后，仍未得到解决。

事故流程管理最佳实践 (p167)

• 划分优先级：控制影响范围，恢复服务，同时为根源调查保留现场。
• 事先准备：事先和所有事故参与者一起准备一套流程。
• 信任：充分相信每个事故参与者，分配职责后让他们自主行动。
• 反思：在事故处理过程中注意自己的情绪和精神状态。如果发现自己开始惊慌失措或者感到压力难以承受时，应该寻求更多帮助。
• 考虑替代方案：周期性的重新审视目前的情况，重新评估目前的工作是否应该继续执行，还是需要执行其他更重要的或者更紧急的事情。
• 练习：平时不断使用这套流程，直到习惯成自然。
• 换位思考：上次你是事故总控负责人么？下次可以换一个职责试试。鼓励每个团队成员熟悉流程中的其他角色。

连锁故障 (p259)

连锁故障是由与正反馈循环导致的不断扩大规模的故障。连锁故障可能由于整个系统的一小部分出现故障而引发，进而 导致其他部分也出现故障。

应该从设计上避免连锁故障。

防止过载 (p265)

• 使用负载压力测试得出服务器的极限，同时测试过载情况下的失败模式。
• 提供降级结果。
• 在过载的情况下主动拒绝请求。
• 上层系统应该主动拒绝请求。
• 进行容量规划。

好的发布流程的特征 (p373)

• 轻量级 占用很少的开发时间
• 鲁棒性 能够最大限度地避免简单错误
• 完整性 完整地、一致地在各个环节内跟踪重要的细节问题
• 可扩展性 可以应用在很多简单的发布上，也可以用在复杂的发布过程中
• 适应性 可以适用与大多数场景的发布，以及可以适应全新的发布类型

可靠发布所需的方法论 (p381-385)

• 灰度和阶段性发布 “金丝雀”测试
• 功能开关框架
• 应对客户端滥用行为
• 过载行为和压力测试

SRE实践经验 (p459)

• 灾难预演与演习
  • 从组织架构层面坚持不懈对安全进行关注
  • 关注任何细节
  • 冗余容量
  • 模拟以及进行线上容灾演习
  • 培养与考核
  • 对详细的需求收集和系统设计的关注
  • 纵深防御
• 事后总结文化
• 将重复性工作自动化、消除运维负载
• 结构化合理性的决策
  • 某项决策的基本方向是事先决定的，而不是事后得出的
  • 决策时考虑的信息源是清楚的
  • 任何假设都应该明确说明
  • 数据驱动决策要优于情感驱动的决策、直觉驱动的决策，以及资深人士的意见