赵成的运维体系管理课
赵成
蘑菇街平台技术总监
立即订阅
5576 人已学习
课程目录
已完结 48 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 带给你不一样的运维思考
免费
应用运维体系建设 (11讲)
01 | 为什么Netflix没有运维岗位?
02 | 微服务架构时代,运维体系建设为什么要以“应用”为核心?
03 | 标准化体系建设(上):如何建立应用标准化体系和模型?
04 | 标准化体系建设(下):如何建立基础架构标准化及服务化体系?
05 | 如何从生命周期的视角看待应用运维体系建设?
06 | 聊聊CMDB的前世今生
07 | 有了CMDB,为什么还需要应用配置管理?
08 | 如何在CMDB中落地应用的概念?
09 | 如何打造运维组织架构?
10 | 谷歌SRE运维模式解读
11 | 从谷歌CRE谈起,运维如何培养服务意识?
效率和稳定性最佳实践 (20讲)
12 | 持续交付知易行难,想做成这事你要理解这几个关键点
13 | 持续交付的第一关键点:配置管理
14 | 如何做好持续交付中的多环境配置管理?
15 | 开发和测试争抢环境?是时候进行多环境建设了
16 | 线上环境建设,要扛得住真刀真枪的考验
17 | 人多力量大vs.两个披萨原则,聊聊持续交付中的流水线模式
18 | 持续交付流水线软件构建难吗?有哪些关键问题?
19 | 持续交付中流水线构建完成后就大功告成了吗?别忘了质量保障
20 | 做持续交付概念重要还是场景重要?看“笨办法”如何找到最佳方案
21 | 极端业务场景下,我们应该如何做好稳定性保障?
22 | 稳定性实践:容量规划之业务场景分析
23 | 稳定性实践:容量规划之压测系统建设
24 | 稳定性实践:限流降级
25 | 稳定性实践:开关和预案
26 | 稳定性实践:全链路跟踪系统,技术运营能力的体现
27 | 故障管理:谈谈我对故障的理解
28 | 故障管理:故障定级和定责
29 | 故障管理:鼓励做事,而不是处罚错误
30 | 故障管理:故障应急和故障复盘
31 | 唇亡齿寒,运维与安全
云计算时代的运维实践 (6讲)
32 | 为什么蘑菇街会选择上云?是被动选择还是主动出击?
33 | 为什么混合云是未来云计算的主流形态?
34 | Spring Cloud:面向应用层的云架构解决方案
35 | 以绝对优势立足:从CDN和云存储来聊聊云生态的崛起
36 | 量体裁衣方得最优解:聊聊页面静态化架构和二级CDN建设
37 | 云计算时代,我们所说的弹性伸缩,弹的到底是什么?
个人成长 (5讲)
38 | 我是如何走上运维岗位的?
39 | 云计算和AI时代,运维应该如何做好转型?
40 | 运维需要懂产品和运营吗?
41 | 冷静下来想想,员工离职这事真能“防得住”吗?
42 | 树立个人品牌意识:从背景调查谈谈职业口碑的重要性
加餐 (4讲)
划重点:赵成的运维体系管理课精华(一)
划重点:赵成的运维体系管理课精华(二)
划重点:赵成的运维体系管理课精华(三)
新书 |《进化:运维技术变革与实践探索》
结束语 (1讲)
结束语 | 学习的过程,多些耐心和脚踏实地
赵成的运维体系管理课
登录|注册

11 | 从谷歌CRE谈起,运维如何培养服务意识?

赵成 2018-01-14
2016 年 10 月,谷歌云平台博客(Google Cloud Platform Blog)上更新了一篇文章,谷歌宣布了一个新的专业岗位,CRE(Customer Reliability Engineering),直译过来就是客户稳定性工程师。我看了介绍后,发现还是一个挺有意思的岗位设置,搜索之后发现,针对这个岗位国内还没有太多的解读。下面我们就来尝个鲜,一起来看一看。

CRE 产生的背景

这个岗位出现的主要背景,还是越来越多的用户选择在云上开展自己的业务,很多企业和用户将业务从原来传统的自运维 IDC 机房迁移到云上。这样做其实就是选择相信公有云平台,但同时也就放弃了对底层基础设施的把控,甚至把企业最为核心的数据也放到了云上。说简单点,就是一个公司的身家性命都交给公有云了。
虽然绝大多数的公有云都宣称自己的稳定性多么高多么好,但是我们知道实际情况并非如此。
其实,我们可以看下 Netflix,虽然业务在相对稳定的 AWS 上,但是自从在 AWS 上遇到过几次严重故障后,就开始自己做稳定性保障的功能,我们熟知的 Chaos Monkey 这只猴子就是这么来的,进而发展到后来的 Chaos Engineering 这样一整套体系。
可以看到,Netflix 秉承 Design For Faliure,从一开始就选择在变化多端且自己不可控的环境里,加强自己系统的健壮性和容错能力,而不是依赖任何云厂商的承诺。
不过,并不是任何企业都具备 Netflix 这样的技术能力把自己打造得这么稳定。所以,当云上不稳定的情况发生时,公有云客户通常是手足无措的。因为他并不了解出了什么状况,不知道是自己的问题还是云上基础设施或基础服务的问题,也不知道自己应该从哪里入手恢复业务,所以时间长了必然就会感到非常焦虑,各种不放心。

CRE 岗位的职责

CRE 出现的根本目的,就是消除客户焦虑,真正地站在客户的角度去解决问题,同时对客户进行安抚、陪伴和关怀
通常的售后支持,都是你问什么问题,我就回答什么问题,能马上解决的就马上解决,不能解决的就转到后端处理,然后让客户等着,承诺多长时间内给出答复。这种流程标准,严格执行 SLA 规范,对于一般问题还好,但要是真的出现大问题就不行了。
业务挂了,我都火烧眉毛了,你还跟个机器人一样,我问啥你说啥;或者你排查下对我说跟你没关系,让我自己再检查下,再或者转给后端处理,让我先等着,这个体验就非常差了。
所以,CRE 这个角色一定是站在客户角度解决问题。加入客户的“作战室”(War Room),和客户一起排查,问题不解决,自己不撤退;还会随时通报进展,必要的时候会将故障升级到更高的级别,寻求更专业的资源投入以共同解决;同时根据客户的不同反应进行不同方式的安抚。
CRE 还会发挥谷歌多年积累下来的非常宝贵的线上运维经验,在日常就跟客户沟通传递一些稳定性保障的知识。CRE 可以按照谷歌总结出来的类似 SRE 的标准规范,对客户线上系统进行稳定性标准评审,并给出专业的建议。如果客户同意遵守这样的标准规范执行,在后续出现故障时,CRE 就完全可以按照非常成熟的 SRE 的运作模式去协作用户处理故障,这样就会大大提升 CRE 和客户的协作效率,为故障快速处理赢得更多宝贵时间。同时 CRE 也可以发挥更大的专业作用,而不是之前的对客户系统不熟悉,空有一身绝世武功,却使不上劲。
所以,CRE 这个角色,既具备良好的专业技术能力,又有非常强的问题解决能力,同时还要具有优秀的客户沟通和关怀能力。背后还有谷歌多年的全球最佳运维实践 SRE 的经验和方法论支持,让 CRE 这个角色发挥出更加独特的作用,这一点可能是其它公有云厂商难以达到的。

从 CRE 谈谈做运维为什么要有服务心态

上面花了些篇幅对 CRE 做了一个整体的介绍。我个人的整体感受,CRE 更多的是一个服务性质的岗位,最终是要对客户的满意度负责,所以我们可以看到他的职责里面处处充满了紧贴客户需求和痛点的工作内容。
我们可能一下子达不到 CRE 这么高大上的水平,但是日常工作中我们要不断提升自己的服务意识还是很有必要的。而且我观察下来,有时候我们日常工作中出现的很多沟通问题、协作问题甚至是技术问题,都是因为服务意识不够而导致的。
我总结了一下,是不是有服务心态,表现在我们的做事方式上,就是我们是否能够站在对方的角度考虑问题、解决问题
具体怎么做,可以有很多方式,这里我给出我个人的几个建议。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《赵成的运维体系管理课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(5)

  • Li Yao
    所以在业务提需求时,要求业务同时把需求和最终目的同时提出来很重要,防止折腾半天最后发现做了大量无用功
    2018-05-25
    2
  • haormj
    其实我有一个问题,现在云计算已经成为基本资源,对于小公司来说,完全没有必要自己管理机房,直接使用各大云厂商的资源会更加的方便,也有利于为小公司节省时间和成本,我非常认同之前的一系列观点,比如从传统的运维到现在以应用为中心,现在我做的事情就是相关的内容,第一版做了一个系统出来,但是还是不太稳定,需要继续加强。以及公司自己CMDB的建设,现在还清楚的记得为了理清楚运维对象,可以从应用的生命周期出发,看了之后确实有共鸣,以及到后面的将基础资源服务化,然后才可以运维;不过对于我这里来说,各大云平台已经将自己的资源服务化,而且提供了可视化的界面,所以我这里感觉也没有必要在继续调用它的接口,将这个内容显示到公司自己的面板上,这个地方个人还是比较纠结,公司使用的云服务也不可能是单一的,比如可能因为公司业务分布,会分别选择国内和国外的云平台,到这里之后,我不清楚运维应该如何走,以应用为中心没有错,但是基础资源服务化感觉没有必要,特别期望作者可以出一篇类似基于公有云的运维应该如何搭建的文章。最后也多谢作者的分享。

    作者回复: 单从资源管理层面,云平台已经足够完善了,多云就需要有CMP这样的管理平台。

    关键是在与自身的应用体系结合时,就需要与云平台结合实现业务层面的管理,也就是我们讲的内容。

    2018-01-15
    2
  • 岑崟
    深挖诉求从日常工作的角度来说做到的难度比较大,很多业务方人员提的不是需求,直接就是一个解决方案,而运维人员听了之后往往不会去分析为啥要这样就直接开干了,业务人员达成效果后就走了,留给运维一个“隐患”,日积月累终有一天爆发了

    作者回复: 这个需要引导,需要思路上转变,管理者一定要有这个意识,然后要有耐心等着慢慢转遍。

    2018-01-25
    1
  • 宵伯特
    挖掘问题背后的真正诉求这一点经常有感同身受,不论是在日常开发还是沟通协作中,常常会以已有的问题为目标去寻找答案,结果多是走了弯路或干脆走了岔路,而业务人员也常因频繁的沟通了解了一些技术术语就提出一些所谓的技术上的问题,但是实际的需求可能毫无干系。所以在解决问题这件事情上,明确问题本身大多时候是更为重要的。

    作者回复: 这个是日常沟通中很典型很常见的低效沟通模式,耗时耗力。

    2018-01-14
    1
  • David Mao
    了解用户的原始需求很重要。
    2018-12-17
收起评论
5
返回
顶部