读SRE Google运维解密有感(一)

前言

这几天打算利用碎片时间读了一下"SRE Google运维解密"这本书,目前读了前几章,感觉收获颇多,结合自己的工作经历和书中的要点,写一些感悟和思考

SRE

有关SRE我就不多介绍了,中文名字叫站点可靠性工程师,它的由来是google想通过软件工程师来解决复杂运维问题。 它里面有很多有意思的点,比如:

  • 运维工作只能占比工作时间50%
  • 另外50%要开发工具解决问题
  • SRE和开发工程师会轮岗

这些相关概念网上很多都介绍了,我就不赘述了,我说下一些我感兴趣的点

谷歌神话

谷歌一直在技术领域处于世界领先位置,从bigtable的三篇论文,开源的k8s,分布式关系数据库,谷歌的技术在IT领域可以说是标杆。

有个传说是谷歌内部使用的系统一般2-3年以后才会出相关论文或者开源版本实现,出来了以后其它企业开始实践还需要2-3年,等到你把这些实现了,谷歌又不知道实现了什么黑科技。IT界如果是江湖的话,谷歌就像是少林派,有一种天下武功出少林的气派。

所以SRE这本书自带光环,很多人都觉得这是运维圣经,觉得这是拯救运维领域的不二法宝。

或许你也在读这本书,你也想在内部尝试SRE的一些方法和思想。

那么首先我劝你先冷静一下,它并不是一个万能的解药,要先考虑下你的公司现状,问题,结合实际国情,找到切实可行的方法。

我为什么这么说呢?请往下看

谷歌的肌肉

首先本书一开始简单说了下SRE的思想和方法论,然后介绍了谷歌的基础设施,就好像一个人一样,谷歌的基础设施就是这个人的肌肉,有了强劲的肌肉才能跑得快,跳得高。

网络设施

谷歌基于自研的交换机Clos,使用SDN技术,确保每个数据中心可提供海量带宽,并且可以动态带宽管理优化网络连接。

调度系统

使用Borg负责在集群层面管理任务编排工作

存储

在物理机设施(磁盘)上构建了一套简单可用,可靠的集群存储服务。

  • Colossus GFS文件系统的改进白本
  • Bigtable 松散存储的,分布式,有顺序,持久化的NoSQL数据库
  • Spanner 分布式的关系型数据库

分布式锁

Chubby 提供一个可以处理异地,跨机房级别锁请求的集群锁服务

监控和报警

Borgmon 从监控对象抓取监控指标,这些指标可以用来触发报警,也可以存储起来供观看。(开源实现是Prometheus)

RPC

所有谷歌服务之间使用RPC通信,称为Stubby(开源实现gRPC),传输格式是Protobuf。

GSLB和BNS

  • 利用地理位置进行负载均衡DNS请求
  • 用户服务层面负载均衡
  • RPC层面负载均衡

通过各个层面的负载均衡将用户流量导向健康的服务上面。

这些完善的基础设施,给SRE中的方法和思想做了强有力的支撑。

故障不是洪水猛兽

SRE中定义了一个概念叫SLO(服务质量目标),通过SLO合理评判一个服务要达成的服务质量。

首先我先说下”故障“这个词,这个词对运维人员来说,是非常不想听到和遇到的。运维人员有一个重要任务是确保服务的稳定,换句话说就是没有故障。

所以我们或多或少谈到“故障”就会色变,遇到故障马上第一时间解决,为了避免下次还出现,我们可能还会开“事故总结会”,优化流程和工具。

其实我们很多时候对于“故障”的理解是简单粗暴的,从一线员工到老板都认为“故障不能有”,“故障必须消除”,我们耗费很大精力“消除了一切故障”,系统平稳运行了,自己也会萌生成就感,感觉干的还不赖。可是并没有进一步去思考一下,故障存在的意义。

我们常见的所谓“99.9%”,“99.99%”的服务可用性,但是并没有使用科学方法来分析和规划业务到底应该3个9还是4个9。

SRE中说到一句话“100%稳定的系统是不存在的”,它把这个做为一个前提,那也意味着系统是肯定要出故障的。

SLO就是用来解决这个事情的,首先服务的故障不可避免,每个服务的级别不同,不可能所有服务都是99.999999,要针对业务的不通特性制定不同的SLO。

比如: 谷歌的企业服务,针对企业用户是有签署服务中断赔偿协议的,那么稳定性要求很高,所以它的SLO级别必须很高。 谷歌的youtube(当时),针对终端用户且版本迭代很快,业务在不断变化和创新,SLO级别可以放低。

SLO的制定通常是产品经理,开发团队,SRE一起协商完成,大家根据业务的规模,产品特性,产品处于的阶段制定。

SLO的制定,我觉得就是科学的面对“故障”这个问题,故障不可避免,不应该以消灭故障为目的,合理的接受它,确保它在SLO标准的范围内,高于这个标准会浪费人力和成本,低于这个标准就需要进行优化。

SLO的制定很大程度在于各个团队之间的协商,大家都有基于数据的科学评判方法,比如产品预估的用户数,产品发版周期,使用带宽等。

中国的国情更多的是拍脑袋,老板的态度,上面的一句话“不能有事故”,那就是99.999999999999999无限,没有科学的进行评估。

SLO解决的问题

通过这样一个SLO,之前很多令人头疼的问题就迎刃而解了。

成本和收益的矛盾

大家都知道维护服务可用性的成本不是线性增长的,到一定程度,增加一个9可能需要10倍100倍的成本,通过SLO让成本和收益取得很好的平衡,假设一个业务增加SLO等级,可以计算一下需要的成本和带来的收益,如果得不偿失就可以不用增加SLO等级。

科学的运维

有了SLO,对于运维工作有了可量化的标准,运维工程师不用每天提心吊胆,生怕出现故障,只要故障在SLO范围内就是可接受的,节省出很多精力用在更重要的事情上。

稳定和创新的矛盾

大家都知道运维工程师最不喜欢的就是“线上变更”,一个服务如果不做变更一般都是很稳定的,问题往往出现在变更上。
可是一个新业务往往需要大量变更,不停的迭代创新。
这个时候运维会说:别做变更了,稳定是第一位的,出了故障,我们得背锅。
开发会说:我们得变更,这样才有新功能,才能获取更多用户啊。
矛盾因此产生了。
通过SLO很好的解决了这个矛盾,我们先一起给这个业务制定好SLO的等级,如果是需要频繁的变更的,可能SLO等级就会低一些。
这样在满足业务创新的需求上,只要在SLO范围内,就认为业务是稳定的。
反之,如果变更太频繁,使故障率超出了SLO可接受的范围,可以要求开发调低变更频率,或者重新制定SLO等级。
这样就解决了业务既要“稳定”又要“创新“的矛盾。

结语

SRE Google运维解密是非常好的一本书,它是谷歌运维体系的结晶,但是它也是建立在谷歌”健壮的肌肉“之上,建立在科学评估(非人治)之上,我们可以从中学习,也要冷静思考。
这是SRE读后感第一篇,后续再读几章,再写点。

附一个360的招聘==>https://www.addops.cn/page/wanted

时间: 2024-10-29 19:08:52

读SRE Google运维解密有感(一)的相关文章

读SRE Google运维解密有感(四)-聊聊问题排查

前言 这是读"SRE Google运维解密"有感第四篇,之前的文章可访问www.addops.cn来查看.今天我们来聊聊"问题排查"这个话题,本人到目前为止还在参与一线运维的工作,遇到过很多"稀奇古怪"的线上故障和问题,结合SRE中给出的一些方法,来说说"问题排查"那点事. 排查问题不是玄学 排查出线上问题,并找到根本原因加以解决,是一件很有成就感的事情,曾经有人问过我,"你是怎么想到问题出现在xxx的?又是怎么确认

读SRE Google运维解密有感(二)

前言 这是读"SRE Google运维解密"有感第二篇,第一篇参见 这本书最近又读了几章,结合自己的经历,有些地方真的能感同身受,有些地方也惊叹SRE充满辩证的思想,总之SRE是好一本好书,会给你很大的启发. 充满辩证的思想 本书主要是讲通过SRE思想进行运维体系的构建,除了技术层面以外,我更关注SRE内在充满辩证的思想. 一个辩证的思想是凡事都有两面性,这个道理很简单,大家一听就说"对啊,这不是废话么",可是面对具体问题的时候,有时候往往做不到这一点. 服务太稳定

读SRE Google运维解密有感(三)

前言 这是读"SRE Google运维解密"有感第三篇,之前的文章可访问www.addops.cn来查看.我们今天来聊聊"on call"也就是运维值班制度, 本人到目前为止也还在参与一线运维的值班,对运维值班体系也有一些感悟和心得,再参考SRE的"on call"中的方法来说说这个让运维同学"又爱又恨"的值班. 值班 因为运维人员的工作性质,要时刻保障线上服务的稳定可用,遇到事故问题要第一时间处理,所以很多运维团队的工作必须

google运维解密

1.运维团队与开发团队的矛盾: 运维追求业务的稳定.开发更关注新功能的添加与版本的快速迭代.但是由于业务更新,有很大可能导致故障.从本质上来说,两部门是矛盾的. deops应该是: 1.对重复性工作有天然排斥感 2.有足够能力快速开发软件系统来代替手工操作 sre团队职责:可用性改进.延迟优化.效率优化.性能优化.变更管理.监控.紧急事务处理.容量规划与管理 2.告警系统: 监控系统不应该要人来去分析告警信息,而是要告诉人要做 3.sre要密切关注系统的性能和资源利用率,进而改进资源利用率,降低

IT运维工作

在"高效运维"公众号中读到<运维自我提升:怎样做好企业IT运维工作>这篇文章,比较赞同,消化一下并记录下来,与大家交流.一.运维工作按工作层次划分:1.硬件运维2.桌面运维(helpdesk)3.系统运维(sa-system admin)4.数据库运维(dba)5.应用运维6.网络运维7.运维开发(devops)8.系统稳定性运维(sre)9.··· ··· 二.运维工作好坏的评价标准运维工作给公司及业务带来的价值与影响,一切行为要围绕业务展开三.运维工作中的工作方法1.技

【我拼搏的2016】-苦逼运维如何变身为SRE成长经历

提起运维很多人能联想到的字眼就有"苦逼"."辛苦"."加班"."背锅",随着国内互联网大潮的兴起,特别是最近几年互联网行业的火爆,催生了大批运维从业人员.类似于当年网络管理员的职业发展,由于普通人对于该领域专业知识的匮乏和良莠不齐的从业人员素质,拉低了整个社会对于这一职业的认知,和当今的运维职业何其相似. 作为运维大军中的一员,我也是经历过从自己摸索自学到专业培训机构系统化学习,再到逐渐完善知识体系和不断提高眼界认知,过程是极

运维学习之加密和解密

运维学习之加密与解密: 众所周知,在网络的世界里不存在绝对的安全性.各种钓鱼网站,病毒等等危害着我们的网 络环境.所以,作为一个运维人员,在我们利用网络进行通信时,保证通信的机密性.完整性.可用性是必要的. 我们的日常生活中有以下三点威胁网络安全的行为: 1.威胁机密性的攻击行为,它的途径是窃听.嗅探.扫描和通信量分析 2.威胁完整性的攻击行为,它的途径是更改.伪装.重放.否认 3.威胁可用性的攻击行为,它的途径是拒绝服务 为应对以上问题,我们在技术和服务两方面提出了解决方案: 从技术上我们使用

运维的误区:好心办坏事,终成背锅侠---腾讯云与前沿数控之数据问题有感

本人运维老司机,有个体会,如题.运维人员责任心都很强,但是有时就会出现"好心办坏事,终成背锅侠"的结果. 看到告警,首先想到要解决,这个思路没有问题,但是由于操作上的问题,终成大错! 教训与反思:1.数据搬迁流程要开启数据校验,数据是根,马虎不得.2.数据搬迁完成之后,源仓库数据要保留足够长的时间.3.完事不能完全依托服务商或产品,用户要有自己的备份机制.4.运维规范化.自动化.流程化势在必行,降低人工干预,降低人为错误.5.应急备案要重视. 相关文章:腾讯云微信公众号:关于客户&qu

从运维角度看中大型网站架构的演变之路

前言 网上有很多文章类似于我今天要分享的课程,有架构师写的,有运维写的,还有开发些的,偏重点都不同,今天我以咱们运维角度全面讲解. 一个成熟的网站架构并不是一开始设计就具备高可用.高伸缩.高性能等特性的,它是随着用户量和业务线不断增加,基础架构才逐渐健壮的.在发展初期,一般都是从0到1,不会一上来就整一些大而全的架构,也很少人这么任性. 说明 适用业务:电商/门户/招聘网站 开发语言:PHP和JAVA Web服务:Nginx/Tomcat8 数据库:MySQL 操作系统:CentOS 物理服务器