最近，这类广告泛滥了互联网。 尽管薪水令人愉悦，但内心却写着一个野蛮的异端，这让我们感到尴尬。 最初，我们假设可以将“ DevOps”和“工程师”用一个词粘在一起，然后随机生成一些需求列表，其中一些需求可以从系统管理员的空缺中清楚地复制出来。
在本文中，我想谈一点关于我们如何达到真正的DevOps以及如何处理它的观点。
可以通过各种可能的方式谴责这种空缺，但事实仍然存在：其中有很多，这就是目前市场的运作方式。 我们召开了一次开发会议，并公开宣布：“ DevOops-不适合DevOps工程师使用。” 在这里，对于许多人来说，这似乎很奇怪和疯狂：为什么人们在进行完全商业化的活动时会与市场竞争。 我们现在将解释所有内容。
关于文化和过程
首先，DevOps不是工程学科。 一切始于这样一个事实，即历史上确定的角色划分对产品质量无济于事。 当程序员仅编程但不希望听到有关测试的任何信息时，该软件会布满错误。 如果管理员对软件的编写方式和编写方式一无所知，那么支持就会变成地狱。
例如， 著名的Google SRE图书开始于对sysadmin和SRE-shny服务管理方法之间的区别的描述。 作为DORA调查的一部分，进行了有趣的研究-可以看出，最好的开发人员以某种方式设法比每小时一次更快地将新更改部署到生产中。 他们用手进行的测试不超过10％（从去年的DORA中可以看出）。 他们是如何做到的？ 报告标题之一说：“ Excel或死”。 有关测试方面这些统计信息的详细讨论，您可以转到Baruch Sadogursky 的主题演讲“我们有DevOps。 让我们在其他会议Heisenbug中解雇所有测试人员 。
“当同志们没有达成协议时，
效果不好，
它不会从面粉中出来，只有面粉。
曾经是天鹅，巨蟹和派克……”
您如何看待，Web程序员的哪个部分真正了解在产品上操作其应用程序的条件？ 他们中有多少人会去找管理员，并试图弄清楚基数下降时会发生什么？ 谁会去测试人员那里，问他们如何正确编写测试？ 而且仍然有安全警卫，产品经理和一群人。
DevOps的总体思路是在角色和部门之间建立交互。 首先，这不是通过一些巧妙调整的软件来实现的，而是通过交流的实践来实现的。 DevOps与文化，实践，方法论和过程有关。 没有这样的工程专业可以回答这些问题。
恶性循环
那么，“开发工程”的学科是从哪里来的呢？ 我们有一个版本！ DevOps的想法被证明是很好的-如此之好以至于它们成为成功的受害者。 围绕这个话题，一些气氛非常特殊的泥泞的招募者和人口贩子开始旋转。
想象一下：昨天您在希姆基（Khimki）做了沙瓦玛（Shawarma），今天您已经是个大人物，高级招聘人员。 搜索和选择候选人的全过程，并非易事，您需要了解。 假设部门负责人说：在X中找到一名专家。我们将X分配为“工程师”一词，重点是帽子。 需要Linux吗？ 好吧，它绝对是一名Linux工程师，您需要DevOps-DevOps工程师。 作业不仅包含标题，而且必须在其中输入一些文本。 最简单的方法是输入Google的一组关键字，他们对此有足够的想象力。 DevOps由两个词-“ Dev”和“ Ops”组成，这意味着您需要将与开发人员和管理员相关的关键字整合在一起。 因此，拥有42种编程语言以及同时使用Kubernetes和Swarm已有20年的空缺。 工作计划。
因此，某种超级英雄的无意识和无情的形象扎根于人们的思想，他们将为詹金斯建立所有人，幸福就会来临。 啊，只要那么简单。 Eichar认为：“而且您还可以通过这种方式入侵系统管理员，这个词很时髦，关键字相同，必须啄。”
需求创造了供应，所有这些垃圾空位都吸引了无数的系统管理员，他们意识到您可以做与以前相同的事情，但获得的回报却要高出几倍，称自己为“发展者”。 当您一次用一只手通过SSH配置服务器时，您将继续进行配置，但是现在看来这是一种devops实践。 这是一种复杂的现象，部分与传统管理员的低估以及与DevOps的炒作有关，但总的来说，发生了什么。
因此，我们有供求关系。 滋生自己的恶性循环。 这就是我们正在努力解决的问题（包括通过创建DevOops会议）。
当然，除了系统管理员（重命名为“ devops”）外，还有其他参与者-例如，专业SRE或“基础结构即代码”的开发人员。
人们在DevOps中做什么（实际上）
因此，您想在学习和应用DevOps实践方面取得进步。 但是怎么做，用哪种方式看呢？ 显然，一味地受到流行关键字的引导是不值得的。
如果有工作，应该有人做。 我们已经发现这些不是“ DevOps工程师”，那又是谁呢？ 用职位而不是具体工作领域来表述似乎是更正确的。
首先，您可以做DevOps的核心工作-流程和文化。 文化并不是一件快速而困难的事情，尽管传统上这是管理人员的责任，无论是从一种方式还是从另一种方式，每个人都参与其中，从程序员到管理员。 几个月前，蒂姆·李斯特（Tim Lister） 在接受采访时说 ：
“文化是由组织的核心价值观决定的。 通常人们不会注意到这一点，但是我们从事咨询工作多年，已经习惯了这一点。 您进入公司，几分钟后您便开始感觉到正在发生什么。 我们称其为“香气”。 有时候这种味道真的很好。 有时会引起恶心。 （...）在实现具体行动背后的价值观和信念之前，您无法改变文化。 行为容易观察，难以说服。 DevOps就是事情越来越艰难的一个很好的例子。”
当然，这个问题还有一个技术部分。 如果您在一个月内获得了用于测试的新代码，而在发行版中仅在一年内出现，并且实际上不可能加速所有这些操作，那么您就无法兑现良好的做法。 好的做法由好的工具支持。 例如，考虑到“基础架构即代码”的思想，您可以使用从AWS CloudFormation和Terraform到Chef-Ansible-Puppet的任何内容。 您需要知道并且能够做到这一切，这是一门完整的工程学科。 重要的是不要将原因与后果混淆：首先，您要遵循SRE的原则，然后才以某些特定的技术解决方案的形式来实施这些原则。 同时，SRE是一种非常全面的方法，它不涉及如何配置Jenkins，而是涉及五个基本原则：
- 改善角色和部门之间的互动
- 接受错误是工作不可或缺的一部分
- 渐进式变化
- 使用调整和其他自动化
- 衡量一切可以衡量的
这不仅是一组陈述，而且是具体的行动指南 。 例如，在犯错误的道路上，您将需要处理风险，使用SLI（ 服务水平指标 ）和SLO（ 服务水平目标 ）之类的东西来衡量服务的可用性和不可访问性，学习如何编写验尸并使其易于编写。
在SRE学科中，工具的使用只是成功的一部分，但是，它很重要。 我们需要不断进行技术开发，观察世界上正在发生的事情以及如何将其应用到我们的工作中。
反过来，Cloud Native解决方案现在变得非常流行。 根据对Cloud Native Computing Foundation的当前了解，Cloud Native技术使组织能够在当今的动态环境（例如公共云，私有云和混合云）中开发和运行可伸缩应用程序。 示例包括容器，服务网格，微服务，不可变的基础结构和声明性API。 所有这些技术都允许松散耦合的系统保持灵活性，可管理性和良好的可观察性。 良好的自动化使工程师可以经常进行大的更改，并获得可预期的结果，而无需将其变成繁琐的工作。 Docker和Kubernetes等著名工具栈为所有这些提供支持。
这个相当复杂和繁重的定义与该地区相当复杂这一事实有关。 一方面，有人认为应该很简单地添加对该系统的新更改。 另一方面，要弄清楚如何创建一种容器化的环境，在该环境中，松散耦合的服务将生活在软件定义的基础架构上，并使用连续的CI / CD在其中进行交付，并围绕所有这些DevOps实践进行构建-您需要多个吃狗
该怎么办
每个人都以自己的方式解决这些问题：例如，您可以发布常规作业来打破恶性循环。 您可以弄清楚DevOps和Cloud Native等词的含义，并正确使用它们。 您可以在DevOps中进行开发，并以自己的示例演示正确的方法。
我们正在举办DevOops 2020莫斯科会议，该会议提供了一个更好地了解我们刚刚谈论的内容的机会。 有几组报告：
如何选择去哪里？ 有一个微妙的地方。 一方面，DevOps是关于交互的，我们真的希望您能从不同的块中获取报告。 另一方面，如果您是一位参加会议的开发经理来专注于一项特定任务，那么没有人会限制您-显然，这将是有关流程和文化的障碍。 不要忘记，会议结束后您会得到注释（在填写反馈表之后），因此以后总是可以看到不太重要的报告。
显然，在会议本身上您不能立即同时进入三个轨道，因此我们以这样一种方式创建程序，即在每个时隙中都有各种口味的主题。
仅当您是DevOps工程师时，才知道该怎么做！ 首先，尝试确定您实际在做什么。 通常他们喜欢称呼这个词：
- 处理基础架构的开发人员。 SRE和Cloud Native对话组最适合您。
- 系统管理员。 更复杂。 DevOops与系统管理无关。 幸运的是，关于系统管理的主题，Internet上有许多出色的会议，书籍，文章，视频等。 另一方面，如果您对了解文化和流程，探索云技术以及Cloud Native的生活细节感兴趣，那么我们将很高兴见到您！ 考虑一下：您现在在行政部门，然后您将做什么？ 为了不突然陷入不愉快的状况，现在值得研究。
还有另一种选择：您坚持并继续声称自己是DevOps工程师 ，除此之外，别无其他。 然后，让他们感到悲痛的是，DevOops并不是DevOps工程师的会议！
慕尼黑康斯坦丁·迪纳报告的幻灯片
DevOops 2020 Moscow将于4月29日至30日在莫斯科举行，门票已经可以在官方网站上购买 。
此外，您可以在 2月8日之前提交报告 。 请注意，在填写表格时，您必须选择目标受众，您的报告将为其提供更多帮助（ 列表中掩藏了一个惊喜 ）。