随着AI技术在各个应用领域的落地与实践，IT运维也将迎来智能运维新时代。算法的效率提升了AIOps的价值。通过不断学习，智能运维将使运维人员从复杂的告警和噪音中解放出来。那么，基于算法的IT运维与自动化运维有什么区别呢？现阶段运维中哪些痛点适合引入人工智能技术？如何加快实施？第十四届8月26日下午在北京举办了以“TechNeo”为主题的技术沙龙活动，将进一步拓宽运维/开发人员的运维思路，激发创新能力。清华大学计算机系副教授、智能运维算法专家裴丹以“如何实现智能运维”为主题分享了精彩演讲。演讲伊始，裴丹教授通过运维大背景介绍了通用智能运维的关键技术，旨在让最先进的智能运维技术惠及所有企业。裴丹教授认为，智能运维普及化的解决方案在于四个方面：数据、算法、算力和人才。第二部分是对智能运维中的关键技术进行分解定义，通过分解关键技术定义科研问题。裴丹先生指出的研究问题如下：清晰的输入和数据的可用性。输出清晰，输出目标实用。有一个高级技术路线图。有参考资料。非智能运维领域的学术界可以理解并解决。裴丹教授还指出，Gartner报告中对智能运维的描述过于宽泛。如何做好智能运维？裴丹教授认为，机器学习本身有很多成熟的算法和系统，也有大量优秀的开源工具。如果你成功地将机器学习应用到运维中，你需要以下三个方面的支持：数据。互联网应用本身就有海量的日志。存储需要优化。数据不够，需要独立生成。注释数据。日常运维工作会产生带标签的数据。比如发生事故后，运维工程师会记录这个过程，这个过程会反馈给系统，进而提升运维水平。应用。运维工程师是智能运维系统的使用者。用户在使用过程中发现的问题，可以对智能系统的优化起到积极的作用。通过与百度运维和搜索部门的合作，裴丹教授分享了三个智能运维案例，包括异常检测、瓶颈分析和智能熔断。第一个案例是基于机器学习的KPI自动化异常检测。上图为运维人员判断KPI曲线异常并标注出来，系统学习标注的特征数据。这是一个典型的监督学习，需要高效的标注工具来节省运维人员的时间：比如拖动、放大等等***，裴丹教授分享了搭建KPI异常检测系统的相关实践和挑战及相关解决方案。以下为演讲实录：我们都知道智能运维的发展历程。在运维发展过程中，最早出现的是人工运维；DevOps和智能运维出现了。在运维过程中，涉及的步骤可以归纳为：生成海量监控日志，分析决策，通过自动化脚本进行控制。运维的发展过程主要是分析决策步骤的变化：首先是人工决策分析；之后，根据收集到的数据，使用自动化脚本进行决策分析；最后，使用机器学习方法进行决策分析。根据Gartner报告显示，与智能运维相关的科技行业正在兴起。2016年AIOps部署率不足5%，Gartner预测2019年全球AIOps部署率可达25%，AIOps前景广阔。如果AIOps被广泛部署会是什么样子？现在做运维的同学会怎样？从机器的角度，将基础的、重复的运维工作交给计算机；同时，机器通过机器学习算法为复杂问题提供决策建议，再向运维专家学习解决复杂问题。从运维专家的角度来看，运维专家主要处理运维过程中的疑难问题，同时根据机器建议给出决策，培养机器徒弟。运维工程师将逐步转型为大数据工程师，主要负责开发数据采集程序和自动执行脚本，构建大数据基础设施，高效实现基于机器学习的算法。机器学习科学家主要负责人工智能的应用。与其他AI应用领域相比，智能运维的优势在于我们不仅拥有大量的应用数据，而且拥有实际的应用场景和部署环境。因此，人工智能除了计算机视觉、自然语言理解和语音识别之外，还有另外一个应用——这是一个尚未开发的金矿。智能运维科研门槛高——当行业普遍有“前程似锦”、“前程似锦”之时，随之而来的是“曲折之路”。事实上，智能运维是一个门槛很高的工作。为什么？因为智能运维需要三个方面的知识：我们要熟悉应用行业，比如互联网、电信，或者是比较传统的行业，比如金融、电力等等。我们需要熟悉运维相关的场景，包括异常检测、故障预测、瓶颈分析、容量预测等。虽然业界熟悉运维行业和场景，以及生产实践中的挑战，也有数据。但是，整个智能运维中最重要的部分——如何将实际问题转化为算法问题，业界并不熟悉（后面会讲到如何将实际问题分解为多种算法，一一解决）。同时，行业对咨询研究文献，尤其是跨行业文献不是很熟悉。因此，智能运维是一个高门槛的领域，需要三个领域知识的结合。智能运维文献中常见的基础算法有几十种。然而，业界并不熟悉这些算法。因此，我们用微信公众号来介绍这些算法。下面我将介绍一个例子——使用机器学习方法来提高视频流的用户体验和观看时间。这是一个CMU教授的系列文章，他在一家做视频分发的初创公司做一些工作。2011年，他在学术界发表了一篇文章。这项工作比较简单，主要是为了提高用户观看流媒体的体验，使用了简单的相关分析、线性回归、信息增益等算法。2013年，教授根据网络行为数据和性能数据，采用决策树的方法预测用户的观看时长。该教授在2017年发表了一篇新文章，将视频质量的实时优化问题转化为一个基本的强化学习问题，并使用上界置信区间算法高效求解。智能运维研究门槛高学术界很少有人从事智能运维方向。这是因为，对于学术界来说，进入智能运维的科研领域是非常具有挑战性的。为什么？学术研究人员虽然具有较强的算法能力，但往往对行业和运维领域的相关知识并不熟悉。智能运维处于三个领域的交叉点。这就导致智能运维的门槛比较高，进入智能运维领域需要花费大量的时间和精力。我讲了如何降低行业进入智能运维的门槛。同时，我也做了一些工作，降低学术界进入智能运维领域的门槛。比如我受邀在《中国计算机学会通讯》上发表文章，向学界同仁介绍智能运维方面的科研问题。但是，仅仅宣传是不够的，我们还需要实践。去年，我在第一届APMCon大会上做了一个报告，描述了当时与百度合作的三个案例，包括异常检测、瓶颈分析和智能熔断。这次宣传也给我自己带来了很多新的合作。除了与百度的合作，我们清华实验室还先后与滴滴、搜狗、阿里巴巴、腾讯签署了正式的合作协议。这验证了我去年在APMCon演讲中的观点：业界可以获得算法层面的深度支持，学术界可以获得现实世界的前沿问题和数据，有利于发表论文和申请国家级项目。产学合作1.0：一对一交流合作然而，目前产学合作还处于1.0阶段，即一对一交流。在这个过程中，我们遇到了很多挑战：交流合作效率低，见效慢。比如我是教授，我跟A公司讨论，再跟B公司讨论，很多时候不同公司遇到的问题都是相似的，比如异常检测。但是，我需要与每个公司一起解决这些问题。C公司可能不知道我的情况，所以它又找了一个教授来解决这些问题。这大大降低了沟通和合作的效率。我们知道，科学研究中最困难的部分是在实践中定义一个问题。问题定义好了，其他的问题只要数据准备好了就可以解决了。智能运维算法不幸成为特权。因为很少有教授愿意做这种一对一的交流，愿意或者有渠道和学校科研人员交流的企业也不多。因此，在国外，只有少数大公司和教授可以合作。例如，只有谷歌、微软、Linkedin、Facebook、雅虎等大公司发表过智能运维方面的论文。涉及知识产权，不符合开源大势。因为一对一合作需要签订涉及知识产权的协议，不符合开源的大势。2.0：开源开放一对一沟通效率低下，怎么办？我们希望拥抱开源开放的文化，形成产学合作的2.0。开源和开放的大趋势对工业界和学术界产生了巨大的影响。大家熟悉的Hadoop、Ecosystem、TensorFlow等都是开源开源的产物。算法层面，目前有arXiv共享算法（论文）平台和Github代码共享；在数据层面，ImageNet等数据共享平台对机器学习算法的研究起到了巨大的推动作用；在算力层面，各大公司都已经建立了AI云；在人才层面，我们也可以看到，学术界和产业界的人才流动比以前顺畅了很多。所以我们的基本思路是希望建立一个智能运维的题库。具体来说，我们尝试将运维中的常见问题整理出来，存储在问题库中。这样，对于缺乏智能运维背景知识的科研人员来说，在问题的输入、输出、数据集完备的前提下，也可以轻松上手解决题库中的科研问题。对于业内做运维实践的同学，遇到实际问题可以到题库中查询答案。这种思路受到斯坦福教授李飞飞的影响。她最近一直在宣传通用人工智能的理念——让所有人都能接触到人工智能。李飞飞教授建立的ImageNet拥有超过1000万张图片的分类和标注数据。2012年，Hinton教授提出了基于CNN的图像分类算法，取得了比以往最佳结果高出几个百分点的结果，掀起了深度学习的复兴。现在，她还担任谷歌机器学习部门的负责人。她在宣传全民AI理念时提到，全民化有四个基本点：算力、数据、算法、人才。这四个基本点与我们在实施智能运维中遇到的挑战是一样的。因为我们还需要利用机器学习和AI技术来解决智能运维中的挑战性问题。除了题库，学术界还需要数据集。此外，工业界可以首次提供云计算资源，让学术界提供的算法可以在云端运行。数据公开后，学术界可以发布训练好的算法，工业界可以直接使用这些算法。在人才方面，产业界可以与学术界合作。同时，那些参加我们智能运维算法大赛并获得高分的同学，也可以成为行业的人才库。最终，我们希望所有的企业都能使用最先进的智能运维算法。分解定义智能运维中的科研问题。下面对智能运维中的科研问题进行分解定义。由于时间关系，我只能概括一下算法的特点。为什么我们需要定义科学研究问题？对于科研人员来说，Gartner报告中列出的智能运维问题过于宽泛。第一，科研问题需要明确的输入和数据；第二，科研问题要有明确的产出，产出目标要切实可行；第三，科研问题要有高水平的技术路线图和参考资料；***，非智能运维领域的学术界要能看懂科研问题。这些是我们整理出来的一些科研问题，后面会利用时间来讲解这些算法。这些算法分为三种：第一种算法是一个相对独立的基础模块，面临的挑战较少，可以直接实现。第二种算法依赖于其他算法，我们需要将这些算法分解成问题的可行解。三是对非常难的问题，降低要求和难度，“退而求其次”。基础模块先说基础模块。基础模块相对独立，可以实现。KPI瓶颈分析算法我介绍的第一个基础模块算法就是KPI瓶颈分析算法。在智能运维和APM领域，我们收集了很多KPI时序、日志等形式的数据，如果以打开一个页面的响应时间（首屏时间）为我们的KPI，当第一个屏幕时间不理想和不理想，我们希望找出是哪种条件组合导致了首次屏幕时间不理想。这就是我们要解决的KPI瓶颈分析的定义。此问题的输入是一个又宽又长的表，其中包含KPI和影响KPI的多维属性。输出是可能影响KPI性能的属性组合。该科研问题应用场景广泛，包括首屏时间、应用加载时间、软件报错、视频传输用户体验等。在具体应用中，该科研问题面临诸多挑战：搜索空间巨大;不同属性之间可能存在相关性，无法使用简单的分析方法。KPI瓶颈分析常用的基本算法有：决策树、聚类树（CLTree）、层次聚类。故障预测算法我介绍的第二个基础模块算法是我们最近和百度系统部合作的一个案例——交换机故障预测。在切换失败之前，我们可以从切换日志中提取一些失败的迹象。如果我们发现这些信号，我们最多可以提前两个小时预测开关故障。故障预测的应用场景还包括硬盘故障预测、服务器故障预测等，使用的算法包括隐马尔可夫模型、支持向量机、随机森林等。在具体应用中，故障预测面临一些挑战。训练故障预测模型的数据需要足够大，但实际中故障案例往往比较少。虽然日志量很大，但是日志中有益的信息却比较少。我们已经实现了一个实用的系统，它已经在百度上运行了。当我们的应用层出现问题的时候，我们希望找到问题的原因。已经描述了这里要解决的问题。常用的根本原因分析算法是基于故障传播链和基于概率图模型的。这里我们将基于故障传播链的思想来解决问题。如果我们有这样的故障传播链，同时有很好的事件监控和准确告警，那么分析根因就简单了。因为你只需要沿着故障传播链找到告警，最后一个告警就是根本原因。关键有两个步骤，一个是KPI异常检测，一个是故障传播链，下面会详细介绍。异常检测首先是异常检测。很多算法都是基于KPI趋势预测，也有一些算法是基于机器学习。机器学习算法需要被标记。标注会给运维人员带来很大的开销，那么是否可以做一些工作来降低标注的开销呢？这包括搜索类似的例外情况。运维人员标记异常后，能不能自动把相似相关的异常全部找出来？以上是对异常检测问题的简单分解，后面会做更详细的解释。异常检测的问题定义很简单，就是对于这样一条随时间周期性变化的KPI曲线，当出现异常时能够快速准确的报警。其常用算法有：基于窗口、基于预测、基于逼近、基于隐马尔可夫模型、机器学习、集成学习、迁移学习、深度学习、深度生成模型等。异常检测面临的挑战是存在是不同类型的KPI。如果是基于趋势预测算法，调整算法参数费时费力。同时需要人工标注，人工标注也可能不准确。让我们再分解一下。我们刚刚提到，异常检测的一种思考方式是基于KPI趋势预测。KPI趋势预测就是利用时间序列数据的算法来预测KPI未来会是什么样子，取什么值。常见算法包括ARIMA、EWMA、Holt-Winters、时序数据分解、RNN等，主要挑战包括突发事件、节假日、数据不规则的影响。最重要的是，人们对异常的定义不同，会存在主观因素，导致这些算法难以调整。异常检测的另一种思路是基于机器学习，但这种方法通常需要标注，耗费人力资源。而如果标注不完整或者不准确，这个机器学习模型的效果就会大打折扣。下面我们分解一下减少异常标注的工作，在同一条曲线中发现相似的异常，跨KPI发现异常。KPI相似异常搜索是在KPI中发现异常，运维人员对异常进行标记，然后算法将标记的异常作为模块寻找曲线上的其他相似异常，可以减少标注开销。比如图中红色部分就是标签，输出的就是其他类似的异常。常用的基础算法有DTW、MK***配对等。如果KPI有交叉，可以预先将一个模块的各个KPI聚类，标记在同一类别的某条曲线上，然后在其他类似曲线上对应位置也是不正常的。聚类中使用的基本算法包括DBSCAN、K-medoids和CLARANS。聚类基于曲线的相似性。如果曲线不相似，但它们内在的相关性导致它们经常一起变化，这也可以发现更多的异常，这可以作为一种减少标记开销的方法。这是“KPI相关性分析”的科研问题，其基本算法包括相关性分析算法和格兰杰因果分析算法。故障传播链的另一个关键因素是故障传播链的构建，即事件A的发生会导致事件B的发生，如果弄清楚事件的传播关系，就可以形成故障传播图.上面提到的KPI关联分析和KPI聚类都可以使用。下面介绍异常事件的关联关系和KPI关联关系的挖掘。上图显示了故障传播链。当应用层和业务层发生故障时，如果有故障传播图，可以找到相应时间范围内的相关事件。如果有，则沿着传播链继续查找，直到找到根本原因。我们希望得到这样的故障传播图，但是很多软件之间的模块关系非常复杂，难以描述。另外，刚才提到的调用关系，即模块A调用模块B，并不是说A中的异常就会导致B中的异常，而是还有很多其他的因素。通过机器学习算法挖掘各种关联关系，辅以模块调用关系链，相对容易构建准确完整的调用关系链。挖掘关联关系包括前面讲过的KPI聚类和KPI关联分析，下面对另外两种算法进行介绍。首先看异常事件之间的关系。两个相关的事件在历史上是不是经常一起发生，比如这四个不同的事件都发生在这个时间窗口内，如果经常一起发生，就是成对的关系。现有文献中常见的算法有：FP-Growth、Apriori、RandomForest。另一个是事件和KPI的关系，比如程序启动的事件。在某个时间点启动程序A，在下一个时间点启动程序B。每次程序A启动时，CPU利用率都会上升一个更高的水平，但B不会。因此，事件与曲线的关系还包括变化的顺序和方向。常用的基础算法有Pearson相关分析、J-Measure、Two-sampletest等。nextbestthing我们前面已经分解了rootcauseanalysis的问题，但是有时候由于数据收集不全等原因，完整的条件根因分析不可用，这就要求我们降低要求，“退而求其次”，解决方案更简单但同样具有实际意义的问题。智能断路器众所周知，80%的上线故障都是由于产品上线或变更引起的。也就是说，在这种情况下，运维人员的运维、上线和变更是业务出现问题的根源。那么我们可以针对这个根本原因做些什么吗？答案是肯定的，就是智能熔断器。产品上线后，根据已有数据判断业务层的问题是否是上线操作导致的。具体实现可以采用CUSUM、奇异谱变换(SST)、DID等算法。异常告警聚合算法是另一个角度。现在有各种监控告警。如果运维人员不能正确聚合，就无法决定下一步的操作。因为监控的KPI太多，异常告警是多余的。我们的算法会把各种告警原始数据聚合起来，比如把100个异常告警聚合成5个，这样实际处理起来会比较容易。具体算法包括基于服务、机房、集群等拓扑的层次分析，以及基于故障传播链的关系挖掘和告警聚合。故障定位算法最终给出了次优解。当业务出现故障时，故障定位并不能给出完整的根本原因，但可以大致区分问题出在哪里。输入是各种性能指标，输出是根本原因的具体位置。比如在去年的SIGCOMM2016上，微软提出了基于数据中心的故障定位。首先，用试验台模拟所有可能出现的故障，同时采集各项监测指标。通过机器学习建立模型，根据实际发生的监控指标的症状，推断出问题根源的大致位置，从而加速止损。相关文献中使用的基本算法有随机森林、故障指纹构造、逻辑回归、马尔可夫链、狄利克雷过程等故障定位方法。简单总结一下，实现智能运维的关键技术有3种途径。相对独立的算法可以直接实现，依靠其他算法的根因分析可以解决问题，数据条件不成熟的可以退而求其次。另外，从上面列举的众多算法示例中，大家可以看到，确实有很多算法可以应用于智能运维。业内朋友可以花点时间和精力简单了解一下这些算法，知道这些算法的输入和输出是什么，可以解决运维中的哪些实际问题，结合起来可以解决哪些问题。更快的维度落地具有事半功倍的效果。总结与展望智能运维本身的前景是非常光明的，因为它拥有丰富的数据和应用场景，将大大提高智能运维领域的生产力，也是一个尚未被挖掘的宝库在人工智能领域得到充分利用。智能运维需要产学界的密切合作，但仍局限于一对一的相对低效的合作。少数公司、少数教授的特权，不符合我们开源开放的趋势。我们的解决方案是以科研问题为导向，从日常工作中发现相关问题，然后将这些问题分解定义为可行的科研问题，归纳为科研问题库进行智能运维。同时，业界可以提供一些脱敏数据作为评估数据集，学术界可以下载数据贡献算法。我实验室NetMan将运营“智能运维算法大赛”网站，汇总智能运维科研问题库，提供数据下载，举办智能运维算法大赛。包括美国eBay在内的多家公司已同意为网站提供脱敏运维数据。在此非常感谢业界的所有伙伴，也感谢我在清华大学的团队NetMan，堪称智能运维算法的特种部队。***，勉励大家：智能运维的前景是光明的，但道路一定是曲折的。在智能运维领域，我们从去年开始就在实践中推动智能运维算法落地。我已经行动了一年，我们还有四年的时间。相信只要有更多的学术界和产业界的朋友参与进来，再加上我们“智能运维算法大赛”网站这个载体，我相信就像ImageNet曾经推动深度学习和人工智能的复兴一样，我们一定能够在实践中推动智能运维算法更好的落地！谢谢大家。TechNeo技术沙龙是2016年开始定期举办的面向IT技术人员的线下交流活动，目前仅限北京地区。周期是一个月一次。每期聚焦一个话题，涵盖大数据、云计算、机器学习、物联网等技术领域。
