研发，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 年提出来的。这个工种诞生的背景有这么几个：
- 像 Google 这样大规模线上服务简单，服务稳定性要求高。
- 研发通常更关注把货色做进去上线，但对于后续线上的保护少一个心眼。而且往往为了尽早上线，会疏忽上线后的稳定性问题。
传统运维须要转型。
1 和 2 促使须要一个专门的工种，而 3 则提供了 SRE 的稳固起源。因为 SRE 是在研发和运维之后呈现的工种，所以第一批的 SRE 就是从那两个工种里转型而来。又因为 SRE 的很大一部分工作还是保障业务稳定性，所以从运维转型而来的占大多数。
简略来说，SRE 是传统运维的升级版，区别于传统运维的中央：
- 不再负责和物理设施打交道，这部分交给云服务了。
- 通过体系化的伎俩来保障业务稳定性，比方构建自动化工具，和研发团队一起制订 SLO (Service Level Objective)，让单方有能够一起恪守的契约，来保障服务的衰弱度。
- 工程研发能力。SRE 也能够说是具备研发能力的运维，有些 SRE 还具备很强的研发能力，比方监控软件 Prometheus 的作者就曾是 Google 的 SRE。
上图描述了研发 (Dev)，SRE，运维 (Ops) 的穿插关系。研发和运维基本上是没有交加的，而 SRE 就像后面说的是具备研发能力的运维，但整体还是更偏运维一点。
DevOps
DevOps 是一种体系，后面提到研发 Dev 和运维 Ops 这两个工种是没有交加的，DevOps 就是要把这两个工种交融在一起，更确切的讲，是要让 Dev 去承当 Ops 的工作。在 DevOps 的体系里，是没有传统运维这个角色的，运维的职能可能由研发和 SRE 独特分担，也有可能由研发单独承当，连 SRE 角色都没有。后一种状况下，研发等于变成了全干工程师。
容易混同的点
搞不清楚 SRE 和运维工种之间的区别。简略了解，SRE 是会写代码的运维，是传统运维的升级版。
搞不清楚 DevOps 是体系还是工种。这个取决于上下文，DevOps 起初代表的是一套体系，交融研发和运维的职能。这个体系下可能研发和 SRE 同时存在，也可能只有研发存在。后一种状况就也会用体系的名字，也就是 DevOps 来示意工种，所谓的 DevOps 工程师。毕竟如果一个足球阵型里含糊了前锋，中场，后卫这些地位边界，那阵型名字就能够叫自在阵，所有球员都被称作自由人也很正当。
当 DevOps 作为工种了解时，搞不清楚和 SRE 的区别。简略了解，DevOps 是做运维的研发，SRE 是做研发的运维。
大节
想写这篇文章，是有同学给我发了张朋友圈截图，过后一看到不规范的大小写我的强迫症就又犯了。
不过转念一想这几个概念的确容易混同。因为当年 SRE，DevOps 的概念一进去，不少传统运维 / 研发团队就像抓到根救命稻草，马上披上 SRE, DevOps 马甲，但做的事件其实一点没变。就像当初许多公司尽管把 KPI 改成 OKR，但绩效考核形式还是截然不同，所以搞的大家云里雾里。说到 OKR，呼兰的段子解释得特地好。
笔者写不了段子，只能尝试用文字加配图来解释一下。如果还是只知其一; 不知其二，也不要焦急，接下来笔者会持续开展研发，SRE，DevOps 之间的故事，来进一步论述他们各自的职责和撕扯合作，后续也还会引入新的角色退出剧情（运维因为曾经快出局了，就不多说了）。
💡 你能够拜访官网：https://www.bytebase.com/，收费注册云账号，立刻体验 Bytebase。