DevOps的承诺十分明确。然而，企业构建应用程序的方式变更可能引起团队之间的反感。
有时候，运维人员认为开发人员坐在自己的象牙塔里，整天写代码，希望快点发布程序，无视现实世界的制度约束。开发人员则视运维为灾难预言者，一直声称IT基础设施会在新代码的压力下崩溃。企业的变革脚步正在加快，创造更大、更复杂的应用，某种程度上，两者之间的关系愈加紧张。
归并观念冲突不容易。企业必须打破这两个群体之间的隔阂，让他们以一种更加合作的方式开展工作。此外，运维需要引入必要工具来实现自动化变更管理流程。只有经过这些步骤，DevOps文化才会深入团队。
聚焦变更管理流程
企业处于不断变化的恒定状态。
“通过改变业务流程，产品和用户服务，公司可以抓住需要立快速响应以及立即采取行动的新机遇，”Bill Claybrook，马萨诸塞州New River Marketing Research公司总裁说。
DevOps帮助他们实现了这一目标。这种IT文化将开发测试与系统运维紧密的联系在一起。两个团队更紧密的合作并实现自动化部署过程，不需要再关注运维如何辛苦地上线新服务。结果就是新版本能更快也更频繁地发布。某些情况下，变更几乎是不间断产生，例如Amazon Web Services每11.7秒就会部署一次软件更新。
DevOps的快速步伐会给运维和开发带来压力。企业需要持续设计与测试更大规模和更复杂的产品。Microsoft Office 2013 Professional占用约700MB磁盘空间，由数十亿行代码构成。让一款应用程序中的所有元素很好的协同工作，对开发和运维来说是个充满挑战的过程。
超越软件的变更
除了软件变更，公司还需要不断改善，增加新系统，升级现有设备，招聘和解聘员工。
“许多IT部门都在纠结如何让系统跟上移动、社交和云解决方案的步伐，”企业系统管理软件公司IDC的研究副总裁Mary Johnston Turner说。
随着变更次数不断增加，也会出现类似人为错误的可能。DevOps团队可能会推送1000次变更，其中可能有一个可能会造成干扰引发问题。
公司“近视”威胁到DevOps文化
沟通是系统缺陷的主要原因之一。业务部门、开发和运维都是根据设定的流程进行合作。这就像不同的团队各自拥有小块的应用程序拼图，有时候，近视、误解与不信任会产生涟漪效应。当团队从不同角度解决同样挑战时，也必然会出现误传。存在的问题既浪费精力又徒劳无功，最后会导致所有的后果都推到替罪羊身上。
开发周期越后面出现的问题，造成的创伤性影响也越大。例如在即将推送的更新中，开发人员重写了几个运行在New York Stock Exchange上的应用程序shell脚本。
“整个系统崩溃了，几乎有一小时无法进行交易，”顾问兼软件工程师Bob Aiello说，结果造成了数百万美元的损失。（他是《Configuration Management Best Practices: Practical Methods that Work in the Real World》一书的联合作者。）
严苛的业务流程
当系统出现故障时，首先需要通知运维，运维的职责在于维护系统的可用性。员工与企业越来越多的依赖100%可用性的IT服务。面对潜在的宕机风险，运维人员对稳定性的价值十分珍惜，并且对可能导致维护与宕机的变更有抵制，因为执行这类变更往往会导致服务器故障并影响声誉。更少的变更意味着减少可能出现的故障。此外，故障排除也会随着系统处于恒定的变更状态而愈加复杂。
为了保护基础设施，IT运维团队经常会为开发者设立近乎苛刻的流程。例如，英国政府支持的Information Technology Infrastructure Library（信息技术基础设施库，ITIL）是一套IT服务管理设计最佳实践，设计用于提供满足企业需求的IT服务。流程包括如何处理变更管理，但开发人员通常会抱怨说，这些东西十分繁琐，也不必要。
要培养长期的DevOps企业文化，企业就必须取得平衡。运维必须更有效地应对变化。监控系统变化是个耗时并有挑战性的工作。今日，系统自动化工具如Puppet Labs Puppet和Chef，已经能够企业更快更有效的提供IT资源。
开发者需要看到他们的工作对业务的其他方面产生的积极或消极后果。一个办法是让他们带寻呼机，这样在出现问题时，能实实在在的感受到混乱以及支持人员那种紧张。这种同情会在新版本中潜移默化，让他们更明智。
DevOps试图将运维与开发更紧密的结合在一起。从理论上讲，引入DevOps文化有助于满足企业快速变化业务的需求。
投入是值得的。根据Puppet Labs的调查显示，把开发和运维紧密联合起来，提高了部署速度并降低了变更事故率的时间以及从故障中恢复的时间。但是，这些好处只有在两个团队都意识到需要互相支持，并且公司投资新工具简化资源配置流程下才能得以实现。
