虚拟座谈会：聊聊AIOps的终极价值

作者 郭蕾

简单来说，AIOps就是希望通过人工智能的方式，进一步提升运维效率，包括运维决策、故障预测和问题分析等。在InfoQ最近的一些文章中，都有不同程度地聊到AIOps相关的话题，比如美丽联合集团运维经理赵成认为AIOps必定是运维的发展趋势，宜信技术研发中心高级架构师张真系统分析了他们的实践案例，AliExpress的周志伟也表示他们正在落地智能驱动的SRE理念。

从历史发展的角度来看，这些年，运维平台大致经历了流程化->工具化->Web化->自动化的演进历程。随着运维管理复杂度的提升，以及企业自动化运维体系的成熟，运维平台必定会向智能化靠拢。而从结果来看，智能化才是运维平台的最终目标。正如InfoQ的另外一篇文章所言，在这个数字化转型的年代，任何使用传统技术来管理机器数据的企业要么是忽略了信息的价值，要么已经让他们的运维团队不堪重负。随着数据的暴涨，运维团队应该快速拥抱AIOps。传统AI仍然会在某些领域发挥它的作用，而AIOps将为企业带来最直接最深远的价值。

讨论组成员

曲显平：百度运维部技术经理

万金：ThoughtWorks咨询师

涂彦：腾讯游戏运维总监

InfoQ：如何理解AIOps? AIOps里面会涉及到哪些技术？这又是一个新名词吗？

曲显平：AIOps, Gartner有报告解释为Algorithmic IT operations platforms，当然国内大多理解为AI+Ops，智能化运维。涉及的技术概括来讲就是ABC, AI+BigData+Cloud，当然AI的部分，不仅包括时下流行的机器学习等技术，其实也要包含传统的数据挖掘等方法。

百度从2014年初提出智能化运维的思路，这个名词在我们这里不算新了。

万金：AIOps是一次跨界创新，它结合了运维场景和运维数据，使用人工智能方式试图将运维决策自动化。

AIOps技术会涉及到数据收集方面的基础监控，服务监控和业务监控，甚至会涉及到与持续交付流水线的数据和状态整合（比如在软件发布的阶段会自动关闭某些监控项。异常判断时会参考流水线目前的状态）。数据存储与人工智能技术，其中人工智能包括机器学习算法与深度学习模型（用于模式识别）。

AIOps可以算一个新名词，他会是比自动化运维更高级的阶段，即为了保证确定的运维目标（SLA）使用人工智能自动决策阶段。（自动运维是将重复出现的运维动作自动化，而需要人来判断什么情况（或是条件出发）执行那种自动化过程。）

涂彦：不论是AIOps还是OpsAI，都是智能运维。简单来说，就是把成熟的人工智能技术应用于互联网及互联网+的运维工作场景中。AIOps可以认为是运维岗位一个分支，本质还是运维。AIOps本身也是由多个子岗组成的，比如智能场景规划、数据清洗、机器学习开发等。如果从运维的发展历史来看，确实是一个新名词。也代表了运维是个在未来有很大发展潜力与核心竞争力的工程师岗位。

InfoQ：你认为AIOps是运维发展的必然趋势吗？从手工运维，到自动化运维，再到现在的AIOps，谈谈你理解的运维发展趋势？

曲显平：很多人认为，运维是手工->自动化->智能化，但其实百度不是这样认为的，自动化运维可以说是终极状态，不管是Web化、平台化、还是智能化，用写死的if/else还是机器学习模型，都是实现的方式而已。其实运维人，要做的，就是一切皆自动，其实AIOps也就是讲的如何把人的决策也自动化起来。

为什么说他是必然趋势呢？主要还是因为传统方法仍然不能解决运维很多问题。比如在百度，一线运维最主要有3类场景：变更管理、故障管理、服务咨询。

·变更管理，相比之下自动化程度最高，但仍然不能做到完全无人值守，最主要的问题是，如何检查一次变更是否符合预期、变更过程中遇到问题如何处置等。

·故障管理，这个问题的复杂程度就比变更管理高很多了，从应该部署什么样的监控、如何设定报警、收到报警后如何判断并做出止损操作、止损后如何做根因分析、case study、如何彻底解决这一系列问题等等，这些还都是原有技术无法解决的。

·服务咨询，这个领域向来都是自动化程度最低的，也一直是亟待解决的。

其实从这些描述来讲，在传统意义的自动化运维过程中，大家更多地是完成了两件事：一个是平台化，不再需要上到服务器去操作了；一个是大规模并行，一个任务可以同时在成千上万个实例生效。但一旦问题变得复杂，不是if/else能够解决，而需要人工决策的时候，传统自动化就不灵光了。

这种需要人工决策才能解决的问题，是制约运维走向终极自动化的主要障碍，从现今的技术发展来看，AIOps显然是最合理的路。

万金：AIOps是运维的必然趋势，随着数字化转型的推进，业务快速扩张规模不断扩大，监控规模与数量（系统，服务和业务监控项）越来越多，云计算又导致更进一步的集中化。这些因素使得运维工作复杂度超越人力所能管理的程度，必须通过自动决策方式辅助人来进行运维工作。而对于业务而言希望不通过增加运维团队规模的方式支持迅速扩张的业务。以上两点导致智能运维的必然性。

AIOps并不是一开始就出现的，运维的技术是随着业务的规模与复杂的提升而不断演进的，为业务选择合适的运维方式是首要考虑的问题。相比较而言，智能化运维需要投入很大的启动成本，但是能达到前所未有的运维效率；而反观手动运维启动成本很低，适合在业务规模很小的初期使用，不过云原生应用和云计算平台降低了AIOps的启动成本，可以帮助快速扩张的业务解决手动或自动运维无法解决的问题。

总结运维工作的特点，业务在初期都是需要手动梳理运维业务的问题，从中发现系统性问题，从而为自动化运维提供知识储备；到了自动化运维阶段会不断的标准化运维管理对象，并积累运维数据为智能运维做准备；当业务处于爆发期通过AIOps方式自动化保证SLA的执行就成了顺理成章的选择了。这里所说的无法通过自动化批量执行的任务，往往需要根据实际情况（不能通过阈值判断的情况）进行判断后采取行动。这样的任务正是AIOps的入手点。

比如海量阈值的自动设置来降低监控系统的错报和漏报情况，或是在海量的分布式告警信息中找到故障的根音。

涂彦：AIOps是互联网大势所趋，也是运维发展的必然趋势，更是现阶段运维发展的终极目标，相信在未来5年内将更为广泛应用在不同行业的运维工作中。自动化运维是一个承上启下的转折点。从手工到自动化，需要跨越标准化。而从自动化到智能化，需要跨越数据化。标准化和数据化是智能运维建设要思考的底层问题。从组织能力到技术能力，缺一不可。

InfoQ:AIOps的出现是为了解决哪些问题？这些问题自动化运维没办法解决吗？

曲显平：这个问题在上一问解释过了，AIOps的出现是为了让运维早日达成完全的自动化运维，也就是解决人工决策->自动化决策的问题。

万金：任何运维问题本质上都可以通过手动或自动化方式完成，但是如果考虑到MTTR（平均故障修复时间）对业务的影响和对运维团队人数的限制，就必须引入AIOps。

首先，运维每天最多的工作就是监控系统是否正常运行，如果出问题了就需要及时解决，比如99.99%的可用性就意味着每年只能出现52.56分钟的系统不正常时间，一般人工处理一个故障在熟练的情况下也会在20分钟也就是说在频繁上线更新的情况下只能期望一年系统不要出2次以上的问题。如果想提高系统可靠性就必须引入AIOps。

其次，AIOps的出现大大缩短了MTTR，在解决如何发现系统异常（自动化监控项管理）和如何找到问题根因（告警抑制：通过关联性判断，把计算资源、软件和网络具有相关性的告警信息聚合，让运维人员迅速找出问题根因的技术）。

最后，人的管理能力是有限的，就像人可以驾驶汽车，但飞机就需要自动导航只在启动和降落需要人工干预，对于宇宙飞船，宇航员只有在出现故障的时候才会手工干预。AIOps就像驾驶宇宙飞船的计算机，只有AIOps的自动决策结果与预先设定好的目标（SLA）不相符才需要人工干预。

涂彦：质量、效率、成本、安全，是运维工作核心四要素。用AIOps来解决，会在提升效率的同时，将质量与成本更加精细化，使安全的应变能力更强。自动化在决策方面很难快速适应千变万化的生产环境和业务需求，运维经验仍然是主导地位，依靠个人能力的痕迹明显，对企业管理的风险都受控于个人。

InfoQ：落地AIOps的前提条件是什么？什么样的团队适合落地AIOps？

曲显平：从百度运维的AIOps经验来看，落地AIOps的前提条件是已经具备了比较完善的运维平台和有较充分的运维数据，也就是ABC（AI、BigData、Cloud）里的A，离不开B和C的支撑。

我们的团队，用了5-6年的时间才完成了运维的完全平台化，以及建立了统一的运维数据仓库，在这之前当然也可以落地一部分AIOps场景，但相对应的，也是需要这部分场景的B和C具备。目前看，应该是运维平台和数据都已具备时，才是落地AIOps的理想时刻。

万金：在那些具有较强自动化运维能力，和一定的数据储备的条件的团队才适合AIOps落地，同时业务是否对运维效率提升有需求也是一个考虑因素。

引入AIOps之后，是否能对AIOps的模型或数据进行不断优化也是一个新的挑战。人工智能在一开始都不是很完美的，需要不断优化才能达到实际应用的要求。对于发现问题和问题根因分析方面的AIOps落地速度比较快，对于高级阶段的根据SLA自动调度的AIOps就需要比较长的优化

涂彦：标准化、工具化、自动化、数据化、场景化是前提条件，同时这也是逐一递进的关系。

随着人工智能技术的愈加成熟，只要具备业务需求的团队，都适合落地。人工智能技术在运维行业的应用与其在其它行业落地的状况类似。所以说，AI并不是那么神秘，使用的门槛只会越来越低。但是如果要想在企业中真正用好，需要对业务理解并紧密结合技术方案的运维，比如通过智能场景规划来找到痛点，再结合数据清洗与机器学习开发来完成落地。

InfoQ:AIOps中的数据是怎么来的？数据是必要的吗？

曲显平：数据非常必要，因为AIOps中的A主要指的是算法（数据挖掘、机器学习），每一个算法都离不开数据的支撑，尤其对于深度学习而言，普通体量的数据都不足以支撑训练出理想的模型，需要非常庞大的数据量。

AIOps的数据，从来源上看，主要分四类：设备、系统、平台、业务，设备主要指IDC、网络、服务器等偏硬件、数据中心层的设备信息；系统主要指操作系统等；平台主要指基础运维平台、PaaS平台等；业务主要指产品服务的日志等。

AIOps的数据，从类型来看，主要也是四类：一个是时序数据，这个重要性最高，因为其结构化层次高，在百度，这个数量级能达到十亿级。第二个是运维事件数据，这个同样也非常重要，每一次异常事件、变更事件、运营事件等等，都是需要被记录并加以分析的。第三个是日志数据，相比之下日志数据的结构化偏弱一些，但同样十分重要，由于量级太过庞大，我们也只会挑选并存储较为重要的部分，来进行分析训练。当然，还有最后一类，因AIOps而产生的数据“标注数据”，这部分数据的完善程度将直接影响着每一个算法模型的实际效果。

万金：AIOps中的数据是从监控系统和相关的运维经验中来。而AIOps也是有不同的实现的技术，比如通过机器学习算法的AIOps依赖数据较小，只要找到合适的算法就能对当前数据进行处理，但是处理效果随着数据模式的改变而改变，也就是当数据体现的模式改变后就必须手动更换算法适应新模式。而深度学习的算法就不必人工更换模型只需要设定目标（SLA）但对数据依赖比较多。

涂彦：训练的基础就是数据，这个与其它行业并无区别。数据来自于运维工作与服务的场景。质量、效率、成本、安全，任何一个维度都需要将数据标准化采集，这是一切的基础。再比如技术运营的一些触达到用户或者产品的场景，也是一个数据化的过程，任何一个节点的数据都可以被采集。这些标准化和数据化的工作，都是AIOps的基础工作。

InfoQ：可否谈谈你们的AIOps落地场景？

曲显平：在百度运维，AIOps应用的很广泛，监控异常检测、故障诊断分析、智能流量调度、SQL入侵检测、成本优化、性能分析优化等等。

我们在自动化异常检测方向的研究非常早，早期还以传统的时序数据分析为主，现在由于机器学习等方法的兴起，已经多样化很多，在百度大多数核心时序指标的监控都是用的自动化异常检测模式。

在故障诊断方向，这一直是一个比较难的课题，我们研究过非常多的行业paper，真正实现后效果出色的少之又少，当然这也可以理解，因为对于人来讲，诊断故障也一直是一个让人头疼的问题。

此外，在智能流量调度、SQL入侵检测、成本优化、性能分析优化等层面，我们应用了非常多的机器学习模型，为公司业务的可用性、成本、性能等的提升做出了巨大贡献。

万金：故障识别和故障自愈，资源自动调度。

更高级的场景会引入全自动软件发布控制与回滚，自然语言容量管理，主动安全识别和在软件研发完成前对软件体验进行评分。

涂彦：腾讯游戏的运维团队聚焦在基础服务与增值服务中落地。基础服务包括发布变更、故障管理、用户体验服务。增值服务包括触达到用户与产品决策的运维扩展服务。发布变更中的数据预测、故障管理中的根因分析、用户体验中的多维告警等，都是AIOps的落地场景。触达用户的云控策略、产品决策的舆情分析等，也都有着很好的应用场景。

InfoQ：目前业界有哪些可以参考的AIOps实践？

曲显平：在AIOps和智能化运维这个角度，百度运维是做的比较早的，我们将运维能力标准定义为六级，L0-L5，每一级都有相对明确的定义，很多方向都可以应用AIOps来助力等级的提升。

当然除了百度，推荐看下Netflix的Winston，以及Google的Auxon，这些实践，不仅是用某种算法在解决一个领域的问题，他们正在尝试构建一种开放的自动化/智能化运维模式。

越来越多的公司关注并且重视这部分信息的开放和共享，从场景到算法，从数据到开放框架，百度运维也正在参与其中，也欢迎大家合作共建智能化新运维。

万金：在我的文章里提到一些算法方式的实践，深度学习方式由于依赖多，成本高不确定性大应用比较少。行业参考如下：

·Twitter: Seasonal Hybrid ESD (S-H-ESD)

·Netflix: Robust PCA

·LinkedIn: exponential smoothing

·Uber: multivariate non-linear model

涂彦：腾讯蓝鲸智云来自于腾讯游戏数百款游戏的基础服务与增值服务的最佳实践。目前已经对外提供社区版和企业版。蓝鲸可以帮助运维团队在标准化、工具化、自动化的深度建设，结合蓝鲸数据平台，AIOps将提供给运维团队更多想像空间。