2019阿里云上海峰会，由阿里云资深技术专家周琦带来以“基于AlOps的探索和最佳实践”为题的演讲。AIOps意味着智能、安全的管控平台，阿里巴巴经过十年的变革在AIOps上有重大探索，那么AIOps究竟能够为大家带来什么益处呢？接下来本文将对AIOps进行详细的介绍。
视频直播回顾
云原生专场PPT下载
以下为精彩视频内容整理：
AIOps 能带来什么？
现在无人驾驶技术一直备受关注，无人驾驶技术从L1到L5一共有5个等级代表越来越智能的自动化程度，从目标来看，无人驾驶技术希望在安全驾驶的过程中不断去提升整个通行效率，并且降低整个公路的安全隐患，并降低污染的排放。
与无人驾驶类似，AIOps目标是为IT基础设施平台的运转提升效率，提升系统稳定性并解放人在运维上的投入。近几年来，云原生和容器服务使应用、发布、部署的环节效率能够大大加快，但在整个发布和运营的过程中环境的复杂性、应用部署规模、用户多样性等使得整体风险越来越高。AIOps目标就是通过数值驱动手段，在更快的发布效率同时兼顾更低的风险，减少人力投入，使得IT设施具备既快又安全的“自动驾驶”的能力。
飞天研发史：人与机器斗争史
飞天操作系统是阿里云的基础设施，要知道研发基础平台是一个非常复杂的事情。可以认为就是一部人和机器的斗争史。在第一个阶段，为了能够在大量机器上进行调试，我们使用了大量的监控工具解决可观测性的问题，这个阶段大约需要2个员工管理大小不等的20个集群。
在集群规模从20个变成400个过程中，工程师会花费大量的时间在如何标准化接入、标准化运营上。所以在这个阶段，主要任务就是如何把整个监控和分析能力标准化，接入自动化，本质上是一个把监控+运维工具标准化，服务化的阶段。
在第三个阶段由于集群规模和业务量的不断增大，我们所面临的问题更加复杂，传统手段往往很难解决一些比较复杂的可观测性问题。因此我们使用了大量数据化、智能化的手段进行尝试，获得了较好的结果，每个员工管理集群的和应用的能力，可以达到1：1000或者更高。
云原生和Docker技术解决了一部分运维和发布的负担，但对于个人承担的责任仍然变得越来越大，我们可以把应用上线的过程分成三个阶段：第一个阶段开发人员需要腾出一半的精力测试系统是否稳定、高效，代码是否有逻辑；第二阶段，在整个上线过程中，除了将产品发布以外，还需要花40%的时间在部署和运营上，让用户能够更好的运用产品；第三阶段为上线后阶段，除了运维和运营支撑外，还需要花时间关注安全问题，例如某个系统有没有人登录，登录之后是否做了一些非法操作等。
研发、运维、运营的挑战
作为研发（DevOps） 如何能在快节奏下做到以上的点呢？我们可以看一条非常著名的法则：海恩法则(Ohain's law)是德国飞机涡轮机的发明者帕布斯·海恩提出的一个在航空界关于飞行安全的法则，多被用于企业的生产管理，特别是安全管理中。海恩法则指出: 每一起严重事故的背后，必然有29次轻微事故和300起未遂先兆以及1000起事故隐患。法则强调两点:一是事故的发生是量的积累的结果;二是再好的技术，再完美的规章，在实际操作层面，也无法取代人自身的素质和责任心。
我们关注的是第一点，如何建立一套风险的监控、分析、洞察体系。从安全人员角度来讲，安全人员关注的是在集群上线之后有没有非法登录的现象，安全人员需要采集大量的Logs和规则，用来判断是否防火墙被匿名打开过。对于运营人员来讲，无非是把logs内容变成User Click，然后根据用户的增长进行运营。
因此我们可以把常见工作做一个抽象：对运维、安全、运营而言，无论是从监控场景，还是平时用的基于ELK的Logs场景，还是对安全日志建模场景。要做的往往都是四个步骤：数据采集，根据假设建立一套模型获得初步的结果（Event），根据初步结果获得最后的结论，在步骤三和步骤四的过程中需要进行探索性的Drill Down、Roll Up等操作，不断去Refine自己的假设和模型。
可观察性的挑战
在建立这样一个体系之前，我们结合AIOps场景特点需要解决三个挑战，具体介绍如下：
更快的响应：对于一个在线服务而言，从观测数据的采集到行动，期待能够在秒级之内完成，这样才能保障快速解决。
更多的视角：在安全的角度观察的是有没有漏洞；在研发的角度关心的是有没有错误；在运营人员的角度关心的是流失率和用户点击的路径。所以必须要从更多的视角观察数据。
深入到细节：对数据进行分析时，应该关注数据的具体详情，例如很多细节的状况都需要在秒级才能发现。
统一的数据模型、通用架构、面向分析类的设计
从平台的架构来看，我们构建了一套面向观测数据（Telemetry Data）的系统，数据源主要分成Tracing、 Metric、Logging三类，将三个数据采集到同一套架构中，运用一套方法论和平台对数据进行查询、分析、聚类和预测。在这个基础上，可以利用开源或者商业的可视化软件，构建一套所见即所得的可视化架构，帮助用户更好的感知业务的形态和细节。
Sec、Dev、Ops 解决问题思路
系统构建完成后，我们把问题分析和调查的高频场景做了抽象，并提出了7个高频使用的手段，接下来将会对这7种方法进行详细的介绍。
查找：Grep
GREP是查询问题最频繁的方法，通过这种方式能够快速的找到问题发生的位置。从业界统计《50 Most Frequently Used Unix Command》看，Grep是使用最多的命令之一（排名第一的是tar、第二就是它）。Grep提供了一种“简单暴力”方式过滤掉无用的信息。从业务的视角来看，无论是pssh + pgm方式，还是对Tracing类数据的应用形态进行剖析，或通过开源ELK工具对访问日志的筛选 + 排查，背后都是查找这种方式。
上下文
当查找到关键点后，我们需要定位关键点的上下文。这个就像调查一个犯罪现场一样，需要看周围的环境，该环境一般对于程序人员而言就是上下文。比如一个程序执行出现错误时，出现问题的上十行和下十行代码很有可能和这个错误相关，比如之前传入的参数，或错误后的执行逻辑等，这些上下文能够有效的帮助程序员找到上下游的线索。
上下文对于不同的应用含义是不一样的：
• 一个错误，同一个日志文件中的前后数据
• 一行LogAppender中输出，同一个进程顺序输出到日志模块前后顺序
• 一次请求，同一个Session组合
• 一次跨服务请求，同一个TraceId组合
例如一个很常见操作是grep拿到文件后，跳转到对应机器用vim打开文件，上下翻阅查查找这些线索。在这个过程中，有不少程序员贡献过一些vim插件帮助标记（不同颜色标记error、info、level等级别）。纵观整个过程，我们为了拿到前后几行的数据，做了很多不必要的操作。
我们把上下文定义如下：在一个最小区分粒度上能够准确还原出最原始的序列，不受日志存储、采集等环节影响。
• 最小区分粒度：区分上下文的最小空间划分，例如同一个线程、同一个文件等。在定位阶段非常关键，能够使得我们在调查过程中避免很多干扰
• 保序：在最小区分粒度下保证原子有序，及时一秒内有几万次操作，也要保证顺序是严格的
为了有效的找出问题的上下文，我们设计了一套对应的协议。该协议会在所有的采集器、SDK、Appender中统一实现。该协议的主要思想是，在原始日志产生过程中，设置一个单调递增的ID，这个ID使得服务端在乱序存储的情况下，也能够进行全局的排序。通过全局的排序之后，当命中一条错误的日志时，就能够对整个错误日志的上下游进行关联，进而拿到错误的上下文。为了能够更直观的感受上下文方法，接下来举一个案例（视频）。
案例如图所示，在图中的7月22日中找到线上出现问题的位置，通过上下文快速的浏览这一行错误的上游和下游分别是什么，进而解决对应的问题。
SQL分析
寻找问题的第三种方式为SQL分析，在稍复杂一些场景中，我们需要对数据进行统计发现其中规律。在Linux理念中，任何复杂任务都是可以用一组命令的组合来达到（运维大法的一个入门的例子就是对Nginx访问日志进行命令行处理）。
例如线上在多次访问后依旧请求失败，若想知道这些请求是来自于哪些运营商，或者来自哪个省市，就需要对线上数据做完基础的查询后，再通过SQL分析得出想要的结果。
我们在查找后构建了一套SQL92语法的分析系统，能够对满足结果的数据进行实时统计，让我们来看以下这个例子，动态根据线上数据进行分析：
“线上有大量错误发生时，我们需要需要对这些错误各维度去聚合，是一个全局的错误？还是一个用户的错误？如果是用户的错误，是来自于某些省市的运营商？还是来自于用户的某个业务？每个推断后都是一个不断变化的SQL”
聚类
寻找问题的第四种方式为聚类，在机器学习中就介绍过“聚类”的概念，即数据不需要许多人工制定的规则就能够自动聚集起来。
在过去，如何从正常的数据中判断出异常很依赖于领域专家能力和经验：以系统Latency作为例子，25ms是个绝对数值，只对特定场景有意义：25ms对于一个包大小为4KB 请求偏大，但对于一个2MB 大小的请求是合适的数值。
如何在缺乏领域专家知识情况下如何发现异常？ 这时可以借助统计意义上的大数定律：
大数据定律通俗一点讲，就是样本数量很大的时候，样本均值和真实均值充分接近。例如从数据本身的分布规律来比较哪些是异常的。例如通过聚类我们可以快速将“相似”实例汇聚在一起，定位到“小众”的数据（但不一定是异常）。
对错误类的日志，通过关键字找一个错误可能会搜索到几千条相关信息，但其中只有一两条是问题所在的地方，我们需要用很多grep -v排除掉无用的信息。
对整个线上监控类数据也是类似，假设线上有很多实例，若想看一下负载均衡是否起作用，那么只要将这个实例当前的平均CPU拿出来做排序，看一下哪些机器的CPU使用过高即可。
我们根据线上日志类数据、时序数据（Metric）做了两套原生的聚类算法，例如对日之类数据能够自动识别出变量（例如时间、线程Id、实例信息等），把结构化类的Pattern留下代表一类事件，这样就能够排除数量上的影响，让我们找到背后的关键事件。
以线上为例再进一步介绍聚类方法，选中sys_log搜索数据的结果有3000多条，通过翻页寻找想要的数据非常困难，但是通过使用聚类方法，就能把同一日志里面符合搜索的数据全部选取出来，包括时间、IP等等。3000多条数据通过聚类筛选后只剩20条左右，接着将这20条信息进行对比，判断哪些是新筛选出来的信息，哪些是以前存在的信息。
对于线上服务器的流量数据， 我们也能够通过形态进行聚类，以诊断出哪些机器的行为与其他不一致，负载均衡是否起了作用。
异常发现（时序建模）
聚类解决了同一时刻不同实例下的异同点问题，但在很多场景下我们没有别的参照系。在缺乏专家经验情况下，一种简单方法是从历史角度来判别。
例如我们可以用环比和同比函数，和昨天（Yesterday），一周前（Week）和月（Month）进行对比，如果差别大于某一个Threshold（例如10%）可以认为是异常。
这种方法看似简单直观，但面对复杂一些场景就会产生失效情况，例如“标准日历 vs 零售日历”缺陷：
在零售行业中节假日、周末会比工作日带来60%以上营收。因此每个月进行预测时，往往会随着月的大小周（例如5个周末 vs 4个周末）造成比较大的偏差。
因此对于非平稳序列数据，通过简单同比环比还不够，我们需要对数据规律进行更复杂的建模。例如可以自动排除数据中的噪声，学习数据的趋势、周期等规模，形成一个根据历史数据自动学习的基线。当前数据和基线有较大偏差时，可以认为就是异常。
根因分析
通过方式五中的异常发现已经能够找出异常，接下来我们需要能找到问题的根本原因（Root Cause Analysis）。 假设工程师收到一条流量下降的告警，有经验的工程师会有一个猜疑链，究竟是用户的问题还是网站的问题。若是用户的问题，分析是城市的问题还是某个客户端引起的问题；若是网站开发版本的问题，判断究竟是移动端的问题还是网页端的问题。若是移动端问题，那么还需要判断究竟时安卓带来的，还是IOS。
一个简单的思路就是统计意义上的“啤酒和尿布”问题-频繁模式挖掘，我们可以创建一张表，这个表能够把所有失败的请求列出来，同时相关属性。接着做一个简单的统计，就能知道在所有错误的日志里哪个属性占的比例较多，在这个例子里面很明显，问题发生在交换机（ASW=DEV1）。
模式挖掘方法从统计角度考虑频率的维度，如果数据有时间维度的属性，那我们可以有更多Feature可以提升准确性：根因特征对陡升陡降的变化量影响？根因特征贡献的绝对值与相对值？
一个改进的根因分析算法：
1） 线上流量有突增、将异常数据（突增）标记
2） 根据搜索算法计算突增的影响根元素组合相关性
3） 向用户推荐最有可能的组合（行为和整体的流量突增一致）
领域建模与本体构建
以上的方法提供了一批适合发现、定位问题的有力工具，但一旦离开了人，这些好比是空中楼阁，因此我们如何把人对系统的经验和认知，能够固化成一种让计算机理解并推断的方式会非常重要，只有这样才能做到最后一公里的完全自动化。
从计算机历史上看，AI在上个世纪七十年代提出后经历过一次小高潮后，受限于数据量和计算规模在90年代后没有大的突破。因此2000后科学家把提升准确性的工作借助另一个方向：
• 万维网之父"Time Bernus Lee" 提出《Semantic Web》概念，希望能让互联网的内容都有标注，具备一定的语义性，从而使得机器能够去理解人类在互联网上留下的半结构化知识，并做更好的推理
• 2003年一篇著名Paper提出也提出了一个概念：构建一张不断更新，能够具备一定推理能力的网络，网络能够自动去识别可能的问题。
2005年后，各公司开始尝试通过知识图谱（Knowledge Graph）把知识更有效组织起来应用在各领域中辅助AI。以人脑为例，很容易解释Knowledge Graph：
• 一个有经验程序员去调查问题时，会有一定的背景知识。例如有大量请求发生错误时，他可能会从脑海里去查找过去是否有类似的现象。当聚焦点到某一个设备时，他可能会从脑海里去考虑设备对应的网络结构。
• 所谓的历史经验，问题所依赖的环境，环境背后的关联等就Knowledge，通过Graph这种结构能够把零散的Knowledge组成一张体系的图谱在脑海中存储。当有一个新问题来的时候，他可以根据过去的经验，问题背景（例如业务的架构）等作为判断因素，快速去做推理和假设。
与这个过程类似，我们正在围绕CMDB、云产品API、容器拓扑结构、Logging、Metric等数据整合一张知识图谱。当有了这张图谱后，我们就可以有机地把上诉各种算法定位的结果进行整合，无论是故障搜索、线上环境的自动检查等，都可以更权威、准确地完成。
AIOps 算法落地场景
最后总结一下本文提出的几个方法，通过时序数据的算法能够解决趋势预测的问题；通过异常检测能够分析数据的周期性变化问题；通过聚类方法能够帮助数据进行降维；通过根因推导方法有助于搜索整个建模的问题和故障。