为什么开发反对运营？

我仍然是学生，但是我对操作并不了解，而且我的英语仍然很差。

我的问题是：为什么开发反对运营？何时展开反对行动？

DevOps的要点是，开发不应反对操作，而应该互相支持。

传统上，由于瀑布式部署和大规模更新，开发会在部署时由于测试不足，更改服务器环境而导致操作出现各种问题，因此清单会不断出现。本质上，更新对于操作团队来说太大了，无法有效地部署更新而不会在过程中出现任何问题。这些问题可能就是您为什么认为发展与运营相对立的原因。

另一方面，DevOps致力于减少更新大小，减少刚性环境，并通过增加每年发生切换的次数来总体上改善应用程序在开发和运营之间的切换。随着部署数量的增加，操作的麻烦也减少了，因为它们要么自动执行了更新产品所需的大量工作，要么更好地预见并准备了更新。

Tldr：DevOps旨在通过建立一种思维模式来消除开发反对运营的理论，在这种思维模式下，运营和开发可以协同工作，从而以及时且易于复制的方式频繁地部署产品。

我认为您已经收到了一些全面的答复，但是您说英语并不好，所以我将尝试提供一个非常简短且可以理解的答案：

• 发展的主要目标是做出改变。
• 运营的主要目标是保持环境稳定。

这两件事是矛盾的。话虽如此，发展与运作不应相互反对。他们应该共同努力，以确保实现这两个目标。这是DevOps的目的。

开发与运营之间的紧张关系通常是由于激励措施不当以及团队内部进行优化而引起的。

开发人员经常根据他们可以解决并合并到代码存储库中的问题的速度和数量来判断，他们的回报通常与实际工作或正常工作的代码无关。伸缩性，性能和其他因素要少得多。

经常根据环境的稳定性和代码在生产中的运行情况来判断操作，而很少根据快速带来变更的过程质量来进行判断。

这就产生了一个问题，即激励开发人员创建大量代码并将其丢给运营团队，并且运营团队有动力接受尽可能少的更改以确保环境的稳定性。

DevOps在某种程度上可以解决此问题：

• 他们中的一些人可能是组织性的，团队的流程和动机可以改变。例如，如果开发人员的工作仅在生产中运行了一段时间后才被标记为已完成，则没有问题，并且运营团队同意拥有该代码的所有权。类似地，可以在环境仍处于一定稳定性范围内的情况下，根据接受代码的速度来判断操作。
• 解决方案的另一部分可以是交流和交叉授粉，您可以将操作人员嵌入开发团队，反之亦然。您在这些团队之间碰壁，DevOps工程师通常是这种桥接的结果。
• 解决方案的另一个部分是支持诸如持续集成和持续部署之类的流程的工具，它可以提高更改速度，同时在通过回滚代码或快速解决程序出现任何问题的情况下，保持高质量并快速恢复生产环境。投入生产。

大多数组织通过将组织分解为功能部分并要求每个部分弄清楚如何改进自身来应对复杂性。这通常称为“筒仓”方法。

重要的是要理解为什么这种孤立的方法会阻碍业务的成功，并且常常无法改善整个组织的水平。它不仅影响开发和运营-还影响大型组织中的所有其他功能孤岛，例如质量保证团队，财务，产品和项目管理。

由于每个功能筒仓的管理者被命令通过削减成本或提高速度来进行改进，因此他们的反应通常是：

• 在上一次改进工作中，我完全不知如何解决问题。请别打扰我。
• 您要我做什么，履行职责或从事改善项目？我没有时间做这两件事。
• 再没有！这是本月的另一个程序。

有了这些典型的反应，很少有高管热情地向任何执行小规模改进工作的高管表示欢迎。经理发现自己与其他职能领域在执行改进所需的资源方面竞争激烈。因此，难怪改进命令会加剧跨职能的战斗！

即使经理完成了改进项目的一部分，他也会遇到其他职能部门和其他组织（供应商，承包商等），而他们没有完成他们的工作。这减少或完全否定结果。

这种跨职能的紧张关系不仅限于改进工作。这是整个组织日常决策和管理有效性判断的核心。这是一个真实的例子：

财务经理被告知，“改善”。他决定禁止雇用价格超过市场上可接受的名义价格的承包商。他实施了新政策，并声称今年节省了100万美元。由于开发人员和IT不能雇用承包商来帮助他们使用容器和容器编排，因为这些承包商很昂贵。同一家公司的IT运营经理计算得出，如果不改善其基础架构，每月将使该公司付出10万美元的额外费用。按照这个速度，在年底之前已经耗尽了聘用承包商的年度节省。

您可以想象这两个功能区域之间的关系并不完全一样。

这些跨职能冲突是由筒仓方法驱动的，在筒仓方法中，组织独立衡量每个筒仓的改进情况。如果您是成本中心，那么改进自然就意味着可以提高筒仓内的效率或降低成本。

在此参考框架中，成本被视为遵循“加法”规则。每个筒仓的成本加在一起等于组织的总成本。因此，经理们认为他们所在地区的任何成本降低都是“好”的，因为他们看到了直接转换为整个公司的成本节省。在此参考框架中，改进工作遍布各地，以攻击整个组织的成本和浪费。

一个很好的例子，开发团队开始敏捷地工作，每两周而不是以前的每个季度将代码推送到质量检查和运营部门。质量检查和操作人员尚未准备好进行此类更改，因此应为松弛进行指责。同样，这对开发和运营中人们之间的爱并没有多大贡献。