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成员不断努力。