如今的IT部门存在一个矛盾：敏捷开发者希望可以快速部署常规软件，而运维团队则优先考虑稳定性。开发和运维不同的成功指标使得每个团队都有自己独立的目标。两个团队缺乏沟通使问题更加复杂：开发团队难以觉察到目标环境的变化，而运维团队则不清楚开发团队到底在做什么。

无论具体情景是怎样的，这个问题都说明了如今很多组织都面临技术上的“对峙”。从IT的角度看，运维有责任在复杂的系统基础设施中保持其稳定性，所以规避风险成为他们偏爱的方式也不足为奇。然而从另一个角度考虑，开发团队如今配备了基于云计算的自动化工具，有办法完全绕过运维的障碍。

直面问题

一般而言对流程和规范化实施进行限制有助于运营上的业绩表现——即获得更好的业务成果，那么“稳定性重于处理数量”是一种理性的权衡。但是不要被这种刻板的流程误导，在由CA Technologies委托进行的一项全球调查 “拼装DevOps拼图”中表明，速度和质量并不是相互矛盾的。

调查显示，如今亚太及日本地区的大多数组织（69%）已经实施了DevOps，相比之前的20%有明显提升。而其中15%的DevOps实施者已经达到了 “大师” 级别。

“DevOps大师”更有可能表示他们的数字化举措对竞争力、客户维系和营业额及利润有所贡献。全球范围内，成熟采用DevOps的组织收入增加的可能性是一般组织的2倍，利润增加的可能性是一般组织的2.4倍。

在亚太及日本地区，相比那些未采用DevOps的组织，DevOps大师们：

• 提高客户维系率的可能性是未采用DevOps者的2.2倍
• 赢得更多客户的可能性是未采用DevOps者的2倍
• 提高市场份额的可能性是未采用DevOps者的 3倍
• 增加客户利润率的可能性是未采用DevOps者的2.3倍
• 获得新收入来源的可能性是未采用DevOps者的2.2倍

理解DevOps ——寻求平衡

IT运维的理想状态是能够通过快速引进高质量软件而不断推动业务创新。维持平衡则意味着要消除任何可能会破坏这种状态的障碍。

严格和标准化的运维能够实现这些目标，但不止步于此。在项目开发阶段，更快速度和更多支持的需求（配合大部分的资金投入），通常会优化应用实现更快交付，但这是以牺牲其他因素为前提的。这会导致有更多的系统难以得到维护和支持，增加运维成本上的压力。当然，只有当开发人员一味提高生产力却不对整体失衡负责时，情况才会变得更糟。

为了维持平衡，使IT部门恢复正常的运行状态，跨职能部门必须而采用DevOps的方法，将分歧放到一边。这意味着运维团队需要从幕后走到台前，帮助提高应用的质量，尤其是那些正在开发、测试和部署的应用。而对于开发团队，他们则需要将自我意识放到一边并学会接受，因为弹性、可维护性、可扩展性和安全性不一定总是最重要的，他们需要帮助来整合这些要素。这同时也说明每个人都需要站在客户的角度考虑，才会创建出更容易支持客户的应用。

尽管DevOps被视为推动企业敏捷性和紧跟客户需求的关键因素，然而在亚太及日本地区，只有一半多（52%）的受访者实施了 DevOps并具有完善的DevOps战略和目标。另外，该地区44%的DevOps采用者仍旧忙于处理安全与合规性措施工作，从平台支持和风险管理的角度来看，大多数DevOps活动仍未得到良好支持。除此之外，尽管87%的受访者认为企业利益相关者培训很重要，85%的受访者意识到要在IT内部保证足够的业务优先知识，只有31%的DevOps采用者完成了这几步。未能成功促进团队合作仍然是DevOps取得成功的重大障碍。亚太及日本地区的受访者认为，打破开发团队和运维团队之间的文化壁垒是最具挑战的任务，仅有26%的受访者实现了IT文化和谐。

采用DevOps将取得成功

当然，DevOps的成功不仅仅是依靠双方击掌合作就可以实现的。我们仍然需要高层去引导实施，因为他们可以从文化层面上进行深刻变革。企业非常需要这样的高层，他们能够围绕共同的目标将每个人团结起来，无论是对于那些热衷于业务问题的运维工程师还是分析师，使他们能够共同努力去解决问题。这一举措将会确保“生产至上”的文化与“持续的完善”紧紧相连，进而保持DevOps的稳定。