据Gartner指出，AIOps自2018年进入技术萌芽期之后，预计会在5-10年内进入需求膨胀期，市场深入率将达到20%的规模。在Gartner的另一份报告中，也同样预测到2022年，40%的大型企业将会部署 AIOps平台。

激动之余，让我们来稍微回顾一下智能运维的历史。随着 IT 系统的出现，企业需要通过运维部门来掌握系统的运行状况，从而保证服务质量和用户体验，对异常事件及时进行发现和处理。最开始的情况是大量运维人员通过终端等工具在机房进行手工排查和处理，费事耗力。之后，IT系统在企业中的复杂程度和重要性不断提升，运维工作的专业性也随之迅速增长，大量的自动化脚本的出现实现了运维的自动化，运维效率得到很好的提升。

运维的自动化吹响了将手工阶段的运维人机接口向运维程序接口转化的号角。从这时开始，“运维数据” 正式登上历史的舞台，并开始大放异彩。随着自动化的不断深入，自动化脚本逐渐向着平台化、系统化的方向发展。企业纷纷通过集中监控平台采集和管理系统的各项运行状态和执行逻辑信息，例如网络流量、服务日志等，运维人员据此对系统运行状态完成全面的感知，进而完成自动化操控。围绕这些运维数据逐渐形成了以“监管控”为核心的运维系统。

运维领域向专家系统方向的发展使得运维人员与产品研发人员区分开来，演化为独立的运维部门。然而近年来，DevOps 的兴起将推动了运维开发一体化的进程，运维数据的采集、处理反过来影响着 IT系统本身的设计，运维与研发人员技能和组织也趋向融合，同时促进了运维数据更广泛地的产生。运维数据由此出现爆炸式的增长，每天有上百十亿条的监控指标、日志等产生，给运维带来了新的困难和挑战，也促使智能运维的出现和发展。

图1 运维数据的发展

从 图1 我们可以清晰的看到运维数据爆发式的增长，以及与其对应的 IT 运维方案的发展。如果我们沿着上图的红线，以运维数据的视角来看待 IT 运维系统的演变，就能够更准确的理解运维数据在现代系统中的意义：

• 起始的阶段，运维数据可能仅仅包括 IT 系统的输入输出，由运维人员直接从屏幕上读取；
• 
  
• 自动化运维阶段，运维数据涵盖了支撑自动化脚本运行的各种数据，包括系统配置、状态、监控数据等。虽然经过脚本的处理，但运维数据最终还是由运维人员进行读取和处理的。
• 
  
• 到了 DevOps 或者称为大数据运维阶段，运维数据的范围扩大到各种系统配置信息、监控系统采集的系统数据、指标数据、固定阈值或动态阈值产生的复杂告警信息、以及各种系统定义的五花八门的海量日志数据等等。在这里顺带说一句，由于在开发和系统运维的边界上的模糊和融合，以及大数据技术的发展，运维数据和生产数据的边界也不再那么清晰，例如 网站的用户点击数据既属于运维数据的范畴也是业务数据的重要组成。运维数据在这个阶段产生了爆发式的增长。可惜的是，运维数据的消费方式还是通过竖井式的方案，以不同的系统分别处理，主要还是展现给 DevOps 人员来进行决策。例如，监控系统以获取监控数据为始，以输出规则定义的告警信息给运维人员为终；日志系统已获取和索引日志内容信息为始，以提供复杂的搜索和内容展现给运维人员为终。运维数据的价值挖掘受制于孤立的运维系统的处理能力和运维人员自身的“带宽”。
• 
  
• 得益于大数据和人工智能，运维数据的增长将运维方式推向智能化。
  
  

如果说“我是谁，我从哪里来，要到哪里去”是人生的灵魂之问的话，我们也可以从“来源、形态和去处”三个维度来梳理一下运维数据的终极意义。

	来源	形态	去处
手动运维	系统终端	命令，日志	屏幕，打印机；（消费角色：op）
自动化运维	系统接口，脚本，监控	指标，告警，日志	屏幕，中间件，数据库（消费角色分工：SA，IDC，DBA）
DevOps	云服务平台，分层业务系统，运维系统（监、管、控）	指标、告警、日志、配置信息、调用链、工作流、即时通讯、业务数据	屏幕、大数据平台、规则系统、运维平台（人和机器共同消费：DevOps，SRE、云服务系统、运维工具等）
AIOps	云平台、业务系统、传统运维系统、IoT、容器	指标、告警、日志、配置信息、调用链、工作流、即时通讯、业务数据，用户行为数据等等	AIOps 系统（预防预测、自动学习、根因定位。自动决策和恢复），极少量的人为干预

虽然运维数据纷繁复杂、种类多样、数量巨大，已经超出了人力或者普通的基于规则的系统的处理能力，但是我们可以对运维数据进一步的抽象，利用 AI 和机器学习的能力，挖掘其中的价值。无论是监控指标、告警信息、日志信息等等，我们都可以认为是在目标 IT 系统上特定时间发生的一次“事件”（Event）。举例来说，一条日志信息的具体内容可能完全取决于特定系统或应用的开发者的设计，但是其本质上都是在某一时间点上针对系统的一种信息表达，可能是系统状态、发生的操作等等，而指标数据或者告警数据等其本质也是一样的。因此，我们可以将运维数据统一定义为一系列事件（Event）的集合，而事件可以描述为以下两种信息的组合：

• 时间戳 （Timastamp）
• 
  
• 在该特定时间上发生的事件内容 （Content) 其中“事件”内容，我们还可以把它分类为具体行为（动作）和对此行为的描述或者补充信息，具体我们后面会谈到。
  
  

理解了运维数据以及它的作用，我们需要回答一个问题，是把海量的、异构的运维数据分门别类、各个击破还是关门打狗统一治理？我们将在下篇文章中继续介绍。

据Gartner指出，AIOps自2018年进入技术萌芽期之后，预计会在5-10年内进入需求膨胀期，市场深入率将达到20%的规模。在Gartner的另一份报告中，也同样预测到2022年，40%的大型企业将会部署 AIOps平台。

激动之余，让我们来稍微回顾一下智能运维的历史。随着 IT 系统的出现，企业需要通过运维部门来掌握系统的运行状况，从而保证服务质量和用户体验，对异常事件及时进行发现和处理。最开始的情况是大量运维人员通过终端等工具在机房进行手工排查和处理，费事耗力。之后，IT系统在企业中的复杂程度和重要性不断提升，运维工作的专业性也随之迅速增长，大量的自动化脚本的出现实现了运维的自动化，运维效率得到很好的提升。

运维的自动化吹响了将手工阶段的运维人机接口向运维程序接口转化的号角。从这时开始，“运维数据” 正式登上历史的舞台，并开始大放异彩。随着自动化的不断深入，自动化脚本逐渐向着平台化、系统化的方向发展。企业纷纷通过集中监控平台采集和管理系统的各项运行状态和执行逻辑信息，例如网络流量、服务日志等，运维人员据此对系统运行状态完成全面的感知，进而完成自动化操控。围绕这些运维数据逐渐形成了以“监管控”为核心的运维系统。

运维领域向专家系统方向的发展使得运维人员与产品研发人员区分开来，演化为独立的运维部门。然而近年来，DevOps 的兴起将推动了运维开发一体化的进程，运维数据的采集、处理反过来影响着 IT系统本身的设计，运维与研发人员技能和组织也趋向融合，同时促进了运维数据更广泛地的产生。运维数据由此出现爆炸式的增长，每天有上百十亿条的监控指标、日志等产生，给运维带来了新的困难和挑战，也促使智能运维的出现和发展。

图1 运维数据的发展

从 图1 我们可以清晰的看到运维数据爆发式的增长，以及与其对应的 IT 运维方案的发展。如果我们沿着上图的红线，以运维数据的视角来看待 IT 运维系统的演变，就能够更准确的理解运维数据在现代系统中的意义：

• 起始的阶段，运维数据可能仅仅包括 IT 系统的输入输出，由运维人员直接从屏幕上读取；
• 
  
• 自动化运维阶段，运维数据涵盖了支撑自动化脚本运行的各种数据，包括系统配置、状态、监控数据等。虽然经过脚本的处理，但运维数据最终还是由运维人员进行读取和处理的。
• 
  
• 到了 DevOps 或者称为大数据运维阶段，运维数据的范围扩大到各种系统配置信息、监控系统采集的系统数据、指标数据、固定阈值或动态阈值产生的复杂告警信息、以及各种系统定义的五花八门的海量日志数据等等。在这里顺带说一句，由于在开发和系统运维的边界上的模糊和融合，以及大数据技术的发展，运维数据和生产数据的边界也不再那么清晰，例如 网站的用户点击数据既属于运维数据的范畴也是业务数据的重要组成。运维数据在这个阶段产生了爆发式的增长。可惜的是，运维数据的消费方式还是通过竖井式的方案，以不同的系统分别处理，主要还是展现给 DevOps 人员来进行决策。例如，监控系统以获取监控数据为始，以输出规则定义的告警信息给运维人员为终；日志系统已获取和索引日志内容信息为始，以提供复杂的搜索和内容展现给运维人员为终。运维数据的价值挖掘受制于孤立的运维系统的处理能力和运维人员自身的“带宽”。
• 
  
• 得益于大数据和人工智能，运维数据的增长将运维方式推向智能化。
  
  

如果说“我是谁，我从哪里来，要到哪里去”是人生的灵魂之问的话，我们也可以从“来源、形态和去处”三个维度来梳理一下运维数据的终极意义。

	来源	形态	去处
手动运维	系统终端	命令，日志	屏幕，打印机；（消费角色：op）
自动化运维	系统接口，脚本，监控	指标，告警，日志	屏幕，中间件，数据库（消费角色分工：SA，IDC，DBA）
DevOps	云服务平台，分层业务系统，运维系统（监、管、控）	指标、告警、日志、配置信息、调用链、工作流、即时通讯、业务数据	屏幕、大数据平台、规则系统、运维平台（人和机器共同消费：DevOps，SRE、云服务系统、运维工具等）
AIOps	云平台、业务系统、传统运维系统、IoT、容器	指标、告警、日志、配置信息、调用链、工作流、即时通讯、业务数据，用户行为数据等等	AIOps 系统（预防预测、自动学习、根因定位。自动决策和恢复），极少量的人为干预

虽然运维数据纷繁复杂、种类多样、数量巨大，已经超出了人力或者普通的基于规则的系统的处理能力，但是我们可以对运维数据进一步的抽象，利用 AI 和机器学习的能力，挖掘其中的价值。无论是监控指标、告警信息、日志信息等等，我们都可以认为是在目标 IT 系统上特定时间发生的一次“事件”（Event）。举例来说，一条日志信息的具体内容可能完全取决于特定系统或应用的开发者的设计，但是其本质上都是在某一时间点上针对系统的一种信息表达，可能是系统状态、发生的操作等等，而指标数据或者告警数据等其本质也是一样的。因此，我们可以将运维数据统一定义为一系列事件（Event）的集合，而事件可以描述为以下两种信息的组合：

• 时间戳 （Timastamp）
• 
  
• 在该特定时间上发生的事件内容 （Content) 其中“事件”内容，我们还可以把它分类为具体行为（动作）和对此行为的描述或者补充信息，具体我们后面会谈到。
  
  

理解了运维数据以及它的作用，我们需要回答一个问题，是把海量的、异构的运维数据分门别类、各个击破还是关门打狗统一治理？我们将在下篇文章中继续介绍。