言之无物

我说的一切都是错的

可望不可及的SRE

《可望不可及的SRE》

前两天看了18年的DevOps现状报告,下面这张图给我的印象比较深,它展示了当前实施Devops的5种方式。其中SRE方式占比最少,但是组织希望实施SRE的意愿却最高,无论CXO层、管理层还是团队,都表现出了极高的兴趣。SRE究竟具有什么特质,让大家一边向往,一边又保持距离呢?

《可望不可及的SRE》

SRE,全称Site Reliability Engineering, 是google公司对运维工程师的称呼,也用来表示google的运维方法论。SRE的核心目标是稳定(Reliability)。一般意义上的运维,类似于系统管理,以人工操作(operation)为主,但google改变了这种理念,以软件工程(Engineering)的方法来做运维,通过创造系统来维护系统运行以替代传统的人工操作。

对于开头提出的问题,我觉得大概有3点因素:

1. google效应

google自带明星光环,只要是google出品的,总会引起人们的效仿。另外,google分布全球的服务器集群,每天需要支撑几十亿的访问。负责维护这么庞大集群的SRE团队,是如何运作的,自然很受大家的关注。

2. 理念

系统需要人工参与的地方越多,它的稳定性就越差。SRE就是要尽量消除人工操作,特别是经常发生的,重复性的操作。google把这些操作称为琐事。关于琐事的介绍,可以参考我之前写的文章《减少琐事》。

SRE通过设计、构建自动化工具取代人工操作。传统运维团队的大小基本与所服务的产品负载呈线性同步增长。如果一个产品越成功,用户流量越大,就需要越多的人来重复进行同样的事。而成功的SRE,运维工作量保持在一定范围内,却能支持持续增长的业务规模。它们的关系如下图所示:

《可望不可及的SRE》

SRE代表了管理大型复杂服务的最佳实践,由一个简单的想法“我是一名软件工程师,这是我如何来应付重复劳动的方法”而生。

3. 现状约束

谷歌SRE团队里有两类工程师。50%-60%是标准的软件工程师,其他40-50%基本满足软件工程师标准(具备85-99%的技能),同时具有一定程度的其他技术能力,比如,Unix系统内部细节、1-3层网络知识等。可以看出来,SRE对人员的要求是很高的,传统的运维人员大都没有开发软件工程的能力,有些甚至连linux、数据库都不是很熟悉。运维一般需要跨团队协作,针对不同的问题,由专门的团队来解决,这也是大多数公司采用的做法。

一般公司的项目,并没有google这么大的集群规模,shell脚本+现成的监控工具就能满足运维的需要,采用SRE有点大材小用的感觉。

结束语:

SRE涉及的内容很多,有技术上的,也有管理上的。本文只是涉及了点皮毛。SRE很多具体的策略,如拥抱风险、监控预警、紧急处理、on-call等等,还没来得及深入学习。感兴趣的朋友可以看看《谷歌运维解密》这本书,有时间大家一起探讨。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注