金融企业的IT数据中心通常是一个是巨大的成本中心，大量设备被采购用以支持业务系统。现阶段大部分传统金融企业的IT工作依赖于人工操作，实效性低且往往伴随操作风险，随着业务的扩张，也带来了越来越繁重的运维压力。大型保险企业每年有着千亿级的业务量，数据中心管理了全国的业务系统并负责所有设备的运维工作，这对人员的调配和技能有着极高的要求。随着业务的增长，IT人员的配备已经无法满足当前运维的需要，急需向智能化和自动化转型。
为有效帮助各金融科技的运维同仁们在智能化和自动化运维项目前期规划及建设过程中，有的放矢，消除疑虑，切合自身运维工作实际现状，结合大家的关注问题和交流内容进行了4大分类总结，希望给大家有帮助。

一、 智能化运维的程度和范围，是否可以实现无人化？

二、 企业智能化运维的条件

三、 智能化运维实践过程中的困难，如何解决？

四、 智能运维的算法和应用场景

一、智能化运维的程度和范围，是否可以实现无人化？

1、智能化运维和自动化运维的关系是什么？
现在大家都在谈自动化运维和智能化运维，他们彼此之间是什么关系呢？希望专家能给与谈谈，现在很多厂商也都在说智能化运维，它们之间的分界线在哪里？

回复1：智能化运维是自动化运维的新阶段，可以说是自动化运维向无人化运维转型的必经之路，如果狭义的自动化是将人工操作的流程让机器替代去实现，那智能化就是在此基础上增加了机器的“思维”。这个“思维”来源于通过算法对大量数据的学习。

回复2、我觉得要实现智能化运维。首先要自动化运维。智能化运维的实现并不是简单依靠某一套系统就可以轻易实现的。首先要规范梳理所有的业务。实现基础运维的自动化，在自动化运维的基础上建立更多的逻辑连接。让运维系统逐步学会根据收集到的数据来进行相应的运维操作。
自动化运维只有做的规范。标准和全面之后。智能运维才会顺理成章的建立起来。并且具有一定的实用意义。

回复3、智能化运维狭义上解释是运维的智能化，现阶段运维过程中很多重复性工作可以用机器替代手工，也即日常所说的自动化运维，是需要人一个个场景去自动化，智能化是在自动化基础上更进一步，有些场景可以利用人工智能技术来解决人力所不及的，例如现在常见有的监控动态基线、告警根源定位、自动扩缩容，都利用了一些技术实现海量数据分析、操作决策，以拓展单人所难解决的问题。

回复4、这是devops和aiops的关系了，我个人觉得aiops是devops的技术层面的衍生，通俗的来说，先有devops，再有aiops，devops到aiops的转变有两方面，一个是数据，一个是算法。
1：数据。devops关注的是流程，而不是数据，devops的核心目标是为了更快更好的进行交付。所以devops是依据流水线来完成自动化的目标。它是以运维为核心，打造研发运维测试一体化为目标为核心，判断质量的标准是软件的交付能力。来说说数据，包括了日志数据，网络报文数据，数据的标准化，数据的规范化，数据的结构化只是在devops过程中不断完善自动化需求的前置条件。
2：算法是aiops的核心，有了结构化的数据，那我们就能做到数据的预测，监控的动态阈值。可以说，有了算法的加持，才是devops到aiops的转型的关键因素。在进入aiops的领域的同时，研发测也需要具备相应的理念，比如协议的规范，返回码的规范，链路的规范。基于这些，我们可以做到智能压测、现网的熔断、降级，一键诊断，还有更牛掰的故障自愈。

2、生产系统在智能化运维的自动化故障处置中，如何管控风险，人工以何种方式介入，成本最优？

回复1：对于生产系统。特别是重要生产系统。我觉得只能运维的故障处置一定要谨慎再谨慎，处置应该局限在一些重复性的。切操作结果明确的处置上。对于带有风险性的处置，人工介入我觉得是必要的。
我觉得可以是只能运维系统判定。对于简单无风险的处置可以发送通知到手机端，有风险的则发送修改申请到手机端由人工审核。

回复2、生产系统的智能化+自动化故障处理前期建议将智能化处置结果通过审批流程经过人工二次审核通过后再接入自动化的处理，经过一段时间优化，当智能化的处理结果能与专家评定基本达成一致时，运维达到很高的自愈能力时，对于重要性不高的系统可以做智能化监控接故障自愈的尝试。我们认为在很长的一段时间内，智能化运维自动化故障处置还是离不开必要的人工干预。

3、自动化运维能否解决系统代码级问题？
目前应用系统代码级的问题只能通过探针等工具手动排查，耗时长，更依赖于运维人员经验，自动化运维能否自动解决？

回复1：我们认为智能化运维是可以检测出一些代码问题和潜在风险的，但全自动化解决还是存在很多困难。代码级问题也可以在日常监控中识别到，但需要通过人工去确认和进行修改或优化。例如我们有过一些对数据库日志快照中记录的执行语句情况进行监控，通过资源开销、占比等学习向数据库使用者提供代码优化的建议，确实发现了很多需要优化的脚本，以此可以来规避一些故障发生的风险。

回复2：应用的代码级问题在生产上主要关注的是发现，题主也提到了探针，这是一种很好的方式。还有一些开发规范的约束，日志的集中分析、交易报文的分析都可以作为代码问题发现的一种手段，更好的利用运行数据，做一些监控部署，同时利用一些自动化手段对故障现场进行一些抓取为问题分析提供帮助。

回复3：我觉得很难。不同的程序员写出的系统代码也会有所不同。同样的功能实现起来也会是多种多样。即使人工。都很难去判定孰优孰劣。更别提自动运维了。况且。自动化运维对代码的修改审核还是要经过人工。否则自动化运维对系统代码随意的修改会带来更多的问题。

二、企业智能化运维的条件

1、智能运维、大数据运维对数据中心及系统规模有哪些起点要求？
智能运维，运维大数据，这些听起都蛮好。但实际落地好像总是会有一些疑问：
1：小企业的数据中心主机规模、系统规模 可能并不大，几十台，100-200 ？
小规模的企业，在向 智能运维、大数据运维方向 探索时，需要注意哪些？ 以什么样的路线来尝试跟进？
是否会因为规模小，基础数据少，造成所期望的智能、大数据、机器学习打折扣？如果要向智能靠拢，对现有的运维水平，如自动化水平，标准化水平，又有哪些要求或最佳实践？

回复1：个人的一点看法。
现在的x86架构服务器性价比很高。一个中小规模的集群架构。10-20台左右的物理主机已经可以运行很多东西了。对于中小企业。我觉得基础数据的采集，挖掘是重点。如何去收集更多的基础数据。行业数据作为分析。形成可以实际用于企业生产决策的指导性数据才是大数据和智慧运维的关键。
所以企业的信息化发展应该是业务需求产生信息化系统，多个信息系统的数据采集，汇总形成大数据根据大数据分析形成可视化的数据用作智慧生产。
至于主机的规模。并不一定要局限在物理数量。而是要看硬件资源池是否能支撑业务的发展。

回复2：感谢楼上解答。补充一些个人看法吧，小规模企业在向智能化运维的发展过程首先需要考虑企业自身运维的需要，智能运维可以降低人工操作的风险，提供更多个性化的系统画像，减少运维人力节省成本等。在进行智能运维和大数据运维探索时，建议先找到一些具有运维痛点的场景做尝试，积累经验，再以点盖面推广开来。智能运维对数据中心及系统规模并没有绝对的要求，智能运维是学习运维数据趋势，尝试画出分布并结合模型来辅助运维，对于数据的获取，数据的完整性，历史数据量这些更关注些。而大数据运维则不一样，大数据运维更倾向用现有的平台辅助自动化运维。

2、分布式存储场景中是否也可基于AIops进行一些智能运维？有什么建议？
个人比较关心分布式存储，在金融行业目前也有蛮多分布式存储集群案例，那基于存储所关心的集群存储服务故障自愈、磁盘故障的SMART预测是否也可以借鉴这套算法模型去设计？

回复1：算法本身与数据是如何存储的并无直接关系，基于分布式存储的大数据平台正是机器学习、智能运维分析的奠基石，大量、丰富、有效的数据为算法分析提供了分析的可能。磁盘故障的分析需要首先观察磁盘历史数据的趋势及分布，选择相应算法可以实现有效的预测。故障自愈部分的建设需要结合专家建议，给出特定场景下故障自愈方案才可以落地实现。

3、智能预警基于那些数据实现？
要实现告警的只能预测我理解的是通过机器学习技术基于大量历史告警数据的学习后实现对尚未触发告警的事先预测。但告警事件一般具有偶发性和不确定性，要实现告警的智能预测除了历史告警信息和基础环境信息等还需要哪些数据做聚合查询？贵行的智能化告警实现是基于哪些技术平台实现的？

回复1：通过引入改良的时间序列模型对单一指标进行预测引入机器学习的聚类算法解决与多个指标相关联的异常问题，并根据专家经验制定相应的规则抓取异常数据，以此提高异常识别的准确性。同时将告警规则与预测结果相结合也可以达到预警的效果提前获知未来可能发生的运维问题不仅为问题排查和应急处理争取到了宝贵的时间，也能避免因IT故障所导致的业务损失。

回复2：需要结合具体应用场景进行该问题的探讨。比如容量的智能预警，是基于数据库表空间大小、数据文件大小等原始数据信息的历史记录进行分析，找到原始原始数据的趋势和告警阈值，再选用合适的算法进行建模实现预警。

三、智能化运维实践过程中的困难，如何解决

1、基于机器学习的智能运维实践过程中遇到的困难有哪些?如何解决的?

回复1：困难有很多，主要分数据、算法、平台三个方面吧。
首先是数据采集方面主要是各类日志数据需要进行统一，海量的运维数据需要大量存储资源等。在做智能化算法初期，主要是缺少对历史异常数据的记录和日志数据格式的统一，通过无监督学习算法对未标注数据进行异常检测后难以判定是否有误告或者漏报的情况，短时间很难提高算法的准确性。为此我们经过了很长一段时间的累积，一方面累积适合的历史数据，另一方面也投入了很多专家人力协助我们去评定监控的效果，一点一点进行提升。
算法方面，目前对单一场景的监控、异常检测准确率还可以，但是对根因分析方面还是不是特别深入，可以将问题的链路串联起来，但是比较难以去预防故障发生。
平台方面主要涉及一套体系化的架构设计，这方面我们也充分借鉴了一些外部资源进行技术咨询，结合公司自身的运维监控体系去搭建的一套自适的平台。

回复2：机器学习的基础是数据，数据的完整性、可靠性、及时性都是需要关注的问题，也就是数据治理，这是任一个基于数据的应用都需要做的，而且可借鉴的经验相对少。二是数据标签的准确性，数据都存在各种特征点，如何做好特征标记，是让机器学习有效准确的重要约束。三是算法模型选取，多因子配置，算法效率优化都是需要解决的问题。

2、金融企业做AIOps，如何解决运维监控误报率高，以及时效性延迟?
监控和告警通常是AIOps中首先需要解决的问题，当前的告警机制大多基于单一指标的分布和阈值来判定，误报率非常高，而且在时效上具有一定的延迟性。如何解决这个 问题?大家采用什么方法？

回复1：告警本身是轻量级的程序，模型需要对大量的历史数据进行学习，如果存在时效性问题，还是要分清是由什么带来的，如果确实模型训练耗时真的非常严重，建议采用更高配置的GPU服务器。告警收敛需要结合聚类算法和专家经验进行，具体还需要结合应用场景才有意义。

回复2：1：我的理解是这样的，监控分两部分，一部分是数据的采集、清洗、格式化；一部分的阈值公式的选择。如果是数据问题，那就要保证数据过程中的准确率，如果是阈值问题，那就是告警容忍度问题了，其实这个跟aiops是没有直接关系的。
2：时效性问题，我们也曾经遇到过。说到底还是容忍度。所谓的监控只是事中和事后的，不存在事前，如有人跟你说能做到事前，那是预测，不是监控。再谈谈你的容忍度，你是想要准实时的秒级监控，还是想要分钟级监控，跟你的数据清洗方式，数据采集方式，你的技术选型有相关的。

回复3：我个人认为误报率高和时效性延迟是同一个问题，都属于报警监控指标过于单一化，监控指标粒度不够细，阈值设定过于静态化等问题。误报是由于阈值设定固定导致实际没有问题而发生了报警，时效延迟的问题属于应该监控的指标没有监控，该指标不正常导致发生问题后不能及时报警，与其关联到的其他监控指标受该指标影响在后续时间发生超阈值而报警，此时报警感觉时效滞后，实际是有的指标没得到有效监控导致的。
因此，我个人认为解决这些问题可以考虑以下几个方面:1.监控指标需要更细粒度化。2.监控阈值需要动态化。3.加入算法实现多指标的动态监控策略。

3、贵保险集团在智能运维监控平台建设的经验和遇到的坑有哪些？

回复：在做智能化算法初期，主要是缺少对历史异常数据的记录和日志数据格式的统一，通过无监督学习算法对未标注数据进行异常检测后难以判定是否有误告或者漏报的情况，短时间很难提高算法的准确性。为此我们经过了很长一段时间的累积，一方面累积适合的历史数据，另一方面也投入了很多专家人力协助我们去评定监控的效果，一点一点进行提升。

4、对于多数据源的时间不一致的数据如何处理和分析？
监控数据采集和处理方面，一般采用怎么样的数据频率、模型训练的数据量和异常检测的数据量达到多少？对于多数据源的时间不一致的数据如何处理和分析？

回复1：在数据采集的过程中，由于各个监控系统对系统日志、数据库日志和应用日志等采集的时间点和频率都不相同，针对各个监控系统的指标，我们按照较粗粒度的监控记录进行了时间段的划分，再将时间粒度较小的指标数据进行了汇总处理。模型训练的历史数据采用了近三个月的监控数据，采用当前时间点的数据通过模型判断是否为异常。

回复2：对于时间tongue要求高的业务。一般都是自建NTP服务器来进行内部业务的时间同步。至于监控数据的采集具体就要看业务的重要性，数据采集所产生的数据量等多方面的因素去综合考虑了。
我现有的业务监控对CPU 内存的资源差不多1–5分钟左右采集一次。硬盘则是20分钟左右或者更长。对于业务监控一般是一分钟或者30秒左右采集一次。因为我的业务量不大。频繁的业务检测也不会对业务造成太大的影响。

四：智能运维的算法和应用场景

1、AIOps中的常用机器学习算法都有哪些，各有什么优劣，选用时都要考虑哪些因素？
除了本活动重点探讨的Xgboost算法，在智能化运维实施过程中，还有哪些机器学习算法可以参考，各有什么优劣，选用时都要考虑哪些因素？

回复：算法选择方面首先需要按照已知的监控数据的特性和目标进行大类的划分，前期对数据的摸底和基础分析非常重要。机器学习的目的大致分为回归、分类和聚类这几种，又可以根据有无异常或其他评分标签使用有监督或者无监督的算法。算法的优劣比较较为偏重理论性，建议针对特定的场景，对比适合的算法来体会差异。

2、时间序列模型和LSTM在预测上面有哪些不同，效果对比如何?

回复：时间序列模型是比较简单的用于做时间序列类数据的回归算法，相比基于RNN神经网络的LSTM在计算复杂度上较低，可以快速学习变化的数据，一般适合用于单指标的预测分析。LSTM经过训练后在大部分数据预测的准确度上要优于时间序列模型，且不会有滞后性。具体选择算法要结合实际情况去综合考虑。

3、AIOps中对故障推断预测的逻辑具体是如何实现的？
文章提到整个故障分析是基于学习模型的，具体学习模型的训练集数据来源是什么，是否真实用到了AI的训练推断框架，训练是对历史的故障分析，还是来源于主观的逻辑判断对历史故障问题的总结。

回复：整个故障分析采用的数据范围很广，有运行监控数据，应用日志数据，交易数据，网络安全，数据库日志等。涉及的算法范围也很广，如时间序列算法，孤立森林、聚类算法等。训练有基于历史的故障数据，以及专家对疑似故障数据的分析判断。

4、基于互联网电商应用监控的动态阈值算法选型？
我们业务链路监控是基于日志的清洗，数据聚合，数据分析来达到目的。监控的指标有2W+，包括了耗时类的统计，如平均耗时，峰值耗时，成功率等指标。
每天单个接口的交互达到亿级别，所以清洗后的接口耗时也是亿级，在不考虑营销活动，大促场景的情况下，样本数据相对固定，时间也相对平缓，基于此类样本数据，我们可以通过聚类算法计算出数据趋势和动态阈值。如果遇到大级别营销活动，在活动预热时，会产生大量的毛刺数据，对数据的预测产生比较大的影响，请问下在这种场景下，有没有更好的算法来去除毛刺数据，或者计算毛刺数据的范围？

回复：可以将时间分段进行学习，例如将历史数据划分为常规数据和活动数据。对于预热时的毛刺数据，可以通过寻找离群点的一些方法，例如局部异常因子、孤立森林等先对数据进行分类标注，在做预测时将这部分数据剔除。

5、故障根源诊断与根因定位的分析方法是什么？
在大量的告警和异常检测结果中如何找到根源故障 如何借助算法提供的模型或规律辅助判断故障根本原因 专家经验或规则和其他运维数据如何与算法结合准确定位根源

回复：在初期阶段，对于未标注的数据，我们通过无监督学习算法对疑似异常数据进行识别，并将结果反馈给运维专家进行二次经验判定，来调整告警的准确性。在长期的项目中，将专家在日常运维中发现的异常数据纳入标注的数据池中，通过有监督的机器学习算法训练。将多种异常检测的算法进行集成来提高告警的准确性。具体实现需要结合场景、算法、专家判断综合探索，无法一概而论。

6、机器学习在保险行业主要运用于哪些场景?

回复：除了智能运维，涉及业务的还有团险定价、险种推荐、智能核保和反欺诈等。

7、基于机器学习如何实现大量告警情况下精准的故障定位及根因分析？
在大量复杂运维告警出现时，如何基于机器学习实现大量告警信息的归类压缩，如何快速精准的进行故障定位，分析根因？

回复1：计算机报警种类繁，报警的厂商不同。日志格式，内容还有代码也都没有一个统一标准。想要通过机器学习实现精准的故障定位我觉得还有很长的路要走。至少要所有的厂商都开放自己的日志代码。基本实现统一的日志格式。以目前的技术来看。我觉得机器学习只能是帮助运维去简化和梳理日志。具体的故障判断和原因分析还是需要依靠人的经验。

回复2：关于故障定位，可以分为纵向与横向的问题追溯。横向上通过ESB对各服务模块调用关系进行梳理，建立服务调用关系图谱；纵向上结合系统运行信息分析，找出关联性能指标中潜在的问题，如CPU使用率，内存空间等。当故障发生时，由每个模块产生的智能监控告警结合图谱调用关系链帮助找出故障的源头。

8、智能化运维能够解决哪些生产中的实际问题？
智能化运维具体能够实现哪些功能？已经实现的和未来准备实现的场景。如预测web服务器不足需要做横向扩容。
如果智能化运维预测到风险，如何规避风险？靠人工处理还是通过与自动化的联动实现自动风险规避？

回复1：我觉得智能化运维将来能实现的应该是帮助运维人员日志分析。简化定位故障的范围，简化重复性的劳动比如代码更新，修改。或者在一定的阀值范围内。按照设定的任务对系统资源或者业务进行调整，简单的说我觉得智能化运维要像一个多功能的工具。去帮助和简化人的运维。而不是代替人的运维。毕竟IT系统的业务和内容太过复杂。即使经验丰富的工程师。面对一个故障处理之前都要小心在小心。做足各种备份和应急预案。才会去尝试进行故障的处理。

回复2：通过业务数据、运维数据均可以做异常检测与告警、根因定位和容量预测等；对于重要性较高的系统，需要人工干预进行二次审核，对于重要性一般的，可以自动化联动。