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