基于聊天讨论
最近，关于 DevOps 和 SRE 的定义爆发了真正的争论。
尽管事实上，从很多方面来说，关于这个话题的讨论已经让我（包括我自己）感到紧张，但我决定将我对这个话题的看法带到哈布拉社区的法庭上。 有兴趣的朋友，欢迎关注猫。 并让一切重新开始！
史前
因此，在古代，软件开发人员和服务器管理员团队是分开居住的。 第一个成功地编写了代码，第二个对第一个使用了各种热情、深情的话语，设置了服务器，定期与开发人员联系并收到全面的响应“一切都在我的机器上运行”。 业务正在等待软件，一切都闲置了，定期出现故障，每个人都很紧张。 尤其是那个为这一切乱七八糟买单的人。 辉煌的灯时代。 好吧，您已经知道 DevOps 从何而来。
DevOps 实践的诞生
然后严肃的人过来说——这不是一个行业，你不能那样工作。 他们引入了生命周期模型。 例如，这里是 V 模型。
那么我们看到了什么？ 企业有了一个概念，架构师设计解决方案，开发人员编写代码，然后就失败了。 有人以某种方式测试产品，有人以某种方式将其交付给最终用户，而在这个奇迹模型的输出的某个地方，坐着一位孤独的商业客户，等待着海边承诺的天气。 我们得出的结论是，我们需要能够建立这一流程的方法。 我们决定创建实践来实施它们。
关于实践是什么的抒情题外话
我所说的实践是指技术与纪律的结合。 一个例子是使用 terraform 代码描述基础设施的实践。 纪律是如何用代码描述基础设施，它在开发人员的头脑中，而技术就是地形本身。
他们决定将其称为 DevOps 实践 - 我认为他们的意思是从开发到运营。 我们想出了各种聪明的办法——CI/CD 实践、基于 IaC 原则的实践，数以千计。 接下来，开发人员编写代码，DevOps 工程师将代码形式的系统描述转换为工作系统（是的，不幸的是，代码只是一个描述，而不是系统的体现），交付继续，等等。 昨天的管理员掌握了新的实践，自豪地接受了 DevOps 工程师的再培训，一切都从那里开始。 有晚上，也有早晨……抱歉，不是从那里开始的。
感谢上帝，一切不再美好
一切一平静下来，各种狡猾的“方法论者”开始写厚厚的关于DevOps实践的书籍，关于臭名昭著的DevOps工程师是谁、DevOps是一种生产文化的争议又悄然爆发，不满情绪再次出现。 突然发现软件交付绝对是一项不平凡的任务。 每个开发基础设施都有自己的堆栈，在某个地方你需要组装它，在某个地方你需要部署环境，这里你需要Tomcat，这里你需要一种狡猾而复杂的方式来启动它——总的来说，你的头很晕。 奇怪的是，问题主要出在流程的组织上——这种交付功能就像瓶颈一样，开始阻碍流程。 此外，没有人取消行动。 在V模型中看不到，但右侧仍然有整个生命周期。 因此，有必要以某种方式维护基础设施、监控监控、解决事件以及处理交付。 那些。 一只脚同时涉足开发和运营 - 突然变成了开发和运营。 然后是对微服务的普遍炒作。 有了他们，本地机器的开发开始转移到云端——尝试在本地调试一些东西，如果有数十个、数百个微服务，那么持续交付就成为一种生存手段。 对于一家“规模不大的公司”来说这还可以，但是仍然如此吗？ 谷歌呢？
Google 的 SRE
谷歌来了，吃了最大的仙人掌并决定 - 我们不需要这个，我们需要可靠性。 并且必须管理可靠性。 我决定我们需要能够管理可靠性的专家。 我称他们为SR工程师，并说，就这样吧，照常做好吧。 这里是 SLI，这里是 SLO，这里是监控。 他还涉足运营。 他称之为“可靠的 DevOps”SRE。 一切似乎都很好，但谷歌可以承受一个肮脏的黑客攻击——对于 SR 工程师的职位，雇佣那些合格的开发人员，并且做了一些功课并了解工作系统的功能。 而且，谷歌本身在雇佣这样的人方面也存在问题——主要是因为它在这里与自己竞争——有必要向某人描述业务逻辑。 交付被分配给发布工程师，SR——工程师管理可靠性（当然不是直接管理，而是通过影响基础设施、改变架构、跟踪变化和指标、处理事件）。 不错，你可以 。 但是，如果您不是 Google，但可靠性仍然是一个问题怎么办？
DevOps 理念的发展
就在此时，Docker 出现了，它是从 lxc 发展而来的，然后是 Docker Swarm 和 Kubernetes 等各种编排系统，DevOps 工程师长叹了一口气——实践的统一简化了交付。 它将其简化到了甚至可以将交付外包给开发人员的程度——什么是deployment.yaml。 容器化解决了这个问题。 CI/CD 系统的成熟度已经达到了编写一个文件就可以了——开发人员可以自己处理。 然后我们开始讨论如何与……或至少与某人一起创建我们自己的 SRE。
SRE 不在 Google 上
好吧，好吧，我们交付了交付，似乎我们可以松口气，回到过去的美好时光，当时管理员观察处理器负载，调整系统，并安静地从杯子里啜饮一些难以理解的东西……停下来。 这不是我们开始一切的原因（这很遗憾！）。 突然发现，在谷歌的方法中，我们可以轻松地采用优秀的实践——重要的不是处理器负载，也不是我们更换磁盘的频率，也不是优化云中的成本，但业务指标同样臭名昭著。 SLx。 没有人从他们手中取消基础设施管理，他们需要解决事件、定期值班，并且通常掌握业务流程。 伙计们，开始一点一点地编程，达到一个好的水平，Google 已经在等着你了。
总结一下。 突然，你却已经读腻了，迫不及待地在文章评论中吐槽写信给作者。 DevOps 作为一种交付实践一直如此，将来也将如此。 而且它不会去任何地方。 SRE 作为一组操作实践使这种交付非常成功。
来源： habr.com