《Google SRE》读后感

devopsec 等级 756 0 0
标签: sre运维开发

注:从我的知乎搬移过来,方便管理,link:《Google SRE》读后感

《Google SRE》读后感

Google SRE 封面

国庆长假,出门太堵,遂待在魔都,花了三天时间将《Google SRE》中文版翻了一遍,好书一本,不管是开发人员、运维人员还是架构师,都可以读一读,受益匪浅的。

鉴于自己是做开发的,所以对于运维相关流程化的内容没有涉猎。不过这部分内容对于运维leader应当是大有裨益的。

一、SRE是个全能手,DevOps的实践者

SRE全称:Site Reliability Engineering,翻译过来就是:站点可靠性工程师。SRE的职责确保站点的可用,为了达到这个目的,他需要对站点涉及的系统、组件熟悉,需要关注生产运行时的状态,为此,他需要有很多工具和系统支撑其完成上述工作,比如自动化发布系统,监控系统,日志系统,服务器资源分配和编排等,这些工具需要他们自己完成开发和维护。

SRE是一个综合素质很高的全能手,需要懂服务器基础架构、操作系统、网络、中间件容器、常用编程语言、全局的架构意识、非常强的问题分析能力、极高的抗压能力(以便沉着高效地排障),他们还需要懂性能调优理论...

SRE的工作是Develop+Operate的结合,SRE是DevOps的实践者,他们的工作内容和职责和传统运维工程师差不多:发布、部署、监控、排障,目标一致。但是SRE的手段更加自动化,更高效,这种高效来源于自动化工具、监控工具的支撑,更因为其作为这些工具的开发者,不断优化和调整,使整个工具箱使起来更加得心应手,这也是DevOps的魅力所在。

二、分布式环境运维大不同于传统运维

我的理解:在分布式环境下,系统的复杂度增大、维护目标增多,按照传统的手工或者半自动维护来做,是不行的。所以,需要转变思路:

事务性的工作工具化。比如:版本发布、服务器监控;

让系统自反馈。完善的监控告警机制,完善的日志记录和分析体制,可视化系统的健康状态,使得系统变得可追踪和调校;

分布式策略应对巨量运维对象。负载均衡、流控、数据完整性、批处理的变得不一样,需要重新设计和实践。同时,更要重视连锁式故障。

三、分布式系统的核心——分布式共识

分布式共识问题是指“在不稳定的通信环境下一组进程之间对某项事情达成一致的问题”。

分布式共识系统可以用来解决:领头人选举、关键共享状态、分布式锁等问题。或者绝对点,所有的分布式问题都应当考虑到分布式共识的问题。

分布式共识的理论基础和实现都不是很好理解,抽时间搞清楚是大有裨益的,这里罗列一下几个关键词:

拜占庭问题

可复制状态机

Paxos算法

Zookeeper

Chubby

四、监控很重要!很重要!很重要!

监控是SRE眼睛的延伸。

监控系统应当解决两个问题:现象(什么东西出故障了?),原因(为什么出故障?)

现象—— 用户可感知的现象,比如:登陆不了、支付订单变慢;

原因—— 造成现象的潜在因素,可能只是中间因素或者相关因素,并非根本原因,根本原因需要SRE介入分析并确定。比如:login 服务CPU超过警戒值,订单服务器的CLOSE_WAIT状态的TCP链接数猛增等等。

四个黄金指标:时延、流量(PV)、错误、饱和度(服务器资源使用情况)。前三个是对服务进行监控,后一个是对服务器进行监控,当然也可以包含容器的状态监控,比如线程池、GC等。

几条箴言:

指标简化到不能再简化

关注长尾现象,要时延分布,而不是平均时延

慎重发出紧急警报,预防“狼来了”现象,紧急警报都是课操作的,且不能惯性得出结论的问题

警报不要重复,避免浪费SRE的注意力

五、排障

定位故障点。合理判定问题的严重程度,尝试尽快恢复服务或者缓解问题。

借助监控工具和日志工具检查系统或者服务状态。服务时延和错误率、系统资源使用状态情况、日志统计分析

逐层检查和分解问题,解析问题现象,不断假设/验证地进行诊断,找到根本原因

六、发布

自动化发布应当作为基础设施,第一优先级建设,他的重要性和自动化测试一样。之前参加的“软件工程的精益化管理”课程实验中,实践证明了自动化工具的威力很大,能够明显提升整个团队的生产力。

关于自动化发布的内容和分享网上非常多,而且国内各大互联公司分享出来的材料也是汗牛充栋,用到是可以学习。

七、反思 and 总结

这两个优点对于SRE很是重要,反思使得SRE从失败中学习教训,总结使SRE从时间中获得经验,个人和团队需要学习和践行这种精神,但是对事不对人。

Google的做法是:时事后总结机制。

避免指责,提供建设性意见,充满正能量

时候总结报告需要评审,避免低质量的时候总结带来负面影响

google的事后总结模板

八、追本溯源、怀疑一切

SRE是天生怀疑论者,怀疑一切,眼见为实,追本溯源是本性,感觉自己的性格还蛮适合的~

九、拥抱风险

传统运维是厌恶风险的,但是开发和产品却更关注变化速度,他们都希望迭代速度越快越好,但是这回给系统运行带来风险,所以这天生是矛盾。

为了解决风险和变化的矛盾,google提出了SLI-->SLO-->SLA的机制。

SLI——服务质量指标,如:延时、吞吐量、错误率、可用性等

SLO——服务质量目标,服务的某个SLI的目标值,或者目标范围。比如:SLI<=目标值,min=

SLA——服务质量协议(Agreement),服务(SRE)和用户(开发、产品)之间的一个明确的、或者不明确的协议,描述了在达到或者没有达到SLO之后的后果。或者可以转化为先行的KPI,比如系统可用性99.99%等。

开发和运维针对某个系统协商好一个SLA后,大家有一个量化的指标,一旦出现冲突时,算一下,看看是否违反SLA,如果违反,那么就升级走流程。这样既灵活,也有章可循。如果开发团队牛逼,代码质量高或者运气好,你可以迭代快,反之你需要慢点来,间接地,大家都对线上系统负责了。

十、反直觉的真理

1、不要承诺你的系统100%可靠。

因为这样会要其他人过分依赖于你,一旦你出问题,那么将成为众矢之的,相反的,你应当对自己的系统了如指掌,比如能承受的压力,可用性目标,一些明显的坑,一些不支持的属性等,广而告之。

2、有意识地破坏你的系统

不同于演练,而是真实生产系统,在可控范围内,人为制造故障,然后在有人值守的情况下,找到系统的短板和问题。这样等到真正的故障来临时,可以有章可循,快速解决问题。

主动暴露自己的不足好于别人突然揭发你,当然更重要的是要及时纠正不足。

收藏
评论区

相关推荐

头条研发-SRE运维研发实习生视频面试(一, 二面)
(about:blank%E4%B8%80%E9%9D%A230min "一面 (30min)")一面 (30min) 江湖规矩自我介绍, 很罕见的没有用算法题起手, 直接就问很具体的问题, 点个赞 <3 (htt
《Google SRE》读后感
注:从我的知乎搬移过来,方便管理,link:《Google SRE》读后感(https://link.jianshu.com/?thttps://zhuanlan.zhihu.com/p/22912741?group_id815131133242134528) (https://imghelloworld.osscnbeijing.a
我们离Google SRE还有多远?
经过几年的挣扎和讨论(确切说应该是3年),老板在钉钉群以通告的方式正式告别伴随我们多年的职业Title PE,改名为SRE。(后续以A SRE区别Google SRE) (https://imghelloworld.osscnbeijing.aliyuncs.com/188fb7b287badee91332a9f90c3af347.p
谷歌SRE理论读书札记:SLI、SLO与SLA
趁着这被人扫地出门,无地可去的日子,多学习学习别人的理论知识。 书籍名 《Site Reliability Engineering》网络运维工程,编者Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy第二部分 规则(Principles)
SRE和DevOps值得关注的十大开源项目
构建可扩展且高度可靠的软件系统是每个SRE的最终目标。在SRE/DevOps领域中,有大量出色的开源项目,每个项目都有新颖而激动人心的解决方案。在本文中,我们将会介绍一些在监视,部署和维护领域最受欢迎的开源项目。 1\. Cloudprober可以主动跟踪和监视应用程序,并帮助你提前发现故障。它使用“活动(active)”监视模型来检查你的组件是否按预
IT:从运维到运营
_本文转自公众号:傲寒荐书,作者:陈傲寒_ _IT运维?IT运营?_ _都是 IT Operations,有什么区别?_ _IT运维管理?IT运营管理?_ _都是 ITOM,有什么区别?_ _一字之差,只是翻译不同,还是另有玄机?_ _其实,_**中文真的是一门更精确的语言 :-)** * _IT运维是“活着”,IT运营是“活得好”;_
MySQL运维之
**1、mysqldump备份一个数据库** mysqldump命令备份一个数据库的基本语法: mysqldump -u user -p pwd dbname > Backup.sql 我们来讲解一下备份的文件都包含了什么?\-- MySQL dump 10.13 Distrib 5.5.20, for Win32 (x86)\--
ClickHouse之DBA运维宝典
最近有位网友与我聊天,他是一名 DBA,问我在 ClickHouse 中有没有一些能够 “安家立命” 的运维 SQL 语句。我想对于这个问题很多朋友都会有兴趣,所以就在这里做一个简单的分享。 在 ClickHouse 默认的 system 数据库下(databse),拥有众多的系统表。我们对 ClickHouse 运行状态的各种信息,就主要来自于这
Debezium日常运维手机
关于Kafka-Connect: (1) 是否可以动态添加已有数据的新表?  不可以,Kafka-Connect需要配置先行。如果是已有数据的新表,无法通过修改已有的kafka-connect配置进行新表的Snapshot初始化。 建议通过table white list功能,进行新表的snapshot。然后等到稳定后,再合并到同一个Kafka-con
Google SRE之后的CRE,一起来看看吧
![](https://oscimg.oschina.net/oscnet/5bf875465af5c15f36554f995a073bc2998.jpg) 去年10月份,也就是2016年10月份,Google Cloud Platform Blog上更新了一篇文章,Google宣布了一个新的专业岗位,CRE,Customer Reliabilit
Google 和 Facebook 如何大规模处理 IT 事件管理 —— 2016 SRE 大会之我
**【编者按】本文作者为 Maria Arbisman,主要介绍 Google 与 Facebook 两大巨头是如何大规模处理 IT 事件管理。文章系国内 [ITOM](https://www.oschina.net/action/GoToLink?url=http%3A%2F%2Fwww.oneapm.com%2Fsolutions%2Fvalue.htm
Linux日常运维小结
**1\. 如何看当前Linux系统有几颗物理CPU和每颗CPU的核数?** 物理cpu个数:cat /proc/cpuinfo |grep -c 'physical id' CPU一共有多少核:grep -c processor /proc/cpuinfo 将CPU的总核数除以物理CPU的个数,得到每颗CPU的核数。 **2\. 查看系统负载有两个常用的命
Linux运维常见面试题之精华收录
Linux运维常见面试题之精华收录 ================= **1、什么是运维?什么是游戏运维?** 1)运维是指大型组织已经建立好的网络软硬件的维护,就是要保证业务的上线与运作的正常, 在他运转的过程中,对他进行维护,他集合了网络、系统、数据库、开发、安全、监控于一身的技术 运维又包括很多种,有DBA运维、网站运维、虚
Nginx日志运维笔记
在分析服务器运行情况和业务数据时,nginx日志是非常可靠的数据来源,而掌握常用的nginx日志分析命令的应用技巧则有着事半功倍的作用,可以快速进行定位和统计。 **1)Nginx日志的标准格式(可参考:[http://www.cnblogs.com/kevingrace/p/5893499.html](https://www.oschina.net/ac
Serverless解决方案,与传统和容器化应用的不同之处
![](https://oscimg.oschina.net/oscnet/53406a59-99f1-41b4-9763-436be0d502bf.gif) 无服务架构(Serverless)和DevOps、SRE、微服务、容器等一样,是最近两年比较新兴的概念,数人云之前给大家分享过[《Serverless用这5大优势,挽救了后来7亿用户的I