ai软件技巧本文：顺势而为、知己（Ops）知彼(AI)、触类旁通第一个原则

摘要：本文结合裴丹教授过去二十余年在AIOps领域与几十家企业合作、跨多种科技栈的落地经验累积，以及150篇左右学术论文的算法积累，总结出的AIOps落地的一些经验性方法。

本文分享自华为云社区《AIOps智能运维经验分享-云社区-华为云》，作者：SRE确定性运维。

本文结合裴丹教授过去二十余年在AIOps领域与几十家企业合作、跨多种科技栈的落地经验累积，以及150篇左右学术论文的算法积累，总结出的AIOps落地的一些心得性方法。这些经验分成4大类，分别涵盖AIOps落地的大趋势、价值路线、架构路线、生态路线。

大势所趋：顺势而为、知己（Ops）知彼(AI)、触类旁通

第一个方法主要讲AIOps是大势所趋，无论是从运维角度，还是从人工智能科技的应用视角和科学科技的应用视角来说都是这种。

a顺势而为

运维技术在各行各业的重要性愈发越高，像银行、证券、保险、电信、能源、工业生产、政府部门、互联网等，由于各行各业数字化程度越来越高、系统规模愈发越大、组件监控粒度越来越细、监控数据量越来越大并且新科技和新模块的不断推行，这些造成运维越来越难做，运维工程师也被海量高速的运维监控数据所淹没。

一方面，运维监控数据是海量的、高速的、多模态的、价值极大的、但又信噪比极低的（即：对运维人员来说直接价值最高的异常数据在人数上远远大于正常数据）。目前看，人工智能算法是处理符合上述特征的数据的最有期望的方式。

另一方面，只有在这种数据被关联起来一起预测时才会发挥出他们最大的价值，而关联必须各类复杂的依赖关系知识（逻辑部件之间的调用关系图、逻辑部件在物理模块上推进关系图、物理模块的网络模式关系图）和专家知识（模块内运维故障间的因果关系图），才能有物理含义地把各种运维信号关联起来进行有效预测。目前看，知识图谱技术是制备和应用这种用图表示的知识的最有期望的方式。

由此可见，用AI方法解决运维挑战，势在必行。

其实，不同客户、不同企业的科技风险偏好程度不一样，因此落地AIOps的节奏会有所不同。以上阐述表明了AIOps是运维领域发展的大势所趋，没有其它选择，只能顺势而为。AIOps是运维这一领域必需要做的事情。

b知己（Ops）知彼(AI)

在AIOps落地过程中，相关人员针对AIOps的定义、AIOps的本质、AIOps的素养边界存在一些探讨并且争论。于某些讨论中寻找答案，首先必须确立认知方式论：知己（Ops）知彼(AI)。

知己，是指我们要充分了解到运维（Ops）领域是一个强领域知识的计算机应用领域，要想尽方法将运维领域知识有机结合进来；知彼，是指我们要充分了解AI作为一种计算机科技类别的演变趋势，并尊重其在必定时间窗口内的能力边界。

不同运维场景必须利用不同技术和算是一个相对普世的认知，目前为止，整个人工智能领域都是在特别准确的市场和比较详细的画面中获得的顺利。同理，这是由于市场不同、场景不同，所必须的算法和科技就有所不同。

如果把AI比作一种高级编程语言，AI应用无非就是在一个工具架构上面提供了一部份部件，其个别程序逻辑总结自数据，是概率性的、模糊性的。而任何应用，其逻辑都是领域知识强相关的。就像我们不可能假定学会了Java语言能够自动缓解一切应用问题一样，我们必定要对于确切行业、具体场景才可能做好一个AI应用。

然而，“知己”是指要清醒认识到一切运维工具几乎都是基于强运维领域知识的，AIOps也不例外，一定要想尽方法把运维领域知识有机结合进来。

知彼，是指要充分了解AI作为一种计算机科技类别的演变趋势，并尊重其在必定时间窗口内的素养边界。引用交大大学计算机系张钹院士的看法：AI并非无所不能，当前AI做得好的事必须同时满足五个条件。

（1）有充足的数据或知识

（2）完全信息

（3）有确立的定义（well-defined）

（4）可分析性，按确定性的规律演化

（5）单领域（如语音辨识、图像识别、围棋等）

——中国科学院院长张钹

关于AI的演进趋势，张钹院士最新发表的一篇文章中提及：AI1.0是“知识驱动+算法+算力”，这是深蓝计算机打败国际象棋冠军卡斯帕罗夫的哪个年代的科技；到当时AI2.0“数据驱动+算法+算力“，代表性科技是基于深度学习的计算机视觉；AI3.0是“知识+数据+算法+算力”，融合知识和数据，是将来AI应用的大势所趋。

如前所述，AIOps需要预测关联海量多源多模态运维大数据，因此基于强运维领域知识的AI3.0技术也有AIOps发展的必定技术路线。

AI是任何模拟人类行为的计算机科技，AIOps是任何模拟运维人员行为的计算机科技。它基于专家知识、经验、自动化、机器学习、深度学习或两者的某些组合。不要由于用到了手动化或硬逻辑，就认定其不是AI或AIOps。我们要做的是倡导“知识+数据+算法+算力”的AI3.0概念，这只是AI应用的大势所趋。

c触类旁通

从科学科技的应用视角来说，AIOps也是大势所趋。我在从中国海归加入北大之前，曾短暂做过一段智能医疗，AIOps的相关探讨可以从医学领域追寻灵感和启发，也就是“触类旁通”。我的硕士导师，加州高中洛杉矶学院张丽霞教授也曾多次公开建议从生物学中寻求互联网架构设计的灵感。在运维领域见到的好多问题，在其他科学领域都可能遭遇过，而“它山之石可以攻玉”。

我们可以把负责排障的数据中心组织及人员类比为医院及职员，故障类比为疾病，数据中心软软件平台类比为病人，异常和故障类比为病因ai软件技巧，异常检测算法类比为检验、检测仪器，运维科室专家类比为学校科室医生，各科室运维专家知识类比为各科室医学教授知识。简单疾病（故障）单独科室即可处理，而复杂疾病（故障）必须关联各种数据，并且跨科室专家会诊。

通过类比可以看出，其实现代医学领域仍然在倡导AI3.0里的“知识驱动+数据驱动”。各种新的检验测试科技层出不穷，医学治疗知识也在不断地提高，两者的结合促使了医学领域的高速发展。

价值路线：统筹规划、要事优先、点面结合

智能运维已经如火如荼发展了一段时间，很多企业都在做AIOps的筹划，但是先做哪些后做什么？BigPicture是哪个？怎么做多年规划的同时又逐年有实质落地效果？从AIOps交付的价值视角，谈一下规划的三个方法。

a统筹规划

AIOps在运维的五个基本要素（即品质、性能、效率、成本、安全）中都有很高的应用前景。统筹规划的优先级方面，效率（Develop）相对独立，安全也相对独立，接下去要先关注质量（即平台可用性），其次是性能，在此基础上再进行改进成本。我们主要聚焦在运维质量上进行探讨，而在性能和成本上的落地原则大同小异。

再次类比医学领域著名的扁鹊三兄弟。对于常出故障的平台，最应该的是扁鹊——治大病，其次应该扁鹊二哥——治小病，最后还要扁鹊大哥——治未病。即，首先要增加故障恢复时间，这是规划里最重要、最痛的点；再者，延长无故障时间，识别并防止小隐患；最终，要借助故障演练，提前看到和缓解问题，不妨碍真正的用户。

规划中最迫切的“运维质量：降低故障恢复时间”有众多细分方法，实际落地起来挑战重重。多源多模态且信噪比低的运维数据，关联所必须用到的依赖数据比较复杂且不易取得，有时数据品质也不高。很肯定我们能够一蹴而就，必需要统筹规划，分方法、分阶段地实行，不断获得阶段性的成果。

b要事优先

在上述机制中，决定先做的方法是要事优先，即聚焦并串连最后造成业务故障的常见异常。大个别业务故障遵循“二八定律”，20%的部件故障类型造成了80%的业务故障。因此，我们应首先聚焦解决这种常用故障，要有全局视野，先抓重点细节，聚焦并串起造成这些业务故障的常见组件故障，这就是规划AIOps时从价值视角出发的“要事优先”原则。

c点面结合

规划落地AIOps时，往往有两种误区：一是只看有可量化价值的详细的科技“点”（如业务指标异常检测）；二是只看有可量化的端对端价值的画面（“面”，如MTTR），而我们总结的方法是“点面结合”。也许由于依赖其他技术点，业务指标异常检测还没有造成端对端的效果（增加MTTR），但是其原本有一些评估指标（相比传统方式提前X分钟发现故障），这可以给与我们多大的期望。就像学校里的医疗设施，比以前的设备检测得更准、更快，价值就必须受到认同，而不能由于必须一些其他技术点能够形成完整的端对端价值而被证实。反之，对于端对端价值的执着追求以及以量化方法不断考量（如MTTR）,能清晰指引我们规划必须不断突破的科技点。因此，规划时，点和面都重要，点面要结合，都要表现可量化的价值。

架构路线：数（据）知（识）驱动、算（法）（代）码联动、人机协同a数（据）知（识）驱动

此方法在应急排障中的详细阐述在两方面：基于全量数据做异常发现；基于常识对零散的异常信号做关联，从而获取“上帝视角”。

运维排障中的每个节点都是平台运转过程中的一种可能异常（对应的是一个数据源和异常检测算法）。这些异常在平台里的传播关系就是图中的“边”，最终产生这种的一幅运维排障的常识图谱。其核心模式是：①基于所有可用监控数据的异常检测（寻求所有可能异常）；②基于异常传播的故障定位（将所有相关异常中根据根因可能性顺序）。知识图谱将各类异常算法连在一起，所有的运维排障工作通过知识图谱实现了。

“数据知识双轮驱动”框架在演进历史中，攻克了领域迁移、算法更新、挖掘替代人工配置等挑战，目前已具有在IT运维领域推广的条件。

b算（法）（代）码联动

如原则1.b所述，AI应用虽然包括算法，还涵盖一些（步骤、规则）手动化代码。对一个庞杂复杂的运维场景，通过庖丁解牛的方法进行拆解，分别交给算法、自动化代码去做。

实践过程中看到，AIOps与一些常用的人工智能领域（如计算机视觉）有明显的不同，即运维数据能够运用众包的方法由普通人来标注，必须依赖运维专家，但运维专家可能没时间以及不愿意标注。因此，要尽量选用无监督方式，评估时的少量标签要靠经常多累积案例及相关数据。

c人机协同

“无监督算法+主动学习”是一种有前景的方法，属于“人机协同”。Infocom2020有一个安全相关的工作，就是humanintheloop---无监督异常检测+人工在线反馈，能够监测零日攻击。发生零日攻击时，其攻击指纹尚未看到或推进在防火墙中，因此用传统基于指纹的测量方式一般会忽略零日攻击。无监督方式才能评估出来零日攻击的反常流量，不过不能确保清晰地区分所有攻击和所有新上线的应用的方式，所以我们用线上人工反馈的方法进行反馈。

此处要留意的是，这些反馈是该在线平台运行的有机构成，用户在使用软件时的常规方法（而不是标注离线数据），其使用过程原本就给平台提供了反馈。其他工作中，“人机协同”作为AIOps架构的一个别也行之有效。

总体而言ai软件技巧，从架构角度来说，一个AIOps系统是以运维监控数据和运维领域知识为输入，算法和代码联动、人机协同的分布式平台；每个模块都有其提供的服务（确认性的、模糊性的），而整体上是模拟运维人员的行为。

标准引领、治（理）（应）用并进、生态合作a标准推动

制定标准是生态各方成立共同语言、步调一致的最可行方法，也是一个生态平台健康、繁荣、可大幅发展的前提。前述提到的AIOps系统构架可以成为标准化的一个根据，定义标准化模块。具体策略为：清晰定义模块接口（输入、输出）、清晰定义模块能力指标。

AIOps在迅速发展，标准编制无法一蹴而就，必须大幅迭代，不断推动生态方签署共识，在产品上推动互通互联。

b治（理）（应）用并进

数据治理和AIOps应用孰先孰后，一直存在争议。有一种看法认为“要先做好数据治理，才可能做AIOps落地”。听上去很有道理，但是“脱离实际业务场景来做数据治理和摆脱了应用架构来做数据治理，完全是镜花水月”。通过不断尝试落地AIOps场景，发现数据不足，补充规范运维数据的管控。

然而，数据治理与AIOps应用是齐头并进、互相依赖、互相推动。一些详细画面，如有尚未有标准化的数据品质标准（如指标的采集间隔和连续性），可以先尝试推行相应治理再落地算法。对于应该针对性治理的数据（如CMDB），则要治理与应用齐头并进。

c生态合作

生态各方在同一套智能运维标准推动下建立的系统上，进行知识沉淀、算法代码沉淀、数据治理标准沉淀、服务化模块沉淀，以及AIOps相关自动化工具的沉淀，在遵守生态共同建立的标准的前提下，实现高效互通互联，指数级提速AIOps落地，共建AIOps良好生态。

点击下方，第一时间认识华为云新鲜技术~

华为云博客_大数据博客_AI博客_云计算博客_开发者中心-华为云