摘要：本文结合裴丹教授过去二十余年在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的发展趋势，张钹院士最新发表的一篇文章中提到：AI 1.0是“知识驱动+算法+算力”，这是深蓝计算机打败国际象棋冠军卡斯帕罗夫的那个年代的技术；到后来AI 2.0“数据驱动+算法+算力“，代表性技术是基于深度学习的计算机视觉；AI 3.0是“知识+数据+算法+算力”，融合知识和数据，是未来AI应用的大势所趋。
如前所述，AIOps需要分析关联海量多源多模态运维大数据，因此基于强运维领域知识的AI 3.0 技术也是AIOps发展的必然技术路线。
AI是任何模拟人类行为的计算机技术，AIOps是任何模拟运维人员行为的计算机技术。它基于专家知识、经验、自动化、机器学习、深度学习或它们的某种组合。不要因为用到了自动化或硬逻辑，就判定其不是AI 或AIOps。我们要做的是践行“知识+数据+算法+算力”的AI 3.0概念，这也是AI应用的大势所趋。
c 触类旁通
从科学技术的应用角度来说，AIOps也是大势所趋。我在从美国海归加入清华之前，曾短暂做过一段智能医疗，AIOps的相关思考可以从医学领域寻找灵感和启发，也就是“触类旁通”。我的博士导师，加州大学洛杉矶分校张丽霞教授也曾多次公开建议从生物学中寻找互联网架构设计的灵感。在运维领域遇到的很多问题，在其它科学领域都可能遇到过，而“它山之石可以攻玉”。
我们可以把负责排障的数据中心组织及员工类比为医院及员工，故障类比为疾病，数据中心软硬件系统类比为病人，异常和告警类比为症状，异常检测算法类比为检验、检测设备，运维科室专家类比为医院科室医生，各科室运维专家知识类比为各科室医学专家知识。简单疾病（故障）单独科室即可处理，而复杂病症（故障）需要关联各种数据，并且跨科室专家会诊。
通过类比可以看出，其实现代医学领域一直在践行AI 3.0里的“知识驱动+数据驱动”。各种新的检验检测技术层出不穷，医学诊断知识也在不断地提升，两者的结合促进了医学领域的高速发展。
价值路线：统筹规划、要事优先、点面结合
智能运维已经如火如荼发展了一段时间，很多企业都在做AIOps的筹划，但是先做什么后做什么？Big Picture是什么？ 如何做多年规划的同时又逐年有实质落地效果？从AIOps交付的价值角度，谈一下规划的三个原则。
a 统筹规划
AIOps在运维的五个基本要素（即质量、性能、效率、成本、安全）中都有很好的应用前景。统筹规划的优先级方面，效率（Develop）相对独立，安全也相对独立，接下来要先关注质量（即系统可用性），其次是性能，在此基础上再进行优化成本。我们主要聚焦在运维质量上进行讨论，而在性能和成本上的落地原则大同小异。
再次类比医学领域著名的扁鹊三兄弟。对于常出故障的系统，最需要的是扁鹊——治大病，其次需要扁鹊二哥——治小病，最后需要扁鹊大哥——治未病。即，首先要降低故障修复时间，这是规划里最重要、最痛的点；其次，延长无故障时间，识别并消除小隐患；最后，要通过故障演练，提前发现和解决问题，不影响真正的用户。
规划中最迫切的“运维质量：降低故障修复时间”有很多细分步骤，实际落地起来挑战重重。多源多模态且信噪比低的运维数据，关联所需要用到的依赖数据非常复杂且不易获得，有时数据质量也不高。很显然我们无法一蹴而就，必须要统筹规划，分步骤、分阶段地实施，不断取得阶段性的成果。
b 要事优先
在上述体系中，决定先做的原则是要事优先，即聚焦并串连最终导致业务故障的常见异常。大部分业务故障遵循“二八定律”，20%的组件故障类型导致了80%的业务故障。因此，我们应首先聚焦解决这些常见故障，要有全局视野，先抓重点细节，聚焦并串起导致那些业务故障的常见组件故障，这就是规划AIOps时从价值角度出发的“要事优先”原则。
c点面结合
规划落地AIOps时，往往有两种误区：一是只看有可量化价值的具体的技术“点”（如业务指标异常检测）；二是只看有可量化的端对端价值的场景（“面”，如MTTR），而我们总结的原则是“点面结合”。也许因为依赖其它技术点， 业务指标异常检测还没有产生端对端的效果（降低MTTR），但是其本身有一些评估指标（相比传统方法提前X分钟发现故障），这可以给予我们很大的希望。就像医院里的医疗设备，比原来的设备检测得更准、更快，价值就应该得到认可，而不能因为需要一些其它技术点才能产生完整的端对端价值而被否认。反之，对于端对端价值的不懈追求并且以量化方式不断衡量（如MTTR）,能清晰指引我们规划需要不断突破的技术点。因此，规划时，点和面都重要，点面要结合，都要体现可量化的价值。
架构路线：数（据）知（识）驱动、算（法）（代）码联动、人机协同
a 数（据）知（识）驱动
此原则在应急排障中的具体体现在两方面：基于全量数据做异常发现；基于知识对零散的异常信号做关联，从而获得“上帝视角”。
运维排障中的每个节点都是系统运转过程中的一种可能异常（对应的是一个数据源和异常检测算法）。这些异常在系统里的传播关系就是图中的“边”，最终形成这样的一幅运维排障的知识图谱。其核心思路是：① 基于所有可用监控数据的异常检测（寻找所有可能异常）；② 基于异常传播的故障定位（将所有相关异常中按照根因可能性排序）。知识图谱将各种异常算法连在一起，所有的运维排障工作通过知识图谱实现了。
“数据知识双轮驱动”框架在发展历史中，攻克了领域迁移、算法升级、挖掘替代人工配置等挑战，目前已具备在IT运维领域推广的条件。
b算（法）（代）码联动
如原则1.b所述，AI应用不仅包含算法，还包含一些（流程、规则）自动化代码。对一个纷繁复杂的运维场景，通过庖丁解牛的方式进行拆解，分别交给算法、自动化代码去做。
实践过程中发现，AIOps与一些常见的人工智能领域（如计算机视觉）有显著的不同，即运维数据无法采用众包的方式由普通人来标注，必须依赖运维专家，但运维专家可能没时间或者不愿意标注。因此，要尽量采用无监督方法，评估时的少量标签要靠平时多积累案例及相关数据。
c人机协同
“无监督算法+主动学习”是一种有前景的方式，属于“人机协同”。Infocom 2020有一个安全相关的工作，就是human in the loop--- 无监督异常检测+人工在线反馈，能够检测零日攻击。发生零日攻击时，其攻击指纹尚未发现或部署在防火墙中，因此用传统基于指纹的检测方法通常会漏掉零日攻击。无监督方法能够检测出来零日攻击的反常流量，不过不能保证清晰地区分所有攻击和所有新上线的应用的模式，所以我们用线上人工反馈的方式进行反馈。
这里要注意的是，这些反馈是该在线系统运行的有机组成，用户在使用工具时的常规步骤（而不是标注离线数据），其使用过程本身就给系统提供了反馈。其他工作中，“人机协同”作为AIOps架构的一部分也行之有效。
总体而言，从架构角度来说，一个AIOps系统是以运维监控数据和运维领域知识为输入，算法和代码联动、人机协同的分布式系统；每个组件都有其提供的服务（确定性的、模糊性的），而整体上是模拟运维人员的行为。
标准引领、治（理）（应）用并进、生态合作
a 标准引领
建立标准是生态各方建立共同语言、步调一致的最可行手段，也是一个生态系统健康、繁荣、可持续发展的前提。前述提及的AIOps系统架构可以作为标准化的一个依据，定义标准化组件。具体思路为：清晰定义组件接口（输入、输出）、清晰定义组件能力指标。
AIOps在快速发展，标准编制无法一蹴而就，必须持续迭代，不断引领生态方达成共识，在产品上实现互通互联。
b 治（理）（应）用并进
数据治理和AIOps应用孰先孰后，一直存在争议。有一种观点认为“要先做好数据治理，才可能做AIOps落地”。听起来很有道理，但是“脱离实际业务场景来做数据治理和脱离了应用架构来做数据治理，完全是镜花水月”。通过不断尝试落地AIOps场景，发现数据不足，补充完善运维数据的治理。
所以，数据治理与AIOps应用是齐头并进、互相依赖、互相促进。一些具体场景，如有已经有标准化的数据质量标准（如指标的采集间隔和连续性），可以先尝试实施相应治理再落地算法。对于需要针对性治理的数据（如CMDB），则要治理与应用齐头并进。
c 生态合作
生态各方在同一套智能运维标准引领下构建的平台上，进行知识沉淀、算法代码沉淀、数据治理标准沉淀、服务化组件沉淀，以及AIOps相关自动化工具的沉淀，在遵循生态共同制定的标准的前提下，实现高效互通互联，指数级加速AIOps落地，共建AIOps良好生态。