的IEEE DevOps Unleashed研讨会上周，我们致力于提供“关于如何通过加速整个企业的软件交付来更快地创新的专家建议”。这显然意味着DevOps是实现这一目标的好方法，我完全相信这一假设。
但是在山景城计算机历史博物馆的活动中，演讲人花了相当多的时间来讨论现实世界中对许多DevOps实现普遍抵制的根源，以及如何克服人们对DevOps最终会变成的完全可以理解的恐惧这意味着每个人都要更努力地工作，而且还要付出更多的努力！
“这很自然，”主持人说第一版他是Chef的副总裁，并合著了两本与开发相关的书(精益企业:高绩效组织如何在规模上创新,持续交付:通过构建、测试和部署自动化的可靠软件发布)，因为DevOps对组织的所有部分都提出了新的要求。
弗雷德里克•保罗
DevOps如何影响业务人员
Humble说，在DevOps环境中，业务人员突然不得不花更多的时间与工程师交谈，这是一个他们可能并不总是喜欢的任务。例如，忙碌的营销人员可能不会倾向于把时间花在担心他们过去可以忽略的技术问题上。
DevOps如何影响开发人员
与此同时，软件工程师现在不得不与业务人员交谈。汉博指出，在很多情况下，人们成为工程师的全部原因是，他们不需要和其他人交谈。
而这仅仅是开发者所面临的改变的开始。Humble说，在许多组织中，开发者通常是根据简单的(如果经常是愚蠢的)指标来衡量的，比如他们写了多少行代码。DevOps提供了一套新的、更复杂的开发人员指标。
DevOps如何影响IT运营
Humble说，在瀑布开发环境中从事IT运维工作的人员可能已经习惯了“每18个月就会有一些糟糕的事情发生”。在DevOps环境中，“现在它总是出现。”他指出，尽管这些发布版本应该与瀑布式发布版本截然不同，但运维人员最常见的反应是，“请停止它!”
该怎么办呢
对于大多数人来说，自然的反应是创建一个障碍——在许多组织中，它采取了变更管理实践的形式。Humble声称:“我们的目标是确保这种改变永远不会发生。”这种抗拒很容易理解:人们害怕失败，害怕失去工作，Humble说，许多公司使用精益原则(包括DevOps)作为“解雇很多人的隐喻”。
汉博说，如果人们害怕了，“他们就会想尽一切办法阻止你，让整个事情停止。”他说，为了防止这种情况发生，你必须清楚地表明，这种改变不是解雇或裁员，而是学习新技能和对自己所做的事情负责。
研讨会的演讲者指出，开发人员喜欢抱怨DevOps如何让他们把所有的时间花在测试上，而没有时间编写任何代码。Humble指出，这可能是个问题。“但这比开发人员编写代码而不关心它在现实世界中如何工作要好。”
他总结道:“开发者并不愚蠢或邪恶。“但如果他们从未体验过自己行为的后果，他们就不会做得更好。”
参见Jez Humble的演讲:企业DevOps:打破开发和IT运营之间的障碍．