×

扫描二维码登录本站

QQ登录

只需一步,快速开始

遥不可及的SRE

标签: 暂无标签
组织采用SRE方式占比最少,但是希望实施SRE的意愿却最高,无论CXO层、管理层还是团队,都表现出了极高的兴趣。SRE究竟具有什么特质,让大家一边向往,一边又保持距离呢?


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

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


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

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


2.理念

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


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

2.png

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


3.现状约束


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


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







上一篇:云端的SRE的发展和实践有哪些?
下一篇:SRE基础入门方法和团队组织方式
太帅

写了 291 篇文章,拥有财富 553,被 4 人关注

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

成为第一个吐槽的人

最新100贴|论坛版块|ITIL先锋论坛 |粤ICP备11099876号|网站地图
Powered by Discuz! X3.4 Licensed  © 2001-2017 Comsenz Inc.
返回顶部