devops_如何进入DevOps

devops

我观察到在过去的一年左右的时间里，有兴趣“进入DevOps”的开发人员和系统管理员急剧增加。 这种模式是有道理的：在这样一个时代，一个开发人员可以花几美元和几个API调用为一个应用程序建立一个全球分布的基础架构，开发和系统管理之间的鸿沟比以往任何时候都更近。 尽管我已经看到很多博客文章和关于凉爽的DevOps工具的文章和思考的想法，但是对于希望从事这项工作的人们，关于指针和建议的内容却很少。

我这篇文章的目的是画出那条路的样子。 我的想法是基于reddit.com/r/devops上的几次采访，聊天，深夜讨论以及随机交谈，可能是啤酒和美味食品。 我也有兴趣听取那些跳伞运动员的反馈； 如果有的话，请通过我的博客 ， Twitter或以下评论联系。 我很想听听您的想法和故事。

旧世界IT

了解历史是了解未来的关键，DevOps也不例外。 为了了解DevOps运动的普遍性和普及性，了解90年代末和90年代大部分时间的IT状况是有帮助的。 这是我的经验。

我的职业生涯始于2006年末，当时是一家大型跨国金融服务公司的Windows系统管理员。 在那些日子里，添加新计算涉及到致电戴尔（在我们的情况下为CDW）并下达数十万美元的服务器，网络设备，电缆和软件订单，这些订单全部用于您的现场和非现场数据中心。 尽管VMware仍在说服公司使用虚拟机确实是托管其“性能敏感”应用程序的一种经济高效的方式，但包括我在内的许多公司仍承诺要在其物理硬件上运行应用程序。

我们的技术部门有一个专门负责数据中心工程和运营的团队，其工作是将我们的租赁费率降低到荒谬的月租费率，并确保我们的系统得到适当的冷却（如果您有足够的设备，这将是一个成倍的难题） ）。 如果这个团队足够幸运/有钱，那么离岸数据中心的工作人员对我们所有的服务器型号都足够了解，不会在盘后交易中无意中拉错了东西。 Amazon Web Services和Rackspace慢慢开始兴起，但远没有达到临界点。

当时，我们还拥有专门致力于确保在硬件之上运行的操作系统和软件能够正常工作的团队。 工程师负责设计可靠的体系结构，以修补，监视和警告这些系统，并定义“金像”的外观。 大部分工作都是通过大量的手动实验完成的，大多数测试的范围是编写一本描述您所做工作的运行手册，并确保您在遵循该运行手册后实际完成了您期望的工作。 这在像我们这样的大型组织中很重要，因为第1级和第2级支持大部分是在国外进行的，而他们的培训程度则以这些手册为结尾。

（这就是您的作者在其职业生涯的头三年中所生活的世界。那时我的梦想是成为制定金本位的人！）

软件版本完全是另一个野兽。 诚然，我在栅栏这一侧的工作没有很多经验。 但是，从我收集的故事（以及最近的经验）来看，这段时间用于软件开发的日常工作大部分是这样的：

• 开发人员编写了代码，这些代码是由业务分析员在不邀请他们参加的会议上提出的技术和功能要求所指定的。
• 可选地，开发人员为他们的代码编写了单元测试，以确保它没有做任何明显的疯狂事情，例如尝试在不引发异常的情况下将零除。
• 完成后，开发人员会将其代码标记为“准备进行质量检查”。 质量保证人员会选择代码并在自己的环境中运行代码，该环境可能会或可能不会像生产环境，甚至可能不是开发人员用来测试其自身代码的环境。
• 故障将在“几天或几周内”发回给开发人员，具体取决于其他业务活动和优先级。

尽管系统管理员和开发人员并不经常见面，但他们共同憎恨的一件事是“变更管理”。 这是由受到严格监管的（对于当时的我的雇主而言），管理公司何时以及如何发生技术变更的高度必要的规则和程序组成。 简而言之，大多数公司都遵循ITIL惯例，这些惯例围绕为何发生，何时，何地以及如何发生的问题提出了很多问题，并提供了建立对导致这些答案的决策进行审核的流程。

尽管系统管理员和开发人员并不经常见面，但他们共同憎恨的一件事是“变更管理”。

正如您可能从我的简短历史课程中学到的那样，很多很多事情都是在IT中手动完成的。 这导致了很多错误。 许多错误导致大量收入损失。 变更管理的工作是最大程度地减少收入损失。 这通常以每两周发布一次的形式出现，并且对服务器的更改（无论其影响或规模如何）排队等待发生在星期五下午4点到星期一上午5:59之间（具有讽刺意味的是，这批工作甚至导致更多错误，通常是更严重的错误。）

DevOps不是虎队

您可能会想：“卡洛斯（Carlos）到底是怎么回事？他什么时候要谈论Ansible剧本？” 我爱Ansible吨，但请继续坚持； 这个很重要。

如果是这样，那么您就是在重温历史。 所有这些都来自以上所有内容。

孤岛是本能地吸引人们与像我们这样的人一起工作。 自然，这种人格特质也在工作场所表现出来也就不足为奇了。 我什至在曾经工作过的250人创业公司中看到了这种情况。 当我开始时，开发人员都在共同的Pod中工作，并且彼此之间进行了紧密的协作。 随着代码库复杂性的增加，从事通用功能的开发人员自然会彼此对齐，以尝试在自己的功能中解决复杂性。 此后不久，功能团队正式成立。

在我工作的许多公司中，系统管理员和开发人员不仅形成了这样的自然孤岛，而且彼此之间展开了激烈的竞争。 当环境崩溃时，开发人员会对系统管理员生气。 当他们的环境过于受限时，开发人员会对系统管理员感到生气。 系统管理员为开发人员一直在以任意方式破坏其环境感到生气。 系统管理员对开发人员要求的计算能力超出他们的需求感到生气。 双方都不了解对方，更糟糕的是，双方都不想。

大多数开发人员对操作系统，内核或某些情况下的计算机硬件的基本知识不感兴趣。 同样，大多数系统管理员，甚至Linux系统管理员，都采用10英尺高的杆来学习编码方法。 他们在大学里试过一点C语言，讨厌它，从不想再接触IDE。 结果，开发人员将环境问题扔给了系统管理员，系统管理员将扔给他们的数百种其他事情排在了他们的优先位置，并且每个人都在互相仇恨时愤怒地等待着他们。 DevOps的目的是结束这一过程。

DevOps不是团队。 CI / CD在Jira中不是一个团体。 DevOps是一种思维方式。 根据运动的说法，在理想的世界中，开发人员，系统管理员和业务利益相关者将作为一个团队工作。 尽管他们可能不了解彼此的所有事物，但他们不仅了解彼此的知识和积压的知识，而且他们在很大程度上可以说相同的语言。

根据运动的说法，在理想的世界中，开发人员，系统管理员和业务利益相关者将作为一个团队工作。

这是使所有基础结构和业务逻辑都在代码中并与位于其之上的软件遵循相同的部署管道的基础。 每个人都是赢家，因为每个人都相互理解。 这也是诸如聊天机器人以及易于访问的监视和图形之类的其他工具兴起的基础。

Adam Jacob说得最好：“ DevOps是我们用来形容向以软件为主导的企业过渡的运营方面的词汇。”

我需要了解什么才能进入DevOps？

我经常被问到这个问题，就像大多数开放式问题一样，答案是：取决于。

目前，“ DevOps工程师”因公司而异。 拥有大量软件开发人员但了解基础架构的人较少的较小公司可能会寻找具有更多管理系统经验的人员。 其他拥有大型sysadmin组织的大型公司和/或较老的公司，可能会针对更接近Google网站可靠性工程师 （即“设计操作功能的软件工程师”）进行优化。 这并不是一成不变的，但是，就像任何技术工作一样，这一决定很大程度上取决于赞助它的招聘经理。

也就是说，我们通常会寻找对以下方面感兴趣的工程师：

• 如何管理和设计安全且可扩展的云平台（通常在AWS上，但是Azure，Google Cloud Platform以及像DigitalOcean和Heroku这样的PaaS提供商也很受欢迎）；
• 如何在流行的CI / CD工具（如Jenkins，Go连续交付）和基于云的工具（如Travis CI或CircleCI）上建立和优化部署管道和部署策略；
• 如何使用基于时间序列的工具（例如Kibana，Grafana，Splunk，Loggly或Logstash）监视，记录系统中的变化并发出警报； 和
• 如何使用Chef，Puppet或Ansible等配置管理工具以代码形式维护基础结构，以及如何使用Terraform或CloudFormation等工具部署所述基础结构。

容器也越来越受欢迎。 尽管大规模反对围绕Docker的现状存在挑战 ，但是容器正Swift成为一种实现在更少系统上运行的服务和应用程序的极高密度同时提高其可靠性的好方法。 （例如，Kubernetes或Mesos之类的编排工具可以在几秒钟内启动新容器，如果它们所服务的主机发生故障。）鉴于此，对Docker或rkt以及编排平台的了解将大有帮助。

如果您是一名系统管理员，希望了解DevOps，则还需要知道如何编写代码。 Python和Ruby是用于此目的的流行语言，因为它们具有可移植性（即，可以在任何操作系统上使用），快速且易于阅读和学习。 它们还构成了业界最流行的配置管理工具（适用于Ansible的Python，适用于Chef和Puppet的Ruby）和云API客户端（适用于AWS，Azure和Google Cloud Platform客户端的Python和Ruby）的基础。

如果您是希望进行此更改的开发人员，我强烈建议您了解有关Unix，Windows和网络基础知识的更多信息。 尽管云消除了管理系统的许多复杂问题，但了解这些事情的工作原理对调试缓慢的应用程序性能有很大帮助。 在下一节中，我将介绍有关此主题的几本书。

如果这听起来势不可挡，那么您并不孤单。 幸运的是，有许多小型项目可以投入您的脚步。 这样的玩具项目就是Gary Stafford的Voter Service，这是一个基于Java的简单投票平台。 我们要求应聘者通过管道将服务从GitHub引入生产基础架构。 可以将其与Rob Mile的出色的DevOps Tutorial存储库相结合，以了解执行此操作的方法。

熟悉这些工具的另一种好方法是采用流行的服务，并仅使用AWS和配置管理就可以为它们建立基础架构。 首先手动进行设置，以很好地了解要做什么，然后仅使用CloudFormation（或Terraform）和Ansible来复制您刚刚做的事情。 令人惊讶的是，这是我们基础架构开发人员每天为客户所做的工作的很大一部分。 我们的客户发现这项工作非常有价值！

阅读书籍

如果您正在DevOps上寻找其他资源，这里有一些理论和技术书籍值得一读。

理论书籍

• 基因金的凤凰计划 。 这是一本很棒的书，涵盖了我先前解释的大部分历史（色彩丰富得多），并描述了在敏捷和DevOps上运行精益公司的过程。
• Terrance Ryan 推动技术变革 。 一本很棒的小书，介绍了大多数技术组织中的常见个性以及如何处理它们。 这对我的帮助超出了我的预期。
• 由Tom DeMarco和Tim Lister 撰写的Peopleware 。 管理工程组织的经典著作。 有点过时，但仍然有意义。
• Tom Limoncelli 为系统管理员提供的时间管理 。 尽管这是针对系统管理员的，但它为大多数大型组织的系统管理员的生活提供了很好的见解。 如果您想进一步了解系统管理员与开发人员之间的战争，则本书可能会提供更多解释。
• 精益创业公司 ，埃里克·里斯（Eric Ries）。 描述了Eric的3D化身公司IMVU如何发现精益工作，快速失败和更快地找到利润的方法。
• Jez Humble和朋友的精益企业 。 本书是《精益创业》（Lean Startup）企业版的改编本 。 两者都是不错的读物，并且很好地解释了DevOps背后的商业动机。
• Kief Morris撰写的《 基础设施即代码》 。 很棒的基础知识，就像代码一样！ 它很好地描述了为什么对于任何企业而言，将其用作其基础架构都至关重要。
• Betsy Beyer，Chris Jones，Jennifer Petoff和Niall Richard Murphy进行的站点可靠性工程 。 解释Google如何进行SRE的书，或者也称为“在DevOps之前的DevOps是一回事”。 提供有关如何处理正常运行时间，延迟和使工程师满意的有趣观点。

技术书籍

如果您正在寻找可以直接入门的书籍，那么您来对地方了。

• TCP / IP由已故的W. Richard Stevens说明。 这是基本网络协议的经典（并且可以说是完整的）书，特别强调了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可能会保留一段时间。 这项工作很有趣，结果很有影响力，最重要的是，它有助于弥合技术与业务之间的鸿沟。 看到这真是一件奇妙的事情。

最初在CC-BY-SA 上的Neurons Firing on Keyboard上发表。

翻译自: https://opensource.com/article/18/1/getting-devops

devops