没有 DevOps 工程师。 那么谁存在,又该如何处理它呢?

没有 DevOps 工程师。 那么谁存在,又该如何处理它呢?

近日,此类广告充斥互联网。 尽管工资待遇不错,但里面却写满了异端邪说,不禁让人感到尴尬。 首先,假设“DevOps”和“工程师”可以以某种方式粘在一起成为一个词,然后有一个随机的需求列表,其中一些显然是从系统管理员职位空缺中复制的。

在这篇文章中,我想谈谈我们是如何走到这一步的、DevOps 到底是什么以及现在该怎么办。

这种空缺可以用各种可能的方式来谴责,但事实是:这样的空缺有很多,这就是目前市场的运作方式。 我们召开了 DevOps 大会并公开宣称:“开发运营 - 不适用于 DevOps 工程师。” 这对很多人来说似乎很奇怪和疯狂:为什么那些做完全商业活动的人会逆市而行。 现在我们将解释一切。

关于文化和流程

首先,DevOps 不是一门工程学科。 这一切都始于历史上建立的角色分工不利于产品质量。 当程序员只进行编程,而不想听到任何有关测试的信息时,软件就会充满错误。 当管理员不关心软件的编写方式或原因时,支持就会变成地狱。

例如,描述系统管理员和 SRE 服务管理方法之间的区别 著名的 Google SRE 书籍开始。 有趣的研究已经在 朵拉调查 - 很明显,最好的开发人员以某种方式设法以比每小时一次更快的速度将新更改部署到生产中。 他们用手测试不超过10%(这一点可以从 去年的朵拉)。 他们如何做到这一点? 报告标题之一写道:“要么成功,要么死亡”。 有关测试背景下这些统计数据的详细讨论,可以参考 Baruch Sadogursky 的主题演讲 “我们有 DevOps。 让我们解雇所有测试人员吧。” 在我们的另一次会议 Heisenbug 上。

“当同志之间没有达成一致意见时,
好吧,他们的生意不会这样做,
它不会起作用,只有面粉。
从前有一只天鹅、一只小龙虾和一条梭子鱼……”

您认为 Web 程序员中哪一部分真正了解他们的应用程序在生产中使用的条件? 他们中有多少人会去找管理员并尝试弄清楚如果数据库崩溃会发生什么? 而他们中的哪一个会去找测试人员并请他们教他们如何正确编写测试? 还有保安,产品经理,还有其他一堆人。

DevOps的总体思想是创建角色和部门之间的协作。 首先,这不是通过一些巧妙配置的软件来实现的,而是通过沟通的实践来实现的。 DevOps 涉及文化、实践、方法论和流程。 没有任何工程专业可以回答这些问题。

恶性循环

“devops 工程”这门学科从何而来? 我们有一个版本! DevOps 想法很好——太好了,以至于他们成为了自己成功的受害者。 一些阴暗的招聘者和人贩子,他们有自己的氛围,开始围绕这整个话题打转。

想象一下:昨天你在希姆基制作沙瓦玛,今天你已经是一个大人物,一名高级招聘人员。 寻找和选择候选人有一个完整的过程,一切都不容易,你需要理解。 假设某个部门的负责人说:找一位 X 方面的专家。我们将“工程师”一词分配给 X,然后就完成了。 需要Linux吗? 嗯,这绝对是一名 Linux 工程师,如果你想要 DevOps,那就是一名 DevOps 工程师。 空缺不仅包含标题,还必须在里面输入一些文字。 最简单的方法是输入一组来自Google的关键字,具体取决于您的想象力。 DevOps 由两个词组成——“Dev”和“Ops”,这意味着我们需要将与开发人员和管理员相关的关键字粘在一起,全部粘在一起。 精通 42 种编程语言、同时使用 Kubernetes 和 Swarm 20 年的职位空缺就这样出现了。 工作图。

某个“devops”超级英雄的无意义、无情的形象就这样在人们心中扎根,他将配置所有人部署到Jenkins上,幸福就会到来。 哦,如果一切都这么简单就好了。 “这也是你追捕系统管理员的方法,”HR 认为,“这是一个时髦的词,关键词都一样,他们应该上钩。”

需求创造供应,所有这些垃圾空缺都被大量的系统管理员填补,他们意识到:你可以像以前一样做所有事情,但通过称自己为“devops”可以得到数倍的好处。 正如您一次通过 SSH 手动配置服务器一样,您将继续配置它们,但现在这应该是一种 DevOps 实践。 这是某种复杂的现象,部分与对经典管理员的低估和围绕 DevOps 的炒作有关,但总的来说,发生的事情就发生了。

所以我们有供给和需求。 恶性循环,自食其力。 这就是我们正在反对的(包括通过创建 DevOops 会议)。

当然,除了将自己更名为“devops”的系统管理员之外,还有其他参与者 - 例如,专业的 SRE 或基础设施即代码开发人员。

人们在 DevOps 中做什么(真的)

因此,您希望在学习和应用 DevOps 实践方面取得进步。 但如何做到这一点,朝哪个方向看呢? 显然,你不应该盲目依赖流行关键词。

如果有工作,就应该有人去做。 我们已经发现他们不是“devops工程师”,那么谁是呢? 似乎不从职位的角度来表述这一点,而是从具体工作领域的角度来表述更为正确。

首先,您可以解决 DevOps 的核心——流程和文化。 文化是一项缓慢而艰难的事业,尽管传统上它是管理者的责任,但从程序员到管理员,每个人都以这样或那样的方式参与其中。 几个月前 蒂姆·利斯特 在采访中说:

“文化是由组织的核心价值观决定的。 通常人们不会注意到这一点,但在咨询行业工作了多年,我们已经习惯了注意到这一点。 你进入一家公司,几分钟之内你就会开始感受到正在发生的事情。 我们称之为“风味”。 有时候这种味道真的很好闻。 有时会引起恶心。 (...) 在具体行动背后的价值观和信仰被理解之前,你无法改变一种文化。 行为很容易观察,但寻找信念却很困难。 DevOps 只是一个很好的例子,说明事情是如何变得越来越复杂的。”

当然,这个问题还有一个技术部分。 如果您的新代码在一个月内得到测试,但仅在一年后发布,并且实际上不可能加快全部速度,那么您可能无法实现良好的实践。 好的实践需要好的工具来支持。 例如,考虑到基础设施即代码的理念,您可以使用从 AWS CloudFormation 和 Terraform 到 Chef-Ansible-Puppet 的任何内容。 你需要知道并能够做到这一切,这已经是一门工程学科了。 重要的是不要混淆因果关系:首先按照 SRE 的原则进行工作,然后才能以一些具体的技术解决方案的形式实施这些原则。 同时,SRE是一个非常全面的方法论,它不会告诉你如何设置Jenkins,而是告诉你五个基本原则:

  • 改善角色和部门之间的沟通
  • 接受错误作为工作的一个组成部分
  • 逐渐做出改变
  • 使用工具和其他自动化
  • 测量一切可以测量的东西

这不仅仅是一些陈述,而是一个具体的 行动指南。 例如,在接受错误的过程中,您需要了解风险,使用 SLI 等工具来衡量服务的可用性和不可用性(服务水平指标) 和 SLO (服务水平目标),学会写事后分析,让写起来不再可怕。

在 SRE 学科中,工具的使用虽然很重要,但只是成功的一部分。 我们需要不断地发展技术,看看世界上正在发生什么,以及如何将其应用到我们的工作中。

反过来,云原生解决方案现在变得非常流行。 根据云原生计算基金会今天的定义,云原生技术使组织能够在当今的动态环境(例如公共云、私有云和混合云)中开发和运行可扩展的应用程序。 示例包括容器、服务网格、微服务、不可变基础设施和声明性 API。 所有这些技术都允许松散耦合的系统保持弹性、可管理和高度可观察。 良好的自动化使工程师能够频繁地进行重大更改并获得可预测的结果,而不会使其成为一件苦差事。 所有这一切都得到了 Docker 和 Kubernetes 等一系列知名工具的支持。

这个相当复杂和宽泛的定义是因为该领域也相当复杂。 一方面,有人认为应该非常简单地对该系统添加新的更改。 另一方面,要弄清楚如何创建一种容器化环境,其中松散耦合的服务存在于软件定义的基础架构上,并使用持续的 CI/CD 进行交付,并围绕所有这些构建 DevOps 实践 - 所有这些都需要更多胜过吃狗。

面对这一切该怎么办

每个人都用自己的方式解决这些问题:例如,您可以发布正常的职位空缺来打破恶性循环。 您可以弄清楚 DevOps 和 Cloud Native 等词语的含义,并正确、切题地使用它们。 您可以在 DevOps 中进行开发,并通过示例演示正确的方法。

我们正在开一个会议 DevOops 2020 莫斯科,这提供了一个深入研究我们刚才谈到的事情的机会。 为此有几组报告:

  • 流程和文化;
  • 现场可靠性工程;
  • 云原生;

如何选择去哪里? 这里有一个微妙的点。 一方面,DevOps 是关于交互的,我们真的希望您参加来自不同领域的演示。 另一方面,如果您是一名开发经理,参加会议是为了专注于一项特定任务,那么没有人限制您 - 显然,这将成为流程和文化的障碍。 不要忘记,您将在会议结束后(填写反馈表后)获得录音,以便您以后可以随时观看不太重要的演示。

显然,在会议本身上,你不能同时进行三个轨道,因此我们以这样的方式组织节目,每个时段都有适合各种口味的主题。

剩下的就是了解如果您是 DevOps 工程师该怎么做! 首先,尝试确定您实际上在做什么。 通常他们喜欢这样称呼这个词:

  • 从事基础设施工作的开发人员。 有关 SRE 和云原生的报告组最适合您。
  • 系统管理员。 这里更复杂。 DevOops 与系统管理无关。 幸运的是,互联网上有很多关于系统管理主题的优秀会议、书籍、文章、视频等。 另一方面,如果您有兴趣在了解文化和流程、了解云技术以及云原生生活细节方面发展自己,那么我们很高兴见到您! 大家想一想,你是做行政的,那你做什么呢? 为了避免突然发现自己陷入不愉快的境地,你应该现在就学习。

还有另一种选择:你坚持并继续声称你是 特别是 DevOps 工程师 没有别的,无论这意味着什么。 那么我们不得不让你失望了,DevOops 不是 DevOps 工程师的会议!

没有 DevOps 工程师。 那么谁存在,又该如何处理它呢?
幻灯片自 康斯坦丁·迪纳的报告 在慕尼黑

DevOops 2020 莫斯科将于 29 月 30-XNUMX 日在莫斯科举行,门票已开始发售 官网购买.

或者,您可以 提交您的报告 直到8月XNUMX日。 请注意,填写表格时,您必须选择将从您的报告中受益最多的目标受众(清单里藏着一个惊喜).

来源: habr.com

添加评论