开源其 AIOps 落地三大利器

UAVStack 是智能化服务技术栈，是研发运维一体化的解决方案。UAV 是无人机的缩写，寓意无人机翱翔蓝天，智能的，透明的完成任务。它包括任务机器人（代号 HIT），全维监控（代号 UAV.Monitor）, 应用性能管理（代号 UAV.APM）, 服务治理（代号 UAV.ServiceGovern）, 微服务计算（代号 UAV.MSCP），用户体验管理（代号 UAV.UEM）等。其中，UAV.Monitor+APM 为不但为智能运维采集全维监控数据，也提供了实时监控，自动化问题诊断的工具，是一站式的全维监控 + 应用运维解决方案。

目前 UAVStack 开源系列包括：

DBus 专注于数据的收集及实时数据流计算，通过简单灵活的配置，以无侵入的方式对源端数据进行采集，采用高可用的流式计算框架，对在业务流程中产生的数据进行汇聚，经过转换处理后成为统一 JSON 的数据格式（UMS），提供给不同数据使用方订阅和消费。DBus 将 UAV 采集的全维监控数据以无侵入方式进行实时收集，为下游大数据处理平台 Wormhole 运行统计模型和机器学习提供数据源。

此外，DBus 还提供以下特性：

1.多种数据源支持，海量数据实时传输

2.感知源端 schema 变更，数据实时脱敏

3.初始加载和独立加载

4.统一标准化消息传输协议，可靠多路消息

5.订阅分发支持分表数据汇集

DBus 技术架构

Wormhole 是一个 SPAAS（Stream Processing as a Service）平台解决方案。Wormhole 面向大数据项目的开发，运维以及管理人员，致力于简化和统一开发管理流程。当今运维是典型的大数据应用领域，Wormhole 是智能运维机器学习的有力支撑，尤其是针对流式实时和流式准实时数据处理场景。同时，提供了可视化的操作界面，极简的配置流程，基于 SQL 的业务开发方式，并屏蔽了大数据处理底层技术细节，极大的降低了开发管理门槛。Wormhole 的设计理念是统一流式处理 DAG 高阶分形抽象，统一通用流转消息 UMS 协议抽象，统一通用流转消息 UMS 协议抽象。

痛点是技术升级的驱动力

我们是从传统运维转向自动化运维，进而向智能化运维迈进。通过对 DevOps 工具链的不断建设，我们形成了贯穿全维度监控，CI/CD，自动化测试，应用虚拟化的自动化运维体系。尽管如此，在金融运维 / 运营过程中，我们还是碰到以下痛点：

1、自动化运维确实提升了运维时效，大幅度减少人工，提高了精细度。但自动化的执行流程是由人工定义的、明确的执行过程。随着对系统的适应力，决策力和时效性要求持续地提升，自动化运维也出现了边际效应。

没有“判断力”，不能决策。存在多种可能性的运维事件，需要 SRE 介入判断和分析，才能明确是什么，然后才能对系统下达指令。例如：当发现高 CPU 报警时，服务该不该降级，应用该不该重启。而事实上，让人人都成为运维专家是难以达成的，如果 SRE 不在，问题就搞不定。

适应力不足，人工介入的滞后性。比较典型的情况是报警，通常报警是由运维人员根据经验来设置的策略，但是市场和业务发展的快速变化会使得预先设置的策略过时，不是出现频繁报警，就是出现该报的没报。

2、传统 IT 协作模式越来越“玩不转”了。传统模式是业务找研发，研发找运维，运维找系统的“线条”模式。同时，IT 的语言与业务语言时常“鸡同鸭讲”，误读时有发生，也造成效率低。

业务团队希望随时随地，简单，快速的了解系统运行状况，业务运行情况，当然他们也看不懂 IT 术语，他们希望能听到“人类”的语言。

运维 SRE 变成了关键“瓶颈”，他们的经验没有被沉淀和共享。

研发懂系统，了解业务逻辑，却“不敢”在没有运维 SRE 协助时（即使有自动化远程工具），快速解决业务问题。他们缺少全面了解基础设施、上下游应用的帮手。

3、业务团队需要更多运营支持，移动化，多交互渠道，从而解放人的眼睛。

从层级汇报（人围着人转，人找人）的模式转变为以数据为中心，数字化运营（人围着数据转，人找数据）的模式是大趋势。而这种转变的技术基础是业务团队可以通过各种渠道（不是非得登录某某系统，也不是非得找到某某领导或联络人）快速传播信息，分享数据。

运营措施能够用“听得懂”的语言直接、高效地反馈给业务团队。例如资金需求上来了，资金调拨团队通过资金调拨跟上资金需求的增长，但他们并不清楚实际起到了多大效果，当然通过业务监控能够看到，但金融行业特点，移动办公 / 出差是常态，并不是时刻具备登录系统的条件，但通过微信，QQ 等就方便多了。

以上的痛点归类起来可以认为是两类问题：

时效类问题：运维的本质是提供稳定可靠的服务，而达成这个目标的关键是足够好的时效。

协作类问题：人类的生产离不开协作。尽管有了自动化运维平台或 工具 链，运维很多场景还是需要许多人工协作。

智能运维的自研之路

Gartner 定义了基于算法的运维（ITOA）即是 AIOps，算法即运维，将算法运用运维领域。实际上我们在自动化运维体系中已经将算法落地到 DevOps 工具链中，例如在监控中服务图谱的动态绘制，APM 工具箱中的一键式线程分析，应用虚拟化中的弹性容量计算。但我们认为这些仍然是“自动化”的范畴，需要更加智能的方案。

日益兴盛的人工智能技术，让我们意识到赋予系统“智能化”是大趋势。对 AIOps，我们更愿意这样解读：AIOps 正是将人工智能技术应用到 IT 运维领域，帮助变革运维模式，提升效率和创造现实价值的“工程化”过程，也是 DevOps 的进化方向。

解决上述问题的目标归纳起来是，我们需要 AIOps 系统成为

运维管理的成员：协调人与系统，不是被动的工具，而是直接参与运维的“助手”

业务运营支持的成员：协调人与业务，参与运营的“助手”

业务与系统的“全知”者：协调业务与系统，管理系统，支撑业务

那么应该怎么建设 AIOps 系统呢？我们确立了几点原则：

目标是从实际痛点入手，找到适合场景以及正确的问题来试点，而不是“大而全”的 AIOps 解决方案。

技术选型上充分利用已经比较成熟的开源 AI 技术，可以做必要改进，但尽量不重复造轮子。

充分使用我们现有的 DevOps 工具链，而不是全面推倒重来。

之所以这样考虑的原因：

AI 技术还不是“平民技术”，尽管已经发展了很长时间，但它的投入产出比可能并不像使用 spring，tomcat，RabbitMQ 这些开源技术栈那样的直接。所以先做“点”的事情，再考虑“面”。要从适合的场景下切入。

尽管 AIOps 会带来颠覆性的运维思维和效应，但是否也要对现有系统软件来一把推倒重来呢？AIOps 是 DevOps 的进化方向，与 DevOps 工具链深度集成是必由之路。所以 AIOps 并非是要取代现有的自动化运维体系，而是赋予现有体系智能。

复用现有 IT 优良资产，最大化资产价值也是必要的考量。

值得一提的是，经过实践证明，自动化运维是智能化运维的构建基础。如果没有自动化运维的成型技术和方案，AIOps 也是空谈。用个形象的比喻，自动化运维体系中，监控系统的数据采集好比人的眼睛、耳朵是用来感知现实的，远程执行好比人的手脚是用来反馈现实的。而 AI 系统好比人的大脑，它接收感知，通过一系列处理形成决策，这是“认知”的过程，然后通过反馈给人或执行结果，体现“智慧”。

我们 AI 的实现形态是任务机器人（代号 HIT）。它是统领智能运维的“大脑”，是类人行为的软件系统。任务机器人应该具备以下能力：

HIT 的设计理念就是对任务机器人能力的抽象。它由三种核心服务构成：

1.Interaction：交互。实现与人类非 GUI 交互界面，目前实现两个方面：文字交互 CUI（内部系统聊天 / 通知，公共 IM 系统，比如微信 /QQ），语音识别与语音合成（手机终端设备）。它是人与系统交流的中介，起到翻译信息，传播信息的作用，使得人不再需要被绑定在特定系统界面才能完成相关工作。

2.Think：决策。这是与自动化的核心区别，它需要通过理解人类的意图，同时收集执行环境的上下文，根据意图来安排执行计划，以及对执行计划做出调整。同时，在实际执行过程中通过对 Interaction 的反馈，将执行计划以及执行过程信息以类人化方式描述（自然语言）。它使用的核心技术包括自然语言处理，知识图谱，机器学习，搜索技术。

3.Handson：执行。这是与聊天机器人的核心区别，根据 Think 提供的执行计划，适配计划中相关系统的 API，完成实际的服务流程编排以及服务流程执行。同时，它还需要给 Think 提供反馈，以实现迭代决策（反馈 + 调整）；它也将执行过程以及执行结果反馈给 Interaction，帮助人了解执行状态（非自然语言）

落地方案

我们的 AIOps 平台是以任务机器人为中心，利用大数据平台实现机器学习和统计模型的处理，与 DevOps 工具链深度集成实现智能化运维。可以从以下几个层面来解读这个架构：

DevOps 工具链为任务机器人 HIT 的知识图谱构建提供了高质量的原始数据

任务机器人 HIT 的核心能力来源于特定领域的知识图谱和计算模型。目前我们的训练领域包括系统 API 模型，个性化交流上下文，服务拓扑，执行计划，问题诊断等。知识图谱是实现认知关联的核心技术，而如何自动化构建知识图谱是关键的关键。成熟的 DevOps 工具链可以为自动化构建知识图谱提供高质量的原始数据。

API 模型包括了应用 / 服务的 API 元数据信息和实例信息，这些信息必须时刻与现实世界保持同步。而全维监控 UAV 提供了应用画像数据，由于 UAV 本身采用了微智能（强调自动发现，自我维护，自动适应）的设计，使得应用画像数据本身就时刻与现实世界保持同步。任务机器人 HIT 通过直接归集应用服务画像数据，按照 API 模型的认知关联结构，就可以生成 API 模型。而微智能的特性天然的、高质量的保障了自动化 API 模型的知识图谱构建。

另一个例子，服务拓扑是反应服务之间的关联关系，在微服务架构下，这种关联关系也变得日益复杂。全维监控 UAV 提供了服务图谱，它也是基于微智能思想的数据，可以及时地与现实世界同步。HIT 也只需要归集服务图谱，按照服务拓扑的认知模型来构建知识图谱即可。

此外，调用链的数据可以帮助自动构建时序关系，CI/CD 的项目特征和人员关联数据可以帮助构建应用与团队的映射关联（从故障问题到应用，再到代码和人员的追溯），测试用例的输入和输出可以帮助构建 API 模型的参数关系，语义关联和缺省参数等。

全维监控 UAV 为任务机器人 HIT 的模型训练提供了全面维度的原始数据

UAVStack 中 Monitor+APM 为实时监控 + 应用深度运维提供了解决方案（如图）。在智能运维体系中，它采集的全维度监控数据是机器学习和统计模型的原始数据来源。全维度的监控数据覆盖基础设施性能，应用 / 服务性能，日志，调用链，线程栈，客户端体验，业务指标，应用画像，服务图谱。

应用 / 服务画像：监控探针自动对应用的技术栈进行分析提取应该的元数据，其中重要的包括应用实例的 URL，有哪些服务接口方法以及 URL，使用了哪些客户端（MQ/DB/Redis/NoSQL/Http/Dubbo 等）以及访问的 URL。

应用 / 服务画像数据示例

应用性能指标：包括应用集群，应用实例，应用中间件 /JVM，服务组件，客户端组件，URL，数据库连接池等性能指标

应用日志：应用产生的各种日志，支持过滤规则。

应用性能指标 & 日志数据示例

应用环境性能指标：虚拟机 / 物理机系统级以及进程级指标，例如 CPU，内存，连接数，网络流量，磁盘 IO 等

应用环境性能指标数据示例

调用链：包含服务 / 客户端 / 方法级，所在类 / 方法，耗时，状态，请求报文，响应报文等

调用链数据示例服务图谱：自动生成服务之间的调用关联关系

服务图谱数据示例线程栈数据：JVM 线程 Dump+ 每个线程的 cpu，内存消耗的数据

线程栈数据示例

Web 浏览器客户端体验数据：页面加载，离开页面，JS 错误，Ajax 请求，地理信息，客户端 IP 等

Web 浏览器客户端体验数据（Ajax）示例

业务指标：应用可以通过埋点或日志方式提供自定义指标

业务指标数据示例

数据总线 DBus 持续的，自适应的将全维监控数据导入大数据

存储尽管通过 UAV 采集到了全维度的监控数据，但是还不能直接使用这些数据来做机器学习和统计模型。其原因是由于它们的存储和查询需求是根据实时监控领域的需要来定义的，因此它们有以下特点：

1.被存储在不同的存储源中，例如服务画像数据存储在 MongoDB，应用日志和调用链存储在 Elastic Search 中，应用性能指标和基础性能指标数据存在 RocketMQ 中等；

2.有着各自不同的 schema 定义，例如 BIN 日志格式，JSON 格式，Plain 日志格式, 性能指标的 schema 与调用链的 schema 是不同的。

3.不同的变更策略，例如服务画像数据是根据应用升级不定期变化的，日志数据也可能是这样。

4.数据总线 DBus 正是解决这三个问题的良方。

5.DBus 能够支持多种数据源，只需通过配置就可实现无侵入对接。采集端包含了数据库的日志采集端、日志采集端、各种基于 Flume 自定义插件的采集端等，这些采集端将数据实时的同步到 Kafka 中，完成数据采集工作。

Dbus 多数据源支持

DBus 能够将不同的格式转换成标准格式（UMS 格式）。它会根据不同的格式和对数据转换和抽取的相关配置，对数据进行实时解析和计算。以应用性能指标和业务指标为例：数据格式是采用 MDF 文件格式（UAV 的一种格式），它是一种 JSON 格式的层次化数据，而 DBus 最终输出的 UMS 数据格式是一种以表为基本单位的数据，因此需要将数据进行扁平化，一条 MDF 日志对应的多条 UMS 数据。

DBus 支持不同格式的标准化

DBus 有自动适应的能力，匹配这些类型和格式的变化。它支持指标动态添加，就算每次来自 UAV 的 MDF 数据都带来新的指标类型，这些新增的指标也并不会影响解析本身数据本身；同时，它还支持动态 schema 变更，即自动感知数据的列名和数据类型，UMS 格式记录了数据的版本和列信息等，一旦发现不属于同一个版本的数据就会自动升级版本号，生成新版本的数据。例如如下的新版本比旧版本多了一个字段 RC406（一种应用性能指标，Http 响应码）。

DBus 自动适应格式版本变更

大数据处理 Wormhole 针对目标场景，基于全维监控数据进行机器学习和统计模型处理

Wormhole 是任务机器人的计算模型生产者。Wormhole 基于 Spark，既可接入 Kafka 在线实效数据进行流式处理，也可接入 HDFS 离线历史数据进行批量处理，在 Spark 之上还抽象出一套新的概念和处理模型，用户可以通过 UI 进行简单配置来实施和管理流式作业，用户只要选择数据从哪里来到哪里去，在流上执行什么样的逻辑即可启动一个流式作业。Wormhole 不光支持落地多 Sink，还支持流上处理，还可以在落 HBase 之前流上做一些数据清洗扩展等操作。

Wormhole 技术架构

目前我们的任务机器人 HIT 的训练主题“问题诊断”的计算模型都是由 Wormhole 来实施训练，实际生产过程中会使用机器学习和某些经典统计模型，主要的有：

时序数据的趋势预测模型：可以根据过去若干天来预测未来一段时间某重要指标的趋势走向。

指标的关联组合模型：识别出哪些指标组合是判断异常的充分条件。

组合指标的异常点识别模型：组合指标在时序上异常点的自动判别。

问题节点的根源分析模型：跨多节点的异常行为关联性识别模型。

举个例子，任务机器人 HIT 根据执行计划驱动 Wormhole 每十分钟从 HBase 上提取最近一个短时间窗口的数据（若干天），HIT 通过“问题诊断”知识图谱选择［时序数据的趋势预测模型］和［组合指标的异常点识别模型］对十分钟增量数据进行异常点识别，并预测出未来一小时的指标趋势，并做适当统计聚合，可以得到一个延迟 10 分钟级别的增量监控指标走向，自动识别的异常点和未来一小时的重要指标趋势预测图，同时也可以根据异常点的严重性级别进行预警。可以看到整个预警体系是非人工参与的，基于机器学习模型和增量数据准实时的推算出来了，当模型准确率越高，预警也会更精准。

另一个例子，任务机器人 HIT 通过“问题诊断”知识图谱选择 [指标的关联组合模型] 和 [问题节点的根源分析模型]，通过应用性能指标发现 CPU 很高，关联上线程栈数据就可以知道是哪些线程引起了高 CPU，线程栈的代码栈又可以关联到服务画像，从而发现与哪个服务的 URL 有关，通过服务 URL 关联服务性能指标可掌握是否是由高并发访问引起的，关联服务图谱可以追溯是哪些上游系统在调用这个服务 URL，哪些下游系统可能会受影响，关联调用链数据可以追溯是哪些业务请求引起的，甚至对下一个时段这些业务请求峰值进行预测。

任务机器人 HIT 通过 API 模型实施执行计划

任务机器人与普通系统的另一个重要区别是：普通系统可以看成是通过编码来“机械”的完成某种事，就系统本身而言，它并不理解“我在做什么”。而任务机器人是以目标驱动的，它根据 API 模型以及其他认知模型（知识图谱）来生成执行计划，并使用 API 模型来实施执行计划，执行计划的本质是对 DevOps 系统 API 的调用。

以系统上线为例，我们给任务机器人一个目标“今晚 19：30 电签网关上线”。任务机器人通过“基本意图理解”知道是要驱动 CI/CD 系统 Hubble 的“一键发布”功能来发布“电签网关”这个系统。API 模型帮助任务机器人通过对句型，关键词，相关性的分析，来关联到 CI/CD 系统，也通过功能与 API 的关联，提取出来需要 buildApp 和 deployApp 两个 API，还帮助实现了两个 API 的参数填充。最后依靠 API 模型中的时序关联来确定了几个 API 的执行顺序，再加上执行时间，最终确定了执行计划。当然执行计划执行的过程会依赖“问题诊断”的认知模型。

这种目标驱动的应用场景还有很多，例如让任务机器人去做线上的智能巡检，协助问题处理，甚至支持运营协作等。

AIOps 团队建设最后来谈谈我们的团队。相信在面对 AIOps 的时候，大家都会思考团队要如何构成。我认为 AI 的生态体系与大数据类似，存在两种基本角色：AI 科学家和 AI 领域工程师（FE）。前者推动 AI 科学的发展，创造新的 AI 知识体系；后者是将 AI 知识运用到生产生活的某个领域，创造现实价值。

我们团队的定位是 AI FE，是将 AI 技术工程化的团队，这样的团队应该具备几个特征：

1.对现有 AI 技术充分了解和掌握

2.选择较成熟的开源 AI 技术是必由之路

3.对运维领域的技术 (比如监控，容器技术，CI/CD，问题诊断等) 是清楚的，最好是专家

4.对运维领域的场景是熟悉的，明白运维的标准，逻辑，原则

我们的团队主要有两类角色：

1.算法数据工程师：掌握算法技术，AI 技术，具备一定的工程化能力，了解运维领域知识

2.服务后台工程师：掌握服务化技术，对 AI 技术有一定了解，熟悉研发 / 测试 / 运维，具备运维经验

任务机器人团队早期是以虚拟团队的模式成立。因为面对新的领域在研发 / 运维体系上需要尝试新的模式，就把算法同学，后台服务同学，运维同学都拉到一块。通过知识交互，经验分享等手段，让大家逐步在认识上同步。并要求所有人掌握整个端到端过程。此外，随着智能化运维的开展，UAV，Wormhole，DBus 等团队也逐步在架构，技术，对接等层面达成一致。