SRE_Google运维解密_笔记

1.70%的事故由变更引起

2.谷歌的SRE倾向于DEVOPS，兼顾效率（快速上线更新）与质量（降低事故率）

3.SRE大致发展历程：手动（凭经验容易误操作）→自动→智能

4.缓慢的不断重启的实例优于永不重启泄露资源的实例

5.SLA（service level agreement）：请求延迟；错误率；系统吞吐量（QPS）；可用性；持久性

SLO（object）：SLI的目标范围

SLI（indicator）：从目标反推指标

6.多创新，少做琐事（DRY），但合理的琐事有助于放松

7.监控系统的4个黄金指标：延迟；流量；错误；饱和度（saturation）：达到100%之前性能就会严重下降

8.监控出现的现象及原因分析：最好能深挖

9.自动化程序：能力，即准确性；延迟，任务开始到执行完毕的时间；相关性，自动化所涵盖的实际流程比例

10.on-call（本质为琐事）的比例，每季度两到三次

11.复杂操作系统本质就是动态和不稳定的→系统的稳定性与灵活性如何追求平衡

12.有效的故障排查手段：反复采用假设-排除手段的过程

12.1.误区：关注错误现象，或错误理解现象含义；不能正确修改配置信息，输入的信息或系统环境不能安全和有效地测试；过早将问题归结为极不可能的因素；念念不忘之前发生过的系统问题（认为只要发生过一次，就可能再次发生）；试图解决与当前系统相关的一些问题，颠倒因果（如数据库异常和环境温度同时出现，优先解决温度问题，却忽略了温度异常可能只是结果）→相关性不等于因果关系

13.正确判断问题严重程度（一定的判断力；保持头脑冷静）

14.出现大型问题，应首先回退，优先恢复业务正常，再进行故障定位和排查（用户对业务感知很敏感）

14.1.检查：监控指标；日志（按需、快速、有选择启用）；暴露目前的系统状态；使用该系统的一个真实客户端（采集具体返回信息）→查看服务端口是否正常运行；检查最近对系统的修改（无外力因素，系统会持续正常工作）

15.紧急恢复（故障处理）→按流程管理→设立warroom而非各自为战

16.事后总结输出（做到对事不对人）：影响，采取的措施，根因，预防措施等，可提供大量经验

17.连锁故障：

1）服务器过载：单点故障

2）资源耗尽：不同种类的资源

3）CPU资源不足：正在处理的请求数量上升（可能进入队列排队）；队列过长；线程卡住（等待某个锁而无法处理请求）；CPU死锁或请求卡住（排队进程访问←→看门狗watchdog杀死）；RPC超时（服务器过载时，回复客户端RPC变慢→超时→客户端重试→更严重的超时）；CPU缓存效率下降（CPU使用过多→任务分配至CPU核心→缓存失败）

4）内存：请求数量上升→消耗更多内存存放请求，回复及RPC对象→直至耗尽

内存耗尽可能导致的情况：任务崩溃（因超过资源限制被容器管理器（VM或其他）驱逐，或因程序自身逻辑；Java垃圾回收（GC）速率加快，导致CPU使用率上升：GC死亡螺旋（当CPU资源减少，请求处理速度变慢，内存使用率上升→GC触发次数增多→CPU资源进一步减少）；缓存命中率下降（向后端发送更多的RPC，导致后端任务过载）

5）线程：线程不足→错误或健康检查失败→服务器因此增加线程→占用更多内存

6）文件描述符：不足时导致无法建立网络连接→健康检查失败

18.队列管理：当请求速度超过单个请求的处理速度，请求进入排队→线程池和队列同时饱和→消耗内存并使延迟升高

队列长度比线程池大小更小会更好→尽早拒绝请求

19.流量抛弃：在软件服务器临近过载时，主动抛弃一定量的负载

1）根据CPU、内存使用量及队列长度等进行节流→返回HTTP 503（服务不可用）

2）将标准的先入先出改为后入先出队列模式

3）使用可控延迟算法

4）适用于基础共享服务采用的方式：精确识别客户端；将请求按优先级处理

20.优雅降级：降低服务质量

21.重试

1）请求延迟和截止时间：定义前端会等待多长时间；恰当的截止时间需在多个限制条件中寻求平衡

2）超过截止时间：客户端已经放弃该请求，继续处理无意义，应在请求过程的每个阶段之前，都检查是否还有足够的剩余时间处理请求

3）截止时间传递：让服务器采用截止时间传递和取消传递的策略（整个RPC树）

，将传递出去的截止时间减少一点，将网络传输和处理时间考虑在内

4）给发出的截止时间设置一个上限

5）请求延迟的双峰分布（Bimodal）：当延迟上升时，额外注意延迟的分布状况；无法完成的请求→→尽早返回一个错误，而非等完整个时间

22.慢启动和冷缓存：

1）进程在刚启动时通常比稳定状态下请求更慢一些：必需的初始化进程；运行时性能优化

2）服务器在缓存没有充满之前效率很低，非常耗时：上线一个新的集群（缓存为空）；在某个集群维护之后恢复服务状态（数据过期）

解决方法：重启（将缓存在多个服务器共享）；将缓存从一个软件服务器拿到另外的独立服务器，如memcached

23.管理关键状态：利用分布式提高可靠性

1）网络问题的出现（早晚）

2）服务应用如何实现强一致性和高可用（ACID，常用于关系型数据库；BASE，常见于Nosql）

BASE：基本可用（basically available）、软状态（soft state）、最终一致性（eventually consistency）→多主复制（multimaster replication）

24.系统的工作原理、运维方式、故障模拟、应急处理方式

25.后备系统和精心设计的API←→操作的东西应更抽象而非具体

26. stackoverflow.com

27. openpyxl.readthedocs.io/en/stable