主持人：接下来由北京睿至大数据有限公司的左龙贺老师来分享睿至进取，我们眼中的AIOps。
左龙贺：大家好，我是北京睿至大数据有限公司的产品经理左龙贺，今天跟大家分享AIOps话题。刚才两位老师分别从日常的项目客户反馈，包括效益，还有自主的产品优势给大家分享了AIOps的一些看法。
今天我们睿至大数据这边主要是想从 AIOps 的一些解决方案落地情况，还有我们在客户这边落地的时候遇到的一些问题和一些难点想跟大家坐在一起分享这样的内容。
首先第一个片子，大概看一下整个AIOps发展的历程，首先最早的时候是2013年提出的ITOA概念，通过技术服务手段采集存储海量的数据，最后成品展现。
2016年提出了 AIOps 的理念，首次在它的理念里加入了智能化的算法内容，这里面我特地把AI和Ops分开，当时的提法只是一个概念型的定义，并没有把算法和一些运维场景进行深度的整合。
仅过了一年，2017年时候又针对AIOps提出了新的提升，也就是后来我们大家所熟知的智能运维概念。
从目前的情况来看，AIOps整个的市场和发展趋势是非常看好的，所以各大厂商都在做积极的投入，也包括我们睿至大数据有限公司。在这种大环境下，首先看一下用户所面临的问题，随着云计算的发展，还有一些微服务的应用，客户这边面临的问题可能就越来越多，主要体现在以下三个点：
首先客户这边规模非常庞大，有两个层面，一个层面相当于设备量大，包含各种厂商，各种型号的设备。另外由于设备厂商数量比较多，数据量也会越来越庞大，包括格式化的，还有非格式化的数据，包括日志。
另外层面是技术非常复杂，运维客户这边引入了这样的过程架构，包括虚拟化和容器的技术，所以整体来说，架构会变得异常复杂，当发生问题的时候，客户很难快速地定位到实际的原因，也是后面衍生的问题，它的问题很难定位。
客户很难在大量的数据里找到他所需要关心的核心价值点。
所以，对于客户来说，他们是想急需借助AIOps平台具有的数据分析能力和产品的功能来帮助他们解决日常手段或者现有方法不能解决的问题。
所以说，客户对于AIOps的想法还是非常积极的，然后不同的用户对于AIOps的一些理解可能也不太一样。之前我这边也跟很多的客户做了一些沟通，我把客户的一些想法总结了一下，基本上我跟客户聊的时候，客户基本上第一次去聊都会问你们平台里大概用到哪些算法，这些算法的准确度有多高，从另外层面来说，他们认为应该每个页面，每个功能都会有算法在里面。
从我们睿至的角度来说，除了算法模型之外，我们这边其实应该在目前的阶段来说，毕竟有些算法还有模型不是太成熟，所以在算法的基础上，我觉得更多的是把我们从客户这边汇聚在一起多角度、多维度的数据跟客户的实际运维场景结合，然后根据用户平时在处理问题的实际场景去尽可能给客户提供更多的数据支持，当客户在解决问题的时候，能更快地发现问题原因。
针对算法这块，其实我们也是在有一些投入，但是我们还是有选择性的会逐步加进来。比如说我们在前期可能会加入一些算法程度比较成熟的，比如像单指标和多指标的预测，还有关联分析，我们后面像这种故障的根源定位，还有一个关联度的影响分析，我们逐步是放在后面做。因为我们觉得有些算法在目前的阶段来说，可能还不是那么准确。
我们睿至对于 AIOps 的理解，或者对于它的定义大概是这样，AIOps是通过深度整合IT数据资源，结合运维的应用场景，这个很重要。我们不论是用算法也好，还是通过整合IT资源也好，最终手段一定要根据实际的应用场景和解决问题的场景深度集成，然后才是运用我们大数据还有机器学习的技术和手段。
然后在以上的层面以多维度的分析视图或者场景化、流程化的处理，最终给客户提供功能或页面，帮助用户快速地分析问题。
这个点是我们对于AIOps的总结，它是智能化辅助的分析平台。智能化是因为引入了大数据机器学习的一些算法，辅助是因为我们觉得当前阶段，算法可能并不是完全准确，它只能是更多的提供潜在的原因，它可能会帮助用户在众多的原因里和众多的资源里帮用户尽可能筛选颗粒度更细节的问题，帮助用户分析它潜在的问题。
这个是我们睿至对于AIOps的理解，可能大家对于它的理解都不太一样，这个我们可以后面做一些更进一步的交流。
基于这样的理解，我们整理和设计了整个AIOps的解决方案，大致是这样的场景。
首先，从整个方案来说，第一个阶段我们认为最重要的，或者说最开始的应该是对于客户这边所有数据的治理工作。因为这边我觉得这个工作对于整个AIOps方案落地来说，是比较关键的点。
大家在实际去做AIOps落地的时候，在前期我们针对于这种客户数据的治理化的工作我觉得会占到整个方案落地时长或者工作量大概有40%到50%的比例。
因为往往客户的数据首先会比较复杂，场景又会比较多变，客户的需求也不一样。之前有些客户的一些内部用的组件是标准化的，需求也比较简单，我们就可以选择比较标准化的开元的组件。有些客户对于要求比较高，有些金融客户可能有些重要数据，是要求你这些数据在抽取到平台后期处理的过程中，是不允许你有丢失的情况出现。
所以，它就会针对你抽取的工具提出更高的要求，比如会要求你在抽取之前、之后你要有一个数据校验过程，你要保证你数据的完整性，你要保证你的数据里面没有比较多的脏数据。
这些要求对于传统的数据开源工具是满足不了需求的，我们一般就会选取公司自研的处理工具去满足客户的需求。
同时当我们把客户的整体数据抽取范围定下来之后，当我们去做数据的一些格式，或者是一些方式的确认时候，往往这里面的问题也会比较多，这个后面我们会有单独的章节去针对这一块可能具体去说一下它的问题。
当我们对客户这边的数据整体做了处理之后，我们会把客户这边对应的不同类别数据抽取到数据平台上，都会打上不同的标签，后面我们会有不同的消费模块，会从上面取相应的数据，比如对数据进行后续的入库，可能有些数据我们可能会入到运维的知识图谱，这里面包含拓扑数据、关系数据，还有运维经验数据会应用到运维的知识图谱里，还有入到实时分析库里，这里面会根据用户的不同需求去入。
包括日志或者一些数据还有服务的要求，所以从服务总线入到段期汇总库还有一个流程，把单独的数据入到长周期的汇总库里，这都是需要客户不同的场景设计后边具体的流程。
当所有的数据都标准化入到库之后，我们后面就结合平台里的一些算法模块，包括分析的引擎就会从不同的库表取相应的数据做后面的数据分析还有跑模型或者验证的工作。
当结果出来之后，我们是通过智能运维的门户，把相关的数据做整体的整合，最终体现给用户去使用。
目前我们这边计划或者已经实现的一些场景，主要就是列在这边，基本上跟之前两位老师讲的场景有一些重复。比如像基于全量数据的全景视图、单指标异常预测，多指标的异常分析，还有全量数据的追踪视图，后面会给大家演示一下我们这边对于AIOps几个核心的场景。
这是我们整个方案的架构，总体来说跟刚才的图差不多，当我们把AIOps方案落地之前，其实我们要明确一下目前来说哪些客户是适合上AIOps的产品，它有哪些特征。
首先，它要有一些比较健全的监控运维流程自动化体系，这是一个前提，只有了这个前提，后续才会有源源不断的、比较丰富的、全量化的数据分析和展现。
同时还要有一定量级的历史数据，而且这个数据一定要是连续的数据，方便我们后续针对模型实现结果。
运维水平和底层数据的标准化相对比较高，有些客户可能这几年连自己也不太清楚他的一些监控的指标到底存在哪些监控系统里，他自己也不太清楚到底存在哪，包括整个业务的拓扑情况，他可能也不是很了解。
因为有些客户他想做分析和后续的内容诊断是不太清楚它的架构，所以这时候我们想去做后续的整体分析，或者问题定位，这后面会比较难。
另外一块AIOps建设大概分几类人，一类是运维专家，当我们落地的时候，运维专家是客户的主要负责人，他比较清楚运维当中的问题和难点，他可以结合难点给我们提出针对这些场景，或者问题分析的场景需求。
另外一块，我们有算法的工程师，这样可以结合运维专家或者客户提出的这样一些场景的需求，他会选择合理的算法去适配，后面根据具体的数据进行数据和算法模型的调优。
下面还有另外一种就是大数据工程师，它的决策主要是结合场景以及数据模型的算法要求提供稳定的数据来源。
除此之外，我个人觉得可能还需要一类决策去协调它们之间的工作，比如说类似于产品经理的概念，可以从产品经理的度说，把运维专家所提出的问题整体做梳理，然后转换成一些算法工程师还有大规模工程师容易理解的语义和场景，这样会更好地将运维场景做一个落地。
有了这种合适的用户环境，包括我们有了比较完整的团队，后续可能我们就要去做这种相关成本的落地。
我们AIOps整个方案落地的时候，我们会给客户建议分步骤实现，一般会分四个步骤，第一个阶段首先我们建议客户做它底层数据的治理和标准化，实际上只有你把底层数据标准化之后，上层才能更好地做数据的分析。
第二个阶段，在我们把数据标准化、结构化之后，可以提供这样的一些场景，或者多维度的视图，可以先帮助客户从实际运维的角度去提供这种多维的数据帮助他们解决一些问题。
在第三个阶段，我们是建议客户选择一些比较成熟的算法，然后运行在我们平台，比如像单指标的预测，多指标的关联，这些的算法可以逐步加入到我们的平台里。
最后的阶段就是把我们相关的算法和机器学习的模型，或者结果，然后以统一的场景结合起来给客户提供这样的一些服务。
首先我们这边结合在客户这边实际部署或者落地的时候遇到的一些问题或者难点跟大家分享，首先在第一阶段会涉及到数据的治理和标准化，这边实际上会有几个层面我们需要关注，首先就是整个数据的范围规划，另外一块相当于数据抽取方案和这种架构的选型，第三方面是数据标准化到底怎么定义，第四方面是针对于数据质量的要求，第五方面针对于数据安全的考量是什么样。
像这些问题，基本上都是我们在客户这边落地的时候，客户比较关注的一些点。
首先我们看一下数据范围规划，首先在数据规划的时候，我们会建议客户分阶段逐步选取它比较有代表性的数据纳入到平台里，这样在短时间内很难看到效果，我们建议最好从已有的业务系统里选择一到两个比较核心，或者是覆盖数据比较全的对象，把它纳入到平台里，然后从这个视角把所有相关的数据，包括数据的准化做全做好。
首先这里面我们需要确认比如规划数据范围内数据的存量方式，包括模式，还有数据的具体格式，数据到底是存在数据库里面是以数据库的方式存在，还是以文件的方式存在，基于这种调研的结果，我们还要再确定，因为你有些金融库有增量抽取，有些工具对于库表字段是有特殊要求的，你要有一些特定的字段，是要适合于做增量抽取的，如果没有的话，可能在这个过程当中，你需要做一些调整，或者对库表进行优化。
另外一块，针对于我们要抽取的库表要了解目前库表的使用频率，包括目前使用的用户，从性能角度出发，我们去判断一下库表是直接从库表抽取还是额外建立试图，避免对它原有的库表产生一些不必要的影响。好多客户不同的数据源在不同的数据里会有不同的时区概念，如果是时区的概念没有树立清楚的话，这些数据抽取过来之后，当你在前台做展现或者统一分析的时候，数据首先是不全，而且由于这种时区不同，数据有所差异性，这点需要重点看一下。
另外一点需要针对的范围是要对应的抽取模式，比如对于库表类比较高的，这种库表和数据有接口分发的，我们一般建议用户把数据先拖到特定的位置，然后再通过相应的位置上抽取，这样就是可以保证数据的及时性，减少对于原始库表的影响。
对于实时性要求不高的，可以通过接口分发的处理方式，我们允许周期的合理设置，因为有可能你的周期设得太长，数据上来比较慢，设的过短，对于表的影响也比较大。
刚才说到针对客户这边，像银行客户有非常重要的数据，客户会有一些要求，这些数据在抽取的过程当中，是不允许丢失的。首先针对于模块要求要保证高管理模式，当某个模块发生故障的时候，你是一种集群模式，它是持续运行的状态，要保证数据进库的状态。我入库之前和入库之后要有完整性的校验过程，有哪些数据丢失的，后续客户会根据这些数据进行额外的处理方式。
另外一块比较重要的就是针对数据标准化这块，首先数据标准化，我们首先要定义平台的准数据模型，这个数据模型里面就包含了我们的性能、告警、日志、变更等一些数据的标准。在这里面尤其重要的一点就是我们配置的唯一性标准，我们一般来说会以这种资源的视角把相关的数据整体作为这种整体的汇总和查看。
如果配置的唯一性标识做得不够好或者不够多的话，其他的报警、日志、变更就很难跟资源做关联。
一般来说，我们在去定义配置的时候，会有这样的一些标准放到里面，比如说像主机和配置，我们就可能是以IP作为标识。像一些数据库，包括中间件就是以IP+端口作为标识。可能像这种存储，我们会去做这种标号标识。我们需要把性能、告警、配置、日志变更等类型的数据标准，尤其是配置的唯一性标准，其他数据都要与之关联，才能整体做一些分析和展现。
中间环节的数据标准指的是比如我们从客户这边的库表上把数据抽取出来后放到数据总线上，从数据总线上入到ES库里面也规定相应的标准，我们也遇到了不少的问题，这个索引一旦定的太复杂的话，你不太利于后面日常的维护和关系。如果你定的太简单，可能存储的数据量会比较大，这样在前端做展现关联或者分析的时候，从里面取数据对于性能有很大的影响。
如果说后续我们是选用HDFS作为历史库，同时我们要去规划在HDFS上的目录和文件的存储结构，这跟我们ES上索引的要尽量一致，后面你在数据做查询，或者分析的时候，可能会比较规范或者好处理一点。
然后从数据的质量这边，我们可能要注意几点，第一个要提供数据的完整性的校验能力，这个一般客户比较关注，同时要验证同步的数据是否有重复记录的情况。
如果一旦你同步数据有重复的情况，包括后面我们做单指标的预测，还有做分析的时候，它在预测的结果，或者展现的时候，都会有一些问题或者很大的差异性。
而且你在最后排查的时候也不太好排查，尽量在做数据抽取的过程当中就要验证一下哪些数据有重复，有重复的话，一解体了，二通过一些方案来解决。
另外的问题就是最后要验证同步数据与我们预期的格式和内容是否有差异。
另外从数据安全性角度来说有两点，第一个对于客户这边比较敏感的数据进行透明处理。同时，要考虑到不同用户有种针对于不同数据权限的查看能力。
后续我们在界面上做查询或者分析的时候，是基于底层数据的安全性考虑的设置，它会有不同的划分，这样才能在界面上保证不同用户查询范围是不一样的。
第二个阶段的建设点里所关注的主要点就是因为我们底层已经有了这样一些标准化的数据，在这个界面我们可以提供一些全景的视图，我可以给用户在同一范围内查看到多维度的数据，在这一点上，我可以提供给客户同一个时间点内不同的变更日志告警或者其他数据的一些内容，帮助他去分析问题。
另外一点相当以在界面上要求会提供拖拽的方式，用户可以随时定义诊断视图，他可以快速地把核心设备、核心指标的内容放在一个图标里进行定义。
另外是对于图表的能力，比如之前在日志聚类的时候可以看到分期聚类所分析组成的具体日志明细有哪一些，基于日志的明细我可以基于日志的上下文查看相关前后发生的事件，然后逐步排查我这个事件具体的一些问题到底在哪。
另外一个点就是可以提供同一时间段内多维度的分析能力，还有基于时间点的上下文的查看能力。
这就是刚才说的基于时间点可以查看日志上下文其有其他指标数据、告警数据的能力。
第三个阶段刚才也说过了，在这里面我们的算法和模型要设计成可插拔式的，方便后续新算法的快速接入。这种算法要提供可查看的结果以及模型参数的调优能力。
然后最终我们加入到平台里的算法模型，尤其要和我们相关的产品和功能进行整合，不要看上去它就是单独的算法平台，作为单一的存在，要和场景和处理过程进行一个深度的融合，帮助客户可以很方便地使用分析出来的结果。
另外一点我们需要考虑的就是算法和模型在应用到具体场景里的时候，可能会有不同的版本，这个模型同时会有多个不同的版本在应用，这个点可能要考虑进去，否则可能后面在算法和应用这块会有一些不少的问题，这些基本上是我们在客户这边实际落地的时候遇到的一些突出的问题。
最后一个阶段就是将我们的多种算法与我们的运维场景进行闭环的设计整合，不要把相关的做法作为割裂的使用。
下面从运维场景和用户处理问题的角度出发，通过多维度的场景和算法结果结合在一起给用户提供完整的全量用户分析。
基于这些我们在客户落地的一些问题，包括客户的需求，我们这边也设定了一些客户的运维场景，这边给大家大概看一下。
第一个场景就是基于业务拓扑的跟踪视图，这个场景我们之前主要适用于银行客户的场景，这边首先我们是把客户的业务拓扑的数据，包括它的性能数据，包括告警数据，还有跟我们场景里面相关的日志数据可能比较汇总到我们平台来，通过我们底层的分析和处理能力，首先我们会把最近一个时间段内客户这边一些交易的情况做一个统计。
比如说到底交易里面失败有多少，成功的有多少，点到某一个失败数据之后可能会列出来失败交易的具体明细，点到具体的交易之后，就会自动地整合业务拓扑里面资源的数据做匹配，这里面就会告诉我这两个资源是跟这个交易流水号相关的，这时候用户就可以通过点击相关的统一数字就可以查看具体的交易日志的具体明细。
基于这些重点的交易明细，我们选择一个点击上下文的分析选项，他就可以去查看基于这条日志之前上下文的情况，可以帮助用户去分析问题失败或者是其他情况在这个之后到底出现了哪些需要用户关注的信息，帮助用户去分析一些潜在的问题。
这是我们这边第一个场景，一般是针对我们这边的精准客户。
第二个场景相对于基于机器学习的多指标关联分析，这个在我们平台里在某一天比如说某一个相关的性能指标可能产生的告警，我们会这样的视图，这个视图里首先跟你告警相关的指标一个基本的情况，包括最近的一些异常点有哪些，然后在下面，我们会列出来跟你当前告警指标相关联的其他一些相关的指标，大概有哪些。
下面多指标的列表是通过我们多指标的关联分析的算法得出来的，用户也可以通过点击不指标的选项可以查看相关指标的一些差异性，或者关联性。
在同一个图表上可以看到不同指标趋势的情况，包括在某些点上的异常是否是有一些一致的进程，通过相关曲线最早发生的异常点还有问题的一些情况，我们可以大致判断一下引起指标的一些主要的问题到底是有哪个指标的问题引起的。
同时，除了这个相关指标之外，我们可以在这个时间范围内，我们右边有一个时间点的概念，可以基于这个时间点，可以查询，这个时间点之内的相关告警或者是日志的具体情况，这样可以从其他的维度帮助用户去分析一下问题可能会在哪里。
这个在之前也说过，这里只是提供一致的原因，帮助用户提供更多的场景信息，帮助用户解决更多这样的问题。
后面的第三个场景是业务画像和故障诊断视图。
业务画像，我们客户这边一般以业务视角去做整个AIOps的场景分析，首先会有一个整体的AIOps状态情况，这边相当于整个AIOps可用性的分析，比如数据里面用到数据库，用到了中间件，当中的分析大概是什么样的，大概是什么情况。
右侧有一个分析的结果，它会把最近的时间段内整个系统资源的问题，有些是通过统计的算法，有些是通过分析的结果会列在这边，让你重点去关注。
另外这边有智能建议，智能建议的内容会包含几部分，一部分包含在这个时间段内高级别的告警，还有一些在这个时间段内我的核心资源一些核心指标有异常的变动，然后在这里面去有这样的一些提醒，让用户提前关注。
在下面这块，实际上是告警关联分析的矩阵图，相当于在下面列的，在这个时间段范围内，我这个业务系统下一些核心的模块，然后它在于时间轴的前后情况下，到底发生的一些告警的情况是什么样的。
这里面，我们的一些告警主要分成几类，主要有变更类的、异常类的、告警类的，异常类的我们通过机器研究算法，也是单指标的预测把这种异常的点得出来之后转化成告警。
这边会列出来上面选择的时间段内有哪些指标是异常的，你根据这个图可以看到，指标哪些有异常的点，通过这个选取不同的指标，你可以看到具体对应的异常指标的情况。
这边列表是跟你这边异常指标有关系的指标到底有哪些，你可以通过这边选择去做一个具体的查看。
另外一块，相对于从日志层面，我们这边刚才看到业务系统是有几个维度，一个是从整体的维度，一个是从告警的维度，还有一块是从指标的维度，下面这块就是从日志的维度。
日志的维度主要是有两块，一个是日志聚类的一块，还有日志量，日志量关注于具体哪一类的日志占某一天的时候，或者某一些时间点的时候是有一个异常突变，这样他可能是需要重点关注的，然后日志聚类，当时我们的想法是把一些具体类别的日志通过聚类的方式提示给用户，告诉他你目前哪一些日志比较多，这种像网络设备产生告警的时候，可能有一些打印出比较多的日志，这个日志最终通过聚类的方式，我们都会在前几名，排得出来。
这样，我们就可以根据聚类的内容可以去大致判断一下可能的一些问题，或者是故障的设备到底在哪。
这一块是业务画像的场景，再往下是基于我们故障诊断，上面还是从告警的列表，点到某一个告警之后，首先上面显示的是某一些告警的信息，这边是一个相关告警的列表，这块是我们通过底层的算法去跟这种告警，包括内容，包括一些时间点发生前后的一个关系，然后自动地做匹配，也就是说跟你这个事件相关的事件大概有哪些会列在这边。
然后我们这边会有一个针对于历史告警的知识库的东西，我们目前是通过两种方式，一种方式是通过手动维护，另外一种方式，通过机器学习，可以去跑一些模型。
最后相当于它会拿到这样的匹配算法，然后在当前的告警内容跟我历史库里的告警情况做匹配，它会给出匹配度排在前两名的内容给出来，用户可以参考历史之前处理的一些问题具体的情况，包括处理的过程去解决他实际现实中的问题场景。
下面这块就是以这个告警前后的时间轴，比如前五分钟，后五分钟，上下文的告警情况。
比如说这个告警发生前五分钟其他资源发生了哪些告警，它是发生的变更还是产生了异常，都可以在这个图上做整体的展现，可以帮助用户大致分析一下你的这一个点的发生大概是不是由于我前面几个点的问题造成。
下面实际上通过这种另外的维度，就是日志的维度，跟你这个告警相关的日志，我们可以通过下面的选择进行勾选，然后去查看在这个时间段内的相关资源的日志有哪些，帮助用户看一下分析潜在的问题到底在哪。
原文发布时间为：2018-10-25
本文作者：左龙贺
