一、新IT应用的出现影响了IT运维服务模式

IT服务管理在整个信息化里面是很重要的一个环节。所有的企业如果你有信息系统那就涉及到运维、涉及到技术支持，就有服务这个概念。我们知道，整个信息化生命周期首先从需求开始，业务需求出来了之后我们要把它论证立项。对于很多成熟企业来说需求立项不是一个一个完全独立立项的，有一个对需求进行统一规划的过程，规划又有不同的规划方式，有策略层面的战略规划，再细一层是支撑层面的架构规划，再到具体项目规划。上一本书我们写的就是“变革时代企业的IT战略与实务”。规划完成后，IT建设项目包括：应用系统、基础设施、流程梳理等等项目或任务就出来了。这些项目的建设实施过程就是项目管理过程、系统实施过程，实施结束后系统一上线还需要有持续的运行维护，不是建设完毕整个系统的工作就到此为止了，IT系统运维管理这个过程更长久。为了更好的完全运行维护工作，业内提出了IT服务管理的概念，英国商务部最早提出IT服务管理的标准体系ITIL，ITIL在1.0版本的时候就被公认为是IT服务管理的最佳实践。

一开始IT服务管理关注的是IT运维这个环节，一般来说IT服务管理很多还是落在运维这个环节，运维管理跟IT服务管理有些人在概念上搞不太明白，前段时间有一个培训机构，它说我的用户要培训IT服务管理，有时候他又说是做IT运维管理，什么是IT服务管理、什么是运维管理，什么关系？我举个例子说这两个观念。假如我们做身体理疗保养，有小姑娘给你按摩，对于这个小姑娘是在做按摩这事，从顾客视角来说就是在为顾客进行保健服务。运维管理跟IT服务管理就是类似这样的关系。对于做系统维护支撑的人来说，他本身在做的是系统运行维护工作，对系统用户或业务人员来说就是对他们进行IT的服务，可以这样理解。

后来ITSM的标准体系ITIL发展到2.0，甚至到现在的3.0，ITIL的框架很大，想覆盖的范围不止在运维环节，往前提，覆盖到IT战略、以及IT系统建设，都被纳入了ITIL3.0的框架，用ITIL体系或ISO20000，现在目前还是最适合运维这一块。前面IT系统建设管理环节有CMMI、PRINCE2等专业框架，再往前IT规划有战略规划的相关方法，如企业架构，所以说ITIL野心大想COVER信息化生命周期的全过程。在应用的实践中，买帐的用户不多，IT标准体系的应用面实际是有细分的。那对于覆盖面更全的COBIT，只是做IT审计比较实用，虽然涵盖全面的信息管理过程，但只是列出了管理的关键内容清单以及关键点，但是每个环节怎么做并没有告诉你，所以这些框架标准都是有应用场景区别的。

今天我们还更多的关注在运维这个环节的IT服务管理。对于IT运维管理，也可以说IT服务管理也是在发展的，现在是互联网+时代，“新IT”应用的出现，IT运维服务模式也在变化，同时IT运维管理本身它也在一点一点的提升。

二、传统的IT运维服务1.0和解决方案

今天下午我探讨的第一个问题是：企业IT运维管理面对的问题和挑战，以及针对它的解决方案。现在任何一个企业不管你提不提IT服务管理，去规范不规范IT运维管理的流程或者IT服务管理流程，但IT部门运维人员面临的压力总是有的，总是有这样那样的问题。所以说，我们无论写书还是做什么，我们一线CIO不搞理论研究，总是要针对问题来谈解决方案，这也是李炜总说的写书的要求，我们一线的CIO能把我们经验和体验，我的真情实感，工作中的切身感受写出来，这些内容肯定更容易打动人，实际上实践比理论更有感染力。

下面看一下实际遇到的这些问题，这些问题延伸出去，每一个问题都可能写一篇文章或一本书。我们知道尤其是企业，传统企业IT系统越建越多，多而杂，而且各种各样的技术规范都可能有，非常乱，这样造成IT运维支持比较困难，出现问题故障定位比较慢，在IT服务管理有一个叫做事件，这个事件包括故障，可能是你的系统用户提出的各种各样的需求或要求。故障定位慢，而且故障频繁发生，出了问题故障找不到人，谁去做？所有这些问题对于我们IT人员来说、IT部门来说，这些压力实际上都放在IT运维人员身上了，IT运维人员压力特别大，大到什么程度？有人做过统计，运维人员基本上65%睡不好觉，在一个企业做运维是最痛苦的一件事。平时你要是不出事谁也不知道你，领导看不见你，因为你做的都是日常琐碎的事情，但是一旦出了事情，麻烦就大了。所以IT运维人员在企业做信息化这些岗位里面是非常辛苦的一个岗位。做了很多在背后的别人看不见的工作，一出事找挨骂的首先是IT运维服务人员。

同时没有好的工具去支撑，因为现在很多企业，老板、高层管理人员对信息化建设的认识很浅，他就觉得系统上线了，软件上线就OK了，实际上后续持续维护投入更大，他不关心后边的维护，只关心系统上线没有上线，只关心应用，有很多企业停留在这个层面。你说给他建一个ITSM流程或支持系统，这有什么用，且要花很多钱。我看了一下李总做的调研有40%以及的企业没有制定IT运维管理流程，还没有ITSM这个概念。当然，金融和电信行业IT运维管理确实走在前面。但是大部分企业别说运维工具可能流程都没有规范。没有这些工具，没有标准化的流程，出现故障问题确实很难定位的。刚才也谈到IT人员业绩怎么衡量，出了事找你，平时看不见你，你怎么能够在领导面前体现你的工作成绩，这都是我们IT部门运维管理所面临的问题。

针对这些问题我们谈IT运维管理，或者IT服务管理。低层面水平，首先解决IT部门遇到的困难，就是为IT人员解决压力问题的。一开始主观上要为IT运维人员来解决这些问题和困惑，客观上它也提升了IT服务质量，提升了运维水平。一会儿我会总结一下，站在IT部门视角规范IT运维流程，提升IT服务管理水平，我觉得都是属于IT运维1.0阶段（我大标题是IT运维2.0）。站在IT视角看待与解决这些问题，提出的解决方案都可以视为IT运维1.0阶段，有这些特点：启动IT运维管理标准化项目往往是IT部门主导来做的，解决自己的问题和困惑。怎么解决？解决方案是什么？

首先最好有工具，先把系统监控起来，出现问题我及时发现，或者实时发现，实时响应，IT资源一体化监控。软件、硬件，首先基础设施要监控起来。咱们的服务器，还有存储、操作系统层面、中间件、数据库等等，更高层面应用的监控等等，对于APM，这是更高层面的，至少你要把基础设施层面监控做起来，然后再延伸到软的层面。

有了这些监控，监控能解决什么问题？它可以及时的发现故障问题，同时发现了问题之后可以直接转到运维人员去处理。处理接收问题事件的过程要有一个规矩，没有流程规范会乱的，那么多系统，各个系统各个环节都报出来问题怎么处理？IT细分专业领域很多，有网络的、硬件的、软件的、数据库DBA的、还有应用层面的，这么多不同角色、不同专业怎么去协同响应这个问题？就需要有一个规范的流程，这在ITIL，或者ISO20000里面有最佳实践，最好流程方式。无论什么最佳实践，到企业都要结合企业的具体情况，具体组织和岗位情况，落实下去才能用起来。以上说的是第二层面要建流程。再好一点的会用一些自动化的工具。建了流程还不够，还要有一个平台支撑，用IT技术服务管理的平台，把流程固化划到这个平台来，进一步。可以使监控到的事件问题直接触发事件流程自动响应这个过程。

最后，为了证明IT人员的绩效，可以把运维的成果，服务的水平，什么可用性，系统的响应时间，事件处理效率，都可以通过工具和平台展示出来，可视化让领导看到，有一个量化的考评。这些就解决了我们IT运维人员最关心的问题。

站在IT部门视角，解决运维管理问题系统的解决方案，有几个层面。首先，建立相应的监控和管理平台。这个监控可能一开始硬件层面的监控、再扩展到软得层面监控，再扩展到应用，这些监控不是一下子建立起来的，因为监控系统花钱是很多的，监控投资是很大的。这里还有一个问题，网络监控、硬件监控还有软件监控等，我看了很多解决方案的供应商，都不能把它们完全集成起来，不能一体化，多数都是相互独立的工具，分散的，这也是一个很大的问题。有的软件监控比较强，如专门做APM的。有的可能网络监控做得好，有的可能在服务器、存储方面监控做得好，但是没有一个好的集成平台，把它们一体化集成整合起来，目前还没有某一家供应商能够把监控集成完美的做好。当然，最理想的将来所用监控要是一体化、才是最优的。

有些企业，监控上完了之后，才上流程。当然也有企业先把IT运维管理流程标准化了，同时再上监控，这种先后的关系可行。有了监控体系之后再把流程体系打造起来，这个不是说我必须先上监控再上流程，我可以把流程规范了然后监控上去，流程规范了至少我IT部门运维管理不乱了，上了监控，我可以通过事件触发和事件管理流程挂接上。流程体系做好之后，把绩效服务水平量化一些指标，可用性、问题响应时间、问题处理域量化出来，每一个运维人员的工作量都可以可视化的展示出来。

做流程体系方面，我知道现在有很多企业做了IT运维管理流程，或者服务管理流程也好，他做得是低层面的技术支持流程，像事件管理、问题管理、发布管理这些做了，但是他做得还是比较低层面的。流程体系做得最完整的方式，应该围绕CMDB配置管理，所有IT软硬件资源都在一个数据库里面清晰的展示出来，实物可以跟这个配置库特别清晰地挂接在一起，有些企业虽上了CMDB，但CMDB所有软硬件配置信息跟实物对接不上，CMDB没有用上。如果CMDB没有真正做好用好，即使你做了标准化流程，也停留在很低的管理层面，只是有一个事件问题的处理的流程响应过程，但不能与系统配置不能与实际IT资产有一个匹配。

还有为了让我们系统用户自助完成处理一些事件或问题，假如说一个简单的故障经常发生，找到的处理方理，可以整理到知识库里面，把这个事件我怎么解决，这个问题我怎么解决，写成案例，这就是运维知识库，知识库就是为了支持用户自助，同时给IT运维人员，更多的是给一线支持人员提供一个参考，使他处理事件问题更快。知识库的积累需要有一些规则，让这些运维人员不断总结这些案例写进去。

以上就是传统层面，站在给IT运维人员减压，主观上减压，同时客观上也提升了用户响应的服务水平的层面，所考虑的一个完整的体系框架。我觉得只是这样的解决方案，还是停留在我把它称做的IT运维1.0阶段。基于这个体系，我这有一个完整的图，是这种运维模式下IT部门理想的工作蓝图。

我刚才讲的这两张图，对于你想做IT运维管理服务的这样一个咨询商也好，实施商也好，有这两张图说服客户足够了，传统IT运维理想模式就是这样的，这个足够了，这个特别清楚。

从这张图，咱们先从系统用户这边说，用户一般通过一个IT热线集中的呼叫进来到服务台，IT热线的服务台，出了故障或者有什么需要支持的需滶，走事件管理流程。这个事件如果经常发生，就会被总结提炼形成问题，就是问题管理流程。如果重大问题涉及到变更，变更还有大小，小变更，变更一个配置简单了，如果重大变更，系统要升级，要做模块开发，这就是新需求，就会产生新IT项目，新项目过来走新项目建设流程。无论是事件、问题、还有变更，最好基于一个配置管理CMDB这个基础。在这个核心、基础之上最好再近一步，能够实现自动化的实时的事件触发。这是基础设施的监控，还有软件层面的监控，有了这些监控，再通过一个事件引擎，直接触发走事件流程，这就有一点自动化的能力。对于用户来说还可以自助，自助通过什么？后边有一个知识库，你看这个蓝图是不是很理想了，我觉得IT运维1.0阶段，这已经是很理想的模式了，这张图特别关键，特别能说明问题。同时做的好不好，还有KPI服务质量管理。

以上说的流程和模式层面的内容，需要一些技术平台支撑，这个技术平台大概有哪些内容？有软硬件的监控，包括数据采集、事件集成等等，无论是监控还是前面的服务管理流程，以及有些软件的自动分发、配置变更、自动化触发都需要一个最核心的CMDB，所以CMDB有没有真正用起来，是考验一个企业运维水平提升的最关键的一个环节。虽然有很多企业上了一些基本管理流程，但CMDB是假的没用，那它后续再提升就会很难，把上图那个完整蓝图实现就很难，因为它配置库里面跟实际资产对不上来，不能给运维人员以及流程自动化提供就基本的可信支撑，用起来的CMDB才能给运维人员提供最大的支撑。这里可以看到，包括服务水平KPI也都可以展示出来。

以上说的是IT运维1.0理想模式，以及IT服务管理技术支持系统架构。现在，能做到这个层次的企业真的不是太多，多数企业停留在1.0阶段的低层次，甚至很多企业还没有关于IT运维管理的优化。

三、互联网+时代企业IT服务管理面临新挑战

到了现在的“互联网+”时代了，“新IT”出现了，在这个时代看看我们又面临哪些挑战？这个时代有什么特点？就是变化快。要快速响应市场与竞争。而且企业不仅要快速响应市场，而且直接与用户或者客户交互了，以用户、客户为中心，当然要求系统建设同样以用户为中心，直接跟用户交互。所以要求在系统层面，提供更敏捷的、好用的系统。在业务模式上，业务模式设计上又是什么情况？创新的业务模式，怎么创新？它是动态的，多变的？因为直接面对用户，现在都关注用户的体验，用户体验要好，才会经常用你的系统，与你企业关系就会更加紧密。

技术层面又有什么新东西？IT系统部署模式变了，云方式。原来我们建系统有一个复杂的实施过程，要安装部署，还要配置推行实施。直接用云的布暑模式，如系统的用户体验好，直接用就好了，在端不用装任何的东西，很简单。然后客户在用这个系统的云端就会积累大量的数据，同时收集更多相关的数据，针对数据处理进行分发响应，就是大数据的应用。而且端的层面是移动化的，用户随时随地可以使用。大数据驱动之后它有一定预测的功能，它可以前瞻性的看到一些趋势，前瞻性的给你提供一些指导，基于这种模式，将来公发展到智能化。

因为系统部署方式变了，系统开发方式也变了，就提出一个新的概念，叫做开发运维一体化，Devops，一会儿我阐述为什么提出这个东西。

总之，在互联网+时代传统企业要转型，所以它的IT架构也要变，IT架构变成互联网的化的架构了，这个架构原因可能你企业客户不直接用你的系统，现在直接用你的系统，互联网的方式。这时候要关注用户体验用户感知，用户体验好经常用你企业的系统，跟你企业发生关系，企业价值才能更好体现。基于新IT架构模式，IT系统故障怎么定位，怎么提高IT服务管理水平？

四、IT运维2.0：基于用户感知立体智能运维

基于以上思考，我总结提出IT运维2.0。将来运维2.0阶段是什么样的？就是直接面向用户体验、用户感知的立体化运维。将来系统在支持运维的时候，不是说站在主要给IT运维人员减压的视角解决问题，我要站在用户视角让他有很好的体验，如在他的视角体验不好了，或者他感知到有什么问题，很快可以追溯到问题原因发生在哪？可以举一个例子，两个视角不一样。原来运维是什么？原来运维往往关注的是监控IT系统本身，一个网络断了，我们首先直接知道网络断了，然后再评估这个网络影响哪些系统、哪些用户群，原来IT运维人员经常是这样。将来这个思路应该转过来，首先用户感觉到系统不能用了，然后IT运维很快就能定位是停电、还是说网络出的问题，还是出其他问题，是直接面对用户视角响应的。直接监控用户体验、应用层面、甚至业务交易，然后看是软硬件等其它环节究竟那个环节出了问题，是中间件出问题，还是服务器、存储、还是网络出了问题。

所以要建立以用户为基点，以应用为牵引，再把应用布署的平台环境，如：中间件、数据库、操作系统、服务器、存储等等给它的立体化的串起来，建立起真实的立体联结关系，刚才我为什么说CMDB非常关键，CMDB把现实资产情况列出来，但是CMDB没有完成一个工作，就是把这些资产的关系都立体连接起来，将来会发展到这一步，站在用户应用的角度，把所有IT资产全给它清晰的建立起立体化的、网状联系。这样，等站在用户视角，问题出来后，运维人员很快可以定位，就是要做到这样。所以IT运维2.0，总结一下，就是面向用户体验、业务感知的立体化的运维。方向已经变了，不是再关注解决我IT运维人员压力的问题。

基于这个将来IT运维管理或者服务管理，它的技术支撑平台就多了很好内容。在1.0服务支持技术架构的基础上，集中监控要有APM，是基于用户感知的APM，听云就是做这个，你用户用我系统，你体验不好了，可以给你追踪那个环节出了问题，这APM叫做应用性能管理。还用运维大数据，我们监控到的这些数据信息、还有业务服务管理流程在运行过程中积累的数据，系统日志以及巡检的数据，所有数据汇集起来在运维大数据库，通过数据建模、算法分析、知识发现，建立起根源分析、知识发现、事件预警。将来巡检可以采取自动化巡检手段，自动化巡检现在有一些工具，当然有些硬件设备本身就有智能化元素了。如，智能化的网络交换机，数据中心机房里也会有智能化的传感器实时监控，甚至有人提出来运维将来是不是可以用机器人？当然可以想象。如果我系统本身可以自组织，本来就智能化了，将来运维人员都可以不要。如果将来我做到预测式运维，这个系统要发生什么问题，什么时间发生问题，我提前几天知道，提前就去处理了，系统就可以不会出问题了，运维人员就大大减少，还搞运维机器人干什么。

针对具体的工具，现在比较热的应用性能管理工具，做什么？站在用户视角追溯，如果用户感知不好出了问题了，追溯后面IT资产哪个环节出现了问题，多层次分析。做这个追溯要基于两点，基于应用层面它们什么关系要知道，基于CMDB 把IT资产之间的关系要建立联系，建立联系方式目前有两种，一种是人来识别的，把它录到库里面，还有一些监控探针有算法自动的建立关系，即使是通过智能探针建立这种自动关系，也可能能建立的不全面，有时还是要靠人去补充进去。

对于大数据的应用，大数据可以通过历史数据分析，分析到每一个环节每一个设备，它发生故障的规律，发生问题的规律。这样就可以设阀值。CPU利用率如设一个值80%应该报警，到时就提前预警了。存储的容量以及其它方面都可以这样做，到利用80%就提前告警，提前告警，你有足够的时间去提前处理，整个系统客户的体验，还有运维人员也会特别的从容，大数据应用就会起这个作用，可以做各种各样的分析，最终提高的是用户的体验。

现在在金融行业、电信行业确实有很多企业都已经着手这样做了，我说这些东西不是没有做的，我知道已经有些金融机构已经在做了，虽做得没有我说得这么理想，但是已经开始了。这些监控，包括用户的感知，基于感知后边的监控。还有包括交易，它不止监控到用户感知，还监控到系统里面应用层面交易的发生，根据监控做运维相应的预案。而且这种监控出来的是有实时的，还有预测性的。运维实际有三个层面：一是响应式运维，出了事我就响应，这是最低的。第二层面通过监控可以实时，我监控出来的问题实时处理，这是状态运维。还有更高级就是通过大数据应用、智能化分析，实现的是预测式运维，没有出事我就那个环节会出事，提前去处理，系统不会出问题，预测式运维就是IT运维2.0阶段了。

再谈谈Devops怎么提出来的？Devops真的不是什么新东西。它讲运维人员跟开发人员有一个紧密联系。我们做信息化都知道，一开始做信息化人的很多企业，在刚上系统的时候，开发系统的人很长一段时间要负责运维。ERP系统上线了，这些负责实施上线的ERP人员，要很多时间坚守在运维的岗位上，那是不是运维人员跟开发人员紧密的结合？那是不是Devops？我觉得算是一种Devops。我觉得这绝对不是新概念。为什么要紧密结合？因为系统刚上线大家都不熟悉，总要变来变去，打补丁，所以传统信息化就存在Devops这种维护方式。如果都照这个方式，每个系统要上线，有一百个项目，就会有一百组IT人员坚守维护工作，浪费成本。所以，最后提出一体化运维，专门构建一个负责运维组或部门，运维负责运维的，实施负责实施的。

到互联网+时代，什么样背景提出新的运维人员、开发人员紧密结合？是这样一个情况，基于互联网化或者云化环境的系统有一个特点，业务变化特别快，系统是迭代式开发从1.0版本、2.0版本是迭代的特别快，这与原来传统上线一个系统不稳定总要打补丁一个道理。不但迭代式开发，系统架构也微服务化，松偶合，IT应用单元化了，单元化之后你在去修补和运维的时候，可以按小单元去做，你变更、发布一个小单元体对整个系统影响小，所以你就没有必要像以前那种模式，运维跟开发有那么强的边界了。

原来我们做IT运维，假如说一个传统一个系统出了故障要做变更、或做升级，要走一个复杂的升级流程。那个复杂流程有七八个人审批，一个新软件版本或打一个补丁叫做重大变更，审批人员很多。在Devops模式下，单元体微服务，每一个小单元体我升级的时候影响很小，变更管理、发布流程不需要那么多人审批了，就会更便捷、快捷，解决要求快的问题。所以Devops是什么新东西吗？我觉得不是。所以现在很多做Devops咨询，这讲课那讲课实际上好象没有那么复杂。

现在“互联网+”时代有一些新词，最近我跟互联网开发人员联系的很紧密，都是80后90后小孩。原来我们传统做系统需求分析的，叫做系统分析师，需求分析师，互联网公司现在叫做产品经理。我以为互联网提产品经理有多高大上，实际上主要是做需求的。

现在我们探讨一下对于传统企业IT架构的转变，你看底层，这是后台历史系统，有ERP、生产管理等等这些历史的系统。还有互联网化的应用，就是针对直接的企业客户或者用户，做一些电商交易、下单、销售、营销这些东西，直接采用互联网化的IT架构。但是现在有一个提法，而且有些企业更极端了，还要去ERP，把整个传统系统全微服务化，这种提法有点“太前瞻”了。传统企业互联网架构的变化分前台、中台和后台。后台我们原来历史系统不是一下子可以去的，ERP里面财务系统至少去不了，对于财务系统，你给它微服务化有意义吗？没有意义，因为财务系统就那么几个人用，不涉及到大并发，不需要你响应有多快，所以不可能所用的IT系统都互联网化，微服务化，要看哪些系统适合做。互联网应用直接对客户前端可能需要一些微服务，那也不是所有架构都做微服务。后台系统至少一段时间内要存在，这就会涉及到运维模式上，两种模式都可能存在。

前端因为是云架构部署、互联网微服务，可采用一些新运维理念，Devops，这些负责开发的人也要负责运维，可能都是一帮人，小的互联网公司哪分那么严格，开发的、测试的、运维的，根本没有那么严格的分法。对于传统系统就要走传统的运维模式，传统系统你要做变更对业务影响会很大，你没有严格变更审批流程，没有严格的发布流程，出了事谁承担？尤其像金融行业。最近我做几个银行项目，跟他们银行IT人员探讨这个问题，我说现在Devops这么火，你们讨论这个事吗？他说我们不敢那么激进，你不严格控制变更流程，发布流程，出了事我担不起。

总结一下，IT服务管理或者说运维管理，本身的发展规律。我总结就是从1.0过渡到IT运维2.0，现在很多前瞻性的企业已经探讨到2.0阶段了，包括：智慧化运维、大数据驱动等等这些东西，而且是站在用户感知视角的立体化运维，刚才说那个IT资产网络化联系要建立起来。

在运维1.0阶段，一开始运维是被动式的，出了问题响应，首先要把流程先规范一下，把IT组织岗位梳理一下，同时上一些监控。在1.0第二个阶段监控完整的上了以后，就可以做主动运维了，主动运维就是实时状态运维。实时监控到自动触发事件流程就是一个自动化的方式。将来运维2.0会是多模式自动化运维，监、管、控一体化，直接面向用户、关注用户体验、业务感知，实现IT服务的自动化、智能化，就是这样一个发展过程。

对于Devops，如果你将来应用完全是云部署，微服务化的，运维就会是Devops模式。如果你还有传统的IT系统在支持业务应用，我觉得全变成Devops这种模式是不现实的，所以将来是种多运维模式并存的。

IT运维提升有它自身的规律，1.0、2.0，1.0还分两个阶段。现在有很多企业基础不同，有可能处于1.0阶段，也有可能在探讨2.0阶段，究竟企业IT运维怎么搞？我觉得这个提升要做两件事。一个是要做IT服务管理体系设计，包括流程、组织、还有技术支持系统需求梳理，并进行IT服务管理的技术支撑平台架构设计，然后选择供应商进行实施。因为我是做咨询的，最后我给自己吆喝吆喝。IT服务管理体系的设计咨询很重要！抛砖引玉，我建议书的名字，是否前瞻些，叫IT运维2.0。

现在时髦1.0、2.0、3.0，或者可以叫智慧化运维。运维是IT专业里面最普遍的，所有企业都要做运维，做运维人员都要拿ITIL证书，IT运维咨询是在IT咨询里面是很低端的咨询，恰恰养活的小咨询公司是最多的，因为运维太普遍了。恰恰搞企业架构的活不多。