《SRE Google运维解密》读书笔记

最新推荐文章于 2024-08-19 11:08:23 发布

无影风Victorz

最新推荐文章于 2024-08-19 11:08:23 发布

阅读量1k

点赞数

分类专栏： SRE 知识梳理文章标签： SRE 运维 google 读书笔记

本文链接：https://blog.csdn.net/victorzzzz/article/details/105351734

版权

知识梳理同时被 2 个专栏收录

18 篇文章 0 订阅

订阅专栏

SRE

2 篇文章 0 订阅

订阅专栏

SRE团队职责：

确保服务可以正常运转，主要方向包括：

可用性改进
延迟优化
性能优化
效率优化
变更管理（渐进式发布）
监控
紧急事务处理
容量规则与管理（N+2 模式，google--> 15倍）

SRE核心处理思想：

灾难预演与演习
确保系统按照预想方式应对故障
寻找系统中未预料的弱点
寻找其他提高鲁棒性的方式避免事故发生
从组织架构层面关注
关注细节
冗余容量
模拟线上灾难演习
培训考核
纵深防御

书写时候总结
究竟发生了什么？
相应的有效速度
下次可以采用其他方案解决问题
如果避免
自动化与降低日常运维负载
结构化、理智决策
决策是事先决定的
决策的信息源是清楚的
任何假设都要明确说明
数据驱动优于情感驱动

服务可靠性层级模型：

错误预算：

1- 可靠性目标

在一个明确的、客观的指标来决定服务在一个单独的季度中能接受多少不可靠性。用来控制调节发布速度

琐事：手动性、重复性、可以被自动化的、战术性没有持久价值的工作

SLI：服务质量指标（请求延迟、错误率、系统吞吐量、可用性、持久性）

不要以目前的状态为基础选择目标
保持简单，避免绝对值
SLO越少越好

SLO：服务质量目标（服务某个SLI的目标值或目标范围）

留出一定安全区
实际SLO也不要过高

SLA：服务质量协议（描述没有达到SLO之后的后果）

服务可用性度量：

基于时间的可用性：=系统正常运行时间 / (系统正常运行时间 + 停机时间)

合计可用性：= 成功请求数 / 总的请求数

可靠性管理：

MTTF ---- 平均失败时间

MTTR ---- 平均恢复时间

监控系统的4个黄金指标：

延迟
流量
错误
饱和度

监控系统的三类输出：紧急警报、工单、日志

传统测试：

单元测试：检验某一个独立的软件单元
集成测试：检验组件的功能
系统测试
冒烟测试
性能测试
回归测试
生产测试
配置测试
压力测试

金丝雀测试：在典型工作负载的服务子集中进行测试。最终用户的验收测试

识别异常任务的方法：跛脚鸭状态

后端任务正在监听端口，并且可以服务请求，但是已经明确要求客户端停止发送请求

任务编排系统发送一个SIGTERM信号给该任务
后端任务进入跛脚鸭状态，同时请求它的所有客户端发送请求给其他后端任务
任何在后端进入跛脚鸭状态时正在进行的请求仍会继续进行
随着请求恢复被发送回客户端，该后端任务的活跃请求逐渐降低为0
在配置的时间过后，后端程序要么自己干净退出，要么任务编排系统主动干掉它

流量相关：

QPS：每秒处理的请求数单位（用来规划服务容量）

过载处理思路：

客户端：某个用户超过资源配额时，后端任务应该迅速拒绝该请求。客户端主动限制请求速度
自适应节流：

请求数量、请求接数量

新的请求以 max(0,requests-K*accepts / (requests + 1))

增加K会使算法不再激进，减少会使算法激进

后端的请求都会标记为以下四种：

最重要
重要
可丢弃的 SHEDDABLE_PLUS
可丢弃的 SHEDDABLE

客户端配额不够时，后端按优先级分级拒绝请求
某个任务进入过载时，低优先级请求会先被拒绝
自适应节流系统会根据每个优先级分别计数

情况1：如果大部分后端任务处于过载状态，请求应该不再重试，而是一直向上传递给请求者

情况2：小部分任务过载应该立即重试该请求，重试注意点：

增加每次请求重试次数的限制
每个客户端的重试次数限制
客户端在请求元数据中加入一个重试次数

情况3：对于超大数量的连接可能造成后端的过载，建议采取以下策略：

将负载传递给数据中心负载均衡算法
强制要求批处理任务使用某些特定的批处理代理后端任务（代理转发请求，并回复转发给客户端）

防止服务器过载：

压力测试，过载情况的失败模式
提供降级结果
在过载情况下主动拒绝请求
上层系统应该主动拒绝请求
容量规划（只能减少可能性）

限流的解决方案：

子集化：限制某个客户端任务需要连接的后端任务数量

子集选择算法：

随机选择
确定性算法

def Subset(backends,client_id,subset_size):
    subset_count = len(backends) / subset_size
    
    # 将客户端划分为多轮，每一轮计算使用同样的随机配列的列表
    round = client_id / subset_count
    random.seed(round)
    random.shuffle(backends)
    
    # subset_id 代表了目前的客户端
    subset_id = client_id % sebset_count
    
    start = subset_id * subset_size
    return backends[start:start + subset_size]

每轮计算使用不同的重排列表时

不同轮中的客户端会使用不同的列表，同一轮中的客户端也会使用不同的列表子集。从而达到了负载均匀分布

加权轮询策略：

每个客户端为子集中的每个后端任务保持一个“能力”值，仍然以轮询方式分发，但是客户端会按照能力值权重比例调节。收到每个回复之后，后端会在回复中提供当前观察到的请求速率、每秒错误值，以及目前资源利用率。客户端根据目前成功请求的数量，以及对应的资源利用率进行周期性调节。

连锁故障

服务器过载（服务器故障，导致其他服务过载）
资源耗尽

CPU:

请求的数量上升
队列过长
线程卡住
CPU死锁或卡住
RPC超时
CPU缓存效率下降

内存：

任务崩溃
Java垃圾回收速率加快，导致CPU使用率上升
缓存命中率下降

线程

文件描述符

资源之间的相互依赖

服务不可用

连锁故障触发条件：

进程崩溃
进程更新
新的发布
自然增长
计划中或计划外的不可用

解决连锁故障：

增加资源
停止健康检查导致的任务死亡
重启
丢弃流量
进入降级模式
消除批处理负载
消除有害流量

队列长度比线程池大小更小会更好，当服务处理速度无法跟上请求到达速率时，尽早拒绝会更好

流量抛弃：根据CPU使用量、内存使用量以及队列长度进行节流

慢启动与冷缓存

保持调用栈永远向下

如果在层内交互会导致：

分布式死锁
交互延迟上升
系统会更加复杂

分布式共识：

分布式协调失败可能原因：

网络慢
某些消息可以通过，某些消息被丢弃
单方面节流措施

脑裂问题：如果主无法确定副实例健康度，会将自己标记为不可用，升级人工处理

分布式协调和锁服务：

屏障
锁

可靠分布式队列和消息传递：

队列
原子性广播

法定租约：分布式共识性能优化手段，降低延迟和提高读操作吞吐量

给系统中的法定人数进程发放一个租约，这个租约是带有具体事件范围的。这个法定租约有限期内，任何对该部分数据的操作都要被法定租约中的所有进程相应。如果租约中的任何一个副本不可用，那么该部分数据在租约过期前将无法被修改

分布式共识的主要物理限制：网络往返时间RTT、数据写入持久化存储时间

故障域：系统中可能由于一个故障而同时不可用的一组组件

周期性任务

cron：仅仅是单台物理机器

幂等性---> 在最差情况下跳过好于执行两次

crond：系统守护进程，负责加载cron任务的定义列表，任务会在对应时间启动

anacron：在恢复运行时，会试图运行那些在宕机时间本来应该运行的程序。通过将所有已注册的cron任务上次运行的时间记录在一个文件中来实现

大型分布式cron系统注意点：