我仍然是学生，但对操作一无所知，而且我的英语也很差。

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

#1 楼

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

传统上，由于瀑布式部署和大规模更新，开发会在部署时由于测试不足，服务器环境更改而给操作带来各种问题，该清单不胜枚举。本质上，更新对于操作团队来说太大了，无法有效地部署它们而不会在过程中出现任何问题。这些问题可能是为什么您认为开发会反对操作的原因。
另一方面，DevOps致力于减小更新大小，减少僵化环境，并通常通过增加开发来改善应用程序在开发与操作之间的切换每年发生移交的次数。随着部署数量的增加，操作的麻烦也将减少，因为他们要么自动化了更新产品所需的大量工作，要么更好地预见并准备了更新。

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

评论

“每年移交的次数增加。”实际上，在功能强大的DevOps组织中，这将是连续的。持续测试，集成，交付并部署到生产中。

–特拉维斯·汤普森（Travis Thompson）
17 Mar 4 '17在2:45


我认为您不能明确地说出来。持续部署并不适合每个项目，因此必须逐案考虑。

–阿德里安
17 Mar 4 '17 at 3:13

#2 楼

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


发展的主要目标是进行更改。
操作的主要目标是保持环境的稳定性。

这两个方面存在冲突。话虽如此，发展与运作不应相互反对。他们应该共同努力，以确保实现这两个目标。这就是DevOps的目的。

#3 楼

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

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

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

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

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


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


#4 楼

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

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

每个职能部门的经理都是通过削减成本或提高速度来进行改进的命令，他们的反应通常是：


我上次改进工作完全无法解决问题。别理我。
您想让我做什么，履行职责或从事改善项目？我没有时间做这两个事情。
不再！这是本月的另一个计划。

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

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

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


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


您可以想象这两个职能领域之间的关系并不完美。
/>
这些跨职能冲突是由筒仓方法驱动的，在筒仓方法中，组织独立地评估每个筒仓的改进情况。如果您是成本中心，那么改进自然就意味着可以提高筒仓的效率或降低成本。

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

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