清华裴丹：AIOps效果落地最后一公里
9月18日，第五届双态IT乌镇用户大会“智能运维算法研讨会”顺利举行，必示科技携手国泰君安共同举办。本文由清华大学计算机系长聘副教授裴丹在会上的主题演讲及后续演讲整理而成。
今天，我的报告主题是《从AIOps算法到量化价值实践》，分为两部分，首先简要回顾一下AIOps落地的15条原则，然后讲述智能运维落地遇到的关键性阻碍以及解决方法论。
01 AIOps落地的15条原则（节选）
结合我在智能运维领域20余年经验，与几十家企业合作、多种技术栈以及近200余篇前沿论文成果，我总结了AIOps落地原则。下面快速分享一下，更多细节请见【智能运维前沿】公众号文章：《清华裴丹: AIOps落地的15条原则》
IT运维技术在各行各业的重要性越来越高，像银行、证券、保险、电信、能源等行业，数字化程度越来越高、系统规模越来越大、组件监控粒度越来越细、监控数据量越来越大以及新技术和新组件不断引入，这些导致运维工程师被海量运维监控数据淹没。
智能运维是大势所趋，Ops须顺势而为。因为我们面临的是海量的、高速的、多源多模态的、高价值但信噪比低的数据，除了采用人工智能技术从运维大数据中提取有价值信号，我们别无选择。此外，我们还需要采用知识图谱技术表征并应用各类复杂的依赖关系知识（逻辑组件之间的调用关系图、逻辑组件在物理组件上部署关系图、物理组件的网络路径关系图）和专家知识（组件内运维故障间的因果关系图）关联起来融合进系统，对海量监控数据进行有效分析。
人工智能经过多年发展，从“知识驱动+算法+算力”AI 1.0时代，到“数据驱动+算法+算力”AI 2.0时代，已经迈向“知识+数据+算法+算力”3.0时代。智能运维亦是如此，智能运维可以定义为“任何模拟运维人员行为的计算机技术，可以基于专家知识、经验、自动化、机器学习、深度学习，或它们的某种组合。”不是说智能运维只能有算法；专家知识和经验也是整个系统必须的一部分。
AIOps与一些常见的人工智能领域（如计算机视觉）有非常显著的不同：运维数据无法采用众包方式交给一个普通人来进行标注，而必须依赖运维专家，但是运维专家可能没有时间或者不愿意标注。因此我们在算法选择时优先采用无监督算法，其次是无监督算法+主动学习、弱监督算法、有监督算法+迁移学习，最后不得已的情况下再选择有监督学习。
精准建模强调对运维问题的解法不要局限于之前的文献和算法，一定要抓住运维问题的本质。比如根因定位要解决的是找根因问题，如果用分类算法会非常难，反之像搜索引擎推荐算法一样推荐前5名的根因，对运维人员有很大的帮助。所以，对问题建模一定要回归运维本质，才能更好地提供落地价值。
这里想强调一下，对于一些具体的智能运维算法普适性不够的情况，我们是死磕把它改变成普适性特别强的算法？还是对它不擅长的场景用另外更加匹配的算法，从而把它们融合起来？集成学习方法可以认为是把多个解决类似问题但针对不同细分场景的算法并联起来。比如指标异常检测有各种不同的算法，我们只需要对这些指标进行特征描述后分类，分完类匹配到合适的算法就行了。如下图所示。
我们再看下如何用串联方法更好地解决问题，我们在根因定位排障的时候，从上往下找症状的根本原因时，每一步都会对系统做进一步的检查和诊断，类似医生做疾病诊断一样，结合目前的检测数据再做额外的CT、核磁等检测，最后找到原因。这种方式基于知识，通过串联的方式把各种算法、技术整合到一起，达到单种技术无法达成的效果。
综上所述， **AIOps系统是一个以运维监控数据和运维领域知识为输入的、算法和规则联动的、各类组件并联串联的、人机协同的大型分布式软件系统。**运维问题和智能运维系统非常复杂，虽然行业内一致看好AIOps发展方向，但在实践中出效果却会遇到各种阻碍。这就要求我们从算法细节里面跳出来，回归运维本质。
02 从AIOps算法到量化价值实践
当前阶段，智能运维的关键词是运维（Ops）。也就是说，智能运维产生的价值是要对运维有价值。运维难题一直没解决好而且变得更加复杂，只有通过AI技术才有可能解决好、解决掉。所以，我们一定要回归运维本质，用AIOps解决运维价值。正如《算法之美》书中提到的，“最重要的永远不是解法，而是决定解决什么问题。最优算法总能找到，前提是确定度量标准。”
智能运维不是概念， 用AI解决问题。首先应该明确解决运维的什么问题，然后价值怎么体现。度量标准是通过不断实验看现在的方法效果如何，可能涉及到数据治理、查找新的数据集、调优算法等。这里引用倪明选老师在谈及大数据AI实际落地时的表述，实践要想出效果可能遇到阻碍，需要多方协作，包括领域专家、数据科学家、工程师等。首先领域专家要给出大致目标，多方讨论；之后数据科学家精确定义目标与工程师沟通，工程师搭建系统或实现分析方法，实现完了进行效果评估。领域专家给出评估和业务应用效果，如果未达到预期，发现新需求进行不断迭代，直到满意了再评估是否解决问题，反反复复小循环大循环，多方协作不断迭代。任何涉及到数据和算法的系统进行应用时，都需要走这种必由之路。
那么，AIOps落地状况如何？根据Gartner报告可以看到，**AIOps已在大企业实际部署，价值大，出效果挑战也大。**下图中，底层圆环从外到内分别表示技术在观望、规划、试点、应用。每个圆圈代表不同的技术，每个圆圈的大小代表该技术对企业的价值。结合Gartner对用户单位的采访，AIOps价值非常大，但是在部署时并非一帆风顺，实际出效果挑战非常大，所以颜色是红色的。
回到刚才的问题，为什么AIOps价值大并且已经做了实际部署，现在出效果还是有风险和不确定性？智能运维的价值到底在哪？实施出效果最大障碍是什么？后续我们应该怎么开展智能运维建设？
结合下面Gartner的两幅图，对比全球和国内AIOps技术成熟度曲线可以看出，**国内智能运维技术成熟度相较于全球处于靠前位置，**会更快地到达成熟和实质生产阶段；从整体趋势来看，中国AIOps平台可能会在2到5年内达到最终成熟的实质生产阶段。中国智能运维领域的探索领先于世界，因为中国金融行业遥遥领先于世界的金融行业，它的数字化程度很高、创新速度非常快，也愿意尝试新技术来解决实际痛点。
在智能运维发展过程中，大家在AIOps刚开始出现时会高估1-2年带来的变化，到了一定程度之后会出现疲态，进入战略相持阶段，低估它未来带来的变革。智能运维发展趋势是确定的，中间遇到挑战是必然的，关键是怎么解决？
其实，不只是智能运维赛道会遇到这个问题，其他赛道也面临同样的困境，所以解决这些问题有一些现成的方法论。比如《实践论》提出“实践、认识、再实践、再认识，这样形式，循环往复以至无穷，而实践和认识之每一循环的内容，都比较地进到了高一级的程度。这就是辩证唯物论的全部认识论，这就是辩证唯物论的知行统一观。”
再比如，达里奥在《原则》这本书中提到的“五步成功法”：
第一，设定目标；
第二，发现通向目标的障碍；
第三，诊断问题所在并制定计划；
第四，列出解决问题的任务清单；
第五，坚决执行任务。
然后这五步反复迭代。
回想一下，智能运维解决的到底是什么问题？智能运维必须要定义并交付端对端的、一句话能讲清的、可量化的价值；其度量标准一定是运维的价值。
当前阶段，智能运维的效果与行业期待有差距的原因，在于目标不够明确。我认为，智能运维在未来2-5年大规模商用之前，实施出效果最大的阻碍是各方对目标没有完全对齐。目标不对齐会导致各方对价值的表述不一致、期待不一致、目标不一致、行动不一致，造成实施过程中大量无用功。反之，如果目标一致，就可以目标导向、抓大放小、合理分工。
以指标异常检测为例，目标是检测指标数据里面的异常，还是为业务问题进行告警？如果是后者，告警出来之后运维人员要马上采取行动，如果不是建事件单的告警，他大概率认为这条告警不准是误报，要放一放。所以，如果我们不能把技术和端到端价值直接匹配上，那么我们就要进行不同封装。如果目标是产生事件单告警，评估时对照事件单来调优，如果目标是检查风险隐患防止系统出故障，就进行风险识别的封装。技术和价值中间存在Gap，专注于检测数据准确率的技术如果要跟业务价值匹配，本质是没有对齐目标。
如何对齐目标？以健康医疗服务来类比，100万人的医疗健康服务需要有各种检验检测设备，比如血压计、血糖仪、B超、验血、CT、核磁等，这些检验检测设备类比为智能运维里面的多种异常检测手段和采集数据的监控手段；各类诊断知识类比于知识图谱依赖关系；还有像指标中心、血液检测中心、医学知识等共同构成了类似数据平台的东西。“急诊服务”价值非常清晰，需要赶紧处理；“呼叫120服务”则判断送急诊还是在家缓一缓看门诊；“重大事项前后深度全面体检服务”类比重大变更之前对系统的仔细检查；“体检服务”识别慢性病后，该看门诊就看门诊；“健身服务”是强身健体。这如同扁鹊三兄弟中扁鹊治大病，扁鹊二哥治慢病，扁鹊大哥治未病，价值都非常清晰的。
就像上面我们站在健康的角度讲这些价值那样，我们能不能站在运维角度，来谈业务稳定性的价值？对应实际业务，智能运维跳出算法细节，必须清晰地给出量化的运维价值。我们把技术、算法并联串联合并在一起，对算法的调优取决于对运维价值有没有贡献。比如智能排障分析平台的价值在于“事件发生即定位”，量化价值是根因定位覆盖率、根因定位准确率、根因定位时间。智能事件管理平台要汇总抓包数据、黄金指标进行业务监控，结合告警数据检测是否应该建事件单。就像120急诊接到电话会判断谁应该更高优派救护车救助一样。
对于变更前后的重要活动，如618、双11电商活动是不是要做大量的运维重保工作？比如一些重要但低频的交易，一笔交易两星期才有一次，但交易金额达到11亿元规模，我们就要确保这笔交易不能失败。由于证券行业对系统可用性要求严格，故障一旦发生会影响股民在高点卖出、低点购入的操作，所以非常不希望发生故障。这时可以通过风险感知平台，提前发现隐患，建立隐患整改单。
还有智能运维演练中心，通过流量模拟、混沌工程进行运维对抗演练，在测试环境中找到实际生产环境中不易高频出现的问题，并消除隐患，那么现场出问题的概率就小了。
最后，对于技术的评估、目标设定，必须是在一定阶段内对运维人员具备清晰无误、一句话说明白的运维价值。比如事件发现怎么进行微循环、微迭代、大迭代？我们定义指标是事件发现覆盖率、事件发现准确率。实践中，我们清晰地认为评估要用事件单进行比对，就对事件单数据进行清洗，接入相关的告警指标等数据，形成一个测试用例集。就像一份试卷，卷面是事件单和告警数据，然后用技术和算法系统作答，再比对答案，发现“应该报出来多少事件单”“事件单之外又报了多少”，即准确率和误报率。
具体到项目启动时，事件发现效果大概率不会好，可能只有30%、40%。这时对每个检测不准确的事件单进行分析，找到原因，可能是数据接入不足，可能数据质量问题，有可能算法问题，也有可能运营推广问题。基于这些原因，分析设定最终目标为80%、90%，再制定每周的接入计划、整改计划。如果绝大多数是数据接入问题，我们就去预计提升多少，做哪些整改项。如果是数据质量问题，就去协调数据供给方，预计提升多少。如果是算法问题，预计提升多少。如果没有设好告警的优先级，就进行相应调整。每个做不做，当前阶段做不做，先做哪个后做哪个？这取决于它对量化指标提升的贡献度。我们制定每周提升的目标值，新一周出现的事件再加到测试集里面，找到不准的原因，每周测试每周出效果，每个季度、每半年看到对应的结果提升，如此循环反复、不断迭代。
故障定位亦是如此，对于故障定位覆盖率、准确率、定位时间，以同样方式建好测试用例集，制定切实可行的目标，每周有所提升，每周复盘制定下周更改计划，日拱一卒，积小胜为大胜。特别是对数据源依赖更多的根因定位场景。很多人说CMDB不好建，建了也没有清晰效果，放在大屏上展示没有问题，但是不知道到底有哪些质量问题，能不能清晰给出CMDB建设不准的部分。根因定位重度依赖CMDB数据，在消费数据时能够提供非常准确的、定向的、靶向的数据治理方向。
如此一来，项目复盘时，**发现的数据质量问题就不再是算法不准、效果不佳的借口，而是对数据治理有直接明确的、不可替代的贡献。**因此数据治理和数据消费场景应该并行建设，边用边治理。
对于软件应用新版本上线前后的变更风险，不管在预发布还是生产环境下，我们同样对变更单和事件单进行比对，由变更导致的事件就对它进行清洗。相当于出一份卷子，假设总共有100个变更导致线上故障，相应有100个变更单，哪些导致了线上事件，哪些没导致，这是yes or no的问题。风险感知系统最初启动可能只有30%、40%的准确率，逐渐提升直至达到目标值。怎么达到目标值？遇到数据不足，就接入更多的数据；遇到质量问题就协调各方整改；运营推广问题就去解决它；遇到算法问题也去解决。整个过程是不断收敛、能够看到目标，不把所有问题归因为技术问题，而是需要多方协同，共同协作把效果做出来。
03 总 结
最后总结一下：
- 从现在开始的两年是AIOps行业的关键两年：回归理性，注重实际效果。
- 实施出效果的最大障碍：没有明确并对齐目标。
- 当前AIOps产品必须要定义并交付端对端的、一句话能讲清的、量化的运维价值。
- 设定目标、分阶段实施、多方协作、反馈、循环往复迭代、不断提升效果指标。
- 数据治理和数据消费场景并行建设，边用边治理：发现的数据问题是对数据治理的直接贡献。
- AIOps效果落地最后一公里: 包含复盘、回归测试的项目交付标准流程,
量化度量AIOps产品价值，作为贯穿产品研制、项目实施全周期的核心抓手。