Richard+Gerdis

为了维持平衡，使IT部门恢复正常的运行状态，跨职能部门必须采用DevOps的方法，将分歧放到一边。这意味着运维团队需要从幕后走到台前，帮助提高应用的质量，尤其是那些正在开发、测试和部署的应用。

如今的IT部门存在一个矛盾：敏捷开发者希望可以快速部署常规软件，而运维团队则优先考虑稳定性。

开发和运维不同的成功指标使得每个团队都有自己独立的目标。两个团队缺乏沟通使问题更加复杂：开发团队难以觉察到目标环境的变化，而运维团队则不清楚开发团队到底在做什么。

无论具体情景怎样，都说明了如今很多组织都面临技术上的“对峙”。从IT角度看，运维有责任在复杂的系统基础设施中保持其稳定性，所以规避风险成为他们偏爱的方式不足为奇。

然而，从另一个角度考虑，开发团队如今配备了基于云计算的自动化工具，有办法完全绕过运维的障碍。

直面问题

一般而言，对流程和规范化的实施进行限制有助于运营上的业绩表现—即获得更好的业务成果，那么“稳定性重于处理数量”是一种理性的权衡。

但是，不要被这种刻板的流程所误导，在由CA Technologies委托进行的一项全球调查“拼装DevOps拼图”（这项全球在线调查于2015年7月由CA Technologies赞助，行业分析公司Freeform Dynamics执行，面向1442名高级IT经理和企业高管，并对主要行业的高管进行了深入的电话访谈。）中表明，速度和质量并不相互矛盾。

调查显示，如今亚太及日本地区的大多数组织（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采用者完成了这几步。

未能成功促进团队合作是重大障碍

亚太及日本地区的受访者认为，打破开发团队和运维团队之间的文化壁垒是极具挑战的任务，仅有26%的受访者实现了IT文化和谐。

当然，DevOps的成功不仅是依靠双方击掌合作就可以实现的。我们仍然需要高层的引导实施，因为，他们可以从文化层面上进行深刻地变革。

企业非常需要这样的高层，他们能够围绕共同的目标将每个人团结起来，无论对于那些热衷于业务问题的运维工程师还是分析师，使他们能够共同努力解决问题。这一举措将会确保“生产至上”的文化与“持续的完善”紧紧相连，进而保持DevOps的稳定。