【扯淡篇】APM，IT能力的一面镜子

在国内，APM很火，一部分是受资本市场的推动，另外一部分是它给人感觉找到了核心痛点，解决了IT中的大麻烦。可我觉得需要冷静的看，APM就是你的IT能力的一面镜子，特别是服务端代码级APM。

去年10月份关注到APM的特点和价值，于是和公司自动化测试组和统计分析组启动了APM专项工作，他们分别实现服务端APM和客户端APM。在页面端的实现主要是依赖W3C的Timing Api的标准实现，提供标准化JS，供业务嵌入页面代码中，在运维侧的推动下，也覆盖了核心业务。这部分的性能数据能带来一些收益，特别是和竞品去对比分析的时候，有非常客观的数据作为基准。不考虑功能的情况下，单纯就速度而言，的确也能代表用户体验,下图是某个业务的页面性能视图。

回到服务端性能监控，我们的业务有两类语言，一类是PHP，一类是JAVA。PHP，我们使用了Xhprof（http://pecl.php.net/package/xhprof），Facebook搞的一个php性能数据采集的方案；JAVA端，我们选择了淘宝的TProfiler（https://github.com/alibaba/TProfiler）做性能监测的方案UProfiler。服务端性能监测的方案在3月份上线，但运行一个多月就给下线了，不得不承认这是一个看上去很美，但是很失败的项目。为何？

▌▌▌原因一、预设了一个错误的场景

这个场景就是为了性能管理，而性能管理，我把它分成两个方面，第一个是性能问题发现，第二个是性能优化。

对于性能问题发现，我拿我们14年Q2/Q3的事件数据做了一次分析（如下图），其纵坐标是影响时长，发现排名前几次的故障因素：系统设计、硬件故障、产品研发质量不可靠（如版本问题）和网络问题等等。我再深入到产品研发质量不可靠之中，发现性能导致的问题为0。由此可见，从性能角度来看，APM带来的价值的确不高，大家也可以拿自己的故障数据统计分析看看。如果一个业务经常出现性能问题，那就是研发、测试和运维都出了问题，比如说研发代码质量不高、架构不合理、测试性能测试没做等等。

再来看看性能优化，最初设想通过性能来驱动研发优化也是一个理想状态。在一个产品功能驱动的业务上，性能优化驱动力很弱，因为它的目标是成本。至少从目前来看，个人见过的能力管理都是在资源能力管理（资源瓶颈），而更上层的服务能力（性能瓶颈）和业务能力管理（业务瓶颈）都没有实现。而往往对于一个互联网公司来说，对于其核心业务来说，成本不是考虑的重点，而非核心业务，资源占用本来就很小，一则管理的粗放性必然存在，二则通过虚拟化，成本就更不是问题。目前最成功的资源容量管理案例还是我之前所在的腾讯部门，通过容量系统持续推动资源占用的优化，但毕竟还是池子那么大，一点的优化带来的效果都是不同。当时的驱动力这是看资源的使用率，如果是低负载，则需要缩容，也没有深入到程序级性能优化层面。

在一个不断满足产品功能需求的企业中，没人去关心程序性能，大部分扩容解决了，当然性能不要太糟。

▌▌▌原因二、和现有的运维措施重叠

说到更细致一点其实就是和我们当前的运维监控方案重叠。有次和做APM的朋友交流，当我们向客户推荐APM产品和价值的时候，一定要准确识别对方的监控能力水平，找到互补地方，APM则可能被应用。

基于端到端的监控方案，让你大大降低对APM的依赖，但我一定是到接口级别，不到代码级。我的实践是，从一开始运维要求研发必须把接口级的性能数据日志标准化（定时汇总），通过采集和分析日志，可以实现接口监控，无须到代码级（如图）。随着后期名字服务对统一调度的接管，该数据采集成本更是大大的降低，可以不依赖研发，通过调度来统一实现。在LNMP架构中，很多业务的性能问题，大部分都是数据库的引起（没加cache、索引不对、请求突增等），真正性能方面的疑难杂症少之又少。

▌▌▌原因三、方案的数据成本很高

我们都知道服务端APM是基于程序执行路径（包含RPC调用）来做性能管理，数据代价非常之高。当时我们在一个500次请求的服务上，开启了Java程序性能嗅探，每个小时积累的原始数据是上G。一切都是因为一次请求进入到系统之后，在代码级的性能嗅探会产生大量的日志，后来使用了抽样方法和TCPCOPY环境启用APM方法来规避这个问题。而采用接口级的数据方案，则是几十M级别。

而APM在某些场景下，依然能看到它的价值，具体的价值分为运维价值、业务价值、IT能力价值：

▉▉价值一、业务拓扑自动发现（运维价值）

自动的业务拓扑发现，对于一个频繁进行架构调整的服务来说，意义很大，运维可以不依赖研发提供架构图的情况下，实现对业务技术架构的可视化管理。而更重要的是，基于该业务拓扑，可以做告警的RootCause分析和收敛，这是每个告警系统都需要依赖的拓扑。

▉▉价值二、业务体验管理（业务价值）

我把这部分的价值更多的归于客户端的APM体现，而非服务端的APM能力。由于客户端的APM考虑了公网网络、基础设施等因素，给出的性能准确而全面。对于一个面向用户的业务来说，产品人员拿到这个指标之后，和竞品进行对比分析，会不断驱动研发、运维优化。

▉▉价值三、检视企业IT能力水平的不足（IT能力价值）

从这个角度来说，初创企业和传统企业应该非常钟情于APM，而在传统企业中那些遗留系统更希望通过APM来帮忙发现性能问题。个人觉得越依赖APM的企业，恰恰是IT能力越不足的企业，更准确的说是互联网技术能力的不足。

随着微服务的实践加深，复杂代码级的性能问题会转移成服务级的性能问题，而服务间的性能问题可以通过接口级监控来实现。接口级性能监控也两种不同的实现，人工探针的实现，通过在程序代码中嵌入性能监测API来收集数据；另外一种就是自动化的实现，这个地方的实现思路也有几种。如果是底层的协议通信接管，在协议底层详细记录服务调用数据；或者把服务间的调用对象都抽象成服务名，在名字服务调度中心就可以把服务间的调用数据实现对研发透明采集、分析展现。让Dev就提前考虑并实现Ops的需求，这也正是DevOps倡导的。

而现实是很多研发从一开始的时候并没有考虑服务的可监控性，而把这个问题留给了人肉运维，如果在应用容器或者框架方面做一点努力的话，带来的收益就很大。当前我们的WEB容器里面集成了很多标准化的服务，在每个服务内部都集成了运维监控的能力，比如说jws.dal集成了对mysql的访问监控、jws.dal.cache集成了mc的访问监控等等。所以有APM的销售问我是否有需求，我说没有的原因也在于此。

因此对于想应用APM的企业来说，一定要准确的知道，希望APM给你带来什么，是性能问题发现（监控）、性能优化（运维优化）还是用户体验改进（产品改进）还是架构改进。在性能问题发现层面上，它和你当前的手段是否有重叠，分析下到底有多少性能问题；在性能优化的层面上，更要仔细的检视APM带来的优化推动力，更多的是关注你的企业是否已经形成成本导向的驱动力；对于用户体验改进，这个应该是落脚力最强，当然还是要结合企业实际来看，比如说银行系统的用户体验问题，已经不仅仅是速度的问题，而更多的是产品设计的问题。

对于互联网运维来说，更不要以为APM会让运维的存在感大增，应该回归本质，把提升服务的运维标准化、IT架构公共化能力和可运维性作为运维解决之道。