智能运维规模化落地，这些难题仍未破解丨话题接力 - 运维 - dbaplus社群：围绕Data、B...

张静、徐新龙 2022-10-21 09:57:44

本文部分内容依据张静老师和徐新龙老师的〖deeplus直播：话题接力丨智能运维AIOps难落地呼声极高，如何破局？〗线上分享演讲内容整理而成。（文末有回放的方式，不要错过）

近几年，智能运维的出现，给传统重复性运维工作的人力成本和效率问题提供了有效的解决方案。然而，目前国内智能运维发展仍处于一个探索阶段，以数据为基础、以场景为导向、以算法为支撑的“三驾马车”还难以结合，智能运维的发展面临着“难落地”的困境。

为此，dbaplus社群邀请到京东科技 智能运维算法高级经理-张静、蚂蚁集团 AIOps技术专家-徐新龙，希望通过汇集两位运维专家的研究成果和实践积累，给大家进一步明确智能运维发展的方向，提供可参考、可落地的智能运维实战经验。

两位老师也列举了各自企业所做的一些智能运维实践，给大家提供参考：

张静

京东科技从2018年开始建设智能运维，基于京东多年一线运维经验，以大数据和人工智能技术为抓手，形成以应用为中心的一体化智能运维解决方案。

• 利用京东内部历年大促场景，沉淀大促数据，积累算法模型，对算法进行不断的优化训练。

• 在监控、数据库、网络、资源调度等多个纵向场景取得突破，可移植性强。

• 建设路径分为两个阶段：第一个阶段主要为运维数仓建设，在有了一定的运维数仓基础建设之后，再同步进行运维算法学件建设，基于京东科技内部的真实运维场景开发与迭代智能运维的算法学件，并落地到智能运维产品功能设计上。

• 形成了一个标准化的从算法开发到算法落地，再到算法迭代整个生命周期管理一体化的智能运维平台。

在建设的过程中取得的成果：

自研通用化智能基线算法学件10+，自研通用化异常检测算法学件10+，场景化异常检测算法方案5+，具备多种自研通用化根因定位算法学件，可以自动触发多维实时根因定位 ，从上万维度属性值中定位到根因维度，自研5种以上增量式学习模板提取与相关分析算法学件，运维知识图谱内涵盖节点30W+，以应用为中心向外延伸出的图谱关系达90W+，赋能根因分析快速精准查询调用。发表IEEE国际会议论文（AIOps方向）7篇，申请40项智能运维专利，提升智能运维产品的业界影响力和认可度。

徐新龙

蚂蚁的智能运维实践主要有基于容量的场景、应急的场景以及智能变更几个内容。

我主要讲围绕SLO健康度体系展开的智能运维实践，因为我们基于现有的运维背景展开的很多实践虽然运用了人工智能技术，但算法的上限受限于数据质量的好坏，所以从源头上建设高质量的数据非常重要。围绕SLO健康度体系，我们生长出了很多能力，包括应急、故障定位、预案推荐，以及基于SLO整个健康度体系的一些运营环节，从而AI产出可以支撑运维决策和驱动运维演进的数据，这是我们基于SLO展开的一些具体的工作。

目前我们基础设施侧的体系主要是搭在SLO这一条线上，主要也考虑到了AIOps实践过程中时常被上层的业务应用和服务所依赖，缺失了很多泛化能力跟迁移能力，比如我们在这个场景下可以做的事情，在另一个场景可能就不合适，所以很多算法学件需要调试和适配，这也是我们实践AIOps一个比较大的难点。所以我们展开了从源头上构建相对高价值的数据资产，让AIOps的落地更成体系化。

dbaplus社群还搜集了一些智能运维的痛难点，跟两位老师一起探讨：

Q1智能运维与数据之间有何关系？智能运维和数据治理如何相辅相成？

张静

数据是智能运维必不可少的一部分，在数据基础之上搭建算法模型，模拟人工发现问题和定位问题的过程，部分场景实现智能化运维；智能运维可以作为自动化运维的触发点，智能运维可以将故障发现和定位的根因传给自动化运维，按流程编排实现故障自愈。在建设智能运维之前要做好数据治理，在智能运维建设的过程中随着落地场景的扩充，需要的数据会越来越多，要同步做数据治理。

• 算法落地如何与数据相结合？有什么具体表现？

我们会把各个层的监控数据统一收集到智能运维平台的数据中心，比如数据库层、中间件层、网络层。以异常检测为例，我们自研通用化异常检测算法学件10+，那么在不同的场景下，最优的算法学件也是不同的，包括网络场景、数据库场景、中间件场景和监控场景。我们内部发现异常之后也会发通知，将告警发给运维工程师，运维工程师能够通过链接点击的形式修正我们的标签。我们的智能运维平台在模型迭代这一块，也闭环在整个产品内部，在不同场景下积累异常的快照标签，能够在平台内部实现哪组算法更适配于哪一个运维场景。

徐新龙

我们在实践AIOps的场景里，不仅有算法，并且用了知识图谱，还能用一些相关性将专家经验带入，这是后处理的一部分逻辑。我们现在做的事情是在数据产生的源头，就将专家经验带入，从而得到运维领域专家经验的加持，使产出的数据相比于一般的metric而言成为相对高价值的数据资产。

在云原生背景下，其实我们的实例数量非常的多，如果需要利用到每一个数据，对于算力来说是很大的开销。所以我们自身实践以及向大家推荐的方式是，在数据产出的过程中把数据提炼成相对高价值的数据资产，让数据携带更多有效的信息，那么就不需要在事后挖掘数据里携带的一些信息商，遵循这个思路迭代我们的AIOps。

Q2随着云原生、微服务技术的普及，给当前IT运维体系转型带来了哪些难度？目前业界的智能运维发展水平及落地效果如何？

徐新龙

我之前从事过应用运维，现在在基础设施团队，也有做k8s相关的智能运维实践，针对云原生和微服务技术的普及给运维转型带来的难度，我总结了“三高”：

一是学习成本高。因为云原生、微服务结合了容器技术，以及k8s的部署调度和编排能力，使目前的软件交付和运行方式发生了巨大的变化。在这个过程中运维人员需要不断学习，而且很多时候这些新技术在学校里是学不到的，而是工作后利用闲暇时间或工作里相关的一些技术培训才能不断提升自己，从而跟上新技术的脚步。客观地说，大部分人随着年龄的增长、角色的增多，可以投入到一件事情上的时间会不断地稀释和减少，学习新技术的成本就变得比较高。

二是迁移成本高。技术的引入往往不是最难的，难的是将存量的业务和应用平稳地迁移到新的架构体系中。

• 底层的基础设施做大量的改造，比如网络、存储、计算、资源调度等；

• 运维平台和工具需要大量的改造，比如PaaS的CI/CD流程需要重新设计，从面向过程式的操作转向面向终态式的交付模式，另外监控也需要调整等等；

• 业务应用整改，包括软件的开发模式、交付方式、运行姿势等。

三是维护成本高。从研发侧看，云原生、微服务技术提升了软件交付的效率；从运维侧，系统架构变得庞大复杂，维护成本极高。例如，以维护K8S为例，企业中一个可以正常运行的K8S集群除了必要的四件套(APIServer、Etcd、ControllerManager、Scheduler)外，还有一堆内部自研的组件和元数据系统，维护成本可想而知。因此，对比K8S的面向终态式的资源交付模式，传统的面向过程式的资源交付更容易排查失败原因和问题。

关于目前业界智能运维(AIOps)的发展水平和落地效果，以我个人的观察和理解，概括总结下来主要有：

首先以点、线、面、体来比喻，目前的发展水平平均应该处于“线”的阶段。

• 点可以理解为某个具体的运维场景，比如某个业务指标的异常检测、故障定位等场景；

• 线是形成了针对一类运维场景的通用AIOps运维平台，比如异常检测平台、故障定位平台等；

• 面是形成了针对某个运维领域(变更、应急等)的全套的AIOps运维能力，比如实现了针对应急场景下的故障预测、异常发现、故障定位、故障自愈等能力的组装，形成了针对应急场景的智能运维流水线定制；

• 体是企业的运维达到了全方位的智能化，在可用性、成本、效率、质量等各个方向都得到赋能。

其次没有形成行业标准，甚至在企业内部也很难形成统一规范。AIOps是高阶的运维实现，本质上还是运维活动，虽然目前行业普遍都有实践，但很少能形成可以直接开箱即用的AIOps产品。即使企业内部，因为和具体业务深度定制绑定，也导致了很多的能力不能直接迁移和复用。因此，AIOps能形成行业标准的前提是运维活动在各个企业内可以高度统一，目前围绕云原生、微服务框架有望形成相对统一的行业标准和规范。

最后产出的智慧有限。当前AIOps还不能实现无人值守的愿景，在具体场景中产出的智慧依然有限，针对算法或AIOps平台的产出信息，依然需要靠人来决策，特别是一些高危的运维操作。之所以还需要人参与，很大原因是可以支撑机器决策的信息和智慧还不够充分，需要借助专家经验来决策。

张静

• 随着云原生、微服务技术的普及，集群规模快速增长，异地多活等高可用架构需求增强，系统间关联越来越多，全面快速分析一个异常的影响和根源越来越困难。

• 京东科技内部的分析工具众多，但无法打通，类似于黑盒的内部服务无法自主掌控，实际效果可能大打折扣。

• 告警总量多，阈值设置困难，误报过多，造成告警疲劳，可能忽略重要警告，造成潜在业务风险。

目前业界的智能运维大家有的是做到了单个场景的落地，有的做到了多场景串联落地及部分场景线上智能化运维。目前业界越来越多的公司投入智能运维相关的产品研发，学术界智能运维相关的创新研究也在普及，国际期刊论文AIOps方向也是踊跃出现，AI算法落地到运维场景不断从时序指标异常检测，到运维日志聚类与分类，再到基于链路和运维知识图谱的根因定位逐步落地，所以将我们的AI算法落到运维场景下可以说是大家都认为比较好的创新领域。

另外在京东科技内部，我们需要去应对目前这种场景下，比如云原生、微服务、容器技术的普及，给传统运维IT体系带来的挑战，找到更合适的场景落地智能运维，进而让AI真正发挥其赋能运维的价值。

Q3

对于处在AIOps建设初期阶段的企业有什么建议？

张静

首先运维数仓的建设非常重要的，也就是数据非常重要，而且要看哪些数据是真正有用的，需要上监控的。如果收集所有数据，那么我们的存储量是巨大的，可能有一些数据在真正运转时量很大，每次访问或查询对应的监控数据也很耗时，会带来一些我们不可避免的问题，所以第一层建设要先把数据治理好。

第二层可以先汇总部门内部比较耗时的故障发生或定位，以及让运维工程师觉得头痛的场景，再盘点前面收集上来的数据，与这些场景进行匹配，将两者结合研发一些算法学件。发现问题传统的不上AI的部分可以先做阈值的监控，看能发出来多少，故障现象真正发生时采集的指标是否能够覆盖。如果不能覆盖说明数据治理上可能还缺乏能够反馈故障快照现象的监控数据，再想办法将其收上来，在数据和场景的基础之上按单场景去做这一层的落地。

刚开始可以不是一个完整的智能运维平台，而是逐步迭代，可以先做运维数仓的建设，不管是实时数仓还是离线数仓，在这个基础之上开发一些AI的运维算法模型，可以是智能运维平台，也可以是公司内部算法工程师用的AI的开发平台，可以先开发出来一套能够发现问题的算法学件。

然后再是整个智能运维产品的设计，如何打通数据和算法，在整个产品上做这一层的迭代，这是下一个阶段的事情。

另外把场景做深，将没有监控数据的场景数据收上来之后，再多做一些场景覆盖度。

徐新龙

企业如果要着手AIOps平台的落地，我从下面几个方向建议：

首先如果决定落地AIOps说明这个场景可能已经探索过了，是有明确的AIOps的需求，而不是为了做AIOps而过度投入。我们一定要在做之前定义清楚：需要AIOps提供什么功能，解决什么问题，最终达成什么运维效果。

二是在落地AlOps的过程中，需要考虑运维场景的数字化能力，因为我们要用AIOps赋能，那么算法的输入一定是数据，而数据是从运维场景的观测性产出的，所以对运维场景观测性的完备性需要能够保证我们开展这项工作。一般的数字化过程会涉及到数据采集存储、数据清洗、数据加工抽取，以及数据展示等一系列数据层面的能力，所以数字化能力很重要。

三是自动化能力，在开展AIOps迭代过程中前期可能不具备自动化能力，但是后期随着产品的迭代，它是一个相互促进的过程。很多公司的产品研发AIOps的开发，一方面需要不断调试和训练，另外它的技术栈很多公司未必支持，比如业务研发用的是Java开发或Go开发，但是因为AIOps涉及到很多算法，所以算法学件是通过Python写出来的。因此一个公司好的自动化能力和比较友好的交付体系对于AIOps的研发是很有帮助的，能够大幅度缩短产品研发的周期。

四是算法能力，可以先上一版算法，自研的或从外面引入一些开源的能力，然后快速运转起来，使效果呈现出来，再决定之后要不要进行，如果达到验收标准，我们就可以进行接下来的迭代。

最后企业开展AIOps的时候会有一些协同工作，涉及到运维、算法、研发，可能很多公司也有产品经理等多个角色，那么如何协同这几方的势力，让产出效用最大？

• 运维专家需要定义清楚引入AIOps的目标：需要AIOps提供什么功能，解决什么问题，最终达成什么运维效果。

• 算法同学根据这个目标进行一些场景数据的抽象，判断这件事情能否通过算法达成。

• 研发同学实现产品设计交互、部署到生产环境等算法同学相对薄弱的能力，在中间起到协调作用。

• 哪些业务场景的运维更适合使用AIOps？

首先我觉得要定性AIOps，就是在我们目前的沟通里，AIOps其实是一个能力集合，所以要清楚我们需要AIOps的什么能力，另外也要定义我们什么业务场景可以用到这些能力，这个定义很多时候出于专家经验，也就是它给工程师和业务人员带来了一些复杂度，而且通过人力已经很难实现了，这时候我们就需要借助人工智能的手段。需要注意的是，很多时候我们的复杂度可能只是一个简单的自动化功能，那么就不需要用到人工智能。

• 达到怎样的业务复杂度，使用AIOps的效果会更好？

首先简单的用自动化就可以实现，如果自动化不能实现，涉及到一些数据分析，需要数据分析产出的信息或智慧辅助我们做决策时，我们就可以运用AI的能力。其次遇到的场景最好是高频次的，如果是一次性的工作我也不建议直接上AIOps，因为这是一个投入比较多的工作。

Q4

AIOps实践过程中离不开“AI”，如何促进传统运维工程师向运维AI工程师转型？如何组建并规划智能运维AIOps团队？

张静

建议大家先组建一个智能运维研发小组，里面的研发角色包括多个资深运维专家（至少一个）、大数据开发工程师、前后端开发工程师、算法工程师。这些是组建智能运维AIOps团队必不可少的角色，整个团队的职责是把智能算法能力落地线上横向业务场景，算法在监控、数据库、网络、资源调度等多个纵向场景取得突破。

• 资深运维专家：团队核心，是运维专家推着我们一步步去实现功能的迭代，才能够让AI技术真正落到运维场景里，最终解决线上业务故障的发现与定位等。

• 大数据开发工程师：建设数据治理。

• 前后端开发工程师：建设一个AI平台，把一些工作实现平台化。

• 算法工程师：在现有的监控平台上把监控做得更好更优。

收集运维工程师平时工作中的需求痛点，包括在日常和大促场景下的一些故障场景。

让运维算法专家定期给传统运维工程师培训，包括解决业务场景复杂多变的异常检测手段、解决故障定位耗时繁琐的AI技术。以学习讨论会或公司内部培训演讲的形式给运维工程师做培训，或者坐在他工位旁边与他聊天，可以碰撞出很多火花，找到更贴合落地的场景。

• 如何解决运维专家和算法人员脱离的问题？

刚开始做AIOps的时候，因为我是做算法研发的，所以我最初跟运维同学沟通是给他讲数学，他很难听懂，同时如果让运维工程师回答算法同学的问题，让他转成算法的描述也是比较困难的。需要转变的是我们算法同学在给运维同学普及算法知识的时候，可以换一种方式，讲得更运维一些，彼此需要经常沟通和打磨。

徐新龙

这个问题我觉得很难给出普适的建议，个人观点是传统运维工程师不一定都要转型运维AI工程师，垂直领域的资深运维专家也是非常有价值的。不论工种如何，能在不同的岗位上产出有效价值就是合理的。如果是团队的发展遇到了瓶颈不能持续产出有效价值，环境会倒逼着团队重新考虑方向和转型，结合实际、按需拥抱变化。

关于规划智能运维AIOps团队，我的理解和建议还是结合实际、按需规划，AIOps不一定是真实的，可以是一个虚拟团队，按需、按场景灵活组装。理想的智能运维团队构成中，有一部分人是懂算法，专注数据分析；有一部分人专攻系统和业务运维；还有一部分人擅长软件设计和产品开发。

另外，运维工作可能涉及到一些算法资源方面，可以让算法同学和运维同学坐在一起，让他们感受到彼此的痛点，能够将这件事情做得更有效果。主要因为双方的背景不同，但AIOps本身是一个交叉领域，所以拉齐双方的认知很重要，这是达成这件事情的一个重要条件。

Q5

AIOps在贵司的建设思路是怎样的？以及在团队内部推进建设的实践路径是怎样的？

徐新龙

以SLO在蚂蚁技术设施实践为例，展开介绍我们团队在推进AIOps实践落地的路径。蚂蚁的基础设施侧存在众多的异构系统，被上层的业务应用和服务所依赖，考虑到不同系统的技术栈、架构、部署等因素，我们希望找到一种通用的、泛化性强的数字化方案指导和构建基础设施域内的健康度体系。基于这样的客观现状，我们开展了蚂蚁基础设施域内从0到1的SLO健康度体系建设和实践，也开展了围绕SLO的一些运维能力的建设，即AIOps能力的展开，主要的发展路径包括：

数据面建设：通过Prometheus + GitOps + ArgoCD + Grafana等产品的组合完成对应用和服务相关的Metric自动化采集、存储、加工、透视、抽取、展示等数字化能力。通过建设SLO，从源头对数据进行精加工，产出高价值数据资产。

生态能力建设：围绕SLO及服务Metric等数据，开展的关于故障应急等相关的AIOps能力建设，其中包括基于SLO数据的预警、故障定位、预案推荐等。

运营：SLO运营数据通晒、SLO周报月报、不达标SLO透视分析等，通过运营数据支撑运维决策和驱动运维演进。

产品化：把散装的能力借助SLO健康度体系组成统一的产品形态，提供用户统一的使用体验。

商业化：通过行业调研分析，国内市场在这块的商业化还是比较欠缺的，这也是我们目前重点投入在做的工作。一种是透出商业化的解决方案；一种是未来提供SaaS服务。

张静

京东科技内部有标准化的运维数据资产平台，所以智能运维平台要做的事情的第一步就是根据我们京东多年的一线运维经验总结出一些痛点和场景，通过场景化打通智能运维平台与数据资产，把数据接入到智能运维平台里。

第二步是选择比较好落地而且能够解决一些运维问题的单场景实现AI技术的落地，利用京东内部历年大促的数据验证它的效果，包括网络层、数据库层的监控数据验证当前的准确度，判断这一套功能是否可以投入使用到生产中。

第三步是多个场景下串联的打通，也就是生成我们一体化的智能运维产品。产品商开始设计产品之后，再在每一块功能往上追加，比如可以解决运维故障发现的能力。在京东科技内部，最开始我们也是像业界一样先做时序指标的异常检测问题，后来做单序列的异常检测，包括单系列基线的趋势预测，动态预知学习的算法学件的建设，以及如何快速地把运维的资产数据接入到我们的智能运维平台里面。

有了整体智能运维产品的设计之后，把我们能够进行落地的算法学件赋能我们内部的多个产品，同时明确整个产品的定位，比如Themis智能运维平台更偏向于业务的智能监控，也会覆盖根因定位，网络层、资源调度和数据库的一些监控。我们不仅打造了一款智能运维平台产品，也会将这几年的算法沉淀赋能我们内部的一些基础监控产品，未来也会将大部分精力放在外部的商业化上。

在运营这一方面，我们也自研了一些算法组件去做整体的成本分析。业界的AIOps专家在制定智能运维的白皮书或标准书的时候可能会分为三大模块，做得最多的是异常的快速发现和故障定位、整体的容量管理包括成本管理两大模块，我们的Themis智能运维平台这两部分都有设计。

Q6

如何解读：AIOps只是数智时代“人机协同”的运维模式，AIOps能否完全替代传统人工运维模式？

张静

AIOps主要是辅助运维同学从被动运维到主动运维的转变，同时帮助运维工程师提前发现问题和定位问题，并不能完全替代传统人工运维模式。运维工程师是我们的核心业务方，他们告诉我们场景如何发力，AIOps只能是将我们的运维工作做得更好，也就是赋能传统运维。

徐新龙

因为时代背景的局限性，我觉得在目前的阶段将AIOps解读为“人机协同”的运维模式是合理的。结合行业现状，运维的主体还是人，我们通过人工智能产出的智慧目前主要还是起辅助作用，以此来支撑运维决策和驱动架构演进。目前的人工智能还没有自主意识，比如根据复杂环境自主决策等，因此我们目前还只能工作在“人机协同”的模式下。

关于AIOps能否完全替代传统运维模式的判断，我个人认为很难，至少未来10年都不能做到完全替换。有很多客观的原因：

• 运维涉及的领域广、常态化工作很杂乱；

• 数字化无法覆盖百分百；

• 很多场景使用AIOps投入产出比不高。

Q7

对智能运维当下的状况及智能运维发展有哪些预测？未来会形成怎样的局面？

张静

当前做智能运维的团队越来越多，智能运维的产品、学术成果也频繁涌现，大家对智能运维的建设意识认可度也在逐渐提高，智能运维未来的发展范围会更广，可能部分场景能够完全实现智能运维，同时智能运维与自动化运维全面打通，运维工程师能够主动发现问题、定位问题并解决问题，通过AI的能力，运维专家也可以成为运维算法的掌舵人。

徐新龙

智能运维当下的发展我认为还是以充分挖掘运维场景，精细化、场景化为主要发展路径。在谈智能运维的发展时，我们必须要参考下整体运维架构的演进路径，这样才能更好的把握智能运维的大方向。所以我们分成两个方向，或许10年内就会达成：

首先是运维的发展：

• 未来，对于大部分企业（特别是传统非互联网企业）来说，可能会没有运维工程师，例如没有IaaS、PaaS层的基础设施类SRE，这时候业务全部上云，企业不需要关心底层的运维和人员投入，这些工作会全部由云服务商来承担；

• 届时很多企业选择业务上云，所以像稳定性、容量、效率、安全等运维问题都会由云厂商来提供和保障，企业只需要支付相应的服务费用，相比于企业自建运维体系，业务上云会节省更多的成本；

• 像云厂商等大型的互联网企业，随着越来越多的传统企业选择上云，将会面临更大、场景更丰富的运维挑战。

其次是智能运维的发展：

• 智能运维围绕云原生和微服务体系逐渐形成行业规范和标准，AIOps的实践场景更加具备行业借鉴意义；

• 在类似云厂商这样的大型互联网企业，实践AIOps的投入产出比会不断提高；

• 智能运维和大部分运维场景进一步深度结合，产出可以自主决策的智慧，在部分场景下真正实现无人干预。

特别鸣谢

点这里可回看本期直播