干货 | 2023大数据挑战赛技术分享：从“解一道题”到“用户桌面”技术落地的实践思考

今天想跟大家一起聊一个很有趣的话题，如何做才能将从 “解一道题”到“用户桌面”这件事真正给企业、工业界带来价值。我将谈一谈技术落地的实践和思考。

我们先从这一道基于多元数据的IT系统故障发现的题目说起，可以看到其实在企业真实的运行过程中，不光有微服务，其实还有设备、硬件、设备、空调、暖通动力等一系列复杂的设备，有复杂的指标日志告警和调用链。那么真实企业在解决一个问题的时候是怎么做的呢？以银行的故障业务故障处理流程为例。上图右侧就是调用链，大家看到这是服务之间的调用和对资源之间的依赖。当我发现有故障有异常的时候，先看看指标有没有问题，如果指标有问题，再看一下调用上下游节点有没有问题，找到问题以后去分析日志。所以，我们提供的任何数据、任何信息都是有价值的，对解决问题都非常有帮助。

那么基于这个问题，简单延展一下。中国的数字经济已经步入成熟期，数字世界的构建方兴未艾，大家可以看到上图左下角的条形图，其实我们国家整个数字经济在GDP的占比在2021年已经达到40%多，预测到2025年可能会达到一半。我们今天解决的小问题，事实上是为了IT世界和数字世界的安全和稳定。

数字世界是有故障、有异常、有问题的，随时都面临崩塌的风险。解决运维的小问题，对整个世界都大有裨益。

运维这件事为什么很重要？我们会看到在传统基建时代，物业公司是非常有价值的公司，因为它叫做“买房一阵子，服务一辈子”，物业公司持续为基建提供长期的服务。再来看今天的这道题，运维公司或者我们今天运维这道题到底解决的是什么问题。随着全国企业等各行各业数字化转型，运维其实就为全站的数字化系统提供了基本的解决方案。所以运维事实上是企业数字化世界里的超级英雄，维护数字化系统的稳定。

而从一道题到用户的桌面之间又有怎样的联系。什么是实验室问题？其实今天给大家分享的这道题本身就是一个典型的实验室问题，我们已经把问题定义好了，已经有了明确的输入输出，也有了明确的评价标准，那么甚至让利数据都给大家准备好了。但是用户桌面的问题要解决的是什么？真正的用户界面往往没有一个well-defined的问题，定义一个问题成为了行业里的巨大挑战。

如果把这个问题抽象成为一个机器学习问题。假设就做一个特别简单的定义：y=f(x)。x是各种各样的输入，包括数据包括特征，f是解决这个问题的方法，y是我们最终优化的目标。对于实验室问题来讲，作为输入的x收集工作量相对较小，而y往往是明确的，在近几年内算法基本上确定的情况下，大部分时间大家解决的是f。但是真正到企业里或者真正赋能于国计民生的时候，你会发现往往 x、f、y都是不确定的。比如我们要做智慧城市、智慧工业互联网等等，定义问题是解决问题的第一步，也是最有挑战的一步。首先要确定x和y，最后才研究怎么让f变得更好，这是从实验室问题到用户桌面问题之间最大的差距。

如何定义一个用户桌面的问题，简单跟大家分享一下我们在运维领域的做法。智能运维怎么解构，智能运维一定离不开我们生产生活中的运维场景，其次离不开智能技术，所以我们有了一个公式，叫做智能运维=运维场景+智能技术。

上图展示了运维的场景，运维就是围绕着指标、日志、调用链和报警产生的所有的可观测数据去发现问题和解决问题。那么这些数据之间到底是什么关系？我们这里做了一个总结，我们把它称之为叫做一元场景、转移场景和二元场景。大家会看到上图左侧有6条虚线，它代表在运维行业，这些数据之间可以转移。日志可以变成指标，因为日志数据量很大，不好存储，日志特征的价值稀疏，可以把它转移成指标再去计算。

另外一方面，我们会发现有调用链数据，但调用链数据缺失，可以从日志里剖出一些调用链去补齐缺失，调用链也可以产生指标。

有了场景之后怎么办？对于智能来讲，有非常多的技术项目，怎么做智能运维，其实就是把运维的场景加智能的技术这道题做好。我们把一元场景转移场景和二元场景结合在一起，再把智能的技术结合在一起。智能运维就是所有的场景，再加上智能的技术，最终就产生了一个行业的变化。

比如一元场景指标，再加上一些时序数据的处理能力，可以进行指标异常检测、预测、复杂系统健康度计算，这个场景对工业是有意义的。日志场景加一些处理的技术，就会做日志的解析、日志的分类、日志的语义上分别等等，它对我们真正的业务是有其价值的。我们会看到指标日志告警调动量来合成一些二元场景，最终可以解决一个复杂业务系统的对应定位和分析问题。

行业的实践者还要系统化地把这些具体的问题定义出来，不同问题解决的是什么，怎么去度量，怎么去评价。指标的异常检测到底是什么？它本质上就是一个正负样本不均匀的二分类问题。那么指标的预测问题是什么？日志的语音识别问题是什么？日志的 Pass问题是什么？日志的命名实体识别是什么？根因分析是什么？我们把这6个问题合在一起出了一道题，希望大家理解在真正领域实践过程中定义问题本身非常的重要，解决问题次之。说到此，我们把这道题做完了，它离真正在用户侧使用还有多远的距离，怎么来用？我给大家看一下我们的组织架构图。

大家可以看到，我们即便把所有的事情都做好了，其实在真正工业应用里，你做的只是这个圈，我们叫做算法的核心研究。事实上今天所讨论的一切仅仅完成了软件这门大学科中的非常微小的一部分。在做完这些理论研究之后，我们要强调的是算法如何工程化，我们要解决它的事实性问题，最后是算法的产品化。我们要把它服务化、可视化、API化、调用管理等等，最终会把它变成一套产品。能不能解决不同领域的问题，才是关键。

下一个层面，如何把在用户桌面能用的软件做到千家万套。这里引用孙院士在我们每次就开学的时候都会讲的一句话：“软件人要能够发现软件使用过程中的真实痛点，切实解决人民群众日常生活中遇到的问题，做出能用管用好用的软件。”这是我们的目标。

那么，我们今天的这些技术在用户那里是怎么解决问题的。

第一点，很多队伍都对指标做了建模分析。这里其实看到的是网卡的指标，因为网卡隔一段时间会有一些流量进来，所以网卡的这种指标异常往往都是在这种规律情况下的一个不规律。还有变更自学习，你会发现当有业务系统上线的时候，CPU往往会有一个突变和波动。还有趋势知识自适应。大家会看到真正在网络流量的时候，流量的量总是上升的，在上升过程中如果有一个突增点会有一点异常，这是指标数据的真实解释。

还有就是趋势加变更。虽然有变更，但是整个流量是在变化的，这种指标在物理意义事件里也是有的。因为在银行和真正工业使用的时候，我们晚上会做一些跑批，所以跑批的指标就是这样。所以如果突然有一些不符合跑批规律的，是真正的异常。

再往后就是一些周期的规律，因为往往业务的指标都是周期的。所以突然升上去突然掉下来，是真正的指标立场，还有就是周期+趋势的一些测试，包括忙闲时的自学习以及物理世界指标的自发现等等。这是建模的指标在物理世界的形态。

第二个是日志分析。大家都说日志里面的价值是稀疏的，但是我先把日志做一个聚类，找出打印日志的原语句。但凡写过代码的人都知道，日志可能打了十几个T、100个T，但是打印日志的语句不会太多。我们分析过大部分中间件也就100个或者1000个左右的打印日志语句。在真正解决问题的时候，我们会先把日志做一个聚类，做一个模式的fast，之后会发现它变成了指标。那么当我们把日志转成指标以后，就可以去做指标异常检测，做问题分析。

把日志这样指标化以后能解决什么问题？给大家看一个例子，就是最右下角这幅图，这是一个真实的例子。一家运营商，每天都会打印一些周期性的turn up，做一些清理日志，而有一天居然没打日志，没打日志往往是一个大的故障出生，因为批量跑批的任务不干了。而这才是在真正业务过程中日志给大家带来的价值。

最终我们做的是基于根因的调用链的根因分析。上图是一个银行扫码登录的调用链，我们简化了场景，真正大家在解决问题的时候，是先拿到指标，看看有没有问题，根据调用链去分析一下哪里可能存在的问题，最终分析根因。

这就是我们真正在场景里的一些应用，从我们的一道算法或者大数据的题到最终用户的桌面，到解决一个现实问题之间，我们到底要做哪些步。最后跟大家做一个总结：解决一道大数据之题，是今天的第一步，第二步是理解一种工程化之术，理解从一道题到一个用户桌面的产品应该怎么做，最终我们希望大家做到领悟一套软件人之道。

我的分享就到这里，谢谢大家。

编辑：文婧