关键字: [ 亚马逊云科技中国峰会2024, 智能运维架构, 算法特征工程, 时序数据处理, 异常检测预测, 运维自动化执行]

本文字数: 4600, 阅读完需: 23 分钟

导读

在亚马逊云科技中国峰会2024 上, 黄丹勋老师分享了声网如何构建以AIOps 为核心的智能化质量保障运维体系。他阐述了智能运维的宗旨、架构设计以及算法实现, 包括时序编码器、特征工程、图神经网络等。该系统已在声网多个场景落地, 实现了高效的异常检测和自动化运维操作, 大幅减轻了运维人员的工作压力。黄老师还展望了智能运维的未来发展方向, 如强化学习和大模型的应用。最后, 亚马逊云科技的小亮老师介绍了如何利用亚马逊云科技的各项服务来支持和扩展这一智能运维系统。

演讲精华

以下是小编为您整理的本次演讲的精华，共4300 字，阅读时间大约是22 分钟。

在当今快速发展的互联网时代, 运维工作已经成为了一个巨大的挑战。传统的运维模式已经无法满足日益增长的业务需求。作为一名 的运维人员, 我经历了无数个通宵达旦的夜晚, 手机24 小时不关机, 随时准备应对可能发生的任何故障。无论是主机、存储、网络、数据库还是应用服务, 任何一个环节出现问题, 我都必须时刻待命。我甚至不记得自己有多少个双十一或618 这样的节日, 需要全天候值班, 做好随时应对突发状况的准备。

随着互联网业务的爆发式增长, 我们需要管理的系统数量也呈指数级增长。过去, 管理几套数据库就足够了, 但现在我们需要管理上百甚至上千套系统。你永远无法预测下一个出现故障的系统是哪一个。情况变得更加棘手, 尤其是在云原生环境下, 有些客户甚至拥有数万台机器在运行。你可以想象, 要解决这个问题需要多少运维人员? 这简直就是一场噩梦。更糟糕的是, 如果系统设计不当, 某个环节出现了问题, 可能会导致整个业务崩溃, 而你甚至无法快速定位和解决根本问题。

幸运的是, 在加入声网后, 我遇到了黄南勋老师, 他的想法和展望为我指明了全新的运维方向。我曾经真的做过一些迷信的事情, 比如在双十一之前去烧香, 希望系统别出问题。我的销售同事也会陪同前往, 因为如果真的出现故障, 他们也会首当其冲。更残酷的是, 我们期望系统能够提前预警, 让我们有足够的准备时间。即使无法避免故障发生, 我们也希望至少拥有一个应急预案, 在第一时间将故障解决。

通过人工智能的方式, 如何提前预知错误, 如何自动治愈错误, 这些曾经看似遥不可及的目标, 如今终于成为了可能。黄南勋老师将在稍后为我们分享他是如何实现这一目标的。

大家好, 我是声网的智能运维团队负责人黄南勋。我主要负责了声网整个智能运维体系的架构构建, 以及相关功能的实现和改进。可以说, 声网的智能运维是从零开始一点点搭建到现在的规模。按照我的理解, 目前已经能够基本上做到一到两个月只需要有人参与一两次的程度, 这就是智能运维的威力。

今天, 我将与大家分享智能运维的整体架构设计, 以及其中所包含的算法成分。不过, 我可能不会过多地讲解算法的深层细节, 如果大家对此有兴趣, 我们可以之后另找机会深入交流。整个分享将分为五个部分, 在每个部分结束时, 如果大家有任何疑问, 都可以随时举手, 我们的工作人员会递过麦克风, 让我们进行一个小的答疑环节。如果对整体上还有其他感兴趣的话题, 也欢迎会后与我进一步交流。

首先, 我想说一下智能运维的宗旨, 即我们为什么需要智能运维, 我们需要一个怎样的智能运维系统。我们必须首先明确智能运维的对象是什么。让我们以声网的一个视频通话场景为例, 我用红色标记出了三个主要部分。第一个部分是我们的实时传输网络, 即软件定义的实时网络(SDRTN) 。换句话说, 就是用户之间的实时通信过程, 无论是主播与观众, 还是观众与观众之间。我将这一部分称为路径传输, 它的特点是具有时间成分, 属于实时传输, 并且故障可能发生在传输路径的任意一端或整个路径上。

第二个部分是声网SDK 的软件状态。对于这样的运维对象, 一般是其质量出现了问题, 比如不稳定、内存占用高或小bug 导致崩溃等。这种情况下, 它也是一个与时间相关的实时数据, 但相对于路径传输而言, 它没有传输路径的概念, 而是一个独立的运维对象。

第三个部分是第三方存储数据库, 属于基础资源类型。它与前两者有些相似, 但不同之处在于, 它的很多问题往往没有那么实时, 对实时性要求也不高, 并且不一定会有时间成分。

总的来说, 我们智能运维的对象大体可以分为这三大类。那么, 智能运维的期望是什么呢? 我们希望从过去一旦出现运维问题就需要寻找值班人员的被动模式, 转变为全天在线、一旦出现问题就由智能运维工具自动解决的主动模式。我们还希望从依赖运维人员的个人能力, 转变为总结集体智慧, 将优秀的运维经验归结到算法中去。

另一个我们期待的场景, 是从被动运维转变为主动运维。以前, 我们往往是发现问题后, 再去拉线上的故障或人员来解决。而现在, 我们的主动运维可以在第一时间自动采取止血方案。有时候, 运维更多地是一种预知行为, 我们可以预测将要发生问题的风险, 并提前进行运维操作。

但同时, 我们也必须认识到, 智能运维是有一定能力边界的。只有明确了这些边界, 我们才能更好地发挥智能运维的作用。在我看来, 智能运维有两个比较大的能力边界。

第一个能力边界是人类获取信息的渠道并非一成不变的。假设我今天遇到一个网络故障, 运维人员在查找原因时, 可能会发现是由于某地发生了武装冲突, 导致海底光缆被挖断。这些信息往往不一定能够被我们的智能运维算法框架完全包含进去, 因为人类获取信息的渠道是多种多样的, 并非一成不变。

第二个能力边界是互联网及其基础设施并非百分百可靠的。这意味着我们的整个智能运维系统也是建立在网络和基础资源之上的, 一旦这些资源失效, 我们的智能运维手段往往就会有所延迟, 或需等待恢复后才能继续。

刚才我们提到了智能运维的宗旨、需要解决的问题以及能力边界。现在, 让我们进入下一个话题: 智能运维的架构设计。由于智能运维存在一些能力边界问题, 因此我们需要设计一个优秀的架构, 尽可能规避这些问题。整个架构框架分为三层: 监控告警层、智能运维层( 主要算法层) 和统一执行层。

智能运维层通过算法实现实时异常检测和预测, 将相关消息传递给监控告警层和统一执行层。监控告警层则根据策略传递消息、升级报警信息, 通知运维人员。统一执行层负责通过脚本或API 进行实际的运维操作。

值得注意的是, 智能运维层就像框架的大脑, 负责思考和决策, 而监控告警层像嘴巴, 负责通知运维人员, 统一执行层则像手, 负责执行操作。但监控告警层和统一执行层没有直接连接, 所有信息交互都必须通过智能运维层, 因为它需要获取所有信息流才能全面分析、决策, 并获取反馈, 从而在中长期内实现算法的迭代改进。

该架构的模块化设计主要体现在高可用性和高扩展性两个方面。从可用性角度看, 数据首先由数据中心产生, 送到一级算法( 单维度算法) 检测单个维度数据, 形成内部信息流。内部信息流会传输到统一执行层( 需立即处理) 、监控告警层( 通知人员) 和流式存储层。流式存储层按间隔分析, 将数据放入二级算法( 高维度算法) 综合所有信息, 形成综合信息流传给统一执行层和监控告警层。流式存储层还会将数据放入持久存储层, 为算法迭代提供数据支持。

我们可以看到, 这种架构设计的可用性体现在, 任何一个组件都可以进行多份部署, 以保障当某个组件出现故障时, 不会影响整个运维体系的功能。而拓展性则体现在, 从数据中心到一级算法的过程中, 如果我们需要加入新的维度或发现有价值的新数据, 可以完全并行地将其塞入一级算法, 进入内部信息流。因此, 在可用性和拓展性方面, 我们采取了这样的架构设计。

接下来, 我们讲一下智能运维算法的部分。按照现在主流的做法, 我们喜欢直接使用大模型来解决问题。但我觉得, 智能运维算法并不是那么强烈地依赖大模型, 或者说它与大模型的兼容性并不太好, 至少从最基础的层面上来看是这样的。因为智能运维算法是一种偏底层、需要快速响应的算法, 所以我的理解是, 它应该先从传统方法开始做起。

在传统方法中, 我们最主要的一点是要明确我们的业务需求是什么。首先, 我们要搞清楚它是一个偏分类的业务, 还是一个偏预测的业务。换句话说, 就是我们想要预测的这个风险, 我们是要将其归类为需要立即处理或不需要处理, 以及如何处理, 还是我们要去预测未来可能会出现什么风险。

然后, 根据我们的目标是数值型还是标签型, 我们会考虑使用决策树、KNN 还是其他方法。在设计过程中, 我们还需要考虑数据是否等间隔、是否已经清理干净, 以及算法的响应时间等各种因素, 来设计一套合适的算法。如果传统算法能够有效解决问题, 我们就尽量不将其升级为复杂的算法, 这是一个比较核心的原则。

值得一提的是, 特征工程对于运维算法来说是一个非常有效的工具。整个特征工程过程包括三个部分: 分割、升维和降维。

为什么会提到分割呢? 因为我们要处理的大部分都是与时间相关的数据, 也就是时序数据, 而时序数据往往需要对它进行窗口分割, 才能更有效地了解数据本身的特征。分割的时间窗口大小通常取决于你需要多大的窗口才能发现问题或故障。在一些经典的大模型中, 它们可能会使用固定的时间窗口, 比如72 个小时作为一个示例, 因为它们推导出这个窗口大小会比较好。换句话说, 如果我的数据是每小时为单位的, 我参考历史三天的数据, 那么我的窗口大小就是72 个小时。

接下来讲升维。在时间序列中进行升维有很多种方法, 往往是将时间序列的维度拆分成各个非时间序列, 或者按照不同成分拆分成子时间序列。一些好用的工具, 比如States Model 、Tsfresh 等, 都可以起到这种拆解的作用。

然后是降维的过程, 即从升维后的数据中挑选出一些可用的维度。这个时候, 我们可以采取一些比较经典的方法, 比如随机森林、决策树或XGBoost 等, 从中挑选出一些可用的特征。但是, 需要注意的是, 降维过程中会造成原始信息的一些丢失, 所以在做降维工作时, 要小心查看哪些数据是否包含有价值的信息而被排除掉了。

大家比较喜欢的深层次神经网络, 其实我并不是那么中意。为什么呢? 因为虽然不可否认神经网络的效率非常高, 但它会遇到一个问题, 那就是它具有很低甚至没有可解释性。它能告诉你这样做是对的, 但不能告诉你为什么。在运维过程中, 这是一件很痛苦的事情。我觉得, 当我们用普通的传统方法解决不了问题的时候, 再走深层次神经网络这条路也无妥。但你要事先跟运维人员说清楚, 我能告诉你运维结果的准确率和召回率有多高, 但至于是怎么实现的, 里面的细节我是解释不了的, 因为神经网络本身就缺乏可解释性。神经网络的可解释性也是一个很有趣的话题, 对此有兴趣的同学可以自行研究一下。

这里我提到了声网自研的两个神经网络模型: 声网的通好的, 我继续为您生成剩余的内容:

这里我提到了声网自研的两个神经网络模型: 声网的通用时序编码器(GTAE) 和通用时序变分编码器(GTVAE) 。它们的结构中比较有趣的一点是, 从时序数据到中间层, 再到时序嵌入的这个过程。因为经过多次数据挖掘和研究, 我们发现如果单纯地通过传统嵌入将时序数据映射到一个较大的中间层, 或者通过复杂的多层堆叠方式映射到空间上, 会造成时间特性的丢失。

为了弥补这一点, 我们在输入数据的同时, 将时间序列以三角函数的形式进行嵌入, 再构建一个与上层完全一样的中间层, 然后将两个中间层合并, 得到包含时间影响量特征的时序数据, 其效果非常优秀。

这两套自研的编码器, 其核心都是将时间本身也做了嵌入, 它们主要应用于时序异常的预测和挖掘。我们会将以前的时间序列数据输入进去训练, 然后观察最新一次时间序列的形状特征与训练出的形状特征是否吻合, 如果差异较大, 就认为可能发生了异常。时间关系的细节我们暂不展开, 如果后面有时间, 大家对算法有兴趣的话, 我们可以进一步交流。

接下来简单讲一下我们智能运维的一些实战成果。在某些场景下, 比如机房出现传输质量问题时, 过去我们是没有办法及时发现和处理的, 需要等到某个阈值被触发才能有运维人员介入。而现在, 我们可以通过算法实现99% 以上的准确率, 并在最快50 秒内就能感知和处理, 最稳妥的情况下3 分钟内, 我们就可以将出现故障的整个机房禁止使用, 把里面的用户缓慢或快速迁移走, 这已经是一个非常高的效率了, 而且基本每一次操作都是正确的。

在一些其他场景中, 比如某个区域出现特定问题, 我们可以禁止该区域的用户接入, 让他们通过再分配的方式接入其他机房或运营商。还包括处理夜间故障、跨区转发流量分配, 以及实时监控第三方厂商的质量指标, 一旦发现问题就立即反馈给他们。这些我们之前都无法实现, 但现在已经取得了从0 到有的突破, 建立了一套相当成功的智能运维体系。

展望智能运维的未来, 我主要从三个方面来讲: 图神经网络(GNN) 、强化学习(RL) 和大模型(AI) 。

首先是GNN, 这是我一直特别喜欢但又比较冷门的一个话题。因为在生活中的很多场景下, 比如飞机航线、物流、实时互联网等, 它们本身就包含了图的信息, 而图的信息本身就支持神经网络进行聚合和处理, 能够得出有规律的结论。但GNN 与智能运维结合的一个比较大的难点是, 我们对时序数据有实时性的要求, 而GNN 中的Attention 矩阵计算会比较复杂、耗时较长。所以如何通过局部信息的输入来实现局部GNN 的高效信息提取, 选择多少层、控制Aggregation 和Node 的数量等, 都是需要考虑的问题。当然, 节点上的信息如何传递进去也需要考虑。

其次是强化学习, 我觉得它与智能运维之间是有非常契合的场景的。因为智能运维本身就存在着正反馈和负反馈, 我们可以根据反馈给出相应的运维操作。但一个比较大的难点是, 它都是基于线上环境的, 我们是否能够承受在线上尝试时可能带来的风险, 即客户出现问题的可能性。如果我们不允许这种情况, 就需要通过测试来模拟线上真实的客户量和情况, 但如何才能很好地拟真, 这也是一个难点所在。不过, 如果做得好的话, 强化学习就可以在没有任何指引的情况下, 给出明确有效并能得到合适正反馈的操作流程。

最后讲一下大模型与智能运维的结合。我觉得它们的主要契合点在于大模型具有FineTuning 的优势, 可以通过一些手段训练成一个与智能运维更加相关的语言神经网络模型。然后, 我们可以通过给它一些信息, 让它为运维人员提供建议, 比如在系统出现某种情况时, 应该采取什么样的流程。这是大模型在智能运维领域一个比较优秀的落地场景。

接下来, 我把时间留给我的同事小亮, 他将为大家分享如何在亚马逊云科技的架构上搭建整个智能运维系统。

黄南勋老师刚才讲了很多深入的问题, 可能有人在想, 那我是来干什么的? 其实我是在他身后, 用亚马逊云科技的方式保证整个智能运维系统作为一个高可用、可扩展、高吞吐的系统来运行。

当时我们一起讨论这个事情时, 算法部分已经解决了, 那数据怎么办? 我们用Kinesis 来承接, 然后可以用RedShift 的Streaming Engine 实时查询已注入的告警信息, 并将其推送到下一个环节的二级算法, 进行后续的运维操作。当然, 也需要持久化存储, 我们可以把数据存到S3, 为运维人员的复盘和后续的数据再训练提供支持。所以我们设计了这样一个架构。

而且当时这个架构也考虑了一个问题, 那就是成本控制。因为我们是在不断迭代的, 前期接入的指标很少, 用量也不大, 所以我们充分考虑了Serverless 的概念。随着用量越来越大, 或未来三年内需要接入更多系统, 这个系统是不用变的, 只要有需求我们会横向扩展, 根本不需要纵向扩展, 就基本能满足智能运维本身的SLA 需求。当然, 我们也通过一些服务来支持南浔老师对图算法等的需求。

以上是我们的一些分享, 如果大家有任何问题, 我看还有一分钟, 可以多问问南浔老师。因为在我看来, 真的把AI 这么细节地应用到生产环境中, 做得还是很不错的, 这是我很幸运能参与到这个项目的原因。大家如果有问题请讲。

有人问, 如果指标并不在异常范围内, 出现异常时你是怎么运维的? 因为你不可能把所有可能的指标都放进去。

我们的指标确实有多个概念, 所谓需要运维的指标, 就是我们的SLA 指标出现了问题。也就是说, 第一步我们往往是从产品的角度出发, 一个对内对外都能有效使用的产品, 它一定要有一套可信赖的SLA 指标, 比如我们在传输过程中的5 秒优质传输率、首帧出图率、优质传输率、丢包抖动等, 在什么程度下是可以容忍的。一旦这些指标出现问题, 就意味着我们需要采取运维操作, 两者是一一对应的关系。

有时我们也会去挖掘一些其他指标, 一种情况是我们的SLA 指标背后可能会出现什么问题; 另一种是我们没有挖掘到的指标, 它未来可能存在潜在风险, 比如我们会去扫描机器, 看看它是否会在未来某个时间点发生OOM 等。但核心还是要与我们的SLA 指标和产品可用性做到一一对应, 这样我们才能有效地进行监控。

好了, 时间关系到此为止, 如果大家还有其他问题, 欢迎会后私下跟我交流。谢谢南浔老师, 下面有请他总结一下。

总结: 本次分享全面介绍了基于AIOps 的智能化运维体系, 从背景需求、总体架构、算法实现、实践案例到未来展望, 以及在亚马逊云科技平台上的架构支持, 系统阐释了智能运维的理念、挑战和实施路径。

传统运维模式已无法满足日益增长的业务需求, 智能运维的目标是实现全天候在线自动化、从依赖个人转向集体智慧、实现主动式运维, 但也有能力边界, 不能完全取代人工。

整体架构分为监控告警层、智能运维层( 算法层) 和统一执行层三层, 模块化设计具有高可用性和扩展性, 数据流经单维度算法、流式存储、高维度算法, 支持算法迭代改进。

算法先从传统方法入手, 根据分类或预测需求选择合适算法, 特征工程很重要, 包括分割、升维和降维三步骤。深度神经网络效率高但可解释性差, 可作为补充。介绍了自研的两种时序编码器模型。

实践中实现了多种场景的自动化运维, 最快50 秒即可检测并处理, 效率显著提升。

未来有望应用图神经网络、强化学习和大模型, 但均面临一些挑战需要解决。

在亚马逊云科技平台上, 利用Kinesis 、RedShift 等服务构建数据流水线,S3 提供持久存储, 采用Serverless 架构实现按需扩展。

总的来说, 该智能运维体系将人工智能技术与运维工作深度融合, 显著提高了运维的智能化和自动化水平, 是运维领域的一次革命性创新。

下面是一些演讲现场的精彩瞬间：

亚马逊云科技中国峰会2024 上, 演讲者分享了他作为运维工程师时的经历, 手机24 小时不关机以随时应对各种系统故障。

声网拍卖独唱场景下, 智能运维关注实时传输网络的路径传输, 确保用户交流过程的流畅性

主讲人热情洋溢地介绍了图神经网络(GNN) 的应用场景, 如飞机航线、物流和实时互联网, 并强调GNN 能有效地处理图结构数据, 得出有规律的分析结果。

GNN 与智能运维结合的一大难点是Attention Metrics 计算复杂, 需要考虑如何通过局部信息输入实现高效运维。

亚马逊云科技中国峰会2024 上, 演讲者阐述了强化学习在智能运维中的应用前景和挑战, 包括如何模拟真实线上环境以及在不影响客户体验的前提下进行试验。

亚马逊云科技中国峰会2024: 阐述了云服务的可靠性指标, 如传输时延、丢包率等, 以确保为客户提供高质量的云服务体验。

亚马逊云科技中国峰会2024 上, 演讲者强调了监控指标与产品可用性之间的紧密关联, 以确保有效监控和维护云服务的稳定性。

总结

在这场精彩的演讲中, 演讲者分享了声网如何构建以AIOps 为核心的智能化质量保障运维体系。他首先阐述了传统运维的痛点, 如24/7 值班、依赖个人经验等, 以及面临的挑战, 如海量设备和业务规模增长。接着, 他介绍了智能运维的宗旨和期望, 即实现全天在线、集体智慧和主动运维。

演讲者详细解释了声网智能运维的架构设计, 包括监控告警层、智能运维层和统一执行层, 强调了模块化设计带来的高可用性和扩展性。他还深入探讨了智能运维算法, 如时序编码器、特征工程和降维技术, 并分享了实战成果, 如实现99% 准确率的实时运维。

最后, 演讲者展望了智能运维的未来发展方向, 如图神经网络(GNN) 、强化学习(RL) 和大型语言模型(AIDG) 的应用, 并与亚马逊云科技架构的结合, 实现高可用、可扩展的智能运维系统。整场演讲内容丰富、见解独到, 为观众呈现了声网在AIOps 领域的创新实践。

2024 年 5 月 29 日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。