从近期不断涌现的风险投资、私募股权投资和收购案例来看，当前应用性能管理（APM）市场越来越受到关注和重视。作为其快速崛起的重要驱动力之一，云计算的广泛兴起为其贡献了不可磨灭的动力。毕竟大量的应用开始使用云环境作为开发和托管的基础平台，相关团队迫切需要一个解决方案来监控和管理应用的实际性能。基于这一切，应用性能管理技术的成功就变得水到渠成。但是这些应用程序和服务的客户——即为其企业购买和维护云应用程序组合的IT和业务运营团队——的态度如何？他们支持的用户希望能够为应用服务提供高水平的维护解决方案，而不管实际的应用类型。遗憾的是，目前市场上的大部分APM解决方案并不能完全满足这类用户的实际需求。出于这个原因，许多已经拥有大量系统管理和监控工具的组织——包括那些拥有庞大且技术强大的IT团队的组织——仍在寻找各种替代方案来帮助他们实现更理想的基于云的应用程序管理效能。而正是这种理想与现实的差距——加上APM领域庞大的ITBusinessOps客户群——构成了未来几年最有希望的APM发展方向。不同群体的不同解决方案显然，没有人会误认为一套源代码调试工具在IT团队的MicrosoftExchangeServer管理领域发挥着重要作用。前者与后者根本没有任何关系，因此无法带来任何实质性的帮助。虽然它提供了大量客观信息，但IT运营团队既不能利用也不能参考它。出于同样的原因，我们不能指望为DevOps团队开发的单一APM解决方案适用于使用ExchangeOnline、Dropbox、Salesforce.com或其他“黑盒”SaaS应用程序的业务运营团队。这些团队不需要登录到应用服务器，他们无法直接通过与其云应用程序接口的网络基础设施来调整应用程序代码或访问日志文件或SNMP信息。事实上，BusinessOps团队对于APM解决方案的需求可谓五花八门，每个DevOps团队可能都有自己独特的具体问题。让我们从选择性问题开始，了解技术团队之前的岔路口：服务级别管理或应用程序调优。帮助开发人员和运营商共同优化他们管理的应用程序或服务的反馈。这些团队使用APM工具来帮助他们了解特定代码或基础架构的改进空间，从而提高他们的应用程序性能和可靠性性能。相比之下，BusinessOps是特定用户群体（包括特定应用场景下的销售、营销和企业整体）与IT部门合作的产物。这些对象现在开始充当云应用程序的“消费者”，而不是传统的持有者。他们专注于确保他们的用户可以访问服务并使用他们所依赖的应用程序提高工作效率。但是，因为它涉及到一系列的应用程序和多个ISP（互联网服务提供商），所以BusinessOps团队还需要一套不同的工具来帮助他们验证和管理相关供应商的服务水平。此外，需要在自己的网络中检测和隔离问题。放手还是亲自动手DevOps团队管理应用程序性能与IT/业务运营团队管理Salesforce.com等应用程序性能的方式之间的最大区别可能是对应用程序源代码和托管基础架构级别的实际访问。对于那些第三方应用程序，业务运营团队不必担心源代码或托管基础设施。这些应该是完全“黑盒”环境，就像大多数通过网络交付的应用程序只允许用户直接访问而绝对不允许深入分析一样。出于这个原因，对这些Web交付的应用程序进行代码级调整甚至集成可以说是不现实的。业务运营团队需要使用APM解决方案来连接云应用程序中公开的UI和API并与之交互。只有这样，才能保证相关应用能够为用户提供预期的服务效果。高容量或高容量用户应用程序DevOps团队，尤其是那些正在构建托管在公共云中的消费者或B2B应用程序的团队，通常专注于单个应用程序或相对较小的应用程序组合构建和管理。但是，他们也需要测试和优化自己应用的交付效果，所以这样的小应用往往需要面对几乎无限大的用户群、远程终端、密集的代码执行路径访问。他们希望收集和分析尽可能多的数据，以便在不影响用户体验的情况下，为更多不同规模、来自世界各地的用户提供服务。需要再次强调的是，也正是因为如此，塞入原托管主机的解决方案才具有如此重要的现实意义。相比之下，业务运营团队面临着不同的问题。他们通常要处理和管理的用户群体和接入点相对有限且更熟悉实际情况，因此他们需要相关的解决方案，使他们能够更顺利地管理来自多个供应商的大量且不断增长的应用程序组成——无需他们自己为每个应用程序执行协议和语法的细节。由内而外还是由外而内如果您是应用程序托管服务提供商，您肯定希望能够从网络外部的远程端点获取准确反映应用程序性能的数据——毕竟，服务的实际用户是重要的是在那里并注意他们的具体感受，对吗？无论您采用的解决方案是对云环境中的存在点(POP)进行全面监控，还是通过被动/真实用户监控(RUM)解决方案来跟踪应用程序内部的代码，作为DevOps团队，我们倾向于保持较高的对“由外向内”应用程序性能观点的关注程度。业务运营团队需要采取不同的控制方向。在大多数情况下，他们面对的是用户通过内部办公网络访问基于云的应用程序解决方案。在这种情况下，在提供商的托管存在点之外运行的监控解决方案通常效果不佳，因为它们不遵循所谓的“第一英里”原则——也就是说，它们不从最近的点开始工作的存在。企业自身网络环境的ISP/接入点位置用于性能测试。这是一个巨大的差距，因为大多数应用程序可用性和性能问题的根源都在于这个“第一英里”区域。如果您仅从云环境监控云应用程序，几乎不可能在问题实际影响用户之前发现并解决问题。易用性或分析深度服务提供商可以勾勒出一组清晰的业务用例，以验证各种资源在APM解决方案的集成、部署、培训和实际管理中的投资状况。如果你不能提供高质量的用户体验，那么用户肯定不会继续使用你提供的应用，有效扩展以支持更大的用户群自然会成为一句空话。对于仍处于开发阶段的组织，应用程序服务提供商也具备必要的技能和流程，可以有效地将他们自己的应用程序与APM解决方案集成，并解释他们提供的特定数据。另一方面，业务运营团队专注于支持他们的业务和用户。对于他们来说，APM是实现既定目标的一种措施和手段，旨在帮助他们尽可能地提高工作效率和实际效果。他们是真正的运营团队，而不是软件开发团队，因此需要大量复杂集成和/或脚本编写技能的解决方案对他们来说太麻烦了，尤其是在应用程序组合不断扩展的企业中。他们利用的云应用程序在易于管理方面具有显着且越来越受欢迎的优势。同样，运营团队自然希望他们的APM解决方案具有相同的特性。业务运营团队需要的是一种解决方案，能够实现广泛的分析功能，涵盖当前受监控应用程序的数量和交付，以及用户与云应用程序本身之间的端到端网络路径级别。他们不关心是否可以将特定应用程序的登录时间缩短100毫秒，因为这样做没有明显的积极好处。相比之下，他们希望尽可能检测关键用户交易的执行流程，避免那些几秒就能完成的处理任务被延长到十几秒甚至二十秒。如果是这种情况，IT团队需要能够及时识别此类问题的根源——即使是从业务网络环境外部——并采取有效措施来解决这些问题。BusinessOps——新的DevOps显然，使用云应用的BusinessOps团队所需要的APM解决方案有很多特点，我们不能直接将适合应用服务商和DevOps团队的现成产品应用到他们身上。虽然市场上已经有很多自称为“企业级APM”的解决方案，但这些产品往往针对的是其托管应用运行在自己的服务器或虚拟机环境中的技术团队，而不是云应用运维。团队。尽管名称相似的应用程序性能管理工具，但针对BusinessOps团队的解决方案却大不相同，甚至应该被视为该类别中的一个全新类别的产品——APMforBusinessOps。那么这应该构成一个利基市场吗？目前，答案可能是肯定的。但随着亚马逊、谷歌、微软等众多大佬全面进军云计算领域，所有迹象都指向同一个结论：无论规模大小，内部云应用和服务在整体应用组合中的比重都将越来越大实质性的并继续增长。因此，虽然DevOps的APM浪潮似乎已经达到顶峰，但下一波用于业务运营的APM才刚刚到来。也就是说，这不是岔路口，而是下一场革命的前奏。英语：http://www.apmdigest.com/apm-at-a-crossroad-in-the-cloud
