主持人 > 博客 > 管理 > DevOps 是谁？

DevOps 是谁？

目前，这几乎是市场上最昂贵的位置。 围绕“DevOps”工程师的争论超出了所有想象的极限，对于高级 DevOps 工程师来说更糟。
我担任集成和自动化部门的负责人，猜英文解码——DevOps Manager。 英文记录不太可能反映我们的日常活动，但在这种情况下，俄语版本更准确。 由于我的活动性质，我很自然地需要采访我团队的未来成员，在过去的一年里，大约有 50 个人通过了我的采访，而同样数量的人在与我的员工的预筛选中被剪掉了。

我们仍在寻找同事，因为在 DevOps 标签的背后隐藏着一大堆不同类型的工程师。

下面写的一切都是我个人的观点，你不必同意它，但我承认它会给你对这个话题的态度增添一些色彩。 尽管有失宠的风险，我还是发表了我的观点，因为我相信它有一席之地。

公司对 DevOps 工程师的理解不同，为了快速招聘资源，他们给每个人都贴上了这个标签。 这种情况很奇怪，因为公司准备向这些人支付不切实际的报酬，在大多数情况下，为他们提供工具管理员。

那么 DevOps 工程师是谁？

让我们从它出现的历史开始 - 开发运营的出现是优化小团队交互以提高产品生产速度的又一步，这是预期的结果。 这个想法是通过管理产品环境的程序和方法的知识来加强开发团队。 换句话说，开发人员必须了解并知道他的产品在某些条件下如何工作，必须了解如何部署他的产品，可以调整环境的哪些特征来提高性能。 因此，一段时间以来，出现了采用 DevOps 方法的开发人员。 DevOps 开发人员编写构建和打包脚本来简化他们的活动和生产环境的性能。 然而，随着时间的推移，解决方案架构的复杂性和基础设施组件的相互影响开始恶化环境的性能；随着每次迭代，需要对某些组件有越来越深入的了解，从而降低了开发人员的生产力，因为额外的了解特定任务的组件和调整系统的成本。 开发人员自身成本增长，产品成本也随之增长，对团队中新开发人员的要求急剧上升，因为他们还需要承担开发“明星”的职责，自然“明星”就少了并且可用的较少。 还值得注意的是，根据我的经验，很少有开发人员对操作系统内核的数据包处理细节、数据包路由规则和主机安全方面感兴趣。 合乎逻辑的步骤是吸引一位熟悉这一点的管理员，并为他分配类似的职责，由于他的经验，与“明星”开发的成本相比，这使得以更低的成本实现相同的指标成为可能。 这些管理员被安排在一个团队中，他的主要任务是根据特定团队的规则来管理测试和生产环境，并将资源分配给该特定团队。 事实上，DevOps 就是这样出现在大多数人的脑海中的。

随着时间的推移，这些系统管理员部分或完全地开始了解这个特定团队在开发领域的需求，如何让开发人员和测试人员的生活变得更轻松，如何推出更新而不必在周五过夜办公室，纠正部署错误。 随着时间的推移，现在的“明星”是了解开发人员想要什么的系统管理员。 为了最大程度地减少影响，管理实用程序开始出现；每个人都记住了隔离操作系统级别的古老而可靠的方法，这使得可以最大限度地减少对安全性、网络部分管理和主机配置的要求。整体，从而减少对新“明星”的要求。

一个“奇妙”的东西出现了——docker。 为什么精彩？ 是的，只是因为在 chroot 或监狱以及 OpenVZ 中创建隔离需要对操作系统有一定的了解，相比之下，该实用程序允许您在某个主机上简单地创建一个隔离的应用程序环境，其中包含所有必要的内部和手动内容重新掌控开发，系统管理员只需管理一台主机，确保其安全性和高可用性 - 逻辑上的简化。 但进步不会停滞不前，系统又变得越来越复杂，组件越来越多，一台主机已经不能满足系统的需求，需要构建集群，我们又回到了系统管理员的身上。能够构建这些系统。

一个又一个周期，各种简化开发和/或管理的系统出现，编排系统出现，直到您需要偏离标准流程为止，这些系统都很容易使用。 微服务架构的出现也是为了简化上述一切——更少的关系，更容易管理。 根据我的经验，我没有找到一个完全的微服务架构，我想说 50% 到 50% - 50% 的微服务、黑匣子，进来，出来经过处理，其他 50 个是破碎的整体，服务无法与其他服务分开工作成分。 所有这些再次对开发人员和管理员的知识水平施加了限制。

特定资源的专家知识水平的类似“波动”至今仍在继续。 但我们有点离题了，有很多要点值得强调。

构建工程师/发布工程师

非常专业的工程师，他们的出现是标准化软件构建过程和发布的一种手段。 在广泛引入敏捷的过程中，似乎不再需要它们，但事实并非如此。 这种专业化是作为工业规模上标准化软件组装和交付的一种手段而出现的，即对所有公司产品使用标准技术。 随着 DevOps 的出现，开发人员部分失去了他们的功能，因为是开发人员开始准备产品交付，并且考虑到不断变化的基础设施和不考虑质量的尽快交付的方法，随着时间的推移，他们变成了变革的阻碍，因为遵守质量标准不可避免地会减慢交付速度。 因此，逐渐地，构建/发布工程师的部分功能转移到了系统管理员的肩上。

操作是如此不同

我们一次又一次地前进，职责范围广泛，合格人员的缺乏迫使我们走向严格的专业化，就像雨后的蘑菇一样，出现了各种操作：

  • TechOps - enikey 系统管理员又名服务台工程师
  • LiveOps - 主要负责生产环境的系统管理员
  • CloudOps - 专门从事公共云 Azure、AWS、GCP 等的系统管理员。
  • PlatOps/InfraOps/SysOps - 基础设施系统管理员。
  • NetOps - 网络管理员
  • SecOps - 专门从事信息安全的系统管理员 - PCI 合规性、CIS 合规性、修补等。

DevOps（理论上）是一个直接了解开发周期所有流程（开发、测试）的人，了解产品架构，能够评估安全风险，熟悉方法和自动化工具，至少在较高水平上级别，除此之外，还了解前处理和后处理、产品发布支持。 一个能够充当运营和开发倡导者的人，这使得这两个支柱之间能够进行良好的合作。 了解团队规划工作和管理客户期望的流程。

为了执行此类工作和职责，此人必须不仅有能力管理开发和测试流程，还必须有能力管理产品基础设施以及资源规划。 这种理解下的DevOps既不能位于IT，也不能位于研发，甚至不能位于PMO；它必须在所有这些领域都有影响力——公司的技术总监、首席技术官。

你们公司也是这样吗？ - 我怀疑。 在大多数情况下，这要么是 IT，要么是研发。

缺乏资金和能力来影响这三个活动领域中的至少一个，将把问题的重心转移到更容易应用这些变化的地方，例如根据静态数据对与“脏”代码相关的发布应用技术限制。分析仪系统。 即当PMO对功能的发布设定了严格的期限时，研发无法在这个期限内拿出高质量的结果，只能尽力而为，把重构留到以后，IT相关的DevOps通过技术手段阻止发布。 对于负责任的员工来说，缺乏改变情况的权力，会导致对他们无法影响的事情表现出过度责任，特别是如果这些员工了解并看到错误，以及如何纠正它们 - “幸福就是无知”，从而导致这些员工的倦怠和流失。

DevOps 资源市场

让我们看看不同公司的几个 DevOps 职位空缺。

如果您满足以下条件，我们随时准备与您会面：

  1. 您拥有 Zabbix 并且知道 Prometheus 是什么；
  2. iptables；
  3. BASH 博士生；
  4. 安西布尔教授；
  5. Linux 大师；
  6. 懂得如何使用调试，与开发人员一起发现应用程序问题（php/java/python）；
  7. 路由不会让你歇斯底里；
  8. 高度重视系统安全；
  9. 备份“一切”，并成功恢复“一切”；
  10. 您知道如何配置系统，以便从最小限度中获得最大收益；
  11. 在Postgres和MySQL上设置睡前复制；
  12. 设置和调整 CI/CD 对您来说就像早餐/午餐/晚餐一样必要。
  13. 有AWS经验；
  14. 准备与公司共同发展；

所以：

  • 从 1 到 6 - 系统管理员
  • 7 - 一点网络管理，也适合系统管理员，中级
  • 8 - 一点安全性，这对于中级系统管理员来说是强制性的
  • 9-11 – 中层系统管理员
  • 12 — 根据分配的任务，中级系统管理员或构建工程师
  • 13 - 虚拟化 - 中间系统管理员，或所谓的 CloudOps，对特定托管站点服务的高级了解，以有效利用资金并减少维护负担

总结这个职位空缺，我们可以说中/高级系统管理员对于这些人来说已经足够了。

顺便说一句，您不应该在 Linux/Windows 上强烈划分管理员。 当然，我知道这两个世界的服务和系统是不同的，但一切的基础都是相同的，任何有自尊心的管理员都熟悉其中一个和另一个，即使他不熟悉，也会对于有能力的管理员来说熟悉它并不困难。

让我们考虑另一个空缺：

  1. 具有构建高负载系统的经验；
  2. 精通 Linux 操作系统、通用系统软件和 Web 堆栈（Nginx、PHP/Python、HAProxy、MySQL/PostgreSQL、Memcached、Redis、RabbitMQ、ELK）；
  3. 具有虚拟化系统（KVM、VMWare、LXC/Docker）经验；
  4. 熟练掌握脚本语言；
  5. 了解网络协议网络的运行原理；
  6. 了解构建容错系统的原理；
  7. 独立性、主动性；

让我们看看：

  • 1 – 高级系统管理员
  • 2 - 取决于该堆栈的含义 - 中/高级系统管理员
  • 3 - 工作经验，包括，可能意味着 - “集群没有启动，而是创建和管理虚拟机，有一台 Docker 主机，无法访问容器” - 中级系统管理员
  • 4 - 初级系统管理员 - 是的，一个不知道如何编写基本自动化脚本的管理员，无论使用哪种语言，而不是管理员 - enikey。
  • 5 - 中层系统管理员
  • 6 – 高级系统管理员

总结 - 中/高级系统管理员

还有一个：

  1. 开发运维经验；
  2. 具有使用一种或多种产品创建 CI/CD 流程的经验。 Gitlab CI 将是一个优势；
  3. 使用容器和虚拟化； 如果您使用 docker，那很好，但如果您使用 k8s，那就太好了！
  4. 有在敏捷团队中工作的经验；
  5. 了解任何编程语言；

我们来看看：

  • 1 - 嗯...这些家伙是什么意思？ =) 很可能他们自己也不知道背后隐藏着什么
  • 2 - 建造工程师
  • 3 - 中层系统管理员
  • 4 - 软技能，我们暂时不考虑它，尽管敏捷是另一个以方便的方式解释的东西。
  • 5 - 太冗长 - 它可能是一种脚本语言或编译语言。 我想知道在学校用 Pascal 和 Basic 写作是否适合他们？ =)

我还想就第3点留下注释，以加强对为什么系统管理员涵盖这一点的理解。 Kubernetes 只是一个编排，一个工具，它将对网络驱动程序和虚拟化/隔离主机的直接命令包装在几个命令中，并允许您与它们进行抽象的通信，仅此而已。 例如，让我们以“构建框架”Make 为例，顺便说一句，我不考虑框架。 是的，我知道把 Make 推到任何地方的时尚，无论是必要的还是不需要的——例如，认真地将 Maven 包装在 Make 中？
本质上，Make 只是 shell 的包装，简化了编译、链接和编译环境命令，就像 k8s 一样。

有一次，我采访了一个在OpenStack之上工作中使用k8s的人，他谈到了他如何在其上部署服务，但是当我询问OpenStack时，结果发现它是由系统管理的，也是由系统提出的管理员。 你真的认为一个安装了OpenStack的人，无论他后面使用什么平台，都不能使用k8s吗？=）
这位申请人实际上并不是 DevOps 人员，而是系统管理员，更准确地说，是 Kubernetes 管理员。

让我们再次总结一下——中/高级系统管理员对他们来说就足够了。

挂多少克

所示空缺职位的建议薪资范围为 90k-200k
现在我想将系统管理员和 DevOps 工程师的金钱奖励进行比较。

原则上，为了简化事情，您可以根据工作经验分散成绩，虽然这并不准确，但对于本文的目的来说，这已经足够了。

经验：

  1. 最长 3 岁 – 初级
  2. 6 岁以下 – 中岁
  3. 超过 6 – 高级

员工搜索网站提供：
系统管理员：

  1. 青少年 - 2 岁 - 50k 卢布。
  2. 中 - 5 年 - 70k 卢布。
  3. 高年级 - 11 岁 - 100k 卢布。

开发运营工程师：

  1. 青少年 - 2 岁 - 100k 卢布。
  2. 中 - 3 年 - 160k 卢布。
  3. 高年级 - 6 岁 - 220k 卢布。

根据“DevOps”的经验，使用的经验至少在某种程度上影响了SDLC。

由此可见，其实企业并不需要DevOps，而且通过聘请Administrator可以节省至少50%的原计划成本；而且可以更清晰地定义他们要找的人的职责并更快地满足需求。 我们也不应该忘记，明确的职责分工可以减少对人员的要求，并在团队中创造更有利的氛围，因为没有重叠。 绝大多数职位空缺都充满了实用程序和DevOps标签，但它们并不是基于对DevOps工程师的实际要求，而只是对工具管理员的要求。

培训 DevOps 工程师的过程也仅限于一组特定的工作、实用程序，并且不提供对流程及其依赖关系的一般理解。 如果一个人可以在 10 分钟内使用 Terraform 部署 AWS EKS，并结合该集群中的 Fluentd sidecar 和用于日志记录系统的 AWS ELK 堆栈，仅使用控制台中的一个命令，这当然是件好事，但如果他不理解处理本身日志的原则以及它们的用途，如果您不知道如何收集它们的指标并跟踪服务的退化，那么知道如何使用某些实用程序的人仍然是同一个人。

然而，需求创造供给，我们看到 DevOps 职位的市场极度过热，其中的要求与实际角色不符，而只是让系统管理员赚取更多收入。

那么他们是谁呢？ DevOps 还是贪婪的系统管理员？ =)

怎么活？

用人单位应该更加精准地制定要求，准确地寻找需要的人，而不是乱贴标签。 您不知道 DevOps 做什么 - 在这种情况下您不需要它们。

工人——学习。 不断提高您的知识，纵观整个流程并跟踪实现目标的路径。 你可以成为任何你想成为的人，你只需要尝试。

来源： habr.com

添加评论