由“监控”发展而来APM，已经演变成跨越许多不同的计算平台上的管理应用程序性能的概念。高效的开发运维能够实现部署更快速、出现问题更少，正因如此，Google、Amazon、Netflix、Facebook以及无数初创公司热衷此道，而性能监测更是其关键之一。应用性能管理工具可以在整个应用开发生命周期针对性能提供深入分析，还能促进开发、测试与运维部门之间的协作，跟踪自动化测试的性能并进行分析，识别异常和性能问题。

图1  Dynatrace大中华区技术总监Wilson Lai

Wilson Lai（如图1所示）是Dynatrace的大中华区技术总监，从业二十余年以来，经历了从桌面到移动端的演变，以及从开发、测试到运维完整的应用开发生命周期。在高效开发运维兴起的今天，Wilson是如何看待APM？通过数字化性能管理手段了解每一个用户的需求和感受，并作出分析决策，帮助企业提升用户体验，从而实现应对移动互联网下的机遇与挑战，CSDN对他进行了专访。

CSDN：请简单介绍一下您以及您所在的APM领域。

Wilson Lai：大家好，我是Wilson Lai，我的从业经历非常简单，过去二十几年都是在美国的软件厂商工作，从一个PC级的数据库厂商到Compuware，即Dynatrace的前身，先后负责开发工具、测试、APM，从开发、测试到运维，与整个应用开发流程很匹配。

目前，我在Dynatrace公司负责技术性以及整个大中华区的售前工作，帮助潜在客户去了解他们自身对于APM的需求并提供相应的解决方案。除此之外，也会帮助一些用户计划他们整个APM的流程。APM对于整个企业来讲，是一个非常漫长的过程，不同的企业有着不同的要求，Dynatrace会基于自身的经验以及企业需求来帮其规划APM（如图2所示）。

图2  Dynatrace工作原理

应用性能在几年前比较集中在监控方面，而APM是近五年才开始起步，增长速度越来越快，市场的机会也越来越大，主要有以下几方面原因。

• 真正的监控：过去，许多企业只专注于基础平台与设备，集中做网络监控、服务器监控。在平台建好后，下一步就是应用。所有的企业业务都与应用挂钩，网购、金融等服务的背后都是一大堆的应用。因此，真正的监控并不是纯粹从基础设备开始，而是来自应用的部分。

• 用户体验：许多人对APM的理解仅限于应用性能的监控或管理，但这个性能有着广义的含义。为什么我们要提供一些应用去服务用户？APM除了速度之外，用户体验也是很重要的版块。

• 性能与业务的挂钩：无论系统跑得快或慢，只要对整个业务没有影响的话，可能不会太被关注。所以，在整个APM领域，另一部分就是怎么把性能和业务挂钩，这也是一个很重要的议题。

• 完整的APM解决方案：在中国我们也看到，这几年有许多本土的APM厂商兴起，但却存在一个问题，就是大部分只集中在APM的一两个层面上，并不能为用户提供完整的解决方案，因为APM本身就是一个非常广泛的存在，包含主动监控、被动监控、探针等方式，没有一个单一的方案可以解决所有问题。从这个角度来讲，一个完整的APM方案提供商，必须能够完备地提供满足用户需求的不同组合。

• 数据互联：将这些数据进行整合也很重要。

CSDN：从您的角度讲，APM应用性能管理能够为企业和开发人员带来什么样的好处？

Wilson Lai：从单一角度来讲，APM是一个可视化的工具与平台，它可以告诉用户整个系统的所有情况。说得再详细一些，从开发、测试到运维，有着不同的参与部门。APM的目的是为了提高整体的效率、质量和性能，但每个团队关心的地方并不一样。举个例子，运维希望主动发现问题，并快速定位故障。他们不会关心怎么去修改代码，而是要在短的时间内将系统恢复，提供服务给用户。但开发者则可能需要查看代码级的问题，并收集相关信息。同时，测试对于APM也是有要求的。测试部门是一个很重要的把关，在进行压力测试、功能测试等时，为了确保效率，尽快解决问题，就需要APM提供一些丰富的指标。

虽然APM技术性很强，但其实应用开发的整个生命周期都与之紧密相连。从业务需求发起，透过开发构建应用，测试过关就走到了运维，但运维不是终点，还有一个关键就是：我推出一项服务，这个服务是不是有人在用？是不是可用？哪个部分在用？这些数据也要收集回来，这就是APM可以提供的部分，覆盖了整个移动开发的生命周期。

CSDN：那么，Dynatrace在整个应用开发的生命周期中，具体提供了哪些服务？

Wilson Lai：这可以分几个角度来看。首先，从开发人员角度，他们主要关心如何提高开发效率、进入生产环境能否快速解决出现的问题以及定位问题时能否提升效率等。在开发过程中，会进行功能测试，但功能测试存在一个问题，常常会每天持续地整合，早上开发、晚上测试、第二天看结果，只知道通不通过，而无法深究其原因，这就集中在一个指标上，就是功能。

在进行测试时，如果测试人员能够多收集一些指标，就能更早判断应用的质量。对此，我们会有一些传统的想法，例如，在整个开发过程中，先将功能做好，优化应用，然后测试，后再上线。就与小朋友学习一样，老师会讲每天都要看书温习功课，而不要临时抱佛脚，在考试前一两天才温习。

每天做测试，可以大程度降低风险，因为在产品上线的后几天根本无暇应付。开发也是同样的道理，前面的功能做得很好，要到后面发现性能有问题时才进行修改，已经对先前的代码造成影响。糟糕的还有另外一种情况，就是整个开发过程与预期相比有所延长，要是再压缩测试，势必会造成测试效果不好而仓促上市的局面。

现在有一个比较好的方法就是，在测试过程中将其他性能指标拿出来，好能自动化做一些管理。这样即使在功能上出问题时，进行修改也不会影响其他性能指标，能够让开发者很放心地将应用推到测试环境中。

另外，在进行测试时，尽量将所有问题都找出来，当然这只是理想状态，测试人员无法将发现所有Bug，有时甚至会出现一些无法预期的问题。因此，问题定位显得尤为重要。好的情况是，在生产环境收集不同状况，出现问题的话，直接进行数据分析，这也是APM能提供给开发人员的一些好处，对于快速解决产品出现的质量问题是非常有帮助的。

CSDN：是自动收集问题直接上报？

Wilson Lai：对的。收集、上报，好能很深入地定位到代码级的信息，这样就不会重现问题。如果相关信息都有的话，就能够很快判别这究是怎么回事儿？错误在哪个点？后，开发人员再自己确定解决的方法。

CSDN：这个从技术层面来讲，具体是通过哪些技术手段来实现的？

Wilson Lai：刚才讲的有一点趋向于应用监控，举个例子，基于当下主流平台，许多APM厂商都会通过一个标准的界面去搜集一些性能数据与指标，界面是标准的，而收集的东西也基本类似。Dynatrace有些做法不一样，在做整个产品的天就考虑到两个重点，，它必须要在有很大压力的环境下可以不对应用产生影响，即主要在开销上，在考虑一个产品时，要将其影响降到低。因为一般来讲，在监控应用时会有一些工具，但开销很大，不可能将它放在生产环境中。

图3  交易节点剖析

第二，许多应用都采用分布式系统，完成一个交易会有着很多节点（如图3所示）。而APM厂商在分析这个问题时，就不可以把那些不动的节点拆开看，而应该单一去看。到目前为止，市场上所有的应用监控厂商，都是个别节点收集数据。没有APM，开发人员就需要浏览Log，看日志痛苦的莫过于像大海捞针一样去查询数据，更痛苦的是每一个服务器都有日志，这就表示，要从不相连的“海”里抽出数据，还需有人手将它串起来，这是非常浪费时间的过程，会严重影响到开发人员的效率。

而Dynatrace的优势之一就是跨节点，可以做到自动追踪节点的交易，开发者无需对应用进行任何改动，就可以把所有节点的内容统一放在一个界面上，这样用户就可以查看到整个交易。

图4  Dynatrace可视化界面汇总

此外，在呈现时，每一个点的所有信息都已经汇到界面中（如图4所示），偶尔看个日志信息，就不用到文档、系统中搜索查询，只需右击即可选择进入相应界面或显示内容。而为了让开发者在定位到问题时能够快速进行代码修改，Dynatrace还整合了一些现有的开发工具，通过已有的专利技术（如图5所示），可以直接实现第三方集成，并实现相应的功能与效果，比如，PureStack便揭示了基础设施健康对应用性能和终用户体验的影响。

图5  Dynatrace专利的PurePath与PureStack技术

CSDN：您认为目前国内APM处于一个什么样的现状？相较于国外APM而言有哪些优势与不足？

Wilson Lai：国内外厂商有一个很明确的地方就是，从技术层面来讲，都集中在整个APM范围的其中一两块，没有一家是每一个技术都有，只会解决用户的某一些问题。而对于企业来讲，它的应用是林林总总的，而非单一的一两类App，如果再扩容的话，可能就需要几个厂商的方案，在整合与管理中势必会产生一些问题。这是目前我们看到的大的问题，往后怎样还有待考察。

而相比之下，其实国外APM相对好一点，因为起步比较早，技术比较成熟，客户也更为广泛，所以相对稳定。中国也算起步，越来越多的厂商加入进来。几年内正是厂商兴起的阶段，未来则会发生整合、并购等类似于生态环境的改变。