Google SRE 之后的 CRE,一起来看看吧

阅读数:1 2020 年 3 月 18 日 20:12

Google SRE之后的CRE,一起来看看吧

去年 10 月份,也就是 2016 年 10 月份,Google Cloud Platform Blog 上更新了一篇文章,Google 宣布了一个新的专业岗位,CRE,Customer Reliability Engineering,直译过来就是客户稳定性工程师,按说去年的文章也不是什么新闻了,不过看到国内还没有专门的文章介绍,我就尝个鲜简单分享下。

CRE 产生的背景

这个岗位出现的主要背景,还是越来越多的用户选择在云上开展自己的业务,甚至是很多的企业和用户从原来传统的自运维的 IDC 机房,将业务迁移到云上,这样做其实就是选择相信公有云平台,但是同时也就放弃了对底层基础设施的把控,甚至把企业最为核心的数据也放到了云上,说简单点就是,一个公司的身家性命都交给公有云了。

从 Google 多年的调研和了解看,虽然绝大多数的公有云都宣称自己的稳定性多么高多么好,但是实际情况并非如此,而绝大多数企业级用户也因为自己的业务在云上,所说始终都有非常强烈的焦虑感。

其实,我们可以看下 Netflix,虽然业务在 AWS 上,但是自打在 AWS 上遇到过几次严重故障后,就开始自己做稳定性保障的功能,我们熟知的 Chaos Monkey 这只猴子就是这么来的,进而发展到后来的 Chaos Engineering 这样一整套体系。

可以看到,Netflix 秉承的 Design For Faliure,自打一开始就选择在变化多端且自己不可控的环境下,加强自己系统的健壮性和容错度。

但是不是任何企业都具备 Netflix 这样的技术能力把自己打造的这么稳定,所以在云上不稳定的情况发生时,通常公有云客户是手足无措的,因为他并了解出了什么状况,不知道是自己的问题还是云上基础设施和基础服务的问题,也不知道自己应该要从哪里入手恢复业务,所以时间长了必然会非常地焦虑,十分地焦虑,各种的不放心。

Google CRE 岗位的职责

所以,CRE 出现的根本目的,就是消除客户焦虑,真正的站在客户的角度去解决问题,同时对客户进行安抚、陪伴和关怀。

通常的售后支持,都是你问什么问题,我就回答什么问题,能马上解决的就马上解决,不能解决的就转到后端处理,然后让客户等着,承诺多长时间内给出答复。流程标准,SLA 执行严格规范,对于一般问题还好,真要是出现大问题,业务挂了,我都火烧眉毛了,你还跟个机器人一样,我问啥你说啥,或者你排查下对我说跟你没关系,让我自己再检查下,再或者转给后端处理,你先等着,这个体验就非常差了。

所以,CRE 这个角色一定是站在客户角度解决问题,加入客户的 War Room,帮助客户一起排查,问题不解决,自己也不会撤,同时还会随时通报进展,必要的时候会将故障升级到更高的级别,寻求更专业的资源投入共同解决,同时根据客户的不同反应进行不同方式的安抚。

同时,CRE 还会发挥 Google 多年积累下来的非常宝贵的线上运维经验,在日常就跟客户沟通传递一些稳定性保障的知识。CRE 还可以按照 Google 总结出来的类似 SRE 的标准规范,对客户线上系统进行稳定性标准的评审,并给出专业的建议,如果客户同意遵守这样的标准规范执行,在后续出现故障时,CRE 就完全可以按照非常成熟的 SRE 的运作模式去协作用户处理故障,这样就会大大提升 CRE 和客户的协作效率,为故障快速处理赢得更多宝贵的时间,同时 CRE 也可以发挥更大的专业作用,而不是之前对客户系统不熟悉,空有一身绝世武功,却使不上劲。

所以,CRE 这个角色,既具备良好的专业技术能力,又有非常强的问题解决能力,同时还要具有优秀的客户沟通和关怀能力。而且背后还有 Google 多年的全球最佳运维实践——SRE 的经验和方法论支持,也可以让 CRE 这个角色发挥出更加独特的作用,这一点可能是其它一般的公有云厂商难以达到的。

最后

随着近些年云计算技术的深入发展,和公有云事业的不断拓展,运维领域的分工也在不断的精分细化,而每个细分领域的专业技术要求也越来越高,我想这是一个好的现象,让原来非常模糊的运维行业范畴,变得越来越清晰,越来越具体,也让我们从事运维行业的同事有了更多的选择。

及时了解业界的技术发展趋势非常重要,更加有利于我们掌控自己的职业发展方向和优势技能的发挥。

本文转载自成哥的世界公众号。

原文链接: https://mp.weixin.qq.com/s/dYBjPyMAvm1bEao4SbRddw

评论

发布