在过去一年左右的时间里，我观察到对“入门 DevOps”感兴趣的开发人员和系统管理员急剧增加。这种模式是有道理的：在这个时代，一个开发人员只需花费几美元和几个 API 调用，就可以为一个应用程序启动全球分布式基础设施，开发和系统管理之间的差距比以往任何时候都更小。虽然我已经看过很多关于酷炫 DevOps 工具和思考的博文和文章，但我很少看到关于为希望从事这项工作的人提供指导和建议的内容。
我写这篇文章的目的是描绘这条道路的样子。我的想法基于多次访谈、聊天、在 reddit.com/r/devops 上的深夜讨论以及随机对话，很可能是在啤酒和美食中进行的。我也很想听取那些已经完成转型的人的反馈；如果您有，请通过我的博客、Twitter 或下面的评论与我联系。我很想听听您的想法和故事。
旧世界的 IT
了解历史是理解未来的关键，DevOps 也不例外。要理解 DevOps 运动的普遍性和流行性，了解 90 年代末和 00 年代初 IT 的状况很有帮助。这是我的经历。
我于 2006 年末在一家大型跨国金融服务公司开始我的职业生涯，担任 Windows 系统管理员。在那些日子里，添加新的计算资源需要致电 Dell（或者，在我们的例子中是 CDW），并订购价值数十万美元的服务器、网络设备、电缆和软件，所有这些都将运往您的现场和异地数据中心。尽管 VMware 仍在说服公司使用虚拟机确实是一种经济高效的方式来托管其“性能敏感型”应用程序，但许多公司（包括我的公司）都承诺在其物理硬件上运行应用程序。
我们的技术部门有一个专门负责数据中心工程和运营的团队，其工作是将我们的租赁费率谈判到稍微不那么荒谬的月费率，并确保我们的系统得到适当的冷却（如果您有足够的设备，这是一个呈指数级增长的难题）。如果该团队足够幸运/富有，那么离岸数据中心的工作人员对我们所有的服务器型号都足够了解，以至于不会在盘后交易期间意外拉错东西。亚马逊网络服务和 Rackspace 正在慢慢开始兴起，但远未达到临界规模。
在那些日子里，我们也有专门的团队来确保运行在硬件之上的操作系统和软件在应该工作的时候能够正常工作。工程师负责为这些系统的补丁、监控和警报设计可靠的架构，并定义“黄金映像”的样子。这项工作大部分是通过大量的手动实验完成的，大多数测试的程度是编写一本运行手册来描述您所做的事情，并确保您所做的事情在遵循所述运行手册后实际上做了您期望它做的事情。这在我们这样的大型组织中非常重要，因为大多数 1 级和 2 级支持都是离岸的，他们的培训程度仅限于这些运行手册。
（这就是您的作者在他职业生涯的头三年所处的世界。我当时的梦想是成为制定黄金标准的人！）
软件发布是另一回事。诚然，我在这方面的工作经验不多。但是，从我收集的故事（以及最近的经验）来看，当时软件开发的日常工作大致如下
- 开发人员根据业务分析师在他们没有被邀请参加的会议上提出的技术和功能需求编写代码。
- 可选地，开发人员为他们的代码编写单元测试，以确保它不会做任何明显的疯狂的事情，例如尝试除以零而不抛出异常。
- 完成后，开发人员会将他们的代码标记为“准备好进行 QA”。质量保证人员会拿起代码并在他们自己的环境中运行它，该环境可能类似于也可能不类似于生产环境，甚至可能不类似于开发人员用来测试他们自己的代码的环境。
- 失败会“在几天或几周内”被发送回开发人员，具体取决于其他业务活动和优先级的安排。
尽管系统管理员和开发人员经常意见不合，但他们共同憎恨的一件事是“变更管理”。这是一个由高度监管的（并且在当时我的雇主的情况下）高度必要的规则和程序组成的体系，用于管理公司何时以及如何发生技术变更。大多数公司都遵循 ITIL 实践，简而言之，它会围绕事物发生的原因、时间、地点和方式提出很多问题，并提供一个流程来建立导致这些答案的决策的审计跟踪。
正如您可能从我的简短历史课中收集到的那样，IT 中许多事情都是手动完成的。这导致了很多错误。很多错误导致了很多收入损失。变更管理的工作是最大限度地减少这些收入损失；这通常以每两周发布一次版本和对服务器的更改的形式出现，无论其影响或大小如何，都排队在周五下午 4 点到周一凌晨 5:59 之间进行。（具有讽刺意味的是，这种批量工作导致了更多的错误，通常是更严重的错误。）DevOps 不是老虎突击队
您可能会想“Carlos 在说什么，他什么时候会谈论 Ansible playbook？” 我非常喜欢 Ansible，但请稍等；这很重要。
您是否曾经被分配到一个项目，您必须与“DevOps”团队互动？或者您是否必须依赖“配置管理”或“CI/CD”团队来确保您的管道设置正确？您是否必须参加关于您的发布及其相关内容的会议——在工作被标记为“代码完成”几周后？
如果是这样，那么您正在重温历史。所有这些都来自以上所有内容。
孤岛的形成源于与和我们自己相似的人一起工作的本能吸引力。自然，这种人类特性也体现在工作场所也就不足为奇了。我甚至在我曾经工作过的一家 250 人的初创公司中看到了这种情况。当我开始工作时，所有开发人员都在公共场所工作，并彼此密切合作。随着代码库复杂性的增加，从事共同功能的开发人员自然而然地彼此对齐，试图解决他们自己功能内的复杂性。不久之后，正式成立了功能团队。
我在许多公司工作过的系统管理员和开发人员不仅形成了像这样的自然孤岛，而且还彼此激烈竞争。当开发人员的环境出现故障时，他们对系统管理员感到生气。当开发人员的环境被过度锁定太死板时，他们对系统管理员感到生气。系统管理员对开发人员以任意方式破坏他们的环境感到生气。系统管理员对开发人员要求比他们需要的更多的计算能力感到生气。双方都不了解对方，更糟糕的是，双方都<0xC2><0xA0>不<0xC2><0xA0>愿意了解对方。
大多数开发人员对操作系统、内核或在某些情况下对计算机硬件的基础知识不感兴趣。同样，大多数系统管理员，即使是 Linux 系统管理员，也对学习如何编码采取敬而远之的态度。他们在大学里尝试了一点 C，讨厌它，并且再也不想接触 IDE。因此，开发人员将他们的环境问题抛给系统管理员，系统管理员将它们与抛给他们的数百个其他问题一起确定优先级，每个人都在忙碌地等待，同时愤怒地憎恨对方。DevOps 的目的是结束这种情况。
DevOps 不是一个团队。CI/CD 不是 Jira 中的一个组。DevOps 是一种<0xC2><0xA0>思维方式。<0xC2><0xA0>根据这场运动，在理想的世界中，开发人员、系统管理员和业务利益相关者将作为一个团队工作。虽然他们可能不了解彼此世界的一切，但他们不仅都了解足够多的知识来理解彼此及其积压工作，而且在很大程度上，他们可以<0xC2><0xA0>说同一种语言。
这是所有基础设施和业务逻辑都在代码中，并受制于与位于其之上的软件相同的部署管道的基础。每个人都在获胜，因为每个人都互相理解。这也是聊天机器人和易于访问的监控和图形等其他工具兴起的基础。Adam Jacob 说得最好：“DevOps 是我们将用来描述企业向软件主导型转变的运营方面的词。”
我需要了解什么才能入门 DevOps？
我经常被问到这个问题，而答案就像大多数这样的开放式问题一样：这取决于情况。
目前，“DevOps 工程师”因公司而异。拥有大量软件开发人员但了解基础设施的人员较少的较小公司可能会寻找具有更多系统管理经验的人员。其他公司，通常是规模较大和/或较老的公司，它们拥有稳固的系统管理员组织，可能会针对更接近 Google 站点可靠性工程师 的职位进行优化，即“设计运营职能的软件工程师”。然而，这并非一成不变，因为与任何技术工作一样，该决定很大程度上取决于赞助招聘的经理。
也就是说，我们通常寻找对以下方面感兴趣的工程师：
- 如何管理和构建安全且可扩展的云平台（通常在 AWS 上，但 Azure、Google Cloud Platform 和 PaaS 提供商（如 DigitalOcean 和 Heroku）也很受欢迎）；
- 如何在流行的 CI/CD 工具（如 Jenkins、Go 持续交付和基于云的工具（如 Travis CI 或 CircleCI））上构建和优化部署管道和部署策略；
- 如何使用基于时间序列的工具（如 Kibana、Grafana、Splunk、Loggly 或 Logstash）监控、记录和警报系统中的更改；以及
- 如何使用配置管理工具（如 Chef、Puppet 或 Ansible）维护基础设施即代码，以及如何使用 Terraform 或 CloudFormation 等工具部署所述基础设施。
容器也变得越来越流行。尽管 反对现状的强烈抗议 围绕着大规模 Docker，但容器正迅速成为实现极高服务密度和应用程序在更少系统上运行，同时提高其可靠性的绝佳方式。（如果它们所服务的宿主机出现故障，Kubernetes 或 Mesos 等编排工具可以在几秒钟内启动新的容器。）鉴于此，掌握 Docker 或 rkt 以及编排平台的知识将大有裨益。
如果您是一位希望入门 DevOps 的系统管理员，您还需要知道如何编写代码。Python 和 Ruby 是用于此目的的流行语言，因为它们是可移植的（即，可以在任何操作系统上使用）、快速且易于阅读和学习。它们也构成了业界最流行的配置管理工具（Ansible 的 Python，Chef 和 Puppet 的 Ruby）和云 API 客户端的基础（Python 和 Ruby 通常用于 AWS、Azure 和 Google Cloud Platform 客户端）。
如果您是一位希望进行此更改的开发人员，我强烈建议您更多地了解 Unix、Windows 和网络基础知识。即使云抽象掉了管理系统的许多复杂性，了解这些事物的工作原理也有助于调试缓慢的应用程序性能。我在下一节中收录了一些关于此主题的书籍。
如果这听起来让人感到不知所措，您并不孤单。幸运的是，有很多小型项目可以让您涉足。其中一个玩具项目是 Gary Stafford 的 Voter Service，这是一个基于 Java 的简单投票平台。我们要求我们的候选人通过管道将该服务从 GitHub 转移到生产基础设施。您可以将其与 Rob Mile 的精彩 DevOps 教程存储库结合起来，了解执行此操作的方法。
熟悉这些工具的另一种好方法是使用流行的服务，并仅使用 AWS 和配置管理为它们设置基础设施。首先手动设置它，以了解要做的好的想法，然后仅使用 CloudFormation（或 Terraform）和 Ansible 复制您刚刚所做的事情。令人惊讶的是，这是我们的基础设施开发人员每天为我们的客户做的大部分工作。我们的客户发现这项工作非常有价值！
推荐阅读的书籍
如果您正在寻找关于 DevOps 的其他资源，这里有一些值得一读的理论和技术书籍。
理论书籍
- Gene Kim 著的凤凰项目。这是一本很棒的书，涵盖了我之前解释过的许多历史（内容更丰富），并描述了转型为精益公司，在敏捷和 DevOps 上运行的旅程。
- Terrance Ryan 著的推动技术变革。一本很棒的小书，介绍了大多数技术组织中的常见性格以及如何与他们打交道。这本书对我的帮助超出了我的预期。
- Tom DeMarco 和 Tim Lister 著的人件。一本关于管理工程组织的经典著作。有点过时，但仍然具有现实意义。
- Tom Limoncelli 著的系统管理员的时间管理。虽然这本书主要面向系统管理员，但它深入了解了大多数大型组织中系统管理员的生活。如果您想更多地了解系统管理员和开发人员之间的战争，这本书可能会解释更多。
- Eric Ries 著的精益创业。介绍了 Eric 的 3D 化身公司 IMVU 如何发现如何精益工作、快速失败并更快地找到利润。
- Jez Humble 和朋友合著的精益企业。本书是精益创业在企业中的改编版。两者都是很棒的读物，并且很好地解释了 DevOps 背后的业务动机。
- Kief Morris 著的基础设施即代码。一本很棒的入门书，介绍了基础设施即代码！它很好地描述了为什么<0xC2><0xA0>任何<0xC2><0xA0>企业采用它来构建基础设施都至关重要。
- Betsy Beyer、Chris Jones、Jennifer Petoff 和 Niall Richard Murphy 合著的站点可靠性工程。一本解释 Google 如何进行 SRE 的书，或者也称为“DevOps 在 DevOps 成为一种事物之前”。对如何处理正常运行时间、延迟和保持工程师满意度提供了有趣的观点。
技术书籍
如果您正在寻找直接引导您编写代码的书籍，那么您来对地方了。
- 已故 W. Richard Stevens 著的TCP/IP 详解。这是关于基本网络协议的经典（并且可以说，完整的）巨著，特别强调 TCP/IP。如果您听说过第 1 层、第 2 层、第 3 层和第 4 层，并且有兴趣了解更多信息，您将需要这本书。
- Evi Nemeth、Trent Hein 和 Ben Whaley 合著的UNIX 和 Linux 系统管理手册。一本关于 Linux 和 Unix 如何工作以及如何在其中导航的优秀入门书。
- Don Jones 和 Jeffrey Hicks 合著的在午餐的一个月内学会 Windows Powershell。如果您要使用 Windows 进行任何自动化操作，您将需要学习如何使用 Powershell。这本书将帮助您做到这一点。Don Jones 是该领域著名的 MVP。
- James Turnbull 撰写的几乎所有内容。他出版了关于流行的 DevOps 相关工具的优秀技术入门书。
从将所有内容部署到裸机的公司（仍然有很多公司出于充分的理由这样做）到将所有内容无服务器化的开拓者，DevOps 很可能会在一段时间内保持存在。这项工作很有趣，结果影响深远，最重要的是，它有助于弥合技术和业务之间的差距。看到这一点真是太好了。
最初发布于 Neurons Firing on a Keyboard，CC-BY-SA。
2 条评论