AIOPS的概念最早是由Gartner提出，国内各个行业都在进行尝试用AI解决运维上的问题，但是国内在理解AIOPS时，严重高估了其能力，在笔者看来AI+OPS中的AI是针对OPS的修饰词，即智能化的运维，重头戏还是在运维上，只有对运维业务充分理解的基础上，才能够通过机器学习的方法来解决效率和成本问题。
带着这样的想法，笔者花了整整一年的时间深度研究了serviceNow、pagerDuty、bigPanda、Moogsoft、splunk、BMC Helix AIOps等国际一线厂商的产品，这里面包括了监控、统一告警管理平台、自动化分析及处置工具平台、ITSM、cmdb等产品，所得到的结论充分证明AIOPS不是一个具体的产品，而是通过AI对运维这个行业进行赋能，AI对运维的赋能是场景化的并且是面向不同的领域的，不同的厂商由于能力的问题其面向的AIOps领域会有所不同，如：
| 厂商 | 产品 | 领域 |
| cisco | appDynamics | APM |
| Datadog | Datadog APM | APM |
| Dynatrace | Dynatrace | APM,ITIM |
| Moogsoft | Moogsoft | Event Management，国内用户常说的统一告警平台 |
| bigPanda | bigPanda | Event Management，国内用户常说的统一告警平台 |
| serviceNow | 多款产品 | itsm,itim,event menagement,automation |
| PagerDuty | PagerDuty | Event Management,automation |
国内厂商和客户在实施AIOps时，非常容易被一些“专家”所误导，在实施过程中过度的迷恋算法，所以在这里我根据自己多年AI产品的研发交付经验以及国外厂商的产品调研佐证，总结了AIOps落地的五大支柱（如图所示）：
数据
运维有海量的数据，任何算法在解决问题时，总是从海量的数据中去试图通过统计学、机器学习、深度学习等算法找到其中的模式，如，我们进行某个交易的异常检测，通常会拿指标的3个月左右的数据来学习其中的指标运维周期性模式，并根据这种周期性模式预测未来短时间内的指标正常趋势值，当新的真实指标数据进来时，会同正常的模式所产生的趋势值进行比较，以生成告警事件。企业实现AIOps首先面临并解决以下几个数据问题：
第一个问题即是数据从哪里来，包括哪些数据？如何获取？这里的数据主要包括但不限于指标、日志、告警、变更、配置及配置依赖等。针对不同算法场景的需求，对数据的获取要求也不一样，如在监控工具中实现异常检测，则需要采集指标数据，
第二个问题即是这些数据都是相互孤立的？在建设AIOps有时进行疑似根因分析，我们需要从多个数据源关联告警发生时的数据 ，以获取到完成的告警上下文数据提供给算法和人工来进行判断使用。
第三个问题是数据质量？比如，我们的监控系统产生的原始告警只有一个IP地址，如果通过IP地址，我们需要再反向查找对应的IT实体ID是谁，这样才能通过CMDB来丰富告警的上下文信息，加速排障过程。如，获取该IT实体对应的运维管理员，才是在进行告警事件响应时主要专家响应者之一，如果没有好的数据质量，我们在这些信息的获取、查找会将会大大延长MTTR的指标。
第四个问题是如何进行高效实时的分析？要求在获取实时数据后，必须马上进入分析，以帮助运维工程师用最短的时间获取想要的告警上下文数据或直接推荐疑似根因，以帮助快速进行决策，并降低MTTR。
所以数据成为AIOps必不可少的一大支柱。
专家经验
汉朝郑玄在其《周易注》中记载：“古者无文字，结绳为约，事大，大结其绳，事小，小结其绳。”这是一种最古老、最简单的记录事件的方法，通过这种方式使发生的事件得以记录，并且将这些知识得以有效地传承下来。知识得到传承之后，我们就可以很快地对事件做出判断，如“燕子低飞，天气阴云密布，代表马上要下雨了”，人们可以及早对这样的事件去收拾衣物。
这是早期的专家经验，正是因为中华5000年文明才诞生了四大发明，使这种专家经验成为历史传承的主要表现。
专家经验是非常重要的知识财产，GOOGLE SRE中描述历史上已经出现的故障，再次出现的概率高达85%，这个数字我同样也同国内四大行之一科技能力最强的银行数据中心近百位专家进行过访谈，他们给出的数据范围约在70%-80%之间。
专家经验如果能够成为日常运维的一部分，是不是可以有效地节省对领域专家的依赖，让他们可以更好地去完成其它更有意义的工作，答案是肯定的：这在GOOGLE SRE 还有美国一些AIOPS厂商中已经完全实现，笔者对SRE做过充分的研究，其最大的不同是SRE人员拥有比普通运维人员开发运维工具的能力，他们崇尚通过开发自动化的工具来解决运维上的问题，并最大化的解放领域专家投身更有创造性的工作上。
经验究竟如何获取，如果您是专业的运维人员，相信一定非常了解ITIL的告警后审计过程，在AIOPS的工具产品中加强事件后的审计功能，并逐步将这些针对事件后审计而总结的专家经验知识逐步转化为自动化修复策略，相信您可以为组织积累丰富的专家经验并大大缩短MTTR。
自动化
上一个章节介绍了专家经验，专家经验如果可以规则化+自动化进行处理+自动化验证告警处理后是否正常这种模式来进行，则可以有效地：
节省沟通成本
节省升级专家成本
节省人工输入指令的时间成本
降低人工输入指令出错的成本
通过实施服务编排和告警驱动的工作流来推动业务敏捷性和数字创新
加快告警处理的效率，并最终降低MTTR...
不论是传统的运维还是基于AIOps的运维，我们日常的数据中心管理中有很多的现实场景都离不开自动化：
事件（incidents）驱动的自动化：
当数据中心发生问题时，可以通过自动化平台的某个触发器装置（可以是基于时间的，本例是基于事件的状态变动的，如事件处于触发状态）自动对事件进行判断是否属于之前发生的的事件（专家经验的落地），通常这个触发器会是一系列的条件表达式对事件进行判断。
如果满足，则会触发事件的自动修复（如数据库主机的自动重启，集群问题则可能是上千台主机，为了保障业务的正常运行，通过自动化在不影响业务的情况下，主动对一台或多台主机进行逐台重启操作）。
启动完成后，再触发自动化的健康检查，收集集群的运行日志信息。
系统自动化针对日志信息判断事件是否得到解决，如果得到解决则自动关闭当前事件。
最后，通过可视化的界面，SRE或运维工程师，可以人工审核事件情况。
弹性扩缩容：云资源如果能够做到像自来水一样，使用时付费，则可以大大节约企业的IT成本，这也是云计算诞生的主要因素之后，通过智能的AI算法可以对业务进行预测以判断未来一小时或几小时的业务高峰和低谷，算法动态的告知自动化要释放和申请资源，这样可以按小时级的成本控制来进行管理。
资源供应：在云资源和本地的计算、网络和存储等资源都是需要进行申请的，一旦申请成功，需要人按申请的要求去操作相应的资源，并进行邮件回复给申请人。而更理想的方式是申请一旦得到批准，即会启动自动化策略，自动化的分配计算、网络和存储资源，并自动化按相应的密码策略生成相关信息，自动化邮件通知申请人，申请人一旦打开邮件，自动化系统又可以自动化地进行申请单的关闭操作。
自动化安全策略检查：定期自动化地触发密码策略的安全检查，以自动化邮件提醒用户密码过期或过于简单，需要更换。
另外，还包括devOps的CI/CD、变更后发生告警的自动回滚等，诸如此类的自动化示例数不胜数...
云计算时代&人工智能时代是时候大胆地拥抱自动化了。自动化究竟应该包括一些什么样的组件，如何设计面向整个数据中心的自动化平台，这是一个非常巨大的问题，笔者后续出版的内容会陆续进行介绍。
AI算法
AI算法之所以放到5大支柱的最后，最主要的原因是目前AI算法部分在运维工具产品上还没有发挥主导性的作用，主要还是通过其余4大支柱来实现AIOPS。
人工智能技术的延生确实让人们打开了脑洞，在各行各业进行了大量成功的应用，即不要迷信也不要抵制，在运维领域近几年也被各厂商和投资人不断地吹捧，甚至有的厂商和客户在认知上产生了一些错误：
重AI轻运维本质：这是本文开头我们所提到的严重问题，AIOps的本质是ops，而AI是一种解决ops问题的方法，对于AIOps，AI则成为一个形容词，即智能化的运维。AIOps首先是运维中某个领域的运维工具产品，之后才是通过AI的手段优化该领域中的某些应用场景，使之达到智能化，并降本增效。
有监督和无监督算法：不考虑应用场景，一些不了解运维本质的“专家”不断吹嘘在AIOps中必须应用无监督算法，因为他们认为运维的数据是庞大的，必须应用无监督算法。但实际情况还要区分哪些场景适用有监督，哪些适用无监督算法，如：在告警处置场景的疑似根因推荐，我们就非常适合用有监督的算法来解决问题，因为告警处置完成之后，按ITIL的流程是要对告警后进行总结和分析的，在该阶段对当前的告警需要说明当前的问题是什么原因造成的，相当于是在做数据标注的过程。
算法一定比人强：要客观的看待这件事情，今天我同一个技术大牛沟通我觉得他说的场景非常有道理，在只管理一台服务器的场景下，运维人实时盯着曲线，一定会达到近100%的准备率，而AI可能只有80%，但是如果把一台服务器变成100台、1000台、十万台的情况下，人的准备率可能会急剧降低到50%以下，甚至会需要庞大运维人员团队，而AI其准确率会一直稳定在80%，所以，这就是AI的本质：解决的是成本和效率问题。
算法结果评价标准：同任何软件产品一样，算法出来的结果也是要有评价标准的，否则就变成为了上算法而上算法、没有办法评价、没有办法验收、只能听算法人员一面之词，听起来貌似很有道理，但是自己又没有办法反驳。针对算法结果，没有业务上合理的评价标准都是耍流氓。算法评价在笔者drbool公众号的一篇文章《智能运维算法质量评估》中有详细说明，感兴趣的同学可以看一下。
滥用算法：在不考虑数据规模、应用场景、数据特点的情况下，胡乱套用算法，某大型银行数据中心不到800人，每个运维团队都有自己清晰的分工处理来自不同业务系统、AP主机、DB主机和网络的相关告警，职责分工明确且清晰。以DB运维团队为例整个团队的人员规模不过几十人左右，算法“专家”建议使用推荐引擎算法来推荐在运维过程中出现告警时应该推荐他们看什么信息，且不说只有几十人能产生什么点击量行为，还要费劲去埋点、采集这些数据。而实际情况是DB主机对上为AP主机提供数据服务，对下使用存储设备的存储服务，DBA只关注上下层的信息就可以完成对告警的准确判断。
算法主导AIOPS产品：这是大忌，主要原因在于AIOps这个单词大家把主体想象成了AI，所以导致部分企业尤其是学术圈出来的没有实践经验的就将算法人员当成了主导，要么去同客户谈需求，成就了软件项目的需求分析师；要么闷头在公司里思考产品的未来，具备了产品经理助理或初级产品经理的能力，结果主导实现了一批可以到客户现场一起做研究的想法，却不能正式投产应用的算法；
...
针对算法，我们来看一下在运维的不同领域应用场景示例，来指导大家在建AIOPS系统时建立哪些靠谱的算法场景，如：
监控工具领域：通过异常检测相关的算法来识别业务行过程中的指标异常（如交易的响应时间），来进行告警。
在统一告警管理平台领域：
通过智能的算法识别告警之间的关系，从而进行告警降噪目的。
通过学习历史上运维专家对告警的处理，自动识别疑似根因，并进行推荐。
查找类似告警以加快告警解决。
在云计算领域：通过预测法识别业务未来几小时范围内的波动情况，弹性进行扩缩容，从而有效降低成本。
在chatOps领域：通过NLP算法及其它相关算法的组合，有效地根据数据中心的上下文环境识别用户的交谈意图，快速做出回复。
...
可视化
可视化非常普遍，是在AIOPS中必不可少的组件之一，主要应用场景：
获取的指标、日志等数据需要可视化展示
AI算法分析的结果需要可视化展示
产生的告警，需要通过可视化展示告警的上下文数据，以提供给运维人员更快的见解
告警处置的过程记录，需要可视化来进行管理和审计时查看
疑似根因推荐的结果，需要上下文信息来辅助决策
．．．
总结：五大支柱相互协作
AIOPS的五大支柱是相互协作的，数据层通过各种集成将采集到的数据进行清洗、标准化之后的高质量数据送给大脑（即专家经验+算法）来进行处理、判断并给出结论和执行动作然后下令给自动化平台执行相应的动作。
在动作执行的每个阶段都有数据产生，人可以通过可视化平台去看数据获取的情况、大脑运转分析的情况、自动化平台执行的日志情况，以达到整个AIOPS运行透明且可视化。
数据、专家经验、自动化、可视化是AIOPS五大支柱中最核心的部分，而算法目前来看在AIOPS领域还未起到支柱型作用，更多的属于噱头大过实际应用。期望未来算法能够在AIOPS领域有更实际的突破。
关于布博士
资深的运维领域产品专家，对AIOps有深入的理解，曾参与多家银行AIOps实践，对国际主流AIOps厂商产品有深入理解。
全球第一个提出暗网发现及溯源的解决方案专家，著有《基于网络样本流量分析完成对暗网发现及溯源》，并得到公安部第三研究所、中科院计算所、烽火科技等安全领域多名评审专家一致评审通过。
