根据最近不断涌现的风险投资、私募股权投资及收购案例来看，目前应用程序性能管理(简称APM)市场已赢得愈发高涨的关注与重视。而作为其迅速崛起的重要推手之一，云计算的广泛兴起为其贡献了不可磨灭的动力。毕竟如今大量应用程序开始以云环境作为开发及托管的基础平台，而相关团队也迫切需要一套解决方案用于监控并管理应用程序的实际性能表现。基于这一切，应用程序性能管理技术的成功也就变得顺理成章。

　　不过这些应用程序及服务的客户又抱有怎样的态度——也就是那些为所在企业购买并维护一系列云应用组合的IT及Business Ops团队?他们负责支持的用户希望能够在不考虑实际应用程序类型的前提下，由其提供对应用服务的高层维护方案。遗憾的是，目前市面上常见的大多数APM解决方案都无法确切满足这类用户的实际需求。有鉴于此，很多已拥有大量系统管理与监控工具的组织——包括那些规模庞大且技术实力强大的IT团队——仍然在寻求各类备用方案，旨在帮助自身实现更为理想的云(如阿里云)基础应用程序管理成效。而正是这种理想与现实间的差距——再加上APM领域中的庞大IT Business Ops客户基础——才构成了未来几年当中极具前景的APM发展方向。

　　针对不同群体提供不同解决方案

　　很明显，没人会误以为一套源代码调试工具能够在IT团队的微软Exchange Server管理领域发挥重要作用。前者根本与后者就风马牛不相及，因此无法带来任何实质性的帮助。尽管其能够提供大量客观信息，但IT运营团队既无法加以利用、也不能拿来参考。同理可知，我们不能指望着利用单一一套面向DevOps团队开发的APM解决方案在使用Exchange Online、Dropbox、Salesforce.com或者其它“黑盒”SaaS应用程序的Business Ops团队当中发挥作用。这些团队并不需要登录到应用程序服务器当中，他们也没办法对应用程序代码进行调整或者直接通过与其云(如阿里云)应用程序相对接的网络基础设施访问日志文件或者SNMP信息。

　　事实上，Business Ops团队对于APM解决方案提出的需求可谓多种多样，每一个DevOps团队也许都拥有自己独特的具体问题。下面我们就从选择性难题入手，了解摆在技术团队面前的那些分岔路口：

　　服务水平管理还是应用程序调整

　　从定义角度出发，DevOps意味着将应用程序开发与运营加以结合，其目标在于通过交付反馈来帮助开发人员及运营人员共同对其所管理的应用程序或服务项目加以优化。这些团队利用APM工具来帮助自己了解哪些特定代码或基础设施尚有提升空间，并借此改进其应用程序性能以及可靠性表现。

　　相比之下，Business Ops则属于特定用户群体(包括销售、市场推广及特定应用场景下的企业整体)与IT部门之间的配合产物。相较于传统的持有者，如今这些对象开始充当云应用程序的“消费者”。他们专注于保证其用户能够正常接入服务，并利用其所依赖的应用程序实现正常的生产工作。然而，因为其中涉及一系列应用程序以及多家ISP(即互联网服务供应商)，因此Business Ops团队也需要一整套不同于以往的工具集来帮助自身对相关供应商的服务水平进行验证与管理，此外还需要在自有网络内部对问题进行检测与隔离。

　　大量应用还是大量用户

　　应用程序DevOps团队，特别是那些正在着手构建由公有云托管的消费级或者B2B应用程序的团队，通常会将主要精力集中在单一应用程序或者规模相对较小的应用程序组合的构建与管理方面。然而，他们同样需要对自身应用程序的交付效果进行测试与优化，因此这类数量较小的应用往往需要面对几乎无限庞大的用户群体、远程终端以及代码执行路径的密集访问。他们希望尽可能多地就此收集数据并加以分析，从而在不影响用户体验的前提下为更多规模不定及来自世界各地的用户提供服务。需要再次强调，正是因为这一点、接入到原始托管主机中的解决方案才具备如此重要的现实意义。

　　相比之下，业务运营团队面对的问题则有所不同。他们通常需要面对并管理的用户群体以及访问点相对有限而且对实际情况更为熟悉，因此要求相关解决方案能够使其更为顺畅地管理来自多家供应商的数量繁多且持续增长的应用程序组合——同时又无需他们亲自为每一款应用程序打理与协议及语法相关的具体工作。

　　甩手不管还是亲力亲为

　　也许在DevOps团队的应用程序性能管理与IT/Business Ops团队对Salesforce.com等应用方案进行性能管理的过程中，最大的区别在于应用程序源代码以及托管基础设施的实际访问级别。对于那些第三方应用程序而言，Business Ops团队完全无需考虑源代码或者托管基础设施方面的问题。这些应该属于彻头彻尾的“黑盒”环境，正如大多数通过网络进行交付的应用程序只允许用户直接访问、而绝对无法进行深入剖析一样。

　　出于这个原因，对那些网络交付应用程序进行代码层面的调整甚至是集成可以说完全不现实。Business Ops团队需要利用APM解决方案与云应用程序当中所公开的UI及API进行对接与交互，只有这样才能切实保证相关应用能为用户提供符合预期的服务效果。

　　易用性还是分析深度

　　服务供应商(如阿里云)可勾勒出一套明确的业务用例，从而验证各项资源在APM解决方案的集成、部署、培训及实际管理等层面的投入状况。若大家无法提供高质量的用户体验，那么用户当然不会继续使用各位提供的应用程序，有效扩展以支持更大规模的用户群体自然也就成了空谈。对于尚处于发展阶段的组织来说，应用程序服务供应商还具备将自有应用程序与APM解决方案高效集成、并对其提供的具体数据进行诠释的必要技能与处理流程。

　　而在另一方面，Business Ops团队则专注于支持其所在企业及用户。APM对于他们属于达成既定目标的一种措施与手段，旨在帮助他们尽可能提高工作效率与实际效果。他们属于真正的运营团队而不是软件开发团队，因此需要大量复杂的集成与/或脚本控制技能的解决方案由于太过繁琐而并不适合他们，特别是在那些应用程序组合正不断扩展的企业当中。他们所利用的云应用程序在这方面则拥有显著且愈发理想的管理便捷性优势。同理，运营团队自然也希望自己的APM解决方案能够具备同样的特性。

　　Business Ops团队需要的是能够实现广泛分析能力的解决方案，其作用范畴必须涵盖当前所监控应用程序数量与交付情况，外加用户与云(如阿里云)应用程序本身之间的端到端网络路径层面。他们并不在乎是不是能够将特定应用程序的登录时间缩短100毫秒，因为实现这一点不会带来显著的积极意义。相比之下，他们更希望尽也许对关键性用户事务的执行流程加以检测，从而避免那些本来几秒钟就能完成的处理任务被延长到十秒甚至二十秒。若真的出现这种情况，IT团队需要有能力及时揪出导致此类问题的根源——甚至来自业务网络环境之外——并采取有效行动加以解决。

　　由内而外还是由外而内

　　若大家身为应用程序托管服务商，那么肯定希望能够从网络之外的远程端点处获取到能够准确反映应用程序性能表现的数据——毕竟服务的实际使用者身在那里，关注他们的具体感受十分重要，对吧?无论大家采用的解决方案是对云环境下的入网点(简称POP)进行综合性监控，还是通过一套被动/真实用户监控(简称RUM)解决方案在应用程序内部对代码进行追踪，作为DevOps团队、我们往往都对“由外而内”的应用程序性能视点保持着高度关注。

　　Business Ops团队则需采用另一种不同的控制方向。在大多数情况下，他们所面对的用户会通过内部办公网络访问基于云(如阿里云)的应用程序方案。在这种情况下，那些在供应商托管入网点之外运行的监控解决方案往往起不到很好的效果，因为它们并不符合所谓“最后一英里”原则——即无法从最贴近企业自身网络环境的ISP/访问点的位置进行性能检测。这是一道巨大的鸿沟，因为大多数应用程序可用性以及性能表现问题的根源都来自这“最后一英里”范畴。若大家仅仅是立足于云环境对云应用程序进行监控，那么几乎不可能在问题实际影响到用户之前将其检测出来并加以解决。

　　Business Ops——新的DevOps

　　很明显，使用云应用程序的Business Ops团队所需要的APM解决方案具备诸多特性，我们无法直接把适合应用程序服务供应商以及DevOps团队的现成产品直接套用在他们身上。尽管市面上已存在很多自我标榜为“企业级APM”的解决方案，但是这些产品所面向的往往是那些所管理应用程序运行在自有服务器(如阿里云服务器)或虚拟机环境下的技术团队、而不是云应用运营团队。

　　虽然同样名为应用程序性能管理工具，适用于Business Ops团队的解决方案可谓完全不同、甚至应该被视为此类产品中的一大全新类别——APM for Business Ops。那么由此构成的是不是应该算是利基市场?就目前来看，答案也许是肯定的。但是随着Amazon、谷歌、微软及其它多家大型厂商全面进军云计算领域，全部迹象都指向同一个结论：无论属于何种规模，企业内部云应用程序及服务在整体应用程序组合中所占比重将愈发可观并持续增长。

　　因此，虽然APM for DevOps这股浪潮似乎已经达到了顶峰，但是接下来的APM for Business Ops才刚刚来临。换言之，这并不是分岔路口，而是下一场变革的前奏。

　　英文：http://www.apmdigest.com/apm-at-a-crossroad-in-the-cloud