引言

从九十年代到今天，应该说信息化技术发展经历了快速发展的三十多年。尤其是互联网催生出来的各种信息化技术使得IT从业务的辅助角色逐步变成了业务的推动，甚至是主导角色。同样作为保障企业信息系统安全运行的运维行业也从原来的手动逐步发展到自动，又从自动发展到智能。当然每个企业对于自动化和智能化的理解和建设程度是不一样的，这里也没有统一的标准来评估和定义。作为深耕于企业IT运维条线的从业者，我们有必要通过回顾以及展望来明确看待该问题的思路。

一、从“手动”到“自动”的发展历史

1.1企业最初的IT运维模式

讲到企业最初的IT运维模式，那么就得回到企业最初的IT架构。

以银行为例，90年代之前的历史我们暂不讨论，90年代之前的架构大概都是以单机为基础。企业的信息系统各自为政，每一个应用系统都有一套独立的载体（计算、网络、存储），数据和程序同在一个屋檐下，应用和应用相互并不认识。这个时候的运维得靠那些最初接触计算机技术的工程师依靠命令的方式实现这些载体设备的运行维护，他们不仅是一个小群体，而且是凤毛麟角稀缺的小群体，往往都属于那些设备大厂家的工程师。企业自身的电脑科室人员可能仅限于开关机以及程序使用。

1.2 当企业的IT架构从完全的“单机式”走向“载体裂变”

伴随着企业信息化的发展，信息系统逐渐从完全的单机式走向了“载体裂变”。所谓载体裂变，一方面信息系统的载体从纵向上将计算和存储进行了分离，专业的存储设备承载了信息系统的数据存储功能；另外一方面，信息系统将数据处理功能交给了横向的数据库服务器。这个变革的源动力在于企业数据在量级上和安全性上的要求，当然更重要的是局域网技术发展的支撑。这个时候的运维工作已经进行了细分，企业不仅需要专业的服务器存储管理员，还需要专业的数据库管理员。但是这些管理员的运维工作还是建立在各自设备及软件的命令操作模式上，工作方式没有根本性的改变。

1.3 当企业的IT架构走向“数据集中”

还是以银行业为例，当大银行的分支机构各自发展了一段时间后，新的问题出现了。同一家银行内各地区的信息孤岛问题越来越多，但是业务需要走出地域限制。银行有很多应用系统来支撑客户的各类金融业务需求，但是客户是同一个大群体，客户在同一家银行内的横向信息孤岛问题也越来越严重。这两方面的原因是数据走向集中的源动力。当然必要的技术支撑在于广域网技术、数据传输技术等系列支撑工具的突飞猛进式发展。这个时候，企业的运维工作除了在工种上有了进一步的细分之外，工程师的工作模式上也有了变革的可能性。工程师为了解放劳动力，自发的开始用脚本工具来实现远程管理；IT服务商为了开拓新市场，逐步探索集中监控、集中发布、集中管理等自动化运维管理工具。

1.4 当“云计算”出现

如今在IT行当，最热的词汇莫过于“云计算”、“大数据”、“AI”。但是企业的IT发展都是一点点地发展过来的。云计算最初源于虚拟化技术的应用，但是伴随着互联网的突飞猛进发展。企业的客户群体、业务范围、产品模式都突破了区域的限制，业务模式也从线下转向了线上。这写变革导致企业的数据量级、数据类型、业务模式、并发规模等各个方面都面临了巨大的挑战。于是市场出现了“云计算”、“大数据”、“AI”等新的词汇。企业的运维工作也面临了前所未有的挑战。依靠局部自动化脚本难以满足云计算规模的资源管理，依靠自动化监控工具难以满足如此多变环境下的效率和安全要求。于是新的需求出现了，那就是“主动”、“感知”、“自愈”等一系列带有智能化标签的运维要求。

二、企业IT运维发展历程分析

从第二部分的阐述来看，企业IT运维模式的发展与其IT架构的发展和市场上的信息化技术发展是紧密相关的。企业业务模式以及IT架构的发展是运维模式变革的源动力，信息化技术的及时跟进是保障运维模式发展的必要条件。但是，企业IT运维建设的成熟度和娴熟度在每一个行业和每一个企业都不一样，有的先进有的落后，有的全面有的片面，有的高效有的低效。当然，企业的IT投入是至关重要的资金保障，没有这个保障，企业的IT运维绝不可能达到先进的水平。但是有了这个保障，企业的运维水平也不一定就能发展到行业顶部的水种，原因在于利用运维工具的思路和方法存在差异。

三、从“自动化”到“智能化”

3.1 何为“智能化”

所谓企业IT运维智能化，其实业界并没有一个明确的定义和标准。不同的企业不同的人对它的理解可能会有所差异。但是笔者认为智能化运维基本的原则应该包含以下几个方面：

（1）预警变为预防

在半自动化或者自动化阶段，IT运维的预警主要是指通过固定规则分析资源或对象的未来可能趋势，然后根据既定阀值标准来进行事前的预警。通常来讲需要运维人员根据预警情况进行人工分析之后决策后续动作。但是“智能化”阶段之后，部分或者全部的人工分析就应该变为机器分析，分析之后的动作也应该变成部分或者全部的机器行为。

（2）报警变为解决

同样，在传统的运维发展阶段，IT运维当中的报警主要是指监控平台或者工具的实时报警，当捕捉到资源使用、对象状态以及其他相关异常发生时，实时发出警报。运维人员根据实时警报进行及时处理。具体采取的动作主要是根据报警的内容及运维人员的经验积累来决策临时的处理动作。

（3）日志变为知识

所谓的日志是指监控平台、运维工具以及其他相关的系统运行数据。通常来讲，日志是运维人员用来分析问题以及总结经验的依据。“智能化”运维阶段，这种分析能力和经验的积累学习能力应该部分转化为机器的再学习过程。不仅运维人员要进行分析总结，同时需把这些数据作为输入给到智能运维平台。

3.2 数据是实现“智能化”的前提条件

前边我们从运维的事前、事中以及事后三个角度分析了智能化运维应该达到的目标。仔细分析，不难发现每一个目标的实现都离不来数据的利用。如果没有准确的运维数据采集，预防的判断和后续的操作如何着手？如果没有大量的运行数据，那么机器的学习和积累如何进行？如果没有正确的数据关联视图，机器如何识别并判断风险？因此实现智能化运维的前提条件就是运维数据的利用，而运维数据的利用主要解决以下几个问题：

（1） 数据采集

传统运维思维认为只有那些系统以及设备本身的运行数据才是运维数据，那么在智能化运维阶段我们需要把这个概念扩大到应用系统甚至业务层面。对于运维事件本身的分析不再局限于IT环境本身的分析，而是要纵向扩展，扩展到对应用层面的影响分析。对于IT资源的趋势分析不再局限于简单的线性分析而得出结论，而是要扩展到业务扩展以及业务特点的分析上，因为IT资源使用的源头就在于业务。因此在智能化阶段，数据采集的横向广度以及纵向的深度都应该拓展。

传统运维当中对于运行数据的采集主要依赖于统一化监控平台、日志平台、设备自身。在智能化运维阶段，由于数据量级、类型、范围的巨大变化，数据的采集需要区分直接采集和间接采集，间接采集过程需要加入数据加工的逻辑。要实现如此广度和深度的数据采集，相应的标准化建设是需要先行的，在自动化阶段就应该完成的事情，这里就不再阐述。

（2） 数据分析

这里的数据分析不再是孤立的状态判断以及事件追溯，而是需要结合所有数据视图变化而进行的复杂分析。举个例子，“内存不足”这个告警不再是简简单单的服务器资源扩容的事件，而是要分析导致该事件发生的本质原因。究竟是应用并发访问导致的还是SQL执行计划有误导致的？从前是否发生过类似事件，发生的场景条件是否一样，发生的时间是否有规律？除了计算资源需要调整，网络、存储以及其他资源是否需要协同进行调整或者计算来应对该事件的发生？总结来看，这里的数据分析是需要打通运维数据的纵向格局和横向格局来进行分析。表现出来的异常或变化本身作为线索，应用、网络、计算、数据、存储等各个视图上的变化都会被用来分析整个系统的关联性变化。不仅要分析到事件本身的前因后果，而且还需要分析到目前以及未来应对的整体解决方案。

（3） 数据积累

企业IT的发展需要积奠，数据的积奠、人才的积奠、管理的积奠等都是必不可少的前提条件。同样运维工作也需要积奠。传统运维当中的数据积累大部分都是从对历史数据处理的维度来看待这个问题。在智能化运维阶段，历史数据的积累不再是静态数据的转储了，而是需要变成运维平台进步的基础。一方面运维平台本身需要有先进的自学习算法或者模型来支撑运维知识库的建立，另外一方面知识库本身的升级和优化也需要大量的历史数据来作为训练样本。

总结

虽然说各行各业的IT运维发展存在很大差异，有的勉强刚刚从手动模式步入半自动模式，有的已经完全实现了自动化，有的甚至已经很早步入智能化的探寻阶段。总体而言，将IT运维推进到自动化和智能化相结合的模式已经是当前以及未来的趋势。企业如何做好自己的运维模式转型需要根据自身的环境特征和现实情况来分析抉择，但是利用好自身的数据来实现自动化智能化运维是大家都要走的路。