从系统管理员转型为 DevOps 工程师的理由

存在学习曲线,但现在开始永远不晚。
264 位读者喜欢这篇文章。
Different color butterflies

互联网档案书籍图片。由 Opensource.com 修改。CC BY-SA 4.0

现在是 2019 年,DevOps 是热门话题。系统管理员(sysadmin)的时代已经像大型机一样过去了,如果可以这么说——但真的是这样吗?技术领域的格局经常发生变化。现在出现了叫做 DevOps 的东西,如果没有 Ops,它就不可能存在。

在 DevOps 演变为我们今天所知的样子之前,我一直认为自己站在 Ops 这一边。作为一名系统管理员或工程师,感觉你好像被困在时间扭曲中,带着一丝恐惧,因为你所知道的和必须学习的东西差异很大,而且现在比你预期的更加时间敏感。

Sysadmin/DevOps workstation

为什么会出现这个问题?嗯,与其说这是一个问题,不如说它最初是一个障碍。Web 规模的产品是建立在 Linux 和其他开源软件之上的,而维护它们的技术专业人员市场正在萎缩。需求已经超过了可用的人才储备。作为一名系统管理员,你不能再以目前的技能水平继续工作。你需要自动化技能来管理大型服务器/节点环境,并且需要了解一切如何运作,这样你才能知道哪里出了问题,以及何时以及如何修复这些环境。

你必须遵循的通往 DevOps 的道路上充满了曲折,因为你要学习新的技术和工具,以支持不断变化的新 DevOps 环境。那么,从系统管理员的思维方式和世界到 DevOps 的方式是怎样的呢?毫不奇怪,这个过程从你的思维开始。改变你过去 10 年或 20 年来做事的方式并不容易,但这是强制性的。

首先,接受 DevOps 不是一个职位,而是一套实践的想法。这些实践可以带来凝聚力,打破孤岛,减少错误和缺陷,更频繁和及时的软件生命周期,开发和运维之间更好的沟通,以及对代码和整个持续集成和交付 (CI/CD) 流程的持续测试和重新测试。

在改变你的思维方式的同时,也要获得必要的技能,以维持和支持你的基础设施,并确保其可靠性和可用性,从而持续集成和交付应用程序、服务和软件。

你作为 Ops 人员可能缺乏的一个领域是编程或编码技能。系统管理员在自动化服务器补丁、管理用户帐户和文件、以及故障排除和记录问题时使用的脚本编写方式被认为有些过时。虽然脚本编写今天仍然在较小的范围内使用,但 DevOps 侧重于大规模的实施、测试、构建和部署。

当你处理自动化时,你必须处理你可能的弱点,随着 DevOps 的发展以及需要你在不是开发人员的情况下进行编程的基础设施自动化,这可能会令人望而生畏。

解决方案是什么?你必须学习至少一种编程语言——例如 Python——才能保持相关性和竞争力。但作为一名 Ops 专业人员,摆脱编程是为开发人员准备的感觉可能很难,虽然你不必获得专业的编程知识,但了解如何编写脚本是有利的,无论是在 Python、Bash 甚至Powershell 中。

学习一些编程,这样你就可以在与 DevOps 团队的开发人员合作,或者作为顾问与客户合作时,不会不知所措,这将需要你的时间和精力。无论是每天 30 分钟还是 1 小时,学习这项技能都必须成为你的首要任务。

虽然系统管理员和 DevOps 之间存在共同的任务,但也存在一些重要的差异。有人认为,系统管理员更专注于配置、维护和保持服务器计算机系统的正常运行,而 DevOps 原则的工程师可以做 系统管理员 所做的一切,但 系统管理员 无法做 DevOps 原则的工程师所做的一切。

这种观点站得住脚吗?

系统管理:一个是最孤独的数字

虽然本文讨论了系统管理和 DevOps 之间的异同,但我认为它们之间实际上没有重大差异。系统管理员一直在执行 DevOps 所具有的功能;他们只是当时没有称之为 DevOps。我认为重要的是不要为了区分而区分,因为这根本不是完全必要的。你必须记住,DevOps 不是一个像系统管理员这样的职位,而是一个描述符。

我必须提到这一点,因为如果不指出这一点,那将是对 DevOps 和系统管理的不公平:从传统意义上讲,系统管理涉及拥有一套特定的技能,并专注于不同的基础设施。并非一刀切的命题,但系统管理员会执行许多常见的职能任务。

一些传统的系统管理员任务包括成为某种程度上的杂工,没有专业化。你可能是你组织中唯一的系统管理员,所以你是一个万事通。你做所有的事情,从维护打印机和复印机到执行与网络相关的任务,例如配置和管理路由器和交换机,以及设置防火墙策略和规则。

你还负责升级硬件、检查和分析日志、安全审计、修补服务器、故障排除、执行根本原因分析和自动化——通常是通过 PowerShell 脚本、Python 或 Bash 脚本。 脚本编写的一个例子是用户和组帐户管理。创建用户和设置权限可能是一项繁琐的任务,因为用户几乎每天都在来来去去。脚本编写意味着为更大规模的基础设施项目(如交换机和服务器刷新)以及其他创收项目腾出更多时间,尽管 IT 通常被认为是成本中心。

系统管理员的目标是不浪费时间,并尽可能地省钱。还有一些系统管理员作为一个大型团队的一部分工作,例如,Linux 管理员、Windows 管理员、数据库管理员、存储管理员等等。你可能采用传统的 Follow-the-Sun 模式,或者传统的朝九晚五模式,或者你在 24 小时数据中心工作。

多年来,系统管理员不得不进化他们的心态,并更具战略性地思考,将业务与他们的日常职责结合起来考虑。他们合作的团队和部门面临着资源匮乏的挑战,同时努力始终与日常业务参数保持一致。

DevOps:开发和运营是一体的

DevOps 被认为是一种理念,其中 IT、运营 (Ops) 和开发都已完成。这种看待事物的方式可以说是 IT 领域最大的游戏规则改变者。在 DevOps 的保护下,一边是一个软件开发团队,另一边是一个运营团队。产品管理团队、QA 团队和 UX 设计团队可能聚集在同一区域。这些团队结合优势,简化和稳定运营,以推出新应用程序,并更新代码以支持和改进整个业务。

DevOps 的核心是软件生命周期开发过程。由于运营负责支持开发人员,因此开发人员的任务是了解的不仅仅是在系统及其操作系统上执行的 API。他们还必须了解引擎盖下运行其软件的内容——硬件和操作系统——这样他们才能更好地处理错误问题、解决问题并与运营部门沟通。

系统管理员有能力过渡到 DevOps 团队,只要他们愿意学习当前和新兴技术,并对创新想法和解决方案持开放态度。如果这些系统管理员来自传统的运营背景,他们不必是完全成熟的程序员,但学习像 Ruby、Python 或 Go 这样的编程语言将有助于巩固他们在 DevOps 团队中的地位。虽然系统管理员传统上在他们的日常工作中更加孤独,并且经常被认为是孤独者,但这与应用 DevOps 原则的敏捷团队所需的经验完全相反。

自动化的话题变得越来越重要。系统管理员和 DevOps 都对快速扩展、减少错误以及快速发现和解决现有错误感兴趣。因此,自动化是这两个领域之间的相似之处。系统管理员负责云服务,如 AWS、Azure 和 Google Cloud Platform。他们必须理解 CI/CD 管道以及如何使用Jenkins 等来执行它们。

此外,系统管理员需要使用配置和编排工具,如Ansible,它用于并行部署十个或二十个服务器。前提是基础设施即代码。一切都是软件,软件就是一切。基本上,如果未来的系统管理员要保持相关性,就需要进行一些重新思考。系统管理员来自 Ops 方面,必须能够有效地与开发人员合作,反之亦然。两个人头肯定比一个好。

最后一个重要的组成部分是Git。传统上,Git 并不是系统管理员日常职责的一部分。这个版本控制管理系统被软件工程团队、DevOps、开发团队、敏捷团队等大量使用。如果你在软件生命周期开发过程中工作,你将会使用它。

Git 非常庞大。你可能永远无法学习每个 Git 命令,但你会理解这个工具是协作、沟通和软件生产的核心。如果你在 DevOps 团队中,具备 Git 的基础知识将非常重要。

如果你是一名系统管理员,你将需要提高你的 Git 知识,了解版本控制的心理,并学习那些常见的命令,如 git statusgit commit -mgit addgit pullgit pushgit rebasegit branchgit diff 等等。 有很多关于该主题的在线培训课程和书籍,因此你可以通过一些专注的关注从新手变成专家。 还有Git 速查表,这样你就不必记住每个命令,但你使用 Git 的次数越多,对你越有利。

结论

最终,是否继续做系统管理员或转型为DevOps,这取决于您自己。正如您所看到的,这需要一个学习过程,但现在就是开始的最佳时机。选择一门编程语言来学习,并在学习的同时,利用这个机会学习Git,一个像Jenkins这样的 CI/CD 工具,以及一个像Ansible这样的配置和 IT 自动化工具。无论您做什么决定,请务必不断学习和实践。

User profile image.
Taz Brown 是思科系统公司的高级技术 Scrum Master 和敏捷专家,也是与 DevOps 和软件开发团队合作的产品经理。她是一位热情的作家和演说家,在 Scrum、敏捷、数字产品管理、Linux 系统工程、DevOps 解决方案的管理和部署方面拥有丰富的背景。

3 条评论

很棒的文章。谢谢!

很棒的文章,喜欢这种设置。

我想知道图片中的桌子和显示器是什么型号的?

不错的文章。而且,这是为数不多的让我羡慕办公桌的时候。喜欢《终结者》里的照片。

Creative Commons License本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
© . All rights reserved.