深信服桌面云在 AIOps 领域的探索与实践

本文整理自深信服创新研究院高级技术专家易佳在 QCon 2022 广州站的演讲分享，主题为“深信服桌面云在 AIOps 领域的探索与实践”。

大家好，我是来自深信服的易佳，今天给大家分享的题目是：深信服桌面云在 AIOps 领域的探索与实践。

本次，我将从以下几个方面为大家分享今天的整个演讲。首先，我将简单介绍一下桌面云技术，然后引出桌面云产品衍生出来的一系列问题，最后我们如何去做一套 完整的 AIOps 技术方案，来解决桌面云场景面临的运维问题。这其中涉及到的工程和算法设计，以及最后的实践落地。

桌面云简介及其技术架构

要了解桌面云，需要先了解云终端。云终端是云计算和本地计算结合的解决方案，通过特定的通信协议和虚拟化技术，实现对终端设备的集中管理和算力均衡。由此引申到桌面云，它是虚拟桌面架构的简称，也被称为云桌面，其核心在于云桌面的计算、存储和网络在服务端完成，并通过专有协议与云桌面连接。

深信服桌面云的体系是由桌面云专用服务器来提供服务器桌面池，派生出虚拟桌面，基于自研传输协议，利用网络把桌面通过终端的形式呈现出来。这个终端可以是 PC 机，也可以是手机、笔记本、瘦终端等。

由于桌面云的数据和整体的服务都在服务端，它本身在安全层面是有较大保障的；同时，因为可以在多种不同的终端进行接入，所以它可以很好地满足移动办公诉求。因为桌面云是统一管控，运维效率会比较高，整体的成本也会有一定程度的降低。那么它比较适应于哪些场景呢？因为现在桌面云私有化的部署会相对多，它比较适合于大中型的政企办公、医院、职业培训、可移动的简单办公应用、数据安全要求较高的开发和金融的场景。

桌面云运维挑战

目前在桌面云全场景运维还是存在蛮多挑战的，我们在传统 PC，或者说笔记本办公时代，面临的一些挑战在桌面云中同样也是存在的。

• 表面挑战：如第三方软件兼容性问题、蓝屏木马问题快速定位、应用卡慢、响应延迟如何解决等；

• 深层挑战：如资源不足如何解决，硬件故障如何快速定位，数据资源不能上传到云端，那么在本地小数据中心如何处理，以及网络问题怎么来修复等；

• 衍生挑战：如集群问题如何提前预警、资源使用及未来趋势预测，以及整体健康度跟踪诊断等。

桌面云 AIOps 智能运维一体化技术方案

讲完桌面云的运维挑战，我们来看一下深信服在桌面云的 AIOps 技术实战。

首先看一下我们一体化的桌面云 AIOps 解决方案，最左侧是智能运维三板斧，Logs、Traces 和 Metrics，这些数据通过数据总线汇入 AIOps 分析平台，底层是 Sangfor Cloud Stack，中间有 OpenAPI 连接整体结构。在调度层有策略生成器、动作编排器、以及健康跟踪等，分析业务会涉及到特征、模型及相应的算法，比如异常检测、关联推理、甚至包括图谱分析等。最上层就是对应一些具体应用，比如说桌面云场景比较常用的卡慢识别、闲置虚拟机识别，对应到公有云里边的闲置 VPS 识别，或者闲置容器的识别，很多都是可以做一些复用的。

刚刚提到开始做 AIOps 时，最重要的其实是数据，因为数据是一切的基石，可以说没有数据，就没办法分析。所以我们自研了 Sangfor AIOps Agent，支持 Windows、Linux、Docker 多维度的数据采集。

相较于公有云或常见的业务来说，桌面云业务有一定区别，因为桌面云的 Windows 用户非常多，而用户使用 Windows 办公，需要非常稳定，但桌面云本身受网络的影响很大，资源开销要求极其苛刻，所以 Agent 对资源变化极其敏感，也不宜频繁升级。因此，我们对 Agent 做了以下核心改造：

• all in one，跨平台、多指标支持，这个业界基本都是这个模式。

• 热拔插，采集指标可动态添加与删减，无需频繁升级 agent。

• 支持 Prometheus 协议，这是比较常见的做法，支持热点数据的快速导出，然后做实时模型训练。

• 稳定、高效、可扩展。

做完采集之后，我们的重点就是数据模型与 AI 框架。深信服在这个领域是探索了一段时间，桌面云场景，分阶段演进了几个版本。

第一个版本做的比较简单，是偏监控式的小型运维系统，后期逐步向一个较大规模的、可以支持 AI 动态调度的智能化引擎在演进。第一个版本是一个轻量级、分布式的监控分析系统，Agent 采集数据写入到时序数据库，基于 Prometheus 实现告警，业务上游以规则兜底，还有一些简单业务算法。因为此版本针对于一些小场景，客户数据量并不大，我们用 Influxdb 加上 Prometheus 就能搞定，所以发布后效果还不错。

但第一个版本也有明显的瓶颈：

• 当客户的体量越来越大时，整体性能不够；

• DB 与整个业务的耦合严重；

• AIOps 业务算法（如卡慢检测等），数据量非常小，同时因为是离线场景，算法效果相对难以保障。

在这种背景下，我们进行了第二个版本的演进。

• 业务解耦，基于 API 交互；

• 数据支持统一调度，由 Requests Handler 来管理；

• 引入了缓存机制，存算做分离；

• DB 集群化部署，支持横向扩展，底层用容器做微服务。

相较于 V1 版本，V2 版本有一定提升，瓶颈也很明显：

• OpenAPI 的性能受制于底层数据库，大规模连接的时候，会有性能瓶颈；

• Requests Handler 要解析多类数据，处理瓶颈；

• 一开始 Prometheus 用的是 pull metrics，pull metrics 会强依赖于网络，这对于私有云网络来说，尤其是遇到某些金融客户网段比较分散的时候，会造成数据根本无法分析；

为了解决 V2 版本的一系列问题，所以我们又演进了 V3 版本，V3 版本带来了一些优化方面的改进：

• 接口的抽象，由 Requests Handler 负载均衡。

• 投递分级，内存磁盘双队列。投递分级是跟业务是强相关的，比如客户更加关注 CPU 资源和内存资源，那这一类的数据优先级比较高，会进入内存投递队列。优先级中等或优先级比较低的，对实时性的要求可能会相对不那么高，或者允许一定程度的丢失的，就进入到 Kafka 队列中，逐步的消费，所以这里是做了一个双队列的区分。

• 多级分表，优化数据结构。虚拟机、集群和主机都是一对多的关系，这里要保留横向扩展能力，比如按集群做分库分表，减少非必要的 InfluxDB 里边的 tag，比如 IP 和 Hostname 只保留一个，让整体的负载。降下来

• 平衡实时性与准确度，减少重复数据。

• 多维异构数据的冷热分离。这个相对来说会比较常见，对于监控系统或对于 AIOps 系统来说，当流数据过来，越新的告警、越新的数据往往是客户更加关注的，所以热数据往往会优先在界面上展示或者做一些分析。冷数据一般来为 AI 做 Training 或者做统计分析所用。

完成这些优化后，构建了一个完整的 AIOps 工程算法引擎，底层是一个 Docker Swan 的集群，往上会有一个数据管理层，比如接收业务数据到 MQ ，然后流向 DB。再就是封装了一层通用的 OpenAPI，来过渡整个数据和存储。再往上就是 AI 调度，主要是基于算法的自适应业务策略调度。最上层的 AIOps 算法基于 sklearn、pytorch 等框架构建。

桌面云 AIOps 算法设计

工程侧比较通用，云业务场景基本适用，但是算法就是针对特定的领域了，它需要对业务有深入理解。首先我们要做算法的话，必然会有一套比较完整的算法调度引擎，我们叫业务自适应的 AI 调度引擎，它会统一数据管理、统一模型管理以及统一策略管理。比如说模型上线，什么时候要上 A 模型，什么时候要上 B 模型，都会有模型管理来做调度。最上层就是业务算法，虚拟机里面是会有闲置资源识别、故障预测、故障定位，以及根因分析等。

下面介绍第一个算法，基于 bagging 策略的分段线性回归算法。

我尽量不去讲数学公式，简单来讲，它就是一个评分模型，这个评分模型是为了能够看到整个虚拟机、主机，以及集群的健康状态，也就是你的机器现在多少分，分数越高，证明机器的业务健康度越高。

这个是怎么做的呢？首先我们会有很多的时序数据，还有一些告警数据，基于不同维度的时序数据建立 n 个弱学习器，比如 CPU 维度，它的 T1 时刻占多少，T2 时刻占多少，然后结合专家经验规则对每一个维度做一些评分，多个弱学习器组成一个强学习器，强学习器通过专家规则做最底层的一个 Filter 之后，会做一个加权投票，之后会形成一个评分机制，通过多维的资源能够识别整体负载水平，给一个健康评分，这个评分能够体现机器整体的负载情况以及健康程度。

第二个算法是基于网格搜索的资源扩缩容模型，这个扩缩容模型在公有云场景非常常见。刚刚我也问了上个嘉宾一个问题，如何保障虚拟机资源以及容器资源“刚好合适”？举个例子，有些业务部门，在做业务规划的时候，总是尽可能多要一些资源，但实际利用率往往不高。为此，我们设计了一个缩扩容模型，就是为了能够省成本，且保障用户体验没有下降，或者说是持平的状态，怎么做的呢？

在私有云或公有云，比较重要的两个核心是 CPU 和内存，我们提出了一种有效峰值的算法，CPU 和内存在 95% 水位以上的时候，我们把它作为资源的一个有效判断点，然后基于这个有效的峰值，来设计一个类似于惰性机制的算法。当 CPU 触发有效峰值模型的时候，就会命中扩容或缩容策略，如果之前扩过容，或者缩过容，就不会做一些操作，但如果没有的话，就会命中那个策略。命中那个策略后，实施之前也会有一个网格搜索加 AB 测试的方式来验证整套方案是不是在整个集群中可行，算法校验通过，则推荐扩容或缩容。

第三个是基于资源约束算法和贪心策略的虚拟机新增模型。这个在公有云场景也非常常见，闲时和忙时有不同的新增策略，我们建立一个轻量级的弹性计算算法，保障业务闲时和忙时的新增策略。

最后一个算法是基于时间序列特征提取和随机森林的闲置资源识别模型。我觉得对于公有云和私有云来说，这个模型都非常重要，这个模型非常明显的一个特点就是省成本。首先是用 Facebook 做的 tsfresh 提取很多时序数据的特征，基于这些特征构造一个随机森林模型，因为随机森林本身有多棵决策树，所以相对来说在稳定性和可解释性上也有保障，最终来识别虚拟机是不是闲置，基于这个闲置来做推荐策略，节省成本。

桌面云 AIOps 实践与落地效果

下面和大家分享一下实际效果：

我们做了一个支撑大盘集群主机全栈的监控控制面板。覆盖 800+Metrics，50+专家规则，20 +机器学习和深度学习算法。

AIOps 在桌面云的算法效果：异常检测的准确率接近 90%，能够覆盖大概 65% 的桌面云卡慢场景，47% 的故障问题执行处置策略之后能够得到彻底解决或缓解；执行 AIOps 优化策略之后，综合成本的降低 18%

桌面云 AIOps 总结与展望

总结来看，当前非常棘手的问题有：

• 私有云环境下 AIOps 模型难以动态更新。因为大家都是分散在各个私有场所的，数据不能上云；

• 桌面云业务场景多变，算法模型怎如何做到高覆盖和精准识别。

展望未来，我们会在以下几个方面继续发力：

• 增加更多反馈机制与模型自更新机制，实现多业务场景的覆盖；

• 基于业务画像和运维知识图谱，实现精细化故障诊断。

以上就是我的分享，谢谢大家。

相关阅读：

AIOps 还是 APM，企业用户应如何作出选择？

AIOps 九大发展趋势

值得一看的智能运维 AIOps 关键核心技术概览！

强化企业 IT 运维的五大 AIOps 策略