×

扫描二维码登录本站

标签: 暂无标签
     
写在前面最近花了一点时间阅读了《SRE Goolge运维解密》这本书,对于书的内容大家可以看看豆瓣上的介绍。总体而言,这本书是首次比较系统的披露Google内部SRE运作的一些指导思想、实践以及相关的问题,对于我们运维乃至开发人员都有一定的借鉴意义。
书中的一些思想也令我印象深刻,例如SRE工程师要保证投入50%的时间在项目上、错误预算、命运之轮、事故总结等等,对于从业者有很大的启发。书中提到了很多思想,也提到了很多工具,我想不同的单位有不同的文化、制度背景,这种指导思想未必能够执行,但是书中提到的工具,却有被其他人利用的可能。因此,我就整理了书中提到的一些工具以及搜索是否有对应的开源工程,整理成下面的列表供大家参考。
如果大家发现有不全的,或者对于某个工具希望深入讨论的,欢迎给我留言。
Google 技术栈功能介绍产品对标的开源产品备注
分布式共识系统、分布式锁服务Ch y 书中描述为强一致性存储系统ZooKeeper、Consul
监控服务BorgmonPrometheus、Riemann、Heka、Bosun
Photon
分布式周期性任务系统Cron
任务分发系统,集群管理系统Borg
分布式文件系统GFS
Mesos
管理报警响应及升级规则Escalator
故障跟踪工具(被动收集监控系统发出的所有报警信息,同时提供标记、分组和数据分析功能)Outalator
数据流水线MapReduce、Flume
大规模数据处理WorkflowSpanner ?
Incident Command System
构建系统Bazel
分布式文件系统GFSBorg    调度服务(2003),开源产品 Kubernetes
Borg Name Service BNS 名称解析系统
Bigtable
Blaze/Bazel 构建
Rapid 发布
Midas Pacakge Management MPM 打包
Sisyphus 发布自动化框架
Ch y 强一致性存储系统
Prober 端到端检测(黑盒监控 Black Box Monitoring)
Protocol Buffer (Protobuf)
Alert Manager 报警管理服务
Dapper 分布式组件跟踪工具
Incident Command System 应急事件管理
IRC机器人
Dagger 依赖注入(Dependency Injection)工具
Protocol Buffer 数据交换格式
Auxon 自动化容量规划
gRPC Google RPC 框架
Doorman 协作性分布式客户端节流系统
Zipking 业务流追踪
Stackdriver
两点吐槽一、绕口的翻译
P158:一个测试系统可以检测出一个MTTR为0的Bug。
P253:这种设计类型在服务领头人的工作量是分片的。
P327:Google几乎没有处理大规模消费者产品运行不能直接控制的客户端代码的经验。
二、强大的客户端

全书各章节及小评章节及名称感想
1 介绍
2 Google 生产环境:SRE视角
3 拥抱风险
4 服务质量目标
5 减少琐事
6 分布式系统的监控
7 Google 的自动化系统演进自动化的价值,自动化的层次
8 发布工程
9 简单化
10 基于时间序列数据进行有效报警
11 on-call 轮值
12 有效的故障排查手段
13 紧急事件响应
14 紧急事故管理
15 事后总结:从失败中学习
16 跟踪故障
17 测试可靠性
18 SRE部门中的软件工程实践
19 前端服务器的负载均衡不同数据中心之间的负载均衡策略最佳实践,基本的方案有DNS、VIP(网络负载均衡器 F5)
20 数据中心内部的负载均衡系统从应用层面谈如何进行负载均衡,如何让各台服务器的使用率更加均衡,避免出现闲忙不均的情况。如何更准确的识别出后端的真实状态的方法:跛脚鸭状态。
21 应对过载
22 处理连锁故障
23 管理关键状态:利用分布式共识来提高可靠性
24 分布式周期性任务系统
25 数据处理流水线
26 数据完整性:读写一致
27 可靠地进行产品的大规模发布
28 迅速培养SRE加入on-call
29 处理中断性任务
30 通过嵌入SRE的方式帮助团队从运维过载中恢复
31 SRE与其它团队的沟通与协作
32 SRE参与模式的演进历史
33 其他行业的实践经验
34 结语







上一篇:神速的蚂蚁SRE团队
下一篇:去除谬见:对SRE的误解分析
admin

写了 834 篇文章,拥有财富 28725,被 26 人关注

您需要登录后才可以回帖 登录 | 立即注册
B Color Link Quote Code Smilies

成为第一个吐槽的人

Powered by ITIL  © 2001-2025
返回顶部