关于CRE

2016年10月份,Google Cloud Platform Blog上更新了一篇文章,Google宣布了一个新的专业岗位,CRE,Customer Reliability Engineering,客户稳定性工程师。

大意如下

CRE使命:

创建Google和Google云平台客户之间的共同运营命运,让用户更好地控制委托给我们的关键应用程序,并分享比金钱更重要的命运。

主要职责:

减少顾客的焦虑:引发顾客焦虑 - > 0

概念定义:

焦虑= 1 /可靠性

应用程序的可靠性是两件事的产物:

  • 云提供商的可靠性 (负责人:SRE)
  • 应用程序的设计,代码和操作中固有的可靠性 (现状:负责人:用户自己+一本云厂商提供的白皮书)

为提高整体可靠性,除了有稳定的云平台外,还需要协助应用程序自身也足够稳定,Google采用CRE+SRE的方式和标准来协助客户提升稳定性

价值观:

公司很时髦地告诉客户“我们在一起”,但他们通常不会扮演这个角色。 真正“在一起”的人要彼此负责,彼此承担相互责任。他们作为一个团队一起工作,实现共同目标,分享比他们之间传递的美元更大的命运。 用新的社会契约来降低焦虑,当然,这不是利他主义。这只是一个好的生意——这些原则和做法是客户与Google保持联系的强烈动机。这是一种建立在人际关系上的亲和力,而不是技术锁定。

这是双赢策略,除了客户稳定性提升、焦虑降低、客户联系得以更好保持外,平台方也将得到: “通过将固有的可靠性引入关键应用,我们还可以提高我们平台的实用可靠性。这反过来又让我们更快地创新(我们真的很喜欢这样做)。”


听起来很不错,那么CRE这类角色对普通公司内部云计算小组有帮助吗? 我觉得是有一些的,当技术团队规模做大,且非烟囱式组织结构,就一定会出现底层平台和上层应用技术之间的隔阂,开发上线不再围着运维,也不是页面操作调用脚本,而是隔着一个页面进行:容器化、镜像仓库、埋探针、做健康检查、prestart、PV挂载等等诸多繁杂操作,在缺乏当面沟通协同的情况下,不可避免的导致使用人员的焦虑,如果再出现几次故障,则信任度大大降低,几次投诉后,云平台的年度绩效可能就没了……

所以在企业内的云平台CRE我觉得做几个:

  • 对内,整合所在云平台及周边资源
  • 对外,面向核心业务方,提供稳定性保障方案

需强调的是

  • CRE不是内部的云产品售前或售后人员,稳定性保障是核心工作,产品基本功能的使用培训不在范畴之内。
  • CRE会尽量与内部云产品保持一致,将能力对外输出建立整体优势,但不代表必须任何项目或应用都必须使用已有产品,一切以稳定性为第一要务,如产品功能模块未能符合稳定性要求,可拒绝对核心用户提供。

总结

  • 对公司,我觉得CRE是缰绳,是拉住技术创新这匹野马的一个缰绳,确保技术无论怎么折腾,应用的整体稳定性必须得到保证。当新技术暂时无法很好满足业务稳定性需求时,哪怕是用最原始的方式也应满足业务,这样一方面降低业务压力,另一方面也给技术创新留下空间余地。而不是各说各话导致两败俱伤。
  • 对团队,CRE是市场和技术的缓和剂,当市场上招不到合适数量质量的SRE,但又有强烈需求时,由具有一定运维、开发经验的人担任CRE,面向业务提供力所能及的稳定性保障服务,可短暂缓解这一矛盾。
  • 对个人,CRE也是一把标尺,衡量每个人的技术水准和经验程度,以SRE为目标,激励CRE成员不断努力。