Google SRE 参会总结

Google SRE 参会总结

近期有幸参加了一个小型的运维会议,同《SRE:Google 运维解密》的译者进行面对面的沟通,收益匪浅。会议上大家的讨论非常热烈,话题主要集中在以下几个方面:

什么是SRE,职责是什么?

SRE全称Site Reliability Engineering,是Google内部的一个运维职位,主要职责是保障服务的可靠性和性能,同时负责数据中心资源分配,为重要服务预留资源,该职位不负责某个具体业务的上线和部署。

SRE分为产品SRE和平台SRE。产品SRE负责某个具体产品相关的所有组件的运维,而平台SRE则负责诸如主机计算能力,数据库资源等PaaS资源。按照我个人的简单理解,前者是以业务为单位的纵深管理,后者是以平台为基础的横向管理。不论何种SRE,在我看来,这个职位都对个人能力有较高的要求,非传说中的全栈工程师莫属。

SRE和开发如何分工协作

首先,SRE和开发仅仅只是两个不同的职位,并非某种能力的划分,两者之间可能会存在转换。比如某个产品上线之前没有设置专门的SRE,上线之后为了满足业务需要,从之前的开发人员中选择合适的人担任SRE;

其次,SRE和开发在产品的各个生命周期都可能存在合作。比如产品的设计阶段,需要SRE介入协助进行高可用架构设计;产品交付阶段,又可能需要开发人员配合SRE进行一些故障的分析和诊断。

开发和运维相互之间的职责如何界定

在国内,开发和运维相互扯皮是一个永恒的话题,那么Google是怎么应对的呢?

在Google内部有一个非常好的规则——对事不对人。出了问题,首先想到的不是谁来承担责任,而是大家坐在一起想办法解决问题。他们会尽可能找出问题的root cause,尝试从规则上、流程上杜绝类似问题的再次发生。而Google也不会由于一个具体的case开除员工,当然,如果屡教不改总是犯低级错误,或者工作态度有问题的不在此范围内。

个人觉得这是非常好的一个制度,能够消除面对某个具体问题时,由于可能承担的责任问题,把彼此放在了对立面。毕竟问题已经出了,快速的组织善后工作,从根本上解决问题避免再次发生,才是正确的方向。

当然,一团和气是干不好革命工作的,必要的工作界面划分还是有必要的。不论是开发还是SRE,提供的都是有限责任,就是说我的服务是有边界的,不是任何问题都需要负责。比如我是一个数据库平台的SRE,某个产品使用了该平台上的数据库,开发人员写了个非常消耗资源的SQL语句,导致整个系统夯死。那么这个问题的责任如何界定呢?其实早在业务部门选择这个数据库平台的时候,就已经被告知能够提供哪些服务,比如我的平台能够提供多少计算能力、多少IO能力,超出能力之外的要求概不负责。所以我们举的这个例子,实际上在Google通常不会发生。因为代码中会有相应的检测机制,超出服务能力的请求会被无条件干掉。不像我们在运维的时候,找出问题SQL后可怜巴巴的到处问是谁的SQL,能不能杀掉。可能在犹豫的这段时间,会因为这条SQL消耗过多的资源导致更大的问题出现。因此,Google的解决方案是牺牲个体,保护全局。而这套规则SRE早就告诉了业务平台,出现了问题,只能是业务部分自己想办法处理。这是界面划分杜绝扯皮的又一法门,所谓的阳谋,大概就是如此。

为什么这套规则,在国内比较难以落地

这段会上并没有深入讨论,纯属个人意淫。为什么国内没有形成这样的制度,开发运维各自为政呢?个人觉得有两点原因:

国内不论是底层基础架构还是上层应用软件,基本都是成熟的商业软件,比如Oracle Database、IBM Middleware,开发和运维分别因为某一个项目连接在一起,缺少前期沟通和磨合时间。类似于古时候的包办婚姻,双方缺少感情基础;

开发主要专注于业务逻辑的实现,缺少稳定性和性能方面的考虑,导致系统上线后出现各种奇葩问题。但由于对基础架构不了解,只能依赖于运维方面解决问题,长此以往,形成了运维“无限责任制”。

从这两个层面看,也能理解为什么DevOps近来才火热起来,而且是从互联网公司开始火的,因为互联网公司是自己开发做产品,开发和运维的联系天然比较紧密。传统公司随着业务定制化的增多,运维“无限责任制”又导致各种矛盾不断激化,DevOps需求也就越来越迫切。

以上只是通过会议上大家的讨论,加上个人理解而成,纰漏在所难免,如有不对的地方,还望指正。

稿源:Linux服务器维护 (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 后端存储 » Google SRE 参会总结

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录

登录

忘记密码 ?

切换登录

注册