面向服务架构（SOA）及敏捷编程技术都是要以更快的速度变更复杂的业务应用。然而，真正的业务敏捷性是在不牺牲应用性能或服务质量的前提下更快地进行更多的应用变更。

　　依我之见，要达到业务敏捷性的前提意味着要防止应用性能问题。由于IT运营团体的应用问题解决流程是流线化的，他们开始意识到自己也得在运营生命周期中尽早防止问题产生。换句话说，应用性能问题的数量取决于：1）应用建设模式对产品环境的适应程度；2）应用更新管理的好坏程度；3）缺陷与问题知识库在组织内共享的好坏程度。那些问题驱动着开发兴趣的不断增长以及与运营的协作（DevOps*能克服我们跟运营的障碍吗？）。我们来逐个审视一番，并理解一下为什么。

　　1）应用建设模式对产品环境的适应程度。IT员工应将软件架构师和开发者设计的应用服务模型映射为已有的由物理、虚拟或云设施组成的资源环境。这个映射活动随着应用复杂性的增长已经成为一项工程工作量。由于这项工程工作期间的失误，组织有多达50%的部署要返工。回滚可能由于不正确的IP地址等配置有问题而导致。那种类型的问题在缺乏运营经验的开发者管理这项应用工程工作时会产生。回滚也可能由于替换分布式组件引起不可预期的性能问题。那种类型的问题发生在负责运营的家伙对应用设计几乎没有洞察力，但却在管理着应用工程工作。在进行工程工作时，需要同时运用开发和运营的技巧才能避免那些问题产生。

　　2）应用更新管理的好坏程度。返工发生在多层web应用部署是新事物时，我进行的研究表明，当企业从客户/服务器架构转向多层web应用时，应用更新周期从半年一次变成了每月一次。现在，我开始掌握到SOA和敏捷编程的结合意味着每周一次（有时候甚至是每日）的更新频度。依我看来，很显然，还在利用为半年一次的更新所设计的版本管理工具来进行每周一次的应用更新，结果将会是表现很差的应用。当那些版本管理工具是由具备硬件和操作系统配置经验但缺乏对应用设计和工程的了解的基础设施管理员来使用时，应用性能的质量甚至会更糟。如果目标是不牺牲应用性能的业务敏捷性，那么应用的开发和运营团队就需要新的工具来对更新进行管理。

　　3）缺陷与问题知识库在组织内共享的好坏程度。来自开发团队的缺陷知识极其有用，因为它允许运营团队去建立设施规避的办法（比说在问题出现或开发服务器重启时增加硬件）。这些规避方法在购买时间供开发团队解决问题的同时保护了应用性能。来自运营团队的问题知识是有用的，因为它允许敏捷开发者改善其应用设计，以便下一次进行应用功能开发时能获得更好的性能。因此，依我看来， 很显然，开发和运营之间的沟通越困难，应用性能问题就越多。企业开发和运营团队的鸿沟应该要靠协作来弥合，以便改善应用性能。有效协作就是能让不同的团体在恰当的时间让恰当的人分享合适的信息。

　　因此，就我而言，下一代的应用管理解决方案必须聚焦于这些议题身上以便防止问题产生。在开发和运营之间培育协作应当成为那些解决方案的一个基础能力，如果它们想提供真正的业务敏捷性的话。

　　注：DevOps，简而言之就是能令业务更加敏捷的一切东西，泛指一切可抚平开发和运营鸿沟的东西。