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 其他行业的实践经验

将重复性工作自动化, 消除运维负载

配置错误的自动化系统可能在极短时间内造成极大的财务损失

结构化和理性决策

理性决策过程

  • 某些决策的基本方向是事先决定的, 而不是事后得出的
  • 决策时考虑的信息源是清楚的
  • 任何假设都应该明确说明
  • 数据驱动决策优于情感驱动决策
© 404mzk all right reserved,powered by Gitbookhttp://read.404mzk.com 该文件修订时间: 2024-02-22 22:48:17

results matching ""

    No results matching ""