APM现状和痛点

上图是一个比较经典的运维部署架构，其中的真实用户是基于APP、网页或者是小程序，并通过网络设备访问后端，而后端包含有一些基础架构。这些架构之前可能是建立在私有云或者自建IDC机房，现在有很多是构建在公有云之上，例如Docker、Kubernetes等。另外，还有各种各样的应用程序，例如Nginx、Apache Tomcat等；不同的编程语言，例如Java、.Net、Go、Python等；多种数据库，例如MySQL、Oracle以及其它NoSQL、NewSQL。

APM是做什么的呢？第一代APM主要做的是主动拨测，例如企业可能会在全国各地布很多点，模拟用户操作，通过网络设备访问真实的后台系统，测试系统的可用性。后来，模拟用户操作已经不能满足我们的需求，能不能涵盖真实的用户场景呢？所以，我们通过SDK的方式来访问后端基础架构，看看在真实用户场景下是否会出现卡顿、白屏、崩溃等异常情况。现在出现了很多小程序，其本质上也是HTML 5或JavaScript，所以也可以用类似的方式来测试。

以上主要做的其实是用户体验的监控，而现在APM不仅需要监控技术，也要监控基础架构，例如针对不同的编程语言，插入Agent，抓取调用关系、事务等，形成端到端的打通，实现全链路监控。当我们进行一个操作时，可以获取到响应延时，如果慢了的话，还可以知道是前端慢还是后端慢。

我一直在思考一个问题——运维中出现的问题是平等的吗？更具体一点说，每天遇到的海量报警都一样重要吗？这些报警是否也遵守2/8原则？哪些警报是真正紧急、影响业务的？被影响的业务有哪些？是否为核心业务？如何来补救呢？……

基于以上问题，我们发现在做端到端全链路监控时，运维和业务还是割裂的。例如，从运维角度看，系统的响应时间和错误率上升了，但是无从得知真正影响的是哪些系统。从业务角度看，虽然可以看到一些指标下降，也会接到各种用户投诉，但是他们不知道用户不满意的真正原因，真正投诉的是哪些系统、哪些报警。而从公司角度看，一个问题可能横跨多个部门，所以很难去衡量企业的损失。

在互联网场景中，业务方经常会看到一些指标下降，例如转化率、收入、活跃用户等，他们不知道原因，所以将问题反馈给运维部门，而运维部门查看了网络、CPU等，往往会发现一切正常。通常，想要确定出现某个问题的真正原因，需要经过多个部门，例如运维、研发、网络，甚至包括它们的子部门，而在这期间，公司的业务和健康状况时刻都在受到影响。

在企业场景中也是如此，例如审批系统或办公系统响应慢，点击“提交”之后需要等很久，这会直接影响到业务方。而从运维的角度来看，可能OA、网络、数据库、吞吐量、CPU等都是正常的。

出现这些情况的关键原因就是缺少IT和业务之间的桥梁，所以，今天我们就讲讲如何在IT和业务之间架构桥梁，以解决企业痛点。对于运维来说，很多时候IT是一个成本中心的角色，但我们不希望它仅仅是个成本中心，而是能够走向业务，拥抱业务，真正成为企业的核心力。

什么是APM深水区？

之前运维的目标是保证系统稳定安全，尽量不出事，能够让客户用起来。而现在，我们能不能做得更好一点呢？从运维走向运营，关注用户在使用系统时的感知、体验，关注运维和开发是否能够实现快速交付。

这就需要我们在运维和业务之间构建一座桥梁，在系统的左侧显示运维相关的场景，例如错误列表、追踪结果、前端用户反馈、敏捷度等等。而在系统的右侧展现业务的角度，量化DevOps敏捷的成熟度，显示帮助业务做了哪些事情。例如，之前解决一个问题可能需要一个小时，但是现在只需20分钟，节约的40分钟对于业务有何种程度的提升。

业务运维具体是怎么做的呢？我们认为可以分几步走：
首先是业务指标监控，将业务和IT关联起来，当我们在进行一个操作的时候，可以关联到它的调用关系，如果出现异常情况，业务方可以定位到这是什么操作，具体关联到哪些IT异常。假设响应时间太长，那么就对响应时间进行切片，获取详细分解。这样，我们就建立了一个业务和IT比较初级的溯源。

其次，我们可以做一些业务级的告警。以前只能看到系统的整体错误率，即当天系统有多少异常、报警，但是无从得知业务的可用性和健康状况。在很多情况下，IT系统可能没有问题，但是业务性能已经下降了很多。单从CPU或硬盘等一个角度的信息，很难衡量业务的可用性及健康状况，所以我们要结合积累的所有数据来衡量，从业务层面反馈一些变化。另外，对于一些业务指标的下降，我们能不能提前做一些预警，通过业务信息来反推IT信息。

第三，当我们在做业务追踪时往往会看到用户的投诉，比如某个用户投诉响应太慢了，一般情况下，用户都会有一个唯一标识的用户ID，根据这个ID可以在系统中查看到用户进行了哪些操作，每个操作调用了系统的哪些关键环节，可以快速定位到具体的问题。如果是订单系统，也可以根据唯一标识符抓取到详细信息。

第三，以前做IT监控时，我们看到的只是一个事务，IT请求发过去，不超过几秒，这个事务就返回来了。但是当业务和IT关联起来，就不再只是一个简单的、几秒钟的事务，而是一个业务流。如果是做贷款申请，申请提交之后，后台收到申请会有贷款审批员进行审批，而审批过程可能需要跨部门，最后由放款员来决定是否能够放款。贷款申请的业务流历时多天，横跨多个不同的业务应用系统，把整个业务串联起来。从业务角度来看，业务流关注的不再是一个事务的好坏，而是整个业务流程的好坏。

最后，结合所有的信息，我们可以做业务上的刻画。在不同的企业场景中，使用的度量单位也不尽相同，用户发生的错误、业务的可用性等等都需要刻画。

运维+AI已经有很多老师分享过了，也有很多企业在实践，但是我希望能够在此基础上加上业务信息，真正做到自动化，解决实际的用户体验问题。当我们能够把积累下来的IT数据和业务数据关联起来，那么在很多情况下就不需要人工做判断，而是可以实时、自动的发现潜在的IT系统瓶颈，甚至是业务系统瓶颈。

发现业务瓶颈之后，我们能否结合相关数据一键定位到潜在根因，例如网络访问出现问题的原因可能是河北某个地区的某个运营商出现问题，又或者是某个订票网站与第三方的对接出现问题，导致一小部分用户体验受到影响。传统做法是根据经验判断，或者通过大量的检索和推理来做根因分析。那么，现在我们是否能够根据数据及特征自动找到潜在根因。

技术原理

如果把运维和业务结合起来，确实能够提升企业效率，帮助运维再上一层楼，但是如何去构建运维和业务之间的桥梁呢？所以，我想和大家分享一下我们的技术原理。

APM的原理是什么？一般来说，APM有几种不同的方案，第一种方案是在代码中进行自定义，当有方法要实现时打入日志，通过日志进行总结或计算。这种方式的劣势在于需要改代码，如果是新加入公司的同学，往往会漏掉相应的代码规范，那么系统就很难总结信息。另外，因为打入的日志是非结构化的，日志也会不停变化，随着时间推移，APM监控的系统和现在的系统可能不一样了。

另一种方案是字节码技术，以Java、.Net等虚拟机语言为例，BCI技术的优势在于不需要进行任何代码级的修改，可以利用Java机技术自动获取信息，并且可以将得到的Class文件进行变换，并且在变换时添加想监控的东西。如果是针对C语言、Go语言等编程语言，可能还需要去做一些埋点。

一般来说，我们会在虚拟机内部Load 这个Class，获取性能数据，然后再把它打入到Class中，当加载Class时，就可以把想要的代码替换到原来的文件中，这就是数据获取的原理。

除了性能数据，我们还需要获取业务数据。如果是在前端，可以通过HTTP请求的URL参数或者Header去获取。前端业务数据比较好获取，如何把后端业务数据也获取到呢？举例说明，假设有个Product类，每个Product有个ID，在Web Service层有个调用方法是get product by Order，根据Order的ID获得相应的Product。其中，方法的参数、Order ID、Product类都可以通过BCI技术获取。另外，如果它有返回值string，那么我们可以通过方法的参数或返回值获取。这样，通过程序调用的业务信息都可以利用同样的方式获取到。同时，这个方法中的Product是个Object，不是个类，那么可以通过虚拟机的技术获取到，进行一些简单的数据聚合，形成业务视角。

在构建业务和运维之间桥梁时，也会遇到很多挑战。

第一个挑战是全面数据获取能力。我相信每个团队、每个系统都多多少少会有数据获取的能力，但是如何把前端、后端、数据库等所有数据都全面获取到，这是一个难点。

第二个挑战是全量获取数据能力，这比第一个挑战更难。我们花了一年时间去重写了Agent架构。为什么这样做呢？因为我们在做业务运维时发现，这和传统APM性能不一样，传统方式可以接受数据抽样，抽样10%、20%就可以在重大事件发生时，体现出相应的异常和错误。而业务运维如果做抽样的话，那么只能取得部分数据，无法覆盖到所有受影响的用户，所以只能获取全量数据，而这对于前端和后端的压力是非常大的。重写之前，我们调研了很多探针架构，发现它们都无法支撑，所以我们自己重写了一个新的探针架构。对比新旧版本，我们发现，全量数据获取的效率已经高于以前抽样数据获取的效率，时间更省，效率更高，获取的数据更全。

第三个挑战是数据处理、分析能力。因为获取到的是全量数据，所以信息量很大，对数据处理和分析的能力提出了挑战。业务数据存在数据库中可能只有一行，但是对于运维来说，这一行数据可能横跨多个调用链，分布在不同的机器、容器上，所以如果想要分析出一个结果，运维要处理的数据量远大于业务数据量。另外，如果想要灵活处理、分析数据，对机器查询能力的要求也是非常高的。

最后一个挑战是对新技术的支持。现在出现了很多新技术，例如Kubernetes、容器、分布式、Serverless、边缘计算、IOT等，这些新技术应该如何去支持业务呢？

上图是我们整体的架构图，数据源包括移动App、Web网页、传统APM的模拟拨测、ITIM、日志和NPMD。在数据采集层上面会有一个数据接入层，针对不同的数据类型做简单处理，例如探针管理、数据预处理、数据聚合等。再上一层是数据存储层，有点类似于数据中台，我们会做一些和存储相关的工作，在不同的应用场景下，存储结构也有所不同，例如可能需要把非结构化存储的日志转化成结构化字段。再上一层是数据分析层，主要是分析引擎、数据引擎和机器学习引擎。最后是业务表现层，主要包括的是业务方真正可以用到的东西，例如控制台、仪表板、业务大屏等。

实际案例

听了上面的这些内容，有人可能会觉得比较宽泛、不具象。接下来，我就讲讲具体的实际案例。

如何定义数据结构？抽象来看，我们认为业务系统是一个树状结构，底下会有子业务系统，再往下可能还会有孙子业务系统。而业务系统包含两个部分，一个是用户操作，一个是业务流。用户操作就是字面意思，比如用户通过点击按钮去完成登录、审批、支付等操作。而操作之间会形成业务流，例如订单处理的业务流，先下单，之后由仓库来处理，然后快递员处理，整个业务流的场景可能是要横跨不同的IT系统。

上图是一个电力场景，该场景主要是做供电管理，包括提供供电方案、查看场地、设计检查场地建设、竣工验收、装表装电等。因为这些工作涉及不同的人，有在室内办公的、有在现场勘查的，同时国家对于工作的完成时间也有限制，只通过IT系统是很难衡量这些指标。所以，我们希望能够把不同系统的信息都获取到，并从中量化出相关指标，例如正在进行中的业务流的数量、报错的业务、平均执行周期等等。

另外，我们希望能够从业务视角下钻到运维，例如当前整体业务系统的可用性是多少、受影响的用户有多少、错误有多少，下钻到运维，我们可以看到主业务中的子业务数量、孙子业务数量，甚至可以具体到子业务的操作。

在用户投诉的场景中，我们在接到了用户投诉发送短信失败的工单之后，就可以把用户ID或者手机号输入到系统中，查找到用户发送短信失败的根因，具体的IT错误。在此基础上，我们可以把系统中所有类似的IT错误都搜索出来，找到可能受影响用户的相关信息，例如ID、邮箱等，去做用户关怀，或者及时做修正。

刚刚我们关注的都是运维错误，其实我们常被业务方投诉，是因为业务错误。什么叫业务错误？以支付场景为例，当银行卡余额不足，会报业务错误或提示交易失败，当交易达到上限，会报业务错误。而业务错误是无法在IT系统中体现的，但是站在业务方的角度，这些都是IT系统的错误，所以，我们需要整体通盘的考虑这个问题，找到一个比较好的定义业务方错误的方法。

为什么说APM走到了深水区？最开始的APM是端到端监控，主要是监控用户体验和应用性能。后来，我们可以抓取到业务信息，这时要思考如何把IT数据和业务数据关联起来，并做一些多维度的机器分析和可视化。数据关联之后，我们又开始思考，是否还能结合AI技术，进行智能根因诊断、异常检测、效率提升等等。

如果企业能够综合上图的四个阶段，结合IT视角和业务视角，那么一定可以给到用户更好的决策推荐，帮助他们完成业务目标。

作者介绍：
赵宇辰，听云 CTO，美国伊利诺伊大学芝加哥分校，机器学习和数据挖掘方向博士。拥有十多项美国和国际专利以及多篇最佳学术论文，同时是最早将 AIOps 产品化的实践者之一。

创作场景

APM 深水区：构建连接运维与业务之桥