一文讲透研发，SRE，运维，DevOps 的区别
很多同学，特别是刚毕业的新人，搞不清楚研发，SRE 和运维的区别，正好最近看到一篇文章，讲解的很清楚，分享给大家。
转载信息如下：
作者：Bytebass
链接：https://juejin.cn/post/7130867073609121822
研发，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，DevOps 的概念一出来，不少传统运维/研发团队就像抓到根救命稻草，马上披上 SRE，DevOps 马甲，但做的事情其实一点没变。就像现在许多公司虽然把 KPI 改成 OKR ，但绩效考核方式还是一模一样，所以搞的大家云里雾里。
最后再小结一下这里面容易混淆的几个点：
搞不清楚 SRE 和运维工种之间的区别。简单理解，SRE 是会写代码的运维，是传统运维的升级版。 搞不清楚 DevOps 是体系还是工种。这个取决于上下文，DevOps 起初代表的是一套体系，融合研发和运维的职能。这个体系下可能研发和 SRE 同时存在，也可能只有研发存在。后一种情况就也会用体系的名字，也就是 DevOps 来表示工种，所谓的 DevOps 工程师。毕竟如果一个足球阵型里模糊了前锋，中场，后卫这些位置边界，那阵型名字就可以叫自由阵，所有球员都被称作自由人也很合理。 当 DevOps 作为工种理解时，搞不清楚和 SRE 的区别。简单理解，DevOps 是做运维的研发，SRE 是做研发的运维。
以上就是本文的全部内容，如果觉得还不错的话欢迎点赞，转发和关注，感谢支持。
推荐阅读：