RTE2021 回顾丨实践中的摸爬滚打，AI OPS 落地之路

2022 年 2 月 11 日
本文字数：3390 字
阅读完需：约 11 分钟

本文整理自声网 Agora SD - RTN 网络传输质量负责人于涛在 RTE2021 实时互联网大会上的演讲分享。他在演讲中针对传统 OPS 痛点、AI OPS 的优势以及 AI OPS 工程化的难点进行了全面的分析，并分享了声网研发团队关于 AI OPS 落地实践过程中的宝贵经验。

▲图：声网 Agora SD - RTN 网络传输质量负责人于涛

01 为什么需要 AI OPS

需求往往是从生产中的痛点出发，每一项新技术都是从需求的孵化过程中诞生的。目前传统的 OPS 主要存在三大痛点：7 D × 24 H 无间断运维保障、运维执行的质量以及执行效率问题。

1. 7 D × 24 H

服务的高可用依赖 7 D × 24 H 的不间断运维保障，组建 7 D × 24 H 团队的难度大，成本高。而且随着业务规模的增长，以及产业的全球化，以上问题的难度会线性增加。

2. 质量

业务运维是一个相对比较“吃经验”的工作，这也就是为什么传统运维新人入职往往有比较长的入职培训以及熟悉业务过程。经验的差异会引擎运维处理质量不一致，或导致异常没有捕捉，或导致处理不到位，亦或处理过于激进，这都将直接影响客户的体验。这一点 AI OPS 是能够较好地弥补的，训练良好的算法能够将执行质量逼近经验老道的运维人员群体决策的结果的同时，保持执行结果的高一致性。

3. 效率

运维效率对用户的体验也至关重要。服务质量异常的时候，如果处理需要 1 小时，用户的体验就受损 1 小时；如果处理时间只有 5 分钟，就只影响 5 分钟。以机房网络质量回退来说，经验丰富的人员从报警到处理完成的平均耗时也在 15 分钟左右，加上线上服务规模之大，故障又是相对随即发生的，让有限人数的团队监控如此大规模的服务集群的同时，还要保证所有异常高效地处理异常，传统运维已经捉襟见肘。但是自动化的 AI OPS 在执行效率上却有着先天的优势。

回顾来看，这些传统人工 OPS 上的痛点恰巧是 AI OPS 最大的优势所在：

7 D × 24 小时：机器是不需要睡觉的。
质量问题：经过训练的模型它的执行质量是稳定可靠的。
效率问题：自动化的 AI OPS 系统效率远高于人工。

02 AI OPS 工程化的难点

在具体实践的过程中，AI OPS 的工程化落地还存着诸多的困难。

标准化：从 AI OPS 行业来看，整个行业正处于期望膨胀期，技术和工具不断推陈出新的同时行业缺乏标准，没有成熟稳定的平台和工具链。从公司发展的角度来看，AI OPS 处于探索阶段，在没有标准化的情况下进行工程化成本和风险都非常大。举个例子，这就好比我们要将现有服务容器化上云，却没有如今已经非常成熟的 Docker，K8S 工具，同时各云厂商也没有针对容器做各类适配和兼容，这会增加大量的架构设计和开发工作。这就是 AI OPS 落地过程中面临的第一个比较棘手的问题。

期望不一致：在企业中，业务、运维、算法乃至大数据团队对于 AI OPS 的理解往往是不一样的。过去几年智能驾驶的事故新闻大家应该都还有些印象，其中一个原因就是人们对智能驾驶的期望是"真正的自动驾驶"，然而当前阶段的 AI 是很难脱离人去完全自主运行，当驾驶环境超出 AI 的能力边界的时候驾驶员没有接管，悲剧便产生了。目前 AI 是一个非常时髦的词，但是不同专业的人对其的期望不一样，不一致的期望导致信息差，不仅影响协作进度，还可能引起线上故障。

基础设施要求高：巧妇难为无米之炊，好的 AI 除了优秀的算法，还依赖高质量的数据，AI OPS 也不例外。以全球化的云服务供应商为例，要做好 AI OPS 的基础是做好大数据，除了要做到实时高吞吐的数据中心，还要提供流式计算接口。

03 Agora 的 AI OPS 落地最佳实践

针对 AI OPS 落地的具体实践过程中出现的问题，我们研发团队又是如何解决的呢？

短期与长期目标的制定

对齐长期目标，长期目标的制定能够帮助团队明确发展方向，有利于梳理前期工作重点。

短期目标是将长期目标拆解为阶段化目标，其主要作用是尽快把我们的项目 AI 算法落地，还要为长期目标打基础，一些公共组建要建立起来。

团队间对齐期望，能力互补

由于 AI OPS 是多团队的协作，它是 SRE、业务、算法、大数据四个团队紧密协作下的产物。在此过程中，对齐期望做好团队协作至关重要。

首先是团队之间的能力理解。我们业务团队需要主动了解算法团队的能力，算法团队除了实时的异常捕捉能力、单指标的时间序列异常识别，还能提供用量预测能力，根据数据的质量和用量的规律，算法推测甚至能够提供长达以周或者月为单位的预测。对于 SRE 来说，这在流量规划和成本控制方面能够带来很大的价值。

其次是边界的理解，这个很重要。对其他团队能力边界的模糊认知，可能会酿成线上故障或者是悲剧。机器学习的质量依赖于人工标注的数据质量，算法的能力边界可近似于标注人（群）的能力边界。如果业务团队对算法过度信任，线上故障可能就不可避免了。假设业务团队将有问题的算法应用到一些非常核心的服务，并且完全脱离人的约束，这就好比完全脱离人的自动驾驶，根据墨菲定理，必然出事。

当了解到能力和边界之后，团队间就需要通过互补来达到整体最优。AI 在其最擅长的领域做到高质高效降低人工精力消耗，传统运维则处理一些意外情况保证整体可用性。

解耦业务，运维和算法

在落地的过程中至关重要的一步，就是将运维平台服务化和 API 化。

何为运维？何为落地？运维是指服务层/业务上的操作，那么 AI OPS 的落地就是算法结果作用于业务。但是如果在算法层直接调用业务运维接口或者直接修改数据库，那么首先风险是非常大的，其次耦合非常严重，反过来对于算法，业务和运维开发迭代效率都非常低。这对真正摸索阶段亟需快速迭代的整个项目组来说，无疑是非常大的困难。

为了解决上面的问题，我们将 AI OPS 拆分成三层：

第一层：AI 层
第二层：决策层
第三层：执行层

这三步做完之后，就可以把 AI 和运维解耦，其好处有 3 点：

一: 算法，决策，执行层可以独立开发，提升模块研发效率。各模块尤其是算法可以进行快速的迭代更新，同时可以避免"牵一发动全身"的情况，迭代的成本更低。对于探索阶段 AI OPS，解耦是寻求落地的路上不可或缺的环节。

二: 系统更健壮。决策层可以做更多防呆和安全策略，提高系统鲁棒性。在面对单一算法崩溃，或者结果输出异常，处理空间更大更优雅。

三: 可扩展性强。标准化的输入接口对于后续算法甚至其他自动化脚本的接入提供了更为便捷的接入方法。实质上在公司内部完成了 AI OPS 的标准化。

将多指标转化为单个综合指标——化繁为简

多指标异常检测比单指标的更为复杂，对数据质量和标注质量要求更高，其落地也更加艰难。这时业务侧可以充分发挥互补能力，尽可能把多指标转换成一个综合指标。例如，延时、丢包和抖动都会影响网络传输体验，将其转化为一个综合指标优质传输率。该指标不仅能够准确反应网络质量，对于算法团队训练单指标的算法模型也相对比较简单，加速了 AI OPS 的落地。

“强大”的算法不一定是合适的算法

算法是 AI OPS 的核心。强大的算法不一定是最合适的算法，还关乎到成熟度和鲁棒性。

比如发动机是汽车的动力核心，强大的发动机往往需要更高标号的汽油。同样地，更强大的算法（例如深度学习）需要更高质量的数据。目前这个阶段，要求更高质量的数据，涉及了一个很长的链路。在业务层要定义合适的指标；在传输的过程中，可能会有数据的丢失，或者脏数据；在算法训练方面，需要大量的人工来标注。考虑到这三点，在 AI OPS 早期的挑战是相当大的，选择当前阶段适合业务的算法能更有效的推动落地。