谈AIOps基础从自动化运维到智能化运维

　　今天准备谈下AIOps的内容，在我前面已经写过多篇文章谈DevOps研发运维一体化方面的内容，原来也一直看到AIOps的概念，潜意识里面理解是DevOps里面的一个子内容分解。而实际我们看到AIOps和DevOps没有必然的联系。
　　对于AIOps简单来说就是智能化运维，和你是否实施DevOps和持续集成交付没有任何必然的联系。也就是说你没有实施DevOps，也可以实施AIOps智能化运维。在DevOps里面的运维和技术运营部分，也没有要求一定要实现到智能化程度。对AIOps智能化运维的基础理解
　　图片来自网络
　　AIOps 自从 Gartner 于2016年提出至今已有一段时间，虽然在顶级互联网及电信企业，已有较多落地，但至今仍无基于生产实践的理论体系及实施指南。AIOps，即 Artificial Intelligence for IT Operations，智能运维，将人工智能应用于运维领域，基于已有的运维数据（日志、监控信息、应用信息等），通过机器学习的方式来进一步解决自动化运维没办法解决的问题。
　　从整个IT运维的发展，我们可以看到早期更多的是通过运维人员人工来完成，在人工阶段主要又做了两个方面的重要工作。其一是基于ITIL的运维流程的规范化，标准化和流程化其二是对于日常可重复的运维操作的脚本化和自动化执行
　　以上两个动作只能够划入到运维的第一个阶段，因为在很早以前基本就已经实现。在这个阶段完成后我们进入到自动化运维阶段。
　　对于自动化运维阶段，我的核心理解是：
　　自动化运维是基于预先定义好的规则，通过实时的资源和应用性能采集后进行计算，当满足某种规则的时候自动触发相应的可重复执行的运维脚本。
　　也就是说自动化运维解决了基于规则的运维流程自动化问题。但是里面还有一个重点没有解决，就是规则本身仍然需要人工自动定义进去。如果已有的规则无法覆盖新出现的运维问题，那我们还得不断的扩展和完善人工定义规则，并进行手工的规则定义和配置。
　　也正是这个原因，出现智能化运维就有必要的，对于智能化运维可以理解为：
　　智能化运维是在自动化运维基础上，具备了基于人工智能和深度学习等算法，实现规则的自动生成，已有规则的自适应调整的自动化运维。
　　也就是说智能化运维必须具备规则自生成，自适应调整能力，否则都不能叫做智能化运维，而最多算做自动化运维。而要做到这点，即涉及到AI人工智能里面的机器学习，深度学习方面的内容，如聚类算法，神经网络，预测模型等。
　　图片来自网络
　　AIOps 是运维的发展必然，是自动化运维的下一个发展阶段。
　　Gartner 相关报告预测 AIOps 的全球部署率将从2017年的10%增加到2020年的50%。其应用行业，除了互联网以外，还包括高性能计算、电信、金融、电力网络、物联网、 医疗网络和设备、航空航天、军用设备及网络等领域。对AIOps架构框架比较
　　在了解了AIOps智能化运维基础后，我们先来看下网上能够找到的一些对AIOps整体架构框架的一些图进行对比分析和说明。
　　图片来自网络
　　该图为华为在18年的GOPS运维大会上讲到的一张AIOps整体架构图。
　　最左边列举了我们的数据来源，比如：服务器大家常用的zabbix、HCW（华为自研的采集）、业务侧数据（包括端侧和云侧的数据）还有第三方（如CDN厂商提供的边缘节点数据），这些数据源有实时采集推送，也有非实时的。右侧是运维大数据，一共分为 5层：即数据分析处理层，数据资产层，数据服务能力层，大数据应用服务层，包括了业务监控、日志检索、异常检测、故障诊断等都是这层的能力。
　　从这个图可以看到，整体AIOps架构和我们经常说的大数据平台架构相当类似，我们完全可以理解为是基于自动化运维和智能化运维场景来构建的一个大数据平台。
　　对于类似资源的CPU，内存，JVM等性能数据采集，日志数据采集当然是海量大数据，构建大数据平台并进行分布式存储是必要的，这是进行运维分析和决策的基础。但是这种的难点在于我们的学习模型，分析和算法模型。
　　这个内容实际上在架构图里面的运维算法库这个地方，但是没有展开。
　　对于大数据分析应用这块，整个图比较散，而且智能化分析决策类功能和我们常说的系统运维功能，监控功能是合并在一起的。
　　那么哪些可以算做是智能化分析决策类应用，个人理解应该包括：性能监控预警和自适应调整故障诊断和自动恢复性能趋势分析和自扩展问题诊断和关键因子分析异常告警等趋势和辅助决策分析
　　可能还有其它方面，但是以上实际上是智能化运维最关键的内容。
　　下图是携程Ops大会分享的一个架构图：
　　图片来自网络
　　在这个图里面我们可以看到给出了运维AI平台，该平台基于机器学习和深度学习构建。同时在能力层增加了面向AIOps的算法集，包括了类似聚类，回归，降维，分类等关键算法。
　　同时在解决方案层可以看到关键的还是两个方面的内容。其一是故障发现，定位和解决。其二是容量优化和弹性扩容。即对于故障如前面所说，不是简单的发现故障，而是需要你快速的进行故障定位，并根据定位的故障。
　　图片来自网络
　　在传统的运维里面问题发现可能是系统，但是最终的问题分析定义，问题决策和问题解决则是需要人工进行处理。而到了AIOps阶段，我们希望的是问题分析和决策全部由电脑自建来完成，我们可以预先配置一些规则库，知识库，但是这个知识库本身也要做到能够基于真实的运维场景进行自适应学习和调整，而不是一成不变。
　　问题决策和处理分离，智能运维可以是全部由软件自己来完成，也可以是软件分析决策后给出几种解决问题的分支，然后由人工判断后再来进行解决。
　　举个简单的例子，比如当发现了明显的性能问题后，软件可以给出两个决策路径。其一是进行资源自动化扩展其二是对某几个关键API接口进行限流
　　那么运维人员只需要选择具体采用哪个具体的分支即可。
　　在2018年发布的《企业级 AIOps 实施建议》白皮书给出了一个AIOps平台能力体系。
　　图片来自网络
　　在该图里面也可以看到，智能化运维在传统的自动化运维平台和功能的基础上，增加了底层的大数据存储，处理和分析技术平台能力。同时增加了AI算法库，AI建模分析能力。
　　图片来自网络
　　也就是说当前的AIOps可以为：
　　AIOps = 自动化运维 + 大数据平台 + AI算法和建模
　　如果一个智能化运维平台能够很好的融合上面三个方面的内容，那么基本能够算做是一个智能化运维平台。因此在谈智能化运维前，还是先谈下自动化运维平台。自动化运维平台分析
　　在项目上线完成后，业务系统或平台自然就转入了运维管控期，而在运维期两个重点，一个就是运维流程的标准化和规范化，另外一个就是运维工作本身的自动化。对于运维自动化将成为后续我重点关注的一个内容，因为本身我们DevOps实践也需要这方面的积累。
　　对于运维自动化，传统我们可能是编写自动化的运维脚本，然后是手工或定时的执行运维脚本完成整个自动化执行过程和运维例行检查。而今天要谈自动化运维平台，里面一个重点就是基于我们面对的运维场景，如何将运维操作或任务进行细粒度分解，然后再对运维操作进行组合和编排。
　　为何要这样做？
　　重点就是将整个运维流程可视化掉，能够看到分步骤分任务的执行，并快速定位执行中问题。
　　蓝鲸开源标准运维平台
　　https://gitee.com/Tencent-BlueKing/bk-sops
　　蓝鲸标准运维平台是拥有可视化的图形界面，并进行任务流程编排和执行的系统。
　　标准运维有两大核心服务。
　　一个是调度编排服务：基于蓝鲸集成平台服务总线（ESB）对接企业内部各个系统API的能力，将企业内部多系统间的工作整合到一个流程模版中，实现一键自动化调度。另一个是自助化服务：标准运维通过与蓝鲸集成平台深度整合，为用户提供了＂轻应用＂和＂职能化＂功能，让用户可以将业务日常的运维工作交给产品人员执行，实现业务的发布、变更等工作自助化。
　　标准运维后台使用 Python 作为开发语言，使用 Django 开发框架；前端使用 Vue 开发页面，使用 jQuery 开发标准插件，通过配置式的开发模式， 不断降低用户开发标准插件前端表单的难度。
　　图片来自网络
　　标准运维的产品结构如图所示，接入层包含权限控制、API接口和数据统计等；任务管理层主要对应标准运维的任务编排和任务控制功能，任务编排包含基础单元标准插件框架和标准插件展示层，任务控制包括创建任务实例的模板校验和参数校验，以及任务实例执行时给用户提供的操作接口如暂停、继续、撤销任务等；流程引擎负责解析上层的任务实例，映射节点标准插件对应的服务，并通过底层的蓝鲸服务总线（ESB）调用其他系统的API（如配置平台的创建集群，作业平台的快速执行脚本等），流程引擎还包括了具体的任务执行引擎和流程控制、上下文管理等模块。
　　注意，这里的整个架构涉及实际和SOA的思想很类型，下面是可以复用的原子即服务API接口，上层运维流程基于服务编排和流程编排的思路对底层服务进行组合和编排完成一个完整的运维流程，而实际我们在做服务编排的时候完全可以参考该思路实现。
　　该标准运维平台的功能特点描述如下：多元接入支持：标准运维对接了蓝鲸通知、作业平台、配置平台等服务可视化流程编排：通过拖拽方式组合标准插件节点到一个流程模板。多种流程模式：支持标准插件节点的串行、并行，支持子流程参数引擎：支持参数共享，支持参数替换。可交互的任务执行：任务执行中可以随时暂停、继续、撤销，节点失败后可以重试、跳过。通用权限管理：通过配置平台同步业务角色，支持流程模板的使用权限控制。插件开发：作为官方标准插件库提供服务
　　该标准运维平台基本是开源的，有时间的可以下载并安装验证，通过前面的介绍我们也可以看到是一个很灵活并可扩展的运维管理平台。对于我们日常的应用程序部署，应用日常巡检，定时的数据采集，数据库操作的Job编排等完全都可以用该管理平台来进行管理，并做到端到端运维流程的可视化监控。
　　我们举例来说下一个简单额应用部署功能，即涉及到服务器集群服务停止，已有部署包备份，关键数据库数据备份，新应用部署，服务重启，重启后验证检查等拆分操作步骤。而我们既可以将这些操作步骤组合并可视化涉及在一个标准的产品版本发布流程里面进行管理和执行。这些都将大大提升我们运维管理的标准化和效率。
　　开源运维自动化平台 OpenDevops
　　OpenDevops是一款为用户提供企业多混合云、自动化运维、完全开源的云管理平台。前端基于Vue iview开发、为用户提供友好的操作界面，增强用户体验。后端基于Python Tornado开发，其优势为轻量、简洁清晰、异步非阻塞。
　　OpenDevops开源多云管理平台将为用户提供多功能：ITSM、基于RBAC权限系统、Web Terminnal登陆日志审计、录像回放、强大的作业调度系统、CMDB、监控报警系统、DNS管理、配置中心等。
　　产品介绍:
　　https://www.oschina.net/p/opendevops
　　从基本的文档介绍材料看，其很好的实现的企业多混合云的管理，同时实现关键的IT资产，资源管理，基本的ITSM里面的配置管理。同时实现任务管理和作业调度，支持各类脚本，ssh命令的接入和配置。但是没有类似蓝鲸标准运维平台提供可视化的作业编排能力。
　　从产品介绍来看，该平台由一个小团队维护持续在进行版本迭代，采用微服务的理念构建，模块化开发，目前已有资产管理、定时任务、任务调度、配置中心、域名管理、运维工具几大模块，支持持续集成、持续部署、代码审查、数据库审核与优化建议等众多功能，覆盖大部分的运维场景。因此也纳入我们后续的验证和试用计划中。
　　对于自动化运维平台，首先还是要谈下其基础是运维流程的标准化，然后才是整个运维过程的自动化，整个运维自动化最早是基于ITSM规范或ITIL规范，在DevOps和微服务架构下，还需要和DevOps最佳实践所结合。
　　简单的说，IT运维自动化是指基于流程化的框架，将事件与IT流程相关联，一旦被监控系统发生性能超标或宕机，会触发相关事件以及事先定义好的流程，可自动启动故障响应和恢复机制。自动化工作平台还可帮助IT运维人员完成日常的重复性工作(如备份、杀毒等)，提高IT运维效率。同时，IT运维的自动化还要求能够预测故障、在故障发生前能够报警，让IT运维人员把故障消除在发生前，将所产生损失减到最低。
　　而实际对于自动化运维可以分为以下三个大部分的内容运维流程的自动化：包括了巡检，事件问题管理，变更管理，版本发布等运维配置库：最基本的运维配置管理库，从物理资源到逻辑资源到源代码库到服务库运维监控的自动化：自动化数据采集，监控预警，性能分析，后续触发的自动管控操作
　　对于运维流程最终往往都涉及到运维操作，运维操作最终结果涉及到配置库信息的变更，而对于运维监控本身有可能发现运维类问题并启动相应的运维流程进行处理。
　　对于自动化运维，后续重点关注运维派这个网站，这个网站有很多运维方面的文章可以参考，包括了运维管理流程，DevOps运维实践等，可以重点参考。
　　优维科技自动化运维平台
　　http://www.yunweipai.com/
　　下图是优维科技给出的自动化运维平台的一个总体功能架构，基本覆盖了自动化运维工作常见的各个方面，而我们当前运维本身也就是涉及到版本的发布部署，日常巡检，资源和中间件监控，安全和补丁等各个方面，这些方面都需要去考虑自动化。
　　图片来自网络
　　优维自动化运维平台解决方案是优维一站式DevOps及运维解决方案中的独立功能模块，既能全平台部署又可单独落地。优维自动化运维平台解决方案不同于传统的单一业务自动化解决方案，是真正面向企业运维部门提供平台+场景能力的解决方案。方案融合了优维科技数年的海量互联网运维沉淀及多年传统企业落地经验，依托于原子化作业平台和高度可定制服务编排平台。
　　对于自动化运维，包括当前的开源或商业软件来看，实际上包括两个方面的内容。资源和IT网络管理软件：包括了类似zabbix资源监控，也包括APM应用性能监控。运维流程自动化管理平台：ITSM软件进一步和DevOps持续集成
　　对于最终的运维操作自动化，我们很多时候会写成ssh脚本或py脚本，然后配置定时任务自动执行，而类似上篇谈到的蓝鲸自动化运维平台可以很好的去实现运维各种操作的流程编排和可视化，这也是相对有用的一个功能，当前前提还是应该首先将我们手里面的运维各项操作先进行分解，然后通过脚本实现完全的自动化操作。
　　在自动化运维里面，我们会很强调工具链这个词，即要实现整个运维自动化涉及到诸多的流程协同，底层更是涉及到诸多的工具协同，而这些工具本身都是单一的完成一种类型的操作任务，如果这些工具间没有协同和集成起来，那么将直接导致我们整个运维过程是存在隔离和断点的，也更加谈不上自动化运维。因此DevOps实践过程中完成了一个关键的重点就是为了实现持续集成和交付，完成了底层工具链的一个集成。
　　但是在产品或系统从建设期转到了运维期后，进入到第二个关键集成，即对于IT运维流程和软件产品变更管理和持续交付之间的集成，这两者如果集成协同不好，也同样无法实现自动化运维。DevOps谈研发运维一体化，实际上就是要实现研发的产品在持续交付过程中本身就具备可运维可管理属性，可运维属性应该是贯彻整个持续交付完整生命周期。智能运维场景1-故障定位和解决
　　图片来自网络
　　首先我们要说明下这里谈到的故障和解决是指能够通过软件去解决的故障。如果一个IT基础架构本身单点下的服务器或磁盘损坏，那么这种故障无法恢复。或者说一个HA架构下，两台机器同时出现故障导致宕机，这种故障也不是软件本身能够解决的。
　　对于软件类故障我们经常看到的有数据库的表空间满，没有及时清理导致的数据库不可用应用中间件的JVM内存溢出，导致应用或服务无法访问出现超时整体应用前端访问缓慢而不可用
　　以上都是一些场景的软件类故障，这些故障导致的后果仍然是服务不可用或者中断。一些好的监控系统可以做到就是JVM内存持续超过某个阈值，或者说数据库表空间超过多少后给出告警，但是最终还是需要人工上去处理。
　　而对于AIOps更加希望做到的就是自己发现故障或潜在的故障风险并去解决。
　　我们拿JVM内存溢出来举例。
　　我们原来做法是手工设定一个规则，比如JVM内存持续超过80%而且1分钟以上，我们就对节点进行重启操作，以避免JVM内存溢出。但是这种规则本身存在问题，其一是可能有一个大数据访问请求刚好运行2分钟，那么就导致我们出现误判。或是是在1分钟以内，JVM已经快速上升并出现内存溢出而进行多节点故障漂移，我们还没来得及重启。
　　那么对AIOps我们希望的就是软件自己能够去分析和学习究竟JVM内存保持在要给什么样的状态会对整个集群高可用操作影响，究竟应该在哪个时点进行重启。究竟是应该单节点重启，还是多节点重启。以上问题AIOps都应该学习后给出最佳处理方式。
　　不断的自我学习并调整规则是AIOps系统的一个关键能力。
　　比如，第一次处理你可能是对故障请求进行漂移，将故障转移到其它可用集群节点。但是发现漂移后导致其它节点也陆续出故障，而导致整个集群全部挂掉。那么这次软件自己的决策就是错误的，你如果多次出现类似错误，就应该知道后续不能采用这条决策分支。
　　智能运维在前期历史知识库不足够强大的情况下，你出现决策错误不要紧，但是你需要具备不断持续学习能力，自我适应和调整能力，这才是最重要的。智能运维场景2-性能优化和弹性扩容
　　图片来自网络
　　对于性能的管理实际包括两个方面，一个是性能优化，一个是弹性扩展。
　　对于弹性扩展注意要实现这个场景需要同时结合其它关键子系统的能力。其中最核心的是APM系统和PaaS平台资源调度能力。那么智能化运维要做的就是需要自定义弹性扩容规则或者需要不断的优化弹性扩容规则，基于性能数据的采集和分析来自动的进行集群节点的弹性扩容。
　　图为宜信开源APM图
　　对于性能优化更多的是我前面提到的当出现了性能问题的时候，我们能够对整个应用或服务的调用链路进行详细的诊断和分析，然后进行决策。
　　比如一个前端功能按钮的操作慢，实际上你可以看到经过了前端展现层，API接口服务，逻辑层实现，数据库Sql等多个链路环节。
　　那么出现上面这种场景的时候，需要首先确定具体是哪个环节慢，其次才是能否自动优化。如果你发现的是逻辑层调用慢，那么还需要看是并发导致慢，还是集群节点本身内存遗漏导致。如果是数据库慢通用需要分析是Sql语句导致还是数据库本身不正常等。
　　而这些就涉及到我们说的决策树模型，我们可以根据决策树模型进行初步的分析，但是更加重要的是通过不断的学习完善决策树分支和每个分支的权重。
　　当我们找到关键的分支的时候只是第一步，其次才是自己去优化。比如我们已经找到sql语句慢，那么软件是否可以自动完成Sql语句的优化，比如添加关键索引等。在这里，我们理解只要能够协助完成关键性能点定位已经算做具备AI智能化能力，如果还能够通过学习自己去决策和解决问题，那么就能够实现完整意义上的智能化。智能运维场景3-风险预测
　　图片来源网络
　　在自动化运维阶段，实际上我们已经实现了监控预警和告警，这个相当来说比较简单。只要你提前设置好相应的告警规则和阈值，那么在性能数据采集到经过计算后，只要满足了规则要求，就触发预警或告警。
　　在接收到告警通知后，运维人员可以人工介入去分析告警信息是否需要进行处理。
　　当时在智能化运维阶段，我们需要的是风险预测。
　　运维平台可以实时的采集大量的资源性能数据，中间件日志数据，IT应用的操作日志数据等。而这些数据我们拿到后需要进行各种分析，看是否存在某种特殊的异常情况需要我们去处理。
　　比如我们采集到的日志异常数据，我们可以进行聚类分析，如果发现对于某个功能操作或API接口服务的调用大量持久的出现某种类型的异常，那么我们就需要给出相应的突变告警。再比如，我们在监控整体性能数据的时候，该数据在同比或环比的数据上都出现验证的数值突变，那么我们通常需要进行告警或预警。
　　再有就是我们采集到的CPU和内存等资源性能数据，应用并发数据，异常信息等之间本身存在相关的关联性，我们可以进行关联分析发现差异，如果存在也告警。
　　一个好的运维系统一定是从问题驱动转变到风险驱动，将潜在的故障或问题在风险阶段就彻底解决掉。当然在这个阶段，系统自动化的聚类分析往往经常或出现误判，但是这个不要紧，我们可以在前期多些人工介入，对判断结果进行识别，哪些是正确的哪些是错误的，辅助软件提升自学习能力。这样持续迭代多次，一个完整的专家知识库才可能形成。
　　理想情况下一个软件上线完成后基本能够做到不需要运维人员和监控人员，软件出现的问题或故障能够自动的进行分析，在分析后给出自动的解决措施并完成解决，或者给用户最佳的问题处理方式和流程。智能运维在传统软件运维监控的基础上，能够进一步做到出现问题也能够被自动修复和解决，而不需要人工干预。