DevOps 会抢走我的工作吗?

你是否担心自动化会取代工作场所的人们?你可能是对的,但这就是为什么这不是一件坏事。
343 位读者喜欢这个。
A bunch of question marks

Opensource.com

这是一个常见的恐惧:DevOps 会是我职业生涯的终结吗? 毕竟,DevOps 意味着开发人员进行运维,对吧? DevOps 就是自动化。 如果我把自己自动化出局了怎么办? 持续交付和容器是否意味着运维人员已经过时了? DevOps 完全是关于编码的:基础设施即代码、测试即代码以及这个或那个即代码。 如果我没有成为其中的一部分的技能怎么办?

DevOps 是一项即将到来的变革,在该领域具有颠覆性,看似狂热的追随者谈论着用 三步法(DevOps 的三大支柱)改变世界并拆除壁垒。 这可能会让人不知所措。 那么会是什么样子呢——DevOps 会抢走我的工作吗?

第一个恐惧:我不再被需要

作为管理应用程序整个生命周期的开发人员,人们很容易陷入 DevOps 的想法中。 容器可能是这种思路的一个重要因素。 当容器突然出现时,它们被吹捧为开发人员构建、测试和部署其代码的一体化方式。 DevOps 为运维团队、测试或 QA 留下了什么角色?

这源于对 DevOps 原则的误解。 DevOps 的第一条原则,或者说第一步,是系统思考,或者强调采用整体方法来管理和理解应用程序或服务的整个生命周期。 这并不意味着应用程序的开发人员会学习和管理整个过程。 相反,它是才华横溢、技术娴熟的个人之间的协作,以确保整体的成功。 让开发人员独自负责整个过程实际上与这一原则截然相反——本质上是将单个孤岛奉为整个生命周期的重要性。

DevOps 中存在专业化的地方。 正如受过古典教育且掌握线性回归和二分查找知识的软件工程师在编写 Ansible playbook 和 Docker 文件时会被浪费一样,掌握如何保护系统和优化数据库性能知识的高技能系统管理员在编写 CSS 和设计用户流程时也会被浪费。 编写、测试和维护应用程序最有效的团队是由具有不同技能和背景的跨学科、功能团队组成。

第二个恐惧:我的工作将被自动化

无论是否准确,DevOps 有时可以被视为自动化的同义词。 当自动化构建、测试、部署、监控和通知是应用程序生命周期中的重要组成部分时,运维人员和测试团队还剩下什么工作? 这种对自动化的关注可能与第二步:放大反馈循环 有关。 DevOps 的第二个原则涉及优先考虑团队之间快速反馈,方向与应用程序部署方向相反——从监控和维护到部署、测试、开发等,并强调使反馈重要且可操作。 虽然第二步与自动化没有具体关系,但团队在其部署管道中使用许多自动化工具来促进快速通知和快速操作,或根据支持此原则的反馈进行纠正。 传统上由人工完成,因此很容易理解为什么对自动化的关注可能会导致对未来工作的焦虑。

自动化只是一种工具,而不是人的替代品。 聪明的人一遍又一遍地做着同样的事情,按下红色大乔治杰森按钮,这是一种浪费,是一种未开发的智慧和创造力的财富。 日常工作的自动化意味着有更多的时间来解决实际问题并提出创造性的解决方案。 人类需要弄清楚“如何和为什么”;计算机可以处理“复制和粘贴”。

将会有数不尽的重复性、可预测的事情需要自动化,而自动化让团队可以专注于其领域中的更高级别的任务。 监控团队不再花费所有时间来配置警报或管理趋势配置,而是可以开始专注于预测警报、关联统计数据和创建主动解决方案。 系统管理员摆脱了计划的补丁或服务器配置,可以花时间专注于舰队管理、性能和扩展。 与完全没有人类的工厂车间和装配线的惊人图像不同,DevOps 世界中的自动化任务意味着人类可以专注于创造性的、有回报的任务,而不是令人麻木的苦差事。

第三个恐惧:我没有所需的技能

“我将如何跟上这个?我不知道如何自动化。现在一切都是代码——我是否必须成为开发人员并以编写代码为生才能在 DevOps 中工作?” 第三个恐惧最终是对自信的恐惧。 随着文化的变化,是的,团队将被要求随之改变,有些人可能担心他们缺乏执行其工作将要变成的技能。

然而,大多数人可能比他们想象的更接近。 Dockerfile 或 Puppet 或 Ansible 等配置管理是什么,而不是环境即代码? 系统管理员已经编写 shell 脚本和 Python 程序来处理他们的重复性任务。 多学一点并开始使用他们已经掌握的一些工具来解决更多问题——编排、部署、维护即代码——几乎没有什么困难,尤其是在从繁琐的手动任务中解放出来以专注于成长时。

这个恐惧的答案在于 DevOps 的第三个原则,即第三步:持续实验和学习的文化。 尝试、失败并从错误中吸取教训而不受责备的能力是创造更多创意解决方案的主要因素。 第三步由前两步赋能——允许快速检测和修复问题,就像开发人员可以自由尝试和学习一样,其他团队也可以。 从未使用过配置管理或编写程序来自动化基础设施配置的运维团队可以自由尝试和学习。 测试和 QA 团队可以自由地实施新的测试管道并自动化审批和发布流程。 在拥抱学习和成长的文化中,每个人都可以自由地获得成功并享受工作所需的技能。

结论

行业中任何具有颠覆性的实践或变化都可能产生恐惧或不确定性,DevOps 也不例外。 对自己工作的担忧是对数百篇文章和演示文稿的合理回应,这些文章和演示文稿列举了无数似乎致力于授权开发人员承担行业各个方面的责任的实践和技术。

但事实上,DevOps 是“一个跨学科的实践社区,致力于研究以规模构建、发展和运营快速变化的弹性系统。” DevOps 意味着消除孤岛,而不是专业化。 它是将苦差事委派给自动化系统,让您可以自由地做人们最擅长的事情:思考和想象。 如果您有动力去学习和成长,那么将会有无数的机会来解决新的和具有挑战性的问题。

DevOps 会夺走你的工作吗? 是的,但它会给你一份更好的工作。

Chris Collins
Chris Collins 是 Red Hat 的 SRE,也是 OpenSource.com 的记者,他对自动化、容器编排及其周围的生态系统充满热情,并且喜欢在家中重新创建企业级技术以供娱乐。

2 条评论

我认为自动化的挑战在于设计与人合作的系统,就像一个非常聪明的同事一样。 即使机器在做出决策的方式上也有自己的视角,也许它们的决策应该被构架为建议而不是答案。
考虑到这一点,一个系统不应该仅仅被设计用来提供答案,还应该回答问题。 例如,“为什么这是最佳答案?你是如何得出这个结论的?你能给我一些背景信息吗?” 如果没有别的,这可能会帮助相关人员提出更好的问题。

每个重复性任务都将被自动化取代。 人们需要注意并做好准备!

知识共享许可协议本作品根据知识共享署名 - 相同方式共享 4.0 国际许可协议获得许可。
© . All rights reserved.