您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iProcess 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 

     
   
 订阅
  捐助
IT运维2.0:互联网 时代企业IT服务模式
 
532 次浏览     评价:  
 2019-3-22
 
编辑推荐:
本文来源个人图书馆,本文结合很多企业的IT运维管理的现实问题,我们看一看怎么去应对解决?然后看看在企业IT架构互联网化的转型升级过程中,IT运维领域正在探讨的一些新话题是什么。

一、新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咨询里面是很低端的咨询,恰恰养活的小咨询公司是最多的,因为运维太普遍了。恰恰搞企业架构的活不多。

 

 

   
532 次浏览  评价: 差  订阅 捐助
相关文章

DevOps转型融入到企业文化
DevOps 能力模型、演进及案例剖析
基于 DevOps 理念的私有 PaaS 平台实践
微软开发团队的DevOps实践启示
相关文档

DevOps驱动应用运维变革与创新
运维管理规划
如何实现企业应用部署自动化
运维自动化实践之路
相关课程

自动化运维工具(基于DevOps)
互联网运维与DevOps
MySQL性能优化及运维培训
IT系统运维管理