宜信无侵入智能业务运维实践（分享实录）

随着IT基础架构的不断演进，微服务和云原生技术已得到越来越广泛的应用，各个系统或服务之间的调用关系也变得纷繁复杂，如图列出了一些知名互联网公司的微服务调用关系，最左边是淘宝的，中间是亚马逊和奈飞的，最右边是我们宜信核心业务线的服务流图谱。可以看到，这几家公司内部的微服务调用关系都是相当的复杂，甚至形成了蜘蛛网状。对于这样复杂的服务调用关系以及海量的服务调用，就自然会导致出现问题时很难快速定位了。

在这种情况下，监控系统的重要性就凸显出来了。在企业信息化的建设过程中，监控系统也经历了多个发展阶段，从最早的作为独立的系统、独立的成本中心，到引入到运维流程化自动化，再到结合IT运维支撑和赋能上层业务。未来，我们认为一个好的监控平台，将与业务系统紧密结合无缝衔接，从业务支撑演进成为业务本身不可或缺的一部分，从以往的独立成本中心演进成为公司业务的重要竞争优势。

从业务可持续性调查报告（Business Continuity QuickPoll）的大数据分析结果来看，随着企业规模的增大，关键业务宕机造成的损失从小型企业的每小时1万美元，到中型企业的每小时损失4万美元；再到大型企业，5000人以下规模是每小时损失22万美元，5000-10000人规模是每小时损失近50万美元，而10000人以上规模企业是每小时损失近166万美元。由此可见，关键业务的宕机往往会给企业用户带来巨大的损失。

然而现状却是不管是在互联网还是在企业内部，都广泛存在着 IT运维和业务运维 割裂的情况。对IT运维而言，当IT运维团队发现系统响应时间、错误率上升时，往往因为存在大量的服务调用和复杂的服务调用关系，难以迅速定位问题，所以也不知道具体影响了哪些业务、部门和用户，在这种情况下企业的损失、成本的消耗也就无法准确地衡量、及时地补救。而对业务运维而言，当业务团队发现转化率、活跃用户、收入、KPI迅速下降时，往往也因为难以定位问题，不知具体原因，所以无法及时给出解决方案，或者出现多团队多部门之间解决方案不明确的情况，在这种情况下公司的业务、健康状况都会受到影响。

说回我们宜信，大家都知道宜信是一家互联网金融公司，公司现有业务线比较多，普惠业务和财富业务涉及的系统交互大多会跨多个业务线和多个系统，需多系统协作护航。以老客0次到店贷款业务为例，该业务流程复杂且涉及系统间交互也较多，涉及27个模块，40余名技术同事参与其中。在老0业务上线之初，曾多次出现客户反馈的问题，由于无法快速定位问题系统，造成客户长时间等待甚至流失；技术需要串多个系统定位问题，解决问题效率低下；运营同事也因无法及时给出解决方案，增加了工作压力。

在这种情况下，业务运维的重要性就凸显出来了。那什么是业务运维呢？

二、什么是业务运维

我们认为业务运维是立足于IT，并结合IT运维赋能业务的运维方式。业务运维的具体方式是采用全流程数字化技术，通过辅助风险防范和故障定位来降低技术运维成本，通过量化业务表现和提升用户体验来提高业务运营效率和价值。业务运维可以助力技术运维团队和业务运营团队及时发现短板、持续优化和改进业务。

总的来说，以往的传统运维方式仅能保证IT系统活着，而业务运维可通过全流程数字化技术化被动变主动、快速定位问题并及时解决问题，从而有效提升用户体验。所以不仅能保证活着，还能使公司关键业务活的更好。

此外，业务运维也是监控产品未来的一个重要发展方向。我们认为对于应用性能管理（APM）类监控产品，未来会往2个方向发展：

• 第1个方向是业务运维，属于横向拓宽，从横向扩展业务边界，从而实现从APM应用性能管理到IT支撑业务的发展；

• 第2个方向是AIOps，属于纵向深入，从纵向深挖性能和体验层面，并提供IT数字化信息化的智能解决方案。

三、业务运维的落地实践

接下来介绍业务运维在宜信的具体落地方式。

首先是需要有 IT系统层面的监控运维软件。谈到监控运维软件，实际上目前业界常用的监控软件有很多，但主流的大体有深度和广度这2类。

关注监控广度的代表产品是Prometheus，其特点是生态圈活跃，针对常见的互联网中间件（如MySQL、Redis、Kafka、RocketMQ、MongoDB、ElasticSearch等）均提供了现成的指标采集插件来进行监控。类似产品还有Zabbix、Nagios和Open-Falcon。

关注监控深度的产品也有很多，如听云、OneAPM、PinPoint、SkyWalking。这类软件一般是探针型的，在应用性能监控方面提供了更深入的监控能力。

这些平台各有优势，但也存在不足之处：

无法兼顾监控的广度和深度两方面的能力；

无法同时支持实时指标（Metrics）、调用链（Tracing）和日志（Logging）这三类监控数据的采集，并考虑这三部分功能的集成连通性，解决数据的时效、品控、对齐等问题。

为了克服上述不足，同时满足公司多样化和智能化的监控需求、降低二研的成本和难度，宜信科技中心自主开发了全维监控与智能运维基础平台（UAV）。

目前为止，UAV已提供了包括应用监控、应用环境监控、服务流、调用链、数据库监控、JVM监控、日志监控等多个维度的监控和分析能力，并支持了以上所有功能在容器云平台上的无缝迁移和使用。

然而UAV仅是IT层面的监控产品，主要支撑IT运维（只提供了系统层面的监控能力，如对主机、中间件和应用性能的监控），但不直接支持公司业务。如何更好地支持好公司业务，体现产品的业务价值，是监控团队着重思考的方向。此外，对业务系统而言，一般仅提供了对本系统内业务的监控能力；对跨越多个业务系统的业务流程的监控，也一直是企业流程监控中的一个难点。

为了解决跨多业务线多系统的监控与运营痛点，宜信科技中心全新推出了一套完全无侵入的智能业务运维平台，提供了零成本配置接入、业务全链路跟踪、业务-IT双向追溯、故障根因分析、告警智能降噪、工单自动生成、实时报表展示等一站式服务，这样就赋予了产品面向业务和服务的主动运营的能力；使得在IT层面上可以快速定位问题系统的同时，在业务层面上也能给出受影响或波及的具体业务单据和客户范围，从而可以有效解决IT运维和业务运维的割裂问题，达到直接赋能业务的目的。

具体做法是提供了一套通用的业务链路监控与告警的接入平台。

首先，平台提供了SDK供各业务组埋点业务事件的日志，以便建立业务事件与IT层面调用链的双向关联。当有实际业务发生时，监控Agent会同时采集目标监控应用上的业务事件日志和IT调用链数据，并将这2类数据上送给监控后台。

监控后台提供了如图所示的一系列可复用的“积木块”，包括对异构业务日志的数据切分、过滤、聚合计算等；之后可以将结果持久化，并提供具有业务涵义的链路查询和业务报表的大屏展示；也可以根据结果告警，发出具有业务涵义的告警消息，同时自动生成业务工单。

具体接入实施时，各业务组首先在应用中埋点具有业务涵义的日志，然后自助化配置对业务日志的解析逻辑，也可以配置业务告警策略和告警消息模板的内容，从而可以快速搭建针对自身业务的链路监控系统。平台功能涵盖了业务链路监控、业务告警和业务实时报表。

总的来说，我们提供的是一套通用的业务链路监控的接入平台，由各业务组帮助我们共同构建公司级完整的业务链路监控体系。各业务组只用关心各自系统的接入，由平台负责链路关联、根因分析和告警部分，从而达到1+1>>2的效果。

这套业务运维系统的好处在于：

首先，它将IT层面的调用链与业务事件双向关联，给IT层面的调用链赋予了业务涵义的同时，将跨系统的调用跟踪升级为跨业务领域的跟踪。

其次，发生问题后，平台既可以发出具有业务涵义的告警消息，将业务问题直接反馈给业务运营人员；也能根据调用链 快速定位到问题节点，从而帮到技术运维人员；此外，技术运维与业务运营人员都可以通过业务标识反查系统链路来追溯问题。

但现有方案存在2个问题：

它不是完整的端到端的业务流程监控。调用链仅仅是一次请求/响应的IT链路，而一次普惠线上贷款业务完整的业务环节有很多步骤，涉及独立的IT链路一般都超过20个，单条IT链无法覆盖对跨多个业务线和多个应用的完整的端到端业务流程进行监控；

需业务组各自在应用中使用SDK埋点业务日志，这也是实施过程中最大的痛点：

首先，公司内各项目组常态化忙于实际业务项目，难以抽时间在各自应用中专门引入SDK包并埋点业务日志；

其次，固化的埋点逻辑调整困难，需修改后才能重新上线；当业务流程发生变化时，埋点逻辑也不能及时调整。

所以在现有的业务链路监控与告警接入平台的基础上，我们提出了一个“完全无侵入的业务流程监控”的优化方案。

四、完全无侵入的业务流程监控

首先，在业务数据的获取上，不再需要各业务组使用SDK埋点业务日志，可以通过无侵入技术，采用配置化的方式提取关键业务环节的业务数据，并且支持运行时热生效，应用无需重启。

说明下无侵入技术，目前宜信自研的UAV和开源的Apache Skywalking等监控软件采用的都是javaagent的premain技术，在java类加载时修改字节码，类加载后无能为力，无法运行时热生效，所以目前每次安装完UAV或skywalking之后，业务应用需要增加启动参数并重启才能被监控上。

而在本无侵入方案中，我们采用了agentmain技术，Java类加载后可再次加载，即重定义。也就是说，在业务应用丝毫不改动且正在运行的情况下，可以根据配置热修改应用中的任何类的任何方法，提取方法的输入/输出数据作为业务数据。

上图是流程节点的样例配置。业务流程的每一个节点都是这样配置出来的。比如样例配置了人脸识别这个流程节点对应着签约应用中BizController类的process方法的执行，并且可以提取方法的输入和输出数据作为流程节点的业务状态数据。

此外，该样例节点定义了bizId和state等变量，用于存储该节点待提取的业务状态数据。其中：bizId变量拟从方法的第一个输入参数$1的bizId字段中提取，数据类型是字符串，提取方式是OGNL；state变量拟从方法的输出参数$_的state字段中提取，数据类型是字符串，提取方式也是OGNL。

使用Java虚拟机底层的热加载技术，运行时修改字节码并动态生效，这样就做到了对业务应用完全的无侵入和无感知，业务项目组无开发工作量。

其次，本方案中业务流程是按各个应用实际执行情况来自动生成和自动绘制的，走到咨询节点时绘制出咨询节点，走到申请节点时绘制出申请节点，走到合同签约节点时绘制出合同签约节点；通过业务标识和调用链标识的对应关系，对跨公司多个业务线和多个系统的完整的端到端业务流程进行监控。

第三，业务流程模板也不用手工建模，是根据实际执行过的业务流程实例汇总获得的，并且汇总时考虑了并发和分支的情况。业务流程可按需随时通过修改配置来调整，调整后业务流程模板随实际业务执行的流程而自动改变。此外，本方案在系统中增加了业务类型属性，从而可以将经过同类系统集合的业务流程按不同的业务类型进行染色，进而拆分成多个业务流程。

最后，公司项目也提供了流程数据统计汇总，类似京东618和天猫双11活动当天的大屏监控，业务流程模板上每个节点上都可以展示变化的统计业务指标。

以上就是业务流程的配置化和自动生成、按业务类型染色拆分，以及流程数据统计展示的基本原理。

五、业务运维无侵入方案的总体介绍

1）首先，用户可以通过Web前端界面来配置流程节点信息。流程节点配置信息可以按业务系统的维度进行配置和维护，并统一保存到配置中心。流程节点配置信息包括流程节点名称、待提取数据类的类名、待提取数据的目标方法以及根据方法的输入和输出参数填写的OGNL表达式。

2）其次，配置中心可以将各个业务系统的流程节点配置信息分别下发到预先部署在对应业务系统中的监控代理终端（监控Agent）。监控Agent是具体部署在各个业务系统的宿主机上的独立JVM进程，负责根据配置中心下发的流程节点配置信息来执行对流程节点数据的抓取，并将抓取到的流程节点数据发送到监控后台系统。此外，当应用重新发布或容器重启后，配置中心会将流程节点配置自动重新下发，以防止无侵入配置在应用重启后失效。

3）监控Agent在接收到下发的流程节点配置信息后，可在业务应用正在运行的情况下，通过热抓取的方式，获取与流程节点配置信息相对应的流程节点数据，具体采用了之前介绍过的Agentmain代理、字节码修改、OGNL提取等业务数据抓取技术。之后监控Agent会将抓取到的流程节点数据上送给监控后台系统。需要说明的是，由于监控Agent是根据配置中心下发的流程节点配置信息抓取特定的流程节点数据，而不是对链路数据的全量采集，仅采集流程节点配置信息中定义的流程节点的业务数据，抓取的数据更加精确，降低了监控后台系统后续的数据处理量。

4）监控后台系统可以接收各个监控Agent以HTTP或MQ等方式发送的流程节点数据，之后会根据业务标识和调用链标识对接收到的各个流程节点数据进行梳理和组织分析，并按流程节点的处理时间排序，从而得到跨业务系统的业务流程流转信息。

5）基于业务流程数据，后续的流程自动生成和自动绘制、业务流程的跟踪、业务流程模板的生成、按业务类型染色拆分，以及流程数据统计展示即可依次实现了。

总之，本方案在不需要对各业务应用代码进行任何改造的基础上，实现了对跨业务系统的业务流程的监控，是一种对应用完全无侵入和无感知的监控方法，各业务系统项目组无开发工作量。

无侵入是指本方案不会修改应用的源代码，是一种对于应用的源代码无侵入的方式。

无感知是指本方案在修改应用底层逻辑的二进制字节码之后，应用无需进行重启，便能够即时生效，是一种对处于运行状态下的应用的无感知的方式。并且跨系统的业务流程可以在各个业务应用正常运行的情况下按需随时配置和调整，运行时热生效，应用无需重启，调整后的业务流程即时上线。当业务流程发生变化时，通过添加、删除和修改流程节点的配置，就可以按需随时添加流程节点、删除流程节点和调整流程节点，实现对业务流程的灵活监控。

六、根因分析

首先，业务运维平台接入的告警支持多模式预警，包括单次类预警、聚合类预警和自定义预警。

• 单次类预警是出现即预警模式，适用于重要的业务环节。

• 聚合类预警是在滚动时间窗口内发生N次的预警模式，适用于关心服务整体可用性的场景；如果该告警同时影响了多个用户，则会给出受影响的用户数量和具体用户列表。

• 此外，也提供了自定义预警能力，可以通过配置Flink SQL或自定义脚本来满足定制化业务告警的需求。

业务运维平台可以收集各个已接入渠道的告警，先通过告警过滤将其中重复的告警和不重要的告警过滤掉，再进行关联分析。

业务运维平台中最重要的关联关系就是通过业务链路和IT调用链路建立的强关联关系。其次，也可以通过画像建立与IT类监控数据的关联，比如宿主机与虚拟机、虚拟机与应用服务器、应用服务器和应用、应用和服务组件/客户端组件之间的关系。再次，通过对接DevOps平台，业务运维平台可以按业务指标波动时间线关联配置变更，与服务变更和发布数据建立起关联关系。此外，关联关系也可以是通过机器学习算法建立的，比如同一时间窗口同时变化的指标，可能存在某种关联。需要说明的是，金融行业本身的业务特点决定了对第三方存在依赖性，因此告警的随机性较大，客观上导致学习样本的质量不高。因此，业务运维平台目前使用前三种强关联关系。

关联分析之后是权重计算。权重计算允许用户自定义设置权重值来引导根因分析结果，可以根据预先设置的各类告警的权重，计算成为根源告警的可能性。最后将权重最大的告警标记为根源告警。

最后，还可以根据历史告警处理知识库，找到类似根源告警的推荐解决方案。

在根因分析和定位的过程中，顺带实现了告警收敛和智能降噪。比如我们对重复告警、非根源的一般告警、同一条链路的其它告警，以及偶发问题重试自行恢复的告警进行了压制。如图中所示的这个例子是从A应用到B应用再到C应用并访问数据库的调用链路，当C系统查询数据库出现超时后，告警会层层往前传递，导致A、B均有超时告警发生；此时，根因分析会将告警进行收敛，直接分析出根源告警为C系统访问数据库异常。

七、业务运维平台示例

可以看到，在发给业务运营同事的告警邮件中，内容细化到X年X月X日X:X:X，在X个系统的X个业务环节，发生了X问题，影响了X类型的客户，客户姓名是X，手机号是X。而在发给技术运维同事的邮件中，在业务同事邮件的基础上，额外提供了IT调用链路，以方便技术运维同事快速定位和诊断问题。此外，如果该告警同时影响了多个用户，则会给出受影响的用户数量和具体用户列表。

最后列出了业务运维平台的部分界面，UI涵盖了业务链路监控、业务告警和业务实时报表。此外，根因分析生成的业务告警会自动提交给工单系统，工单系统会实时通知相关团队进行处理。业务运营同事也会定期查看工单处理情况的统计汇总，督促相关团队解决。

八、总结

目前在宜信，智能业务运维平台已成为业务部门实现主动运营的利器。总的来说，我们提供的是一套通用的业务链路监控的接入平台，由各业务组帮助我们共同构建公司级完整的业务链路监控体系。各业务组只用关心各自系统的接入，由平台负责链路关联、根因分析和告警部分，从而达到1+1>>2的效果。

这套业务运维系统的好处是：提供了零成本配置接入、无侵入业务数据抓取、业务全链路追踪、业务-IT双向追溯、问题自动发现、故障根因分析、根源快速定位、告警智能降噪、工单自动提报和实时报表展示等一站式服务，赋予了产品面向业务和服务的主动运营的能力；使得在IT层面上可以快速定位问题系统的同时，在业务层面上也能给出受影响或波及的具体业务单据和客户范围，从而有效解决了IT运维和业务运维的割裂问题， 极大提升了业务运维的问题处理效率，达到了直接赋能业务的目的。

总的来说，全流程数字化的业务运维可以有效助力技术团队和业务运营团队及时发现短板、持续优化和改进业务。智能化的业务运维未来无疑将成为业务本身不可或缺的一部分和公司业务的重要竞争优势。

目前UAV全维监控已经在GitHub上开源，下面是开源网站和开源代码地址，欢迎大家试用。

官方网站：https://uavorg.github.io/main

开源地址：https://github.com/uavorg/uavstack

作者：宜信技术学院 谢知求