伴随着企业IT信息化的不断深入，企业对IT系统的依赖程度与日俱增。面对越来越多的各种IT系统，企业中各层IT人员可谓既爱又恨。爱的是，企业各种IT系统成为了企业业务的助推器，提升了企业业务和管理上效率。恨的是，随着企业愈发离不开IT系统，IT运维被推上了风口浪尖。如何保障IT系统高效、稳定、持续、甚至7×24小时不间断地提供服务，成为企业中各级IT人的亟待解决的问题。

IT运维是指企业IT部门采用相关的方法、手段、技术、制度等，对IT软硬运行环境、IT业务系统和IT运维人员进行的综合管理。随着技术的发展，IT运维近年来也发生了的翻天覆地的变化，下面总结一下近年来IT运维的发展，并展望IT运维未来的总体趋势。

一、IT技术架构：从“IOE架构”走向“互联网架构”

为何从技术架构讲起呢？政治经济学上是这样总结的：“经济基础决定上层建筑”，我认为换到IT业界同样适用。技术架构这个基础的演进，从根本上必然引发其他领域的变革，这当然也包括了我们讨论的IT运维层面。

曾几何时，以IBM为代表的商用小型机、Oracle为代表的商用数据库、EMC为代表的高端存储设计是企业IT体系高大上的标配。我曾在十多年前参观某省级运营商的机房，几乎都是清一色的黑压压IBM小型机；他们的系统数据库无论大小和用途都是Oracle企业级数据库。

回过头来去想，为什么当时的企业都倾向于这种IOE架构呢？当时而言，企业这种选择无可厚非，就连后面叫“去IOE”最凶的阿里，当年最初的技术架构其实也是IOE。在当时分布式技术未能成熟的前提下，IOE这种国外商用成熟软、硬件产品确实比同期其他产品带来无以伦比的单机稳定性和高性能。

我曾在某客户现场看到一台即将下线的老旧小机设备，关机下线前检查了一下启动时间，惊讶地发现这台机器上一次启动时间居然是在3000多天前，也就是说这台小机居然在无故障、无停机的情况下服务了将近十年时间。许多企业正是为这种稳定性和性能，花了大量的银子买单，因为对于IT运维者而言“稳定压倒一切”是其根本需求。

此外，从技术因素考虑，在当时IT系统运维还是以人力为主的年代，系统技术栈构成的单一也有利于开发和运维团队的组建和培养。例如，一两个Oracle的高手再配上一些中低级的DBA就能搞定所有的数据库相关问题，显然是相当合算的选择。

但是随着技术的发展，“IOE”架构所提供的基于向上扩展技术的高端商用产品而设计的传统集中式系统架构达到了瓶颈。特别是互联网企业在技术架构上的不断深入研究，为IT行业带来了全新的技术模式变革。互联网企业掀起这场轰轰烈烈的技术革命背后原因，无非来自于以下几个因素：

 ●  成本： 成本是不得不考虑的，毕竟一台小型机的价钱，能换回来一货车的X86服务器。
 ●  灵活性： 互联网行业多变的业务特征，使技术架构需要及时按需而动，很明显IOE式集中式的架构难以实现这种目标。
 ●  扩展性： 集中式向垂直扩展的技术特点已经开始限制互联网企业的业务发展需求。互联网企业业务迅猛发展的特点，使他们需要一种更具弹性、更易于扩展的水平式扩展的云化技术架构。
 ●  技术控制： 互联网行业汇聚了行业中的各类技术精英，他们需要更为开放的技术环境为其不同的业务场景做出各种极致的改造。打个比方，他们显然更需要一台给他们随之改装的小跑车，而非一台四平八稳的商务车。这是显然也是闭源商用软硬件设备并不具备的。

随着技术的发展，这种云化、分布式、开源化的技术架构开始进入传统企业的视线。2014年9月，银监会就发布39号文即《关于应用安全可控信息技术加强银行业网络安全和信息化建设的指导意见》。此后数年逐步掀起了传统企业去IOE并向互联网架构学习的大潮。

互联网架构其实并不神秘，归纳起来为以下几点：

 ●  X86化和开源软件： 用大量的国产x86服务器代替昂贵的外国小型机和存储，用开源的软件代替闭源商用软件，节省大量采购，许可证（license）以及原厂维护带来的成本。打个比方，就是“用买一头大象的钱买来一个牛群”。
 ●  分布式： 在架构上支持分布式计算能力，以多台机器的性能总和代替集中式架构下的单台小型机的能力。继续沿用上面的比喻，就是“用几十头牛代替一头大象在干拖木头的活”。
 ●  系统可靠性： 在架构上增加必要的冗余，在单个设备不靠谱的情况下，以整体的系统性可靠性代替单个设备的可靠性。再延用上面的比喻，就是“拉木头里的其中一头牛病了，应该马上换一头牛，然而并不会影响拉木头的进度”。
 ●  高度可扩展： 架构设计上支持可以不断加资源以达成更大容量，支撑更高的并发、迎接更多用户。“当拉木头变成了拉石头，要做的事情是增加牛的数量而已”。

因此，在互联网架构、云计算、大数据等新兴技术的冲击下，企业的IT技术架构也逐渐开始改革，从原来单一的IOE架构，逐渐向x86、云化架构以及开源解决方案等多样的技术架构转变（见图1-1）。这种技术架构的革新，必然带来运维领域其他关键因素的革新，推动着“运维”这个行业的向前发展。

图1-1 从IOE架构走向“互联网架构”

二、运维体系：从ITIL走向DevOps

企业的技术架构的不断革新，推动着IT运维管理模式运维体系从稳态向敏态转变。

随着企业信息化的深入，IT系统越来越多，企业IT运维人员也随之增加，不少企业信息部门专门成立运维团队进行IT系统运维工作。IT团队内部自然不可避免地需要对运维人员的各种活动进行管理。ITIL正是为企业的IT服务管理提供了一个客观、严谨、可量化的最佳实践的标准和规范。我认为正是ITIL提出的这些标准和规范在一段很长的时间为我国许多企业的运维体系建设起来指明了方向。

ITIL强调流程：以ITIL理念为核心的各种ITSM系统无不将运维操作流程化。事件管理、问题管理、变更管理、配置管理，大家都按流程办事，杜绝一切拍脑袋决策和盲目操作。

ITIL强调规范：运维人员按组织依据流程进行各种规范的运维操作，约束本身是为了确保大家的行为不要偏离方向，少犯错误。

ITIL强调分工：运维人员按技能进行有效的分工，有人负责服务台的一线响应，有人负责二线的事件和问题处理，有人负责配置管理，有人负责变更审批等等。运维团队内部实现各司其职，分工协作。

这种管理机制在IOE技术架构的年代是非常适合的。这种集中式的技术架构结构相对简单，显然需要更加稳妥运维操作，毕竟所有鸡蛋都放在这几个篮子里面；另外，在这种集中式的架构下面，业务变更也没有如此的频繁，需要动不动就走一个流程是有点麻烦，但是由于频率低，倒也可以接受。

然而，在企业IT技术架构逐步进入互联网架构下，业务的迅速发展，强调IT更好地按需而变，强调更敏捷地响应业务的需求时，ITIL这个体系多少就有些与现实格格不入的感觉。这时，DevOps这个词汇走进人们的视野（见图1-2）。

图1-2 运维体系从ITIL走向DevOps

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

DevOps的思想跟ITIL有着天然的区别

流程压缩，反应敏捷，效率大幅提升：

ITIL强调流程，但是也带来了效率的下降。在IOE时代，企业业务的变更还并不是那么的频繁，这种效率的下降还并不明显。但到了互联网架构下，这种负面效应就会被无限放大。

举个例子，某运营商发布新的系统版本，往往会经历源代码提交、编译、打包、发布到测试环境、UAT测试、修改bug、再测试、最后上线发布的流程，这个流程往往会经历3-4天。因此，该运营商的版本发布一般只能以月为单位，最快也只能以周为单位。相对于业务周期以天来计算的互联网行业，这套体系对业务变更的反应也就太迟钝了。

所以，DevOps体系则更为强调效率，在持续集成、持续的自动化测试、持续部署平台、立体化监控、技术架构优化等多种自动化工具的加持下版本发布和运维的过程被大大压缩，效率被大幅提升。应用版本发布频率可以以天，甚至以小时为单位。这种为了效率有选择性地放弃一些有点拖沓的流程管理，是IT运维管理为适应IT更好地按需而变，强调更敏捷地响应业务需求的一种更好选择。

自动化操作代替冗长流程控制下的规范性：

从另一个方面来说，ITIL强调了规范性，但是这种以建筑于流程之上的规范性仍然有很多缺陷。

再接着上面运营商的例子来说，即使是有再完善的流程加以控制和规范，仍然没有人能打包票说版本上线一定没有问题。在每次版本上线前后，运维团队成员仍然如临大敌，战战兢兢。

原因在于，技术架构复杂程度发展到一定阶段，流程往往无济于事甚至流于形式。在大规模、多类型软硬件设施运维情况下，单纯依赖人的运维体系终将成为整个IT运维的瓶颈。在这种情况下，许多企业尝试将规范性操作细化为各种自动化操作场景，例如，上文就提及过的持续集成、持续自动化测试、持续部署、自动化监控和运维等等的工具和平台。这些高效率、规范化的自动化彻底解放了运维人员的压力，让运维人员的精力可以投入到真正有意义的工作中，而非总是在重复一些机械和重复的常规性事务当中。

以谷歌为例，他们的SRE工程师强制规定他们只有30%的时间会花在on call这种事务型的工作当中，而70%的时间则花在各种自动化工具的开发之中，比如自动化发布系统、监控系统、日志系统、服务器资源分配和编排等，这些工具需要他们自己完成开发和维护。这种以自动化工具下高效率的自动化操作代替冗长流程控制下的规范性，也是DevOps体系的一个比较明显的特征。

开发与运维的融合：

同时，ITIL背景下的分工也带来许多负面问题。例如，运维团队感知和认同感很差。企业高层领导认为运维工作没有亮点和价值，是一个成本部门；运维团队也多半认为自己是“背锅侠”。以至于多年前做项目时曾听到合作某甲方运维团队核心成员的一句抱怨：“少壮不努力，老大干运维”。

这可能也是大多数运维者的心声吧。诚然，这里面有运维工作成果难以量化，企业高层不够重视等因素，但是这种过于壁垒分明的开发与运维的分工也是重要原因之一。

企业开发团队与运维团队形成的鸿沟，使开发团队在规划、设计和研发的过程中过于着重功能的实现，在一定程度上忽视了运维团队所关心的稳定性、性能、可用性等因素。

同时，运维团队又无渠道将这些问题在开发前期予以反馈和修复。于是乎，运维团队不断沦为“救火队员”和“背锅侠”，团队士气下降人才流失，运维质量下降形成了恶性循环。

所以，DevOps体系中强调的是开发与运维的融合。

开发运维一体化使开发和运维的信息透明性，运维过程中遇到的问题更有效地反馈到开发团队中。同时，运维的责任主体从单一运维团队变化开发、运维团队共同承担。这使得开发团队也需要为运维中遇到的故障负责，让开发团队也需要将部分的精力和资源投放到与稳定性、性能和可用性等运维相关的研发中去。

当然，并非说ITIL这套体系就已经完全过时，而是我们需要将两者与企业中的开发运维特点相结合，形成更有效的适合企业自身的开发运维体系。只有适合自己的才是最好的。

三、运维平台：从ITOM走向AIOps

“工欲善其事，必先利其器”，运维工具是我们实现各种运维操作的有效帮手，它解放了运维人员，让他们可以更多更好地维护各种IT系统。运维体系的发展当然也离不开运维工具的发展。

二十多年前，企业IT信息化刚刚起步，IT运维基本还处于刀耕火种的时代，没有所谓运维工具也没有意识其存在必要性。几个小姑娘定时在终端上敲些命令，并在纸质的表格上一丝不苟地记录着读数，这还是当时比较规范运维做法。原因是当年那个年代需要维护IT系统的量很少，单靠人也看得过来。

在IOE架构统治的时代，运维团队的人工维护还是占绝大部分。当然其中也不乏一些人，开始总结他们的运维操作，将一些常用的操作写成大量的脚本以便于从事一些机械、重复的事情时候可以“偷个懒”。但是，在这个阶段手工运维还是占了绝大部分的工作量。

在IOE架构时代的后期以及互联网架构开始普及，也同时伴随着企业IT信息化的不断深入，企业中IT设备量呈现爆发性的增长，单靠人力开始逐渐管不过来。

以我服务过的某运营商客户为例，最初的业务支撑部门负责维护其核心系统，当时只有区区20来台主机，几个数据库。然而其后数年，维护系统规模上升了十数倍，运维团队规模只增加了不到一倍。维护规模和运维团队能力只会形成了事实上的越来越明显的剪刀差，这成为运维管理中最核心的矛盾。

而后到了企业开始尝试引入互联网架构，系统的复杂度更是陡然上升、维护目标更是迅速增长，按照传统的手工或者半自动维护来做，就更是走不通。因此，企业为解决这种问题，尝试引入各种运维工具通过自动化的手段解决运维人手和能力不足的问题，IT运营管理也就应运而生。

IT运营管理（ITOM）是指对IT基础设施以及软件应用等对象的运营进行实时监控管理并提供反馈的服务，为监测对象保持最佳运行状态提供保障。ITOM领域的工具分为三大类别，分别是：

 ●  监控类： 各种提供应用性能监控、基础软件服务监控、主机存储设备、网络设备等自动化监控和告警的软件服务，例如，商用软件中的Tivoli、开源软件中的Zabbix等为代表。
 ●  管理类： 各种提供IT运维支撑服务以及配置管理等方式的软件服务，例如，各种ITSM系统和CMDB软件系统，例如，HP的OpenView之类。
 ●  自动化类： 各种提供自动化运维手段的工具和软件，例如，开源的Ansible、Puppet之类。

IT 运维管理（ITOM）将从原有的人工加被动响应，转变为更高效、更为自动化的运维体系。

以上文提及的运营商客户为例，由于运维人力的增长无法区配IT系统规模的增速，企业连每天早上大规模营业前，对所有IT系统的设备进行一次常规状态巡检也难以维持。

为解决这个矛盾，专门部署和实施了我们的自动化监控和运维平台，将大量常规的操作交由机器实现。就正如每天的巡检动作，只需要定义好相关的巡检模板，机器就会十年如一日地按照我们定义的规范进行各种巡检操作。

如巡检结果中出现任何异常，运维人员的手机就会出现该问题的告警短信，通知相关运维人员处理。这种自动化的运维工具体系，其实质是让机器管理机器，将大量重复、机械的运维工作交给机器执行，有效地降低运维人力资源的投入，也让运维人员的精力得以释放并投向更为重要的领域。

最近我又跟该运维团队的负责人在聊天，了解到他们实际上80%运维操作都交给机器自动去完成。最后，他哈哈一笑道：“其实我们现在运维团队除了应对突发性的系统故障以外，最常见的事务实际上是给应用系统为企业各式人员创建账号和分配权限，并且我们现在正在开发代码将这件事也自动化了”。

ITOM体系将自动化带到运维当中，让IT运维更加高效。但是，ITOM仍然未能打破运维工作对运维者经验的依赖，往往缺乏分析能力，虽然也能采集到运维数据，但无法对这些数据所包含的信息进行洞察，更加无法将数据进行知识化的本质提升。

例如，各种故障的处理分析过程中，仍然是依靠运维者的经验甚至直觉来分析处理，运维决策中各种拍脑袋的例子仍然层出不穷。这是因为传统的ITOM工具往往缺乏数据分析能力。虽然也能采集到部分的运维数据，但是由于数据采集不全面，并且数据未能整合、数据间缺乏连接和分析手段，所以运维者无法对这些数据所包含的信息进行洞察，更加无法将运维背后进行知识化的本质提升。

因此，运维者开始着手进行基于运维数据分析ITOA的探索。大数据技术的成熟，让海量运维数据的分析成为了可能。参考经营分析领域的例子，我们开始着手建立了从运维数据采集、处理、分析和可视化展示的全面运维数据分析体系。我们运维IT系统无时无刻不在产生海量的数据，它产生的数据量甚至可能会超过我们的应用系统，因此运维分析天生就是个大数据的应用场景。

实现基于运维数据的分析ITOA

首先要解决的是数据采集问题：

因为运维体系中的数据是多种多样的，有像监控系统直接采集回来的结构化的数据，也有像各种应用日志、机器日志等非结构化的数据。

为了便于我们后续的数据分析，我们需要将其中难于分析的非结构化数据转换成结构化的数据加以存储。例如图1-3是在Apache Web日志中的一行记录，其中蕴含着会有大量有用的信息，如客户的IP、客户所使用的客户端，它访问的页面信息、访问时间等关键信息。

图1-3 Apache Web日志中的一行记录

我们通过有效的工具将这些信息切分并形成结构化信息，源源不断地存储到运维大数据中心，见图1-4：

图1-4 结构化信息

大数据技术发展也为我们提供了存放海量运维数据基础：

我们可以通过大数据平台构建我们的运维大数据中心，从我们整个运维的IT环境中采集回来的运维数据将在此基础上进行数据存储和整合。这样我们可以改变ITOM体系中数据分散，难以关联分析的缺陷，因为数据需要更多的连接与关联，其背后的价值才能充分发挥。

例如，在ITSM系统中一个孤立的事件可能很难看出什么，但是在运维数据分析的角度，它可能将与历史上一系列相同的事件做比较，发现在附近时间点上各种数据指标的变化。运维人员通过层层筛选和分析，最终通过分析发现其中运维数据背后规律最后总结为知识库与相关优化动作。这正是一切以数据说话，以数据分析代替经验决策的良好结果。

数据检索能力和数据可视化能力提供保障：

当然，运维数据分析除了单纯提供一个大数据存储和分析的载体外，还需要一些必要的能力保障运维人员可以更好地利用其中的运维数据：

平台需要有极强的数据检索能力。运维数据分析平台存储着海量的运维数据，运维人员为了尝试建立和验证一个探索性场景的时候，往往多次反复检索和查询特定数据。如果运维数据分析平台的数据查询很慢或者查询角度很少的情况下，运维人员建立场景的时间就会拖得很长甚至进行不下去。因此，运维人员可通过平台可以实现关键字、统计函数、单条件、多条件、模糊多维度查找功能，以及实现海量数据秒级查询，才能更有效帮助运维人员更便捷分析数据。

平台需要强大的数据可视化能力。人们常说“一图胜千言”，运维人员经常会通过各系统的运维数据进行统计分析并生成各类实时报表，对各类运维数据（如应用日志、交易日志、系统日志）进行多维度、多角度深入分析及可视化展现，将他们分析的结果和经验向他人表达和推广。因此，平台中需要具备各种旋转透视表、常规报表能力就相当重要。

可应用于多种业务场景：

此外，运维数据分析其实不只用于运维这个范围中，在我们的经验中还常有风险分析、审计、情感分析等业务场景之下。通过采集当前环境中的运维数据，集成现有ITOM工具，利用大数据及数据分析的技术，对IT系统中各个环节的问题进行快速定位、故障排除和预测。对来自业务环节中各个分布系统的数据进行整体分析，合理优化IT服务，挖掘关键业务KPI指标，反哺业务端，帮助其做出明智决策。

艾瑞咨询研究院的分析预测ITOM/ITOA的市场规模到2020年将达到114.5亿元（见图1-5），但增长逐渐趋缓，而AIOps正是ITOM、ITOA的延续。

图1-5 艾瑞咨询预测2020年ITOM/ITOA中国市场将达114.5亿元

通过大数据和人工智能技术分析日志和运维数据，发掘更多运维人员尚未觉察的潜在的系统安全和运维问题。

Gartner在2016年发布的报告中首先提出了基于大数据及算法（Algorithmic IT Operations）的IT运维概念。随着人工智能的快速兴起，Gartner将AIOps的概念从原本的基于数据分析，扩充为基于人工智能，期望通过大数据、现代机器学习及更多高级分析技术，提供具备主动性、人性化及动态可视化的能力，直接或间接地提升目前传统IT运维（监控、自动化、服务台）的能力。

AIOps真正应用和落地时间还很短，从目前的应用而言主要是在运维数据集中化的基础上，应用机器学习算法进行各种数据分析和挖掘的工作。主要的应用场景包括：

 ●  异常告警： 根据历史监控指标数据，运用基于时序的相关算法对监控指标异常分析，并对出现异常的监控指标发出精准告警。
 ●  告警收敛： 根据历史事件和告警数据，发现这些事件和告警之间的关系，整合频繁一起出现的事件和告警，并将其认看作同一类故障的告警，从而把多个告警和指标合并，推送给运维人员，做到精细化告警，避免传统监控工具因一故障而导致的告警风暴，生产告警噪音。
 ●  故障分析： 通过运维数据及事件、告警，结合以前发现问题的经验知识库和模型，建立故障树分析，结合决策树等相关算法，通过推导路径使运维人员对于问题的定位更加快速、直观，使得问题的解决更加容易。
 ●  趋势预测： 进行历史数据拟合等算法，进行资源趋势/容量预测。例如，主机CPU，交换页不足、内存不足、存储不足会逐渐导致系统故障或应用故障，该系统建立关联模型，提醒用户可能后继可能发生系统故障或应用故障。在故障产生真正业务影响前，告知运维人员事先解决问题。
 ●  故障画像： 通过采集多维度运维数据，构建多元结构化底层运维数据模型，配合各类运维场景，并在场景里对故障进行画像，通过各种故障画像标准形式来辅助企业进行IT运维 决策和处理过程。

当然，AIOps的应用场景远不止于此，正是由于这个概念出现的时间比较短，也就有更多的发挥空间容我们去细细发掘。总体而言，从手工运维、ITOM、ITOA、AIOps的发展路径体现了运维自动化、数据化到智能化这一主要发展趋势。

四、运维核心：从关注平台走向数据资产

企业技术架构的变迁，引发了运维管理方式的变革，同时运维工具也在不断与时俱进。

从总体而言，IT系统运维正朝着自动化和智能化的步伐不断走下去。作为IT运维工作本身，我认为运维工作难度正在不断下降，运维工作量也在不断下降，毕竟大多数的工作量都交给了机器去完成。作为IT运维者的我们未来的方向，或者说未来的出路在何方呢？

经典的企业架构中，不同的企业架构框架理论虽然角度不同，但是他们对企业架构内容的层次划分大体上还是一致的，基本上都是从如下几个方面（或至少包含如下几个方面）对企业架构进行描述：

一般自上而下会分为业务架构、应用架构、数据架构和基础技术架构。传统上的IT系统运维的主要对象是企业IT环境中的各种硬件及软件平台，例如，各种主机、存储、数据库、中间件等。企业IT运维团队一般主要集中于技术架构层面以及少量应用架构层面（见图1-6）。

图1-6 TOGAF开放群组架构框架的企业IT架构模型

然而，时代在不断向前发展，企业中的基础技术架构在革新，云化、开源化、高弹性互联网架构技术架构逐步成为企业架构主流，大量新技术的涌现和应用，使集中式中心化的系统架构被打破，系统架构日益趋向云化和分布式架构。

首先，分布式的架构和云化的架构使得系统单点被打破，在整体数据稳定性提升的情况下，单一设备稳定性的需求下降。在这种前提下，数据架构方面的工作更为重要，需要更多数据架构师和运维人员参与到前期系统业务架构分析、数据架构规划、数据架构设计、数据模型设计等工作中。

其次，如上文中提及运维相关的工具和产品在不断完善不足。集中式、自动化、智能化运维产品和工具的涌现，使IT系统运维智能化、自动化成为可能，将运维人员从重复、机械的工作中释放出来，降低运维人员的工作量，让运维人员承担更为重要的工作。

此外，各种软硬产品也在不断自我完善。各种软硬件产品使用和维护“simple and stupid”成为一种趋势：

 ●  例如Oracle数据库在Oracle 9i的年代，安装完数据库后，维护人员光是内存分配就需要配置一大堆的系统参数；
 ●  过了若干年，Oracle11g推出，一个memory_target告诉它你计划让他用多少内存就可以了，运维已经变得越来简单；
 ●  到了如今，甲骨文在Oracle database 18C的发布会中，提出了数据库自治的理念，号称Oracle成为世界上第一款的自治数据库，其对应的云平台和服务以最低的成本实现了更高的性能、安全和可靠性的需求，并且降低了操作的复杂度，减少了人为误操作的概率，大部分的工作能够自主地完成，减少了手动操作的工作量，令业界发出“运维危矣”的惊呼，尽管实际结果如何还需要拭目以待，但未来的软、硬件产品越来越智能，基本运维难度下降是个不争的事实。

最后，随着信息技术特别是物联网的广泛应用，网络购物、移动支付、共享经济、智能家居等新业态新模式的蓬勃发展，全球数据呈现爆发增长、海量聚集的特点，每年都产生比以往更大量、维度更丰富的海量数据，采取更好的数据管理方式，更好地利用数据，构建以数据为关键要素的数字经济，核心就是数据资产管理。

在数据资产化的趋势下，企业IT系统运维的重点必然从单一的保稳定，向数据资产变现、增值等更高的数据资产管理运营要求。

业务方数据资产应用问题重重

但是，目前制约企业数据资产应用的问题还有很多。

 ●  很多传统企业，由于其自身的特点所致，企业没有专业高度集中的IT系统建设和管理体系。分散式的IT系统建设，造成竖井式或者烟囱式的系统。企业内部IT系统建设缺乏规范的数据标准和制度，造成数据质量低下，连基本数据集成和共享都显得困难重重，就更难以进行进一步的数据分析、挖掘、数据变现等行为。数据零散而分散，产生大量相互独立的数据壁垒，难以充分发挥数据的协同效应，扩大数据规模，进一步增加数据分析和交换价值。
 ●  在当前传统企业，受限于资金、技术能力、人员编制等诸多方面的限制，IT系统建设大多以外包开发为主。IT系统从规划设计、开发、上线到日常运营的整个生命周期过程中，外包开发对技术架构、数据架构、应用架构甚至业务架构起主导作用。这种企业IT系统核心掌控能力的下降，亦使得许多传统企业逐渐失去对数据资产的主导权和控制力。

企业数据变现的能力弱，数据应用和运营专业技术能力不足，就很难完成预测数据的应用场景。

运维人员的工作未来趋势

运维人员作为IT技术与业务之间的接口，必然要求运维人员向上走，走向数据资产管理的层面。

数据资产管理是规划、控制、和提供数据这种企业资产的一组业务职能，包括开发、执行和监督有关数据的计划、政策、方案、项目、流程、方案和程序，从而控制、保护、交付和提高数据资产的价值。离开高质量的数据，企业难以做出明智及有效的决策。

在大数据时代，数据资产管理比传统时代更加重要，它为企业提供一个透明、可靠和高质量的数据环境，它将成为企业的核心竞争力，帮助企业提供更精准的产品和服务、降低成本并控制风险。我们将企业数据资产管理总结为数据资产管理五星模型，它分为5个相互关联的层面，分别是数据架构、数据治理、数据运营、数据共享与数据变现（见图1-7）。

图1-7 新炬网络数据资产管理五星模型

时代在变，运维人员的工作重点也需要因时而变，这是一个不变的规律。以数据资产为核心，以治理和运营为手段，以共享和变现为目标，是未来企业运维人员从基础设施运维走向以数据资产为核心的运营和运维的总体趋势。

五、总结

经过近年来的发展，企业IT应用系统建设和运维逐步从面向企业业务为中心转变到面向客户为中心。传统的IT架构、运维模式、运维体系甚至于运维对象都受到不同程度的冲击和转变。

在这个转变的过程中，企业IT运维面临着不断叠加的业务需求、应用需求交付周期不断缩短、不断提升的用户体验要求、数据资产价值增值提升等问题。按需而动，成为了当前企业应用系统变革主题，这就要求企业要有一个更具弹性和高度扩展性的IT技术架构，更为敏捷而高效的运维体系以及更具智能化的运维工具体系，才能更快捷地响应来自于用户端的业务需求，把满足用户的核心需求作为全企业的共同愿景。

同时，智能化的运维工具体系以数据化运维为基础，通过大数据、机器学习及更多高级人工智能等分析技术，提供具备主动性、人性化及动态可视化的能力，直接或间接地提升目前IT运维的能力，以更多自动化运维操作解放运维人员，让运维人员有更多地投入到其他如数据分析等工作中，推动企业核心业务的发展。

最后，企业的IT系统运维的重点从技术架构回归到信息本身。企业需要高质量、可靠的数据为其决策支持、运营管理、风险控制、产品提供、营销活动等服务。运维人员从角色而言处于技术与业务的结合点上，是企业数据资产理想的管理者和推动者。运维人员的运维重心在未来很大程度上将从技术架构转移到数据架构之上。

运维的变革将从技术架构、运维体系、运维平台以及运维核心四个维度循序展开，按需而动、智能化以及数据驱动是未来IT运维的总体趋势。

原文发布时间为：2018-10-15

本文作者：梁铭图

本文来自云栖社区合作伙伴“DBAplus社群”，了解相关信息可以关注“DBAplus社群”。