2.3　演进过程

在IT运维初级阶段，企业就有动力通过以算法和自动化流程驱动的“智能运维”来代替人工。当时，信息系统主要以企业内部自用的企业资源管理、计算机服务设计等系统为主，系统服务范围小，运维成本和压力相对较小。企业没有足够的动力来做IT运维智能化的事情。智能运维发展加速的一个重要的催化剂是，如Google这样的互联网公司迫于运维压力，开始尝试利用统计学方法分析运维数据中的模式，预测未来趋势。从2010年开始，云计算和大数据技术的快速发展也推动了企业利用大数据与算法提升IT运维能力的需求，智能运维发展真正进入了快车道。时至今日，在智能运维的演进过程中，主要的里程碑有IT运维分析、事件关联分析、自动化运维、人工智能运维、开发运维一体化。

2.3.1　IT运维分析

IT运维分析（IT Operations Analytics，ITOA）指实现基于海量IT运营数据的演绎、归纳推理，并支撑IT运营数据采集、存储、展现的相关技术及服务。其利用数学算法或创新方法，从海量IT监控管理系统采集的原始数据中挖掘有用的信息。ITOA是通过分析海量、低价值密度的IT系统的可用性和性能数据，发现复杂的数据模式，从而辅助优化企业IT运营过程的系统，其需要具备的核心能力如下。

（1）风险根源定位分析：通过融合分析来自基础设施、应用、用户的监控数据，定位产生风险或对系统健康造成潜在威胁的根源所在。

（2）性能可用性预测分析：基于历史数据预测未来系统性能和可用性的变化趋势，以及关联分析对系统可能产生的影响。

（3）问题识别与派发：围绕当前问题，从历史记录中查找解决方案和适合解决问题的团队或人，提高处理问题的效率。

（4）影响范围推理分析：当发现多个风险可能对系统造成影响时，基于从数据中发现的模式推理找出可能影响更大、优先级更高的风险，指导相关人员及时、高效处理这些问题，降低损失。

（5）多源数据融合互补：对IT基础设施和应用采集的数据进行关联、融合，补全网络、应用、服务拓扑结构，完善探查管理类工具信息视图。

（6）动态风险告警阈值管理：自动发现监控指标的正常运行范围，在用户负载变化或系统配置变更后，能够自动从历史数据中发现规律，调整异常告警区间的限定阈值范围。

对于ITOA技术，Gartner在Data Growth Demands a Single, Architected IT Operations Analytics Platform报告[1]中总结了六种：①日志分析技术；②非结构化文本数据索引、查询和推理技术；③拓扑分析技术；④多维数据库查询分析技术；⑤复杂运维事件处理技术；⑥数据统计分析、模式发现与识别技术。具备这些技术的ITOA才能满足基础设施和应用层的监控需求，实现由多源异构探针采集的时间序列指标、日志、代码链路、网络包和用户数字轨迹数据的聚合、关联和分析。目前，市场上的ITOA产品提供商主要有Splunk、Elastic、Dynatrace和RealSight APM等。

2.3.2　事件关联分析

在主动风险预测和预防性维护技术未成熟之前，企业运维风险管理工作主要以工单、风险告警等事件驱动工作方式为主。在运维过程中，事件关联分析（Event Correlation and Analysis，ECA）[2]则主要用来关联多种监控系统事件，协同不同团队角色人员的工作。具体地说，ECA能够帮助IT运维人员消除重复上报工单事件或告警；根据不同人员角色和业务运维需要来过滤、查询相关事件；根据历史数据或预定义规则关联事件，找出告警事件的根源问题或查找事件间的相关性和影响关系。这种处理方式在一定程度上能减少人工过滤无效事件的工作量，并辅助查找对应事件最合适的处理角色，这也是通过算法实现指定类型风险处理的智能运维的一种简单、有效的方案。市场上主要的ECA产品提供商有Argent Software、Augur Systems、BMC Software和CA。

2.3.3　自动化运维

如果说智能运维技术发展的主线是为了解放运维人员，ITOA、ECA通过数据驱动辅助决策来解放IT运维人员的大脑，那么，自动化运维（Automated System Operations，ASO）[3]技术则主要是为了解放运维人员的手和脚。在日常运维中，当面临大量服务器、应用，需要有限的运维人员维护管理时，自动化运维工具和产品能够帮助运维人员设置自动化脚本，批量安装操作系统，部署中间件和应用，配置变更管理。Gartner将ASO定义为“不需要人工干预，直接操控物理设备就能控制计算机安装配置硬件和软件的过程”。

借助ASO工具，IT运维人员可以在控制台通过定义自动化脚本准备应用的运行环境，安装部署应用，准备集群节点，控制弹性分组。结合脚本语言编程，运维人员可以将更复杂的控制流程自动化。结合ITOA和ECA的风险告警，以及根源定位分析事件触发，可以实现特定场景下对特定风险的自愈控制。比较常用的ASO工具包括Chef、Puppet、Ansible和Saltstack。

2.3.4　人工智能运维

第一个提出AIOps概念的是著名的IT咨询公司Gartner[4]，其给出的定义是算法运维（Algorithmic IT Operations），其中的AI并不是现在大家理解的人工智能。2017年4月，在印度孟买的新闻会上，Gartner将AIOps解释为“AIOps平台由可以完成数据采集、存储、分析和可视化的多层架构系统组成，具备与第三方应用通过不与厂商绑定的API接口对接数据的能力，能够和IT运维管理（ITOM）类工具进行数据交互和能力对接”。Gartner完全站在IT运维数据分析的角度给出了AIOps的基本能力边界，和人工智能没有一点儿关系。然而，由于人工智能技术是大热点，业界更愿意将AI理解为更时髦的人工智能算法，AIOps也就只能顺应潮流，被定义为人工智能运维。从目前机器学习、人工智能技术的应用现状和发展趋势来看，IT运维领域的目标数据以机器数据为主，机器行为相比于人的行为规律性较强，状态数据采集简单，质量相对可控。使用算法运维替代人工运维更容易落地，真正的人工智能运维已经不再遥不可及。

从需求和技术发展的趋势看，企业内多源数据融合和集中式运维与运营数据支撑是大势所趋，但由于采集方式和数据类型多样、数据存储分散、智能分析场景众多，实现难度较大，需要从核心场景出发，按需规划，分阶段递进实现。Gartner给出的AIOps平台的核心能力包括以下几项。

（1）能够从多种数据源采集数据，不与厂商绑定。

（2）支持对接、处理实时数据和批量历史数据。

（3）提供对融合数据的检索、统计。

（4）提供海量实时、历史数据的存储。

（5）支持使用机器学习算法来分析、处理数据。

（6）能够基于分析结果规划下一步的处理动作。

总结企业应用的运维场景，可知常见的人工智能运维场景如下。

（1）基本和高级统计分析：单变量和多变量分析的组合，包括对跨IT实体捕获的指标使用相关性、聚类、分类和外推分析，以及从监控数据源中对数据进行整理。

（2）自动模式发现和预测：使用上述一种或多种类型的历史或流数据，得出数学或结构模式，描述可以从数据集本身推断但不会立即存在于数据集本身的新相关性；然后，这些模式可用于及时预测具有不同概率的事件。

（3）应用异常检测：使用前一个组件发现的模式，首先确定构成正常系统的行为，然后识别偏离该正常系统的行为。

（4）根本原因确定：向下修剪由自动模式发现和预测组件建立的相关网络，以隔离那些代表真正因果关系的依赖关系链接，从而提供有效干预的方法。

（5）规定性建议：对问题进行整理，将它们分类为已知类别；然后，挖掘以前解决方案的记录，分析这些解决方案是否适用，并优先提供这些解决方案，以便尽早使用补救措施；最终，使用闭环方法，并在使用后对其有效性进行表决。

（6）拓扑：对于AIOps检测到的具有相关性和可操作性的模式，必须围绕引入的数据放置上下文，该上下文就是拓扑；如果没有拓扑的上下文和事实上的约束，检测到的模式虽然有效，但可能毫无帮助且会分散注意力；拓扑中的数据派生模式将减少模式的数量，建立相关性并说明隐藏的依赖关系；使用拓扑作为因果关系确定的一部分可以大大提高其准确性和有效性；使用图形和瓶颈分析捕获事件发生的位置及其上下游的依赖关系，可以提供关于将补救工作重点集中到何处的见解。

一些企业，尤其是拥有庞大数据中心和复杂应用的互联网公司，已经将此技术应用于特定场景，比如用户异常行为检测、云端应用弹性控制、容量规划、入侵检测、数据中心PUE能效管理、硬盘损坏预测等。有些企业甚至开始尝试通过融合开发、运维、运营数据来打造一体化智能化平台，关联运营KPI和运维SLO，同时为企业各部门提供全景数据视图和智能决策支持。非IT运维部门，如业务规划部、销售部、产品部和数字营销部都有自己的应用系统和数据，也希望借助其他途径获取更丰富的数据以了解目标用户、市场和使用场景。数据量的激增也使得大数据采集、存储和智能分析成为必备技术。因此，为了满足企业内更广泛的需求，AIOps平台对接的数据源的种类在增加，能力边界也在扩大。例如，传统APM产品提供商Dynatrace已经在践行AIOps的基础上提出了软件智能（Software Intelligence）平台的概念，推出了数字业务分析（Digital Business Analytics）服务，能够为企业数字运营部门提供实时的用户数字体验监控、转化率变化分析、企业营收与应用性能关联分析和用户画像分类等服务。

2.3.5　开发运维一体化

现在企业更加依赖数字信息系统与最终用户交互，企业应用互联网化已经是大势所趋。对于互联网应用的开发与运维，开发运维一体化（DevOps）是回避不了的一个话题。根据Wikipedia[5]的解释，DevOps这个说法第一次出现在2009年比利时Ghent举办的一次由敏捷实践者、项目经理和咨询顾问参与的称为DevOpsDays的会议上。虽然截至目前，学术界和产业界对DevOps的概念还未达成共识，但从企业信息化系统应用开发、运维的实际需求出发，DevOps通常被理解为包含工具、过程和人的一系列最佳实践，融合了应用软件开发期管理（Dev）和运行期维护（Ops），旨在缩短应用全生命周期的开发过程，提升运行期应用的可靠性、可用性和性能。

业界将DevOps概念应用在软件系统运维过程中的实践最早可以追溯到Google提出SRE概念时。当互联网应用新功能上线周期越来越短、代码更新越来越频繁时，Google不得不想办法在满足频繁发布代码需求的同时，保障上线代码的可靠性与性能能够支撑大规模用户同时在线访问，以及提供高质量的最终用户体验。践行DevOps与实现软件自动化发布或制定产品研发工作计划无关，DevOps的初衷是通过提高软件开发与运维体系的衔接水平，将软件价值加速交付给企业的最终用户。要提供价值，企业必须在生产中运行应用程序以测试应用程序，并使用自动化流程管理工具来指导接下来交付的内容。

当企业践行DevOps，建设基于DevOps的应用开发、运维全生命周期管理体系时，应用智能运维系统只是其中支撑应用运行期管理环节的工具。为了支撑DevOps落地，应用智能运维系统不仅需要支撑应用运维人员实现运行期的状态监控、风险管理、用户数字体验保障，而且需要对接开发人员，实现在开发期定义应用业务监控关键KPI指标、分析运行期代码质量和支撑性能工程等过程，并且在新功能上线、代码更新时，支持A/B测试、灰度发布、蓝绿发布等应用场景。在具备面向运维提供代码级白盒监控的能力和风险主动感知的能力的同时，DevOps体系下的应用智能运维系统也需要无缝衔接开发，在代码有故障且运维人员无法处理时，需要快速找到责任人，向开发人员分享相关实时数据。如果应用上线后代码性能不达标，运行一段时间后，应用智能运维系统需要生成分析报告，指导后续性能优化和容量规划。

本章小结

智能运维是企业进一步提高运维效率、提升应用可用性和性能保障能力的关键。本章系统介绍了运维智能化过程中出现的IT运维分析、事件关联分析等一系列相关技术和产品，从背景起源、主要特点和应用场景方面概述了技术背景，相对完整地勾勒了智能运维的发展脉络，为后续介绍应用智能运维相关的技术和建设实践方法奠定了基础。

[1]https://www.gartner.com/en/documents/2599016.

[2]https://www.gartner.com/en/documents/1492516/magic-quadrant-for-it-event-correlation-and-analysis.

[3]https://www.gartner.com/en/information-technology/glossary/aso-automated-system-operations.

[4]https://www.gartner.com/en/information-technology/glossary/aiops-artificial-intelligence-operations.

[5]https://zh.wikipedia.org/wiki/DevOps.