SRE-Google运维解密
总结
评分3.5, 偏介绍型书籍, 里面有些观点会有颇为认同的感觉, 对于怎么管理一个技术团队的偏运维方面经验还是挺全面的一本书
1. 介绍
系统管理员模式
unix系统内部细节和1~3层网络知识是Google最看重的两类额外的技术能力
sre团队成员有以下特点
- 对重复性、手工操作有天然的排斥感
- 有足够的技术能力快速开发出系统软件代替人工操作
整个SRE团队对于传统运维工作设立50%的上限值, 保证有足够时间改进维护的服务, 使其变得更稳定和更易于维护
Google-Sre将大部分工作重心放在"运维手册"的维护上
4. 服务质量目标
汇总
大部分指标都应该以"分布", 而不是平均值来定义
9. 简单化
最小API
书写一个明确的、最小的API是管理软件系统管理简单性必要的部分.
一个很小的,很简单的API通常也是一个对问题深刻理解的标志
16. 跟踪故障
需要关注的指标:
- 每次on-call轮值发生的告警数事多少
- 上个季度的可操作的报警和不可操作的报警的比例是多少
- 本团队管理的服务中, 哪个消耗的人工最高
19. SRE部门中的软件工程实践
从Auxon案例抽取共同点,就是很多次的"发布与迭代", 不要等待完美的设计
需要一个产品经理来处理产品需求和优先级分配,在有一些正面结果的情况下招聘这些人可能会容易一些
22. 处理连锁故障
对于一个流量基本稳定的服务来说, 队列长度比线程池大小更小会更好(如50%或以下)
当服务处理速度无法跟上请求到达速率时, 尽早拒绝请求较好
当发送自动重试时
- 一定要使用随机化, 指数型递增的重试周期
- 限制每个请求的重试次数, 不要将请求无限重试
- 考虑使用一个全局重试次数
- 重试和不可重试错误分开
请求延迟和截止时间
- 每个阶段开始之前都检查是否有足够剩余时间处理请求
23. 管理关键状态: 利用分布式共识提高可靠性jsconfig.json
与ACID(原子性、一致性、隔离性和持久性)相比
越来越多分布式存储系统提供BASE(基本可用、软状态、最终一致性)
分布式协调和锁服务
在实践中, 使用可续租约而不是无限时间锁是很有必要的
几乎所有的分布式共识系统中, 都采用单个稳定的领头人进程机制或者是某种领头人轮换机制
24. 分布式周期性任务系统
Cron任务和幂等性
在Cron服务中, 我们优先于"失效关闭", 宁愿不执行,也不能执行两次
25.数据完整性:读写一致性
交付一个恢复系统, 而非备份系统
- 各团队需要未不同的失败场景定义一系列数据可用性的SLO
- 各团队需要定时演练, 以确保他们有能力满足这些SLO
带外数据校验
一个有效的带外数据校验系统需要
- 校验任务的管理
- 监控、报错、和监控台页面
- 限速功能
- 调试排错工具
- 生产应急应对手册
- 校验器容易使用的数据校验API
27. 可靠地进行产品的大规模发布
应对客户端滥用行为
每个客户端在重试时, 应该引入一定的随机性
28 迅速培养SRE加入on-call
对事故的渴望:事后总结的阅读和书写
忘记过去的人必然会犯重复的错误
如何决策对中断性任务的处理策略
让on-call人专职处理中断性任务
其他人全身心去做自己的事情
30 通过嵌入SRE的方式帮助团队从运维过载中恢复
提出引导性问题
应该提出引导性问题, 而非指责性问题
33 其他行业的实践经验
将重复性工作自动化, 消除运维负载
配置错误的自动化系统可能在极短时间内造成极大的财务损失
结构化和理性决策
理性决策过程
- 某些决策的基本方向是事先决定的, 而不是事后得出的
- 决策时考虑的信息源是清楚的
- 任何假设都应该明确说明
- 数据驱动决策优于情感驱动决策