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