2016年10月,谷歌云平台博客(Google Cloud Platform Blog)上更新了一篇文章,谷歌宣布了一个新的专业岗位,CRE(Customer Reliability Engineering),直译过来就 是客户稳定性工程师。我看了介绍后,发现还是一个挺有意思的岗位设置,搜索之后发现,针对这个岗位国内还没有太多的解读。下面我们就来尝个鲜,一起来看一看。
CRE产生的背景 这个岗位出现的主要背景,还是越来越多的用户选择在云上开展自己的业务,很多企业和用户将业务从原来传统的自运维IDC机房迁移到云上。这样做其实就是选择相信公有云平 台,但同时也就放弃了对底层基础设施的把控,甚至把企业最为核心的数据也放到了云上。说简单点,就是一个公司的身家性命都交给公有云了。
虽然绝大多数的公有云都宣称自己的稳定性多么高多么好,但是我们知道实际情况并非如此。 其实,我们可以看下Netfix,虽然业务在相对稳定的AWS上,但是自从在AWS上遇到过几次严重故障后,就开始自己做稳定性保障的功能,我们熟知的Chaos Monkey这只猴子就 是这么来的,进而发展到后来的Chaos Engineering这样一整套体系。
可以看到,Netfix秉承Design For Faliure,从一开始就选择在变化多端且自己不可控的环境里,加强自己系统的健壮性和容错能力,而不是依赖任何云厂商的承诺。
不过,并不是任何企业都具备Netfix这样的技术能力把自己打造得这么稳定。所以,当云上不稳定的情况发生时,公有云客户通常是手足无措的。因为他并不了解出了什么状况,不 知道是自己的问题还是云上基础设施或基础服务的问题,也不知道自己应该从哪里入手恢复业务,所以时间长了必然就会感到非常焦虑,各种不放心。
CRE岗位的职责 CRE出现的根本目的,就是消除客户焦虑,真正地站在客户的角度去解决问题,同时对客户进行安抚、陪伴和关怀。
通常的售后支持,都是你问什么问题,我就回答什么问题,能马上解决的就马上解决,不能解决的就转到后端处理,然后让客户等着,承诺多长时间内给出答复。这种流程标准,严 格执行SLA规范,对于一般问题还好,但要是真的出现大问题就不行了。
业务挂了,我都火烧眉毛了,你还跟个机器人一样,我问啥你说啥;或者你排查下对我说跟你没关系,让我自己再检查下,再或者转给后端处理,让我先等着,这个体验就非常差了。
所以,CRE这个角色一定是站在客户角度解决问题。加入客户的“作战室”(War Room),和客户一起排查,问题不解决,自己不撤退;还会随时通报进展,必要的时候会将故障升 级到更高的级别,寻求更专业的资源投入以共同解决;同时根据客户的不同反应进行不同方式的安抚。
CRE还会发挥谷歌多年积累下来的非常宝贵的线上运维经验,在日常就跟客户沟通传递一些稳定性保障的知识。CRE可以按照谷歌总结出来的类似SRE的标准规范,对客户线上系统 进行稳定性标准评审,并给出专业的建议。如果客户同意遵守这样的标准规范执行,在后续出现故障时,CRE就完全可以按照非常成熟的SRE的运作模式去协作用户处理故障,这样 就会大大提升CRE和客户的协作效率,为故障快速处理赢得更多宝贵时间。同时CRE也可以发挥更大的专业作用,而不是之前的对客户系统不熟悉,空有一身绝世武功,却使不上 劲。
所以,CRE这个角色,既具备良好的专业技术能力,又有非常强的问题解决能力,同时还要具有优秀的客户沟通和关怀能力。背后还有谷歌多年的全球最佳运维实践SRE的经验和方法论支 持,让CRE这个角色发挥出更加独特的作用,这一点可能是其它公有云厂商难以达到的。
从CRE谈谈做运维为什么要有服务心态 上面花了些篇幅对CRE做了一个整体的介绍。我个人的整体感受,CRE更多的是一个服务性质的岗位,最终是要对客户的满意度负责,所以我们可以看到他的职责里面处处充满了紧 贴客户需求和痛点的工作内容。
我们可能一下子达不到CRE这么高大上的水平,但是日常工作中我们要不断提升自己的服务意识还是很有必要的。而且我观察下来,有时候我们日常工作中出现的很多沟通问题、协 作问题甚至是技术问题,都是因为服务意识不够而导致的。
我总结了一下,是不是有服务心态,表现在我们的做事方式上,就是我们是否能够站在对方的角度考虑问题、解决问题。 具体怎么做,可以有很多方式,这里我给出我个人的几个建议。
1. 多使用业务术语,少使用技术术语
与合作部门沟通协作,特别是对于非技术类的业务部门,尽量多使用业务语言来表达。在讨论一个需求时,如果表达的都是API、缓存、数据库、消息队列等等这些专业术语,估计 业务部门的同学肯定是跟不上我们的思路的,这样的沟通通常无法正常地进行下去,所以就会经常出现业务同学说业务的事情,技术同学说技术的事情,两边不能达成一致,矛盾就 产生了。
这里需要强调的一点是,对于绝大多数的公司来说,业务一定是最重要的,技术是实现业务功能的一种手段和方式,所以一定是从业务角度出发考虑技术解决方案,而不是从技术角度出发让业务来适配技术。
那怎么从业务角度出发呢?就是我刚说的尝试用业务语言去沟通,用对方能够听得懂的表达方式去表达你的技术观点。为了让业务人员理解你的想法,就自然会用业务的思路去思考和解决问题了。这个需要一点点改变,可以先从尝试开始。
2. 学会挖掘问题背后的真正诉求
外部提出的一个问题,可能并不一定是真正的问题,而是问题的一个解决方案。
先举个之前我遇到的例子,有个部门给我们提了一个在服务器上安装翻墙软件的需求,结果我们的工程师就照着这个需求去做了,最后发现软件怎么调都启动不了,中间还牵扯到网络同事的配合,需要检查网络上的配置,最后就差动网络设备了。
后来我就去问,为什么要安装翻墙软件呢?一问才知道,有个业务需求是需要爬取Twitter、Instagram和Facebook上一些时尚达人的时间线信息的,需要部署一个这样的应用,然 后能够对外访问,但是部署在我们机房内部发现不行(肯定不行啊),所以就建议尝试装一个翻墙软件看看是不是能访问出去。
这么一问,就发现安装翻墙软件不是真正的需求,真正的需求是能够访问到海外站点。看问题的角度不同,解决方案也就不一样了。 因为我们有公有云的海外节点,这样的需求,我们直接将应用部署在海外节点就可以了,然后从申请资源、部署上线到调测通过,30分钟搞定。
这种情况非常常见,也是日常团队协作中最容易出现的问题,很多矛盾都是因为这种原因导致的。如果按照上述不假思索的方式去做,极有可能是没有结果,或者是结果无法让人满意。如果你很努力很认真地做了很多事情,但却无法得到对方的认可,那就太令人沮丧了。
遇到类似问题,可以不着急动手做,先多问自己和对方几个问题,比如:
为什么要这样做?
谁要求做这件事情的?
这样做的目的是什么?
这样做是为了解决什么问题?
这一点其实也是站在对方角度去考虑,去思考对方要解决的问题是什么,而不是解决我们的问题。通常情况下,两三个问题后,一般就会暴露出背后最原始的那个需求了。正所谓“磨 刀不误砍柴工”,问题和背景搞清楚了,思路和方案就是顺其自然的事情了。
3. 解决问题的时候关注目标,而不是聚焦困难
我尝试写了一段话想来分享我的观点,但是读来读去感觉有点太鸡汤。所以还是上一张图,这个是我16年去腾讯交流的时候,在腾讯办公区拍到一张照片,对我启发很大。 两种不同的思考问题的方式,带给人的感受也是完全不一样的。
道理还是需要我们自己悟明白的,所以文字也好,图片也罢,期望对你也有所启发。
近些年,随着云计算技术的深入发展,公有云事业也不断拓展,运维领域的分工也在不断地精分细化,而每个细分领域对专业技术的要求也越来越高,专业的服务化程度也越来越高。我想这是一个好现象,让原来非常模糊的运维行业范畴变得越来越清晰、越来越具体。
对于我们运维来说,这样的发展既是机遇,也是挑战。一方面我们要不断提升自己的技术能力,另一方面也要注意自身服务意识的培养,让自己的能力得以发挥,创造更大的价值,获得更好的回报。
对于今天的内容你有怎样的共鸣和思考,欢迎你留言与我一起讨论。文章来源:https://www.toymoban.com/news/detail-409476.html
如果今天的内容对你有帮助,也请你分享给身边的朋友,我们下期见!文章来源地址https://www.toymoban.com/news/detail-409476.html
到了这里,关于从谷歌CRE谈起,运维如何培养服务意识?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!