DevOps意味着开发人员现在应对基础架构和发布负责-但是，此更改背后的驱动力是什么？

DevOps意味着开发人员现在应对基础架构和发布负责-但是，此更改背后的驱动力是什么？

我会把牌放在桌上：我是一名开发人员，曾在“ DevOps”和非文化领域工作过。不必担心基础结构，发行版，质量保证以及相关的仪式，这将使编写好的代码分心。

但是行业正在朝这个方向发展，那么这是什么原因呢？角色专业化的“旧”模型引起了哪些问题？

主要原因是云。

过去，您的代码先放入软盘，再放入CD，然后再部署到服务器上，然后再部署到两台服务器上（以实现弹性）...所有这些部署都可以手动完成由人类完成，因此对人类进行了培训。

如今，您的代码通常要传送到数十个或数百个服务器。实际上，人工操作无法完成对这些服务器的配置，配置和部署。您需要系统管理员知道足够的脚本来自动化该过程，因为您现在使用的是Chef或其同类。但坦率地说，没有足够的系统管理员可以做到这一点。因此，开发人员被拉进来以弥补松弛。

是的，在开发人员不断增长的需求中增加更多技能自然会降低他们在其他地方的能力。这个想法是让开发人员洞悉构建/发布过程，他们可以更好地预测问题，或者拥有改进它的自主权。这样的想法是，自从发行版本胜过代码编写损失以来，所有内容的质量都会提高。

我怀疑这种折衷是否值得人们经常这样做。

各种组织迁移到DevOps的原因多种多样。
我将尝试列出经常出现的那些。

缩短变更周期的
时间在提出变更请求与在组织中实际部署和使用变更请求之间通常要花费很长时间。首先，它是由开发人员在一个开发周期中计划的，而交付后，则是在操作的一个发布周期中计划的。两个周期都包括测试，如果发现问题，则两个周期都会重置。通过整合开发和运营部门，我们可以简化这两个流程。

软件与硬件问题
还记得Bugs Bunff漫画中Bugs和Daffy争论的是鸭子季节还是兔子季节？现在想象一下，我们改为与开发人员和运营商合作，其中开发人员认为这是硬件问题，而运营商认为这是软件问题。对于最终用户而言，这是没有区别的区别。他们只是想要修复它。
通过将开发人员和运营部门整合在一起，他们将不得不解决问题。结果可能是软件和硬件问题。

我们与他们
之间的关系在许多公司中，测试人员和开发人员之间的距离越来越大，因为他们是独立的部门，并且开发周期越来越规范和标准化。
随着敏捷的到来，开发人员和测试人员之间的合作越来越紧密，我们已经开始看到彼此对开发周期的观点，甚至可能会尊重它。
在开发人员和运营部门之间也会发生类似的需求，因为随着这两个领域的成熟以及流程的进一步正规化和标准化，这些部门之间的距离越来越大。因此，传统模型的问题之一是，对于开发人员和运营人员而言，这似乎是“我们”还是“他们”。双方都不完全了解对方责任的难度。

期望/优势
通过DevOps，两个专业都将学习彼此传统上执行的一些技能。没有人会期望系统管理员会成为软件工程师或开发人员会成为网络工程师，但是都希望他们俩承担其他人的某些职责。这意味着当您确实需要一些额外的帮助时，它们就在那儿。

对于开发人员来说，存在一些明确的好处：您现在可以更好地控制测试环境，发现将软件部署给用户更容易，并且组织中有更多人可以与您分享对工艺的热爱。

仅仅编写高质量的代码是不够的。您是问题的一部分，还是解决方案的一部分。

对于许多程序员而言，您正在编写的软件是由某些最终用户付费的。编写高质量的代码是一件好事，但这也是客户/经理认为您应该始终做的很快的事情。这就像说木匠可以准确地切割木板，但是您实际上是在建造有人想要支付的东西吗？

DevOps为开发人员提供了更多控制权，并希望将其代码与最终结果保持一致。谁最适合使操作流程自动化？最终用户满意度是主要的衡量标准。您不仅必须编写质量代码，而且还必须使客户满意。抱歉，但是没有人会回到使用代码行。他们不在乎是否从头开始构建自己的ORM框架，就像普通购房者不在乎是否砍倒树木并自己制作板子一样。是否有人要重做所有配置文件，因为您的“升级”将它们重新设置为默认值？

您想炫耀您的开发人员排行榜吗？建立人们想要购买的东西，其中包括整个用户体验。您正在编写质量代码非常好，但是不幸的是，如果未按付费客户的要求发放奖金，则可能无法获得奖金。随意责怪质量检查人员，但您的公司仍然没有足够的钱来付给您更多。

这与敏捷与Scrum紧密相关。不再有明确定义的工作角色-每个人都是“开发人员”。

这不只是操作。开发人员通常必须承担业务分析，测试，数据库管理和构建经理的角色-清单还在继续。

问题的核心是您可能所说的流失。随着项目中涉及的不同角色的数量增加，会议，误解和资源冲突也越来越多。快速将软件展示在用户面前是最终的选择，可以想象的任何阻碍方式都已经被淘汰了。

这并不完全是一件坏事。您的平均开发商拓展自己的技能虽然果酱越来越非常薄了。它还避免了编码人员和服务器管理员之间的争论，即部署过程中的问题出在哪里。开发人员通常希望使用最先进的技术推出解决方案，而服务器管理员通常不知道管理员POV的含义，直到提供安装集。

才华横溢，富有远见的公司终于开始意识到T型人是一件好事。但是，认为自己是一件好事与期望这在以前采用传统文化的地方神奇地发生之间存在差异。

我敢肯定，开发人员还要（有时）还要管理操作和质量控制有很多理由。这是其中的三个：

• 兴趣
  一些开发人员实际上希望处理产品的各个方面。如果他们擅长于此，并且填补了团队中的空白或为其他角色的现有团队成员提供了良好的支持，则可能没有任何理由阻止他们。
• 成本
  大公司可以负担专业的员工。小公司有时做不到。其中一些地方可以雇用1或2或3个开发人员，他们需要能够简单地将工作内容带到室外。
• 项目规模
  并非每个项目都是一个多人项目。如果您要构建一个“小型”应用程序，那么要由一个以上的人来完成它可能会过大。更重要的是，由许多个人担任特定角色的小型项目令人恐惧。没有人有足够的工作要做-即使您有能力让他们到处晃动手指6个月，好人也不会留下来。如果他们不觉得无聊，就会感到害怕，或者您会发现自己付出了很多钱。无论哪种方式，您的好员工都会离开并告诉所有人远离您。

...我相信还有其他原因。

“不必担心基础结构，发行版，质量保证以及相关的仪式，这将极大地分散编写好的代码的注意力”

从本质上讲，我认为DevOps表示担心基础架构和版本以及QA就是编写好的代码。

在以前在非DevOps文化中工作的角色中，我遇到过许多问题，可以说，DevOps文化本可以避免的。与在非代表性平台上开发的代码有关的性能问题，开发人员不了解客户端使用的字符编码的字符编码问题，经过手工编码的部署指令，并且对于Ops团队而言没有足够的猜测能力-工作。

现在您可能会争辩说，开发和运营方面的专业化程度提高使我们能够克服其中的一些问题，但是仍然只有通过团队之间的知识和工作共享才能解决很多问题。

DevOps不必表示“ Dev现在也可以进行操作”。该术语最初的意思是“ Dev 和 Ops的人员在一个团队中紧密合作”。这确实意味着Ops员工需要变得更像Devs，因为使事物自动化需要某种编程，并且旧的手动方式不能简化它（有关这一点的更多详细说明，请参见其他答案）。

来自维基百科：

DevOps（开发和运营的复合部分）是一种文化，运动或实践，它强调软件开发人员与其他信息技术（IT）专业人员的协作和交流，同时使软件交付和基础架构变更过程自动化

因此，我认为实际上，如果您作为开发人员具有相同的旧职责，现在又具有运营职责，那似乎在管理方面是一种错误的计算。通过使事情自动化，您很有可能需要更少的Ops人员，因此实际上可以节省成本。但是DevOps当然并不意味着“让我们摆脱所有Ops员工，让Devs来做额外的工作”。

像流行语一样，语义扩散经常发生，人们突然想到“让我们也让Devs做Ops，我想我们可以省钱...”