周末和硅谷某些厂商聊了一下 DEVOPS 和 DEV ONCALL。他们觉得苦不堪言，但是这也是 DEVOPS 自己作出来的

[outdoorlife]

本来很多告警是 OPS 处理的，等 OPS 处理不了才会上升到 DEV 那边去

但是 DEVOPS 们都以为自己全知又全能，在干掉了 OPS 后，自己把 ONCALL 权责也接了过去，在搞了二三年后发现这事情很苦，但是又不愿意回到公司有 OPS 这个工种上去。

那责任与权益是对等的，你既然不想要 OPS ，就必须自己干 OPS 的活。

所以讨论这个话题的时候 Google 的表示，你们自己活该。因为他们有 SRE

[plko345]

devops 不就包含 ops 吗？我记得 sre 也是归类到 devops 的一个子集吧

[zhleonix]

搞掉他人工作的报应，直接干掉 ops 就只有卷卷们自己折寿了。

[lhg1397]

sre 和 devops 怎么定义区分的？ 有 sre 还需要 devops 么？

[konakona]

怎么感觉这话说的有些莫名其妙-，，-
还是说我应该理解为现在的 devops 比较浅，只是实现了 CICD ，但对于偏 ops （运维）的部分知之甚少，导致都是 dev 在解决 ops 的专业问题，从而变成了 24 oncall ？

那我会觉得这是公司岗位职责范围和技术规划的问题。与卷可能没有关系？

[konakona]

@lhg1397 可以理解为 devops 中的 dev 单独细分出一个 Site Reliability Engineering （网站稳定性工程师）的岗位。

就是岗位细分了呗。

那我会觉得这样说 devops 的 24oncall 是该 的说法很奇怪啊！！

[kaikai5601]

莫名其妙，devops 和 sre 的作用就是减少事故，提升效能，如果没有这些岗位，ops 很多问题都处理不了，都是人工处理，天天上升到 dev 你愿意？

[libook]

我一直觉得 Ops 、DevOps 、SRE 是三种不同的工作内容，只不过在很多公司一个岗位身兼多项工作，我甚至见过测试工程师兼任做 DevOps 。

Ops 要时刻盯着系统运行状态，要对异常进行预警、发现、处置； DevOps 要面向开发工作提供基础支持和设施，能自动化的都自动化，让开发人员把精力尽可能集中在开发工作本身上面； SRE 要测试和设计方案，以使得系统不出故障，以及在出故障后在尽可能短的时间内恢复。各种职能之间是有交叉地带的，职责界限如何划分，各职责如何协调，需要根据实际情况来定的。

有很多团队其实并不清楚一些新兴的职能为什么出现、用于解决什么问题，只是看大厂有就跟风，不过按 Hype Cycle 来看这挺正常的，有很多人凑热闹踩坑，一个概念才可以在行业内积累不少结论，促进人们科学地运用。
只是主题里的这些概念在硅谷还没有真正做到成熟，我是没想到的。

[Vinceeeent]

我以为 devops 是开发运维系统的，可以让整套运维流程更智能化，其中包括 CI CD 系统、监控系统、日志系统等等的开发或二次开发，当然还包括一些预警的自动处理，甚至引入机器学习或深度学习来更智能的处理这些事情。
系统解决不了的事情，自然转到 ops 那里去了，ops 解决不了的，再联系业务开发来一起处理。
完全不需要运维，开发人员业务运维一手抓的话，那自然苦逼。运维看着上线下线简单，稍微深入一点其实也是一套蛮复杂的工作系统。