研发，SRE ，运维是工种，而 DevOps 是体系。如果拿足球来打比方，研发，SRE ，运维对应的就是前锋，中场，后卫这样的位置，而 DevOps 则是诸如 4-3-3 这样的阵型。
 

研发

也叫研发工程师，工程师，Software Engineer (SWE)，Software Developer 或者简称 Developer (Dev)。主要职责是写代码，实现软件业务功能。比如打车功能就是研发工程师用代码实现的。研发主要和代码打交道。
 

运维

Operations (Ops), Production Engineer (PE)。主要负责机房管理，装机，网络，监控报警，故障应急。早期运维很大比例的工作是和物理机器设备打交道，需要大量的手动操作，操作风险也很高，后来逐渐引入软件或者自己写一些脚本，代码来自动化工作。近 10 多年随着云服务逐渐取代物理机，传统运维的职能被大幅度缩减，成为了一个逐渐要消亡的工种。
 

SRE

Site Reliability Engineer (SRE)，一般不翻译 (线上稳定性保障工程师？)。这是由 Google 在 2003 年提出来的。这个工种诞生的背景有这么几个：

1. 像 Google 这样大规模线上服务复杂，服务稳定性要求高。

2. 研发通常更关注把东西做出来上线，但对于后续线上的维护少一个心眼。而且往往为了尽早上线，会忽略上线后的稳定性问题。

3. 传统运维需要转型。

1 和 2 促使需要一个专门的工种，而 3 则提供了 SRE 的稳定来源。因为 SRE 是在研发和运维之后出现的工种，所以第一批的 SRE 就是从那两个工种里转型而来。又因为 SRE 的很大一部分工作还是保障业务稳定性，所以从运维转型而来的占大多数。

简单来说，SRE 是传统运维的升级版，区别于传统运维的地方：

1. 不再负责和物理设备打交道，这部分交给云服务了。

2. 通过体系化的手段来保障业务稳定性，比如构建自动化工具，和研发团队一起制定 SLO (Service Level Objective)，让双方有可以一起遵守的契约，来保证服务的健康度。

3. 工程研发能力。SRE 也可以说是具备研发能力的运维，有些 SRE 还具备很强的研发能力，比如监控软件 Prometheus 的作者就曾是 Google 的 SRE。

上图描绘了研发 (Dev)，SRE，运维 (Ops) 的交叉关系。研发和运维基本上是没有交集的，而 SRE 就像前面说的是具备研发能力的运维，但整体还是更偏运维一点。
 

DevOps

DevOps 是一种体系，前面提到研发 Dev 和运维 Ops 这两个工种是没有交集的，DevOps 就是要把这两个工种融合在一起，更确切的讲，是要让 Dev 去承担 Ops 的工作。在 DevOps 的体系里，是没有传统运维这个角色的，运维的职能可能由研发和 SRE 共同分担，也有可能由研发独自承担，连 SRE 角色都没有。后一种情况下，研发等于变成了全干工程师。
 

容易混淆的点

1. 搞不清楚 SRE 和运维工种之间的区别。简单理解，SRE 是会写代码的运维，是传统运维的升级版。

2. 搞不清楚 DevOps 是体系还是工种。这个取决于上下文，DevOps 起初代表的是一套体系，融合研发和运维的职能。这个体系下可能研发和 SRE 同时存在，也可能只有研发存在。后一种情况就也会用体系的名字，也就是 DevOps 来表示工种，所谓的 DevOps 工程师。毕竟如果一个足球阵型里模糊了前锋，中场，后卫这些位置边界，那阵型名字就可以叫自由阵，所有球员都被称作自由人也很合理。

3. 当 DevOps 作为工种理解时，搞不清楚和 SRE 的区别。简单理解，DevOps 是做运维的研发，SRE 是做研发的运维。
    

小节

想写这篇文章，是有同学给我发了张朋友圈截图，当时一看到不标准的大小写我的强迫症就又犯了。

不过转念一想这几个概念确实容易混淆。因为当年 SRE，DevOps 的概念一出来，不少传统运维/研发团队就像抓到根救命稻草，马上披上 SRE,  DevOps 马甲，但做的事情其实一点没变。就像现在许多公司虽然把 KPI 改成 OKR ，但绩效考核方式还是一模一样，所以搞的大家云里雾里。说到 OKR，呼兰的段子（https://www.bilibili.com/video/BV163411w7LN）解释的特别好。

笔者写不了段子，只能尝试用文字加配图来解释一下。如果还是一知半解，也不要着急，接下来笔者会继续展开研发，SRE，DevOps 之间的故事，来进一步阐述他们各自的职责和撕扯协作，后续也还会引入新的角色加入剧情 (运维因为已经快出局了，就不多说了)。