极客时间已完结课程限时免费阅读

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

11 | 从谷歌CRE谈起，运维如何培养服务意识？-极客时间

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

2018-01-14 赵成 来自北京
《赵成的运维体系管理课》
课程介绍

讲述：黄洲君

时长10:18大小4.71M

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 这么高大上的水平，但是日常工作中我们要不断提升自己的服务意识还是很有必要的。而且我观察下来，有时候我们日常工作中出现的很多沟通问题、协作问题甚至是技术问题，都是因为服务意识不够而导致的。
我总结了一下，是不是有服务心态，表现在我们的做事方式上，就是我们是否能够站在对方的角度考虑问题、解决问题。
具体怎么做，可以有很多方式，这里我给出我个人的几个建议。
1. 多使用业务术语，少使用技术术语
与合作部门沟通协作，特别是对于非技术类的业务部门，尽量多使用业务语言来表达。在讨论一个需求时，如果表达的都是 API、缓存、数据库、消息队列等等这些专业术语，估计业务部门的同学肯定是跟不上我们的思路的，这样的沟通通常无法正常地进行下去，所以就会经常出现业务同学说业务的事情，技术同学说技术的事情，两边不能达成一致，矛盾就产生了。
这里需要强调的一点是，对于绝大多数的公司来说，业务一定是最重要的，技术是实现业务功能的一种手段和方式，所以一定是从业务角度出发考虑技术解决方案，而不是从技术角度出发让业务来适配技术。
那怎么从业务角度出发呢？就是我刚说的尝试用业务语言去沟通，用对方能够听得懂的表达方式去表达你的技术观点。为了让业务人员理解你的想法，就自然会用业务的思路去思考和解决问题了。这个需要一点点改变，可以先从尝试开始。
2. 学会挖掘问题背后的真正诉求
外部提出的一个问题，可能并不一定是真正的问题，而是问题的一个解决方案。
先举个之前我遇到的例子，有个部门给我们提了一个在服务器上安装翻墙软件的需求，结果我们的工程师就照着这个需求去做了，最后发现软件怎么调都启动不了，中间还牵扯到网络同事的配合，需要检查网络上的配置，最后就差动网络设备了。
后来我就去问，为什么要安装翻墙软件呢？一问才知道，有个业务需求是需要爬取 Twitter、Instagram 和 Facebook 上一些时尚达人的时间线信息的，需要部署一个这样的应用，然后能够对外访问，但是部署在我们机房内部发现不行（肯定不行啊），所以就建议尝试装一个翻墙软件看看是不是能访问出去。
这么一问，就发现安装翻墙软件不是真正的需求，真正的需求是能够访问到海外站点。看问题的角度不同，解决方案也就不一样了。
因为我们有公有云的海外节点，这样的需求，我们直接将应用部署在海外节点就可以了，然后从申请资源、部署上线到调测通过，30 分钟搞定。
这种情况非常常见，也是日常团队协作中最容易出现的问题，很多矛盾都是因为这种原因导致的。如果按照上述不假思索的方式去做，极有可能是没有结果，或者是结果无法让人满意。如果你很努力很认真地做了很多事情，但却无法得到对方的认可，那就太令人沮丧了。
遇到类似问题，可以不着急动手做，先多问自己和对方几个问题，比如：
为什么要这样做？
谁要求做这件事情的？
这样做的目的是什么？
这样做是为了解决什么问题？
这一点其实也是站在对方角度去考虑，去思考对方要解决的问题是什么，而不是解决我们的问题。通常情况下，两三个问题后，一般就会暴露出背后最原始的那个需求了。正所谓“磨刀不误砍柴工”，问题和背景搞清楚了，思路和方案就是顺其自然的事情了。
3. 解决问题的时候关注目标，而不是聚焦困难
我尝试写了一段话想来分享我的观点，但是读来读去感觉有点太鸡汤。所以还是上一张图，这个是我 16 年去腾讯交流的时候，在腾讯办公区拍到一张照片，对我启发很大。
两种不同的思考问题的方式，带给人的感受也是完全不一样的。
道理还是需要我们自己悟明白的，所以文字也好，图片也罢，期望对你也有所启发。
近些年，随着云计算技术的深入发展，公有云事业也不断拓展，运维领域的分工也在不断地精分细化，而每个细分领域对专业技术的要求也越来越高，专业的服务化程度也越来越高。我想这是一个好现象，让原来非常模糊的运维行业范畴变得越来越清晰、越来越具体。
对于我们运维来说，这样的发展既是机遇，也是挑战。一方面我们要不断提升自己的技术能力，另一方面也要注意自身服务意识的培养，让自己的能力得以发挥，创造更大的价值，获得更好的回报。
对于今天的内容你有怎样的共鸣和思考，欢迎你留言与我一起讨论。
如果今天的内容对你有帮助，也请你分享给身边的朋友，我们下期见！
分享给需要的人，Ta购买本课程，你将得18元
生成海报并分享

赞 9

提建议

© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
上一篇
10 | 谷歌SRE运维模式解读
下一篇
12 | 持续交付知易行难，想做成这事你要理解这几个关键点
 写留言

精选留言(11)

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

    作者回复: 单从资源管理层面，云平台已经足够完善了，多云就需要有CMP这样的管理平台。 关键是在与自身的应用体系结合时，就需要与云平台结合实现业务层面的管理，也就是我们讲的内容。

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

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

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

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

    1
  • 永涛
    2022-01-23
    公有云厂商驻场支持，有点像cre的服务角色了。还有一些能力强的全栈工程师，也会帮小公司去看各种问题，也有点这种感觉。
  • 韩伟
    2021-11-04
    沟通时多用业务术语。 挖掘问题背后的这正诉求。 解决问题是关注目标，不要聚焦困难。 以上三点总结的很到位，真的是运维人员应该牢记的三句话。
    1
  • KANE
    2021-10-26
    客户的投诉，也是SRE负责处理吗
  • 口十士心草下央
    2020-10-12
    1.思维转变，从客户角度着想 2.获取客户真正的诉求，从根本上解决问题 3.目标导向

    作者回复: 总结的很好

    1
  • 符亮
    2020-07-21
    学习了，个人觉得，目标与困难这个图有点偏颇，困难与目标客观存在，盯紧了目标不意味着困难度降低。解决困难所需的人力，时间，资金成本跟达成目标后预期的收益要做个平衡吧

    作者回复: 我想这张图想要表达的是，当我们看到的是目标时，想到的可能就更多的是方法，如果都是困难，看到的就都是问题。 当然，你说的要平衡人力、时间和资金等等方面的成本，也是正确的，思考问题，是要全面综合来看。

    共 2 条评论
  • 技术修行者
    2020-05-28
    CRE 出现的根本目的，就是消除客户焦虑，真正地站在客户的角度去解决问题，同时对客户进行安抚、陪伴和关怀。 CRE 这个角色，既具备良好的专业技术能力，又有非常强的问题解决能力，同时还要具有优秀的客户沟通和关怀能力。 挖掘问题背后的真正诉求，关注目标而非困难。 这些需要我们在工作思维上做升级，才能更适应不断变化的环境。
    展开

    作者回复: 就像你说的，以终为始，要关注最终用户和客户的体验，就要为他们的指标负责。

  • David Mao
    2018-12-17
    了解用户的原始需求很重要。