读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