欢迎来到天天文库
浏览记录
ID:38117911
大小:33.00 KB
页数:5页
时间:2019-05-25
《运维从设计开始》由会员上传分享,免费在线阅读,更多相关内容在行业资料-天天文库。
1、运维从设计开始从接触ITIL到ISO20000实施,再到ITSM工具的规划与实施,中间经历了一段学习过程,也经历一段较长的思考过程,以前更多是着眼于某个流程的内部设计,然后是各个流程之间的接口设计,渐渐的开始更多想的是一些框架性的问题了,这里头倒也没有一个非常完整与成熟的想法,只是越发为ITIL或ISO20000是不是能真正解决当前IT应用的问题而感到困惑,于是便有了本文的产生,以记录与启迪思考。ITIL(无论是哪一个版本)、ISO20000、COBIT、ISO27001,这些都是IT服务管理的范畴了,但这些方法论或标准都是面向
2、服务过程的,即根本的一个事实是,当应用这些方法论时,你的服务对象(你可以理解为IT设施,或网络、数据中心、应用系统等等)已经布署完成,这些方法论永远面向是服务对象的后续生命周期,而此时服务对象已经很大程度上固化下来了,这种情况类似于:现在有一个非常成熟的方法论去规范管理汽车的售后服务过程,但汽车的前端过程,比如象设计、制造都没有覆盖到,在这种情况下,汽车的使用与服务能得到最好的保障吗?客户享受到更好的驾驶体验,决定性的是后续的服务过程还是前端的设计制造过程呢?。许多情况下,当服务对象的设计与布署的前端过程中的问题会造成后续服务过
3、程的永远的痛苦与挣扎,许多在服务过程中不断碰到的问题,事实上如果在设计与布署过程中考虑到了的话,会为后续节省更多的资源与成本,服务管理做得再好,在当前的框架内是无法渗透到前端的设计与布署环节的,这就面临着,当服务对象的前端过程做得不好时,服务管理能做的只是“维系”一个现状,甚至无法把服务过程中的知识经验反馈到前端过程,形成一个闭环,这种知识反而是对一个服务主体是最有价值的,比那些事件、问题、变更知识库要有用得多,当前的框架内是没有考虑这些的。尤其当应用系统这种服务对象时,更是如此,虽然有一些小问题可以后续补丁,但有一些根源的问题
4、往往只能忍受着、服务着。CMMI等方法论,是面向软件类的服务对象的前端过程的,但是CMMI与ITIL或ISO20000等上面无法是理论结构还是着眼点亦或者是流程假设都是没有考虑过相融的,变成CMMI只考虑开发过程中的问题,ITIL与ISO20000只考虑服务过程中的问题,服务对象的两个核心的生命阶段的管理可以说是断层与脱节的,也没有一理论框架来解释指导这一个完整的生命过程。而且CMMI只面向软件类服务对象,事实上当前的服务对象范围要更广,ITIL3.0开始有比较清楚的服务生命周期的概念,但我认为这是不够的,生命周期的概念不应该是
5、面向服务的,而应该是面向对象的。当前世界需要的是一个面向服务对象的规划、设计、布署、服务的完整生命过程的框架与方法论,这个框架需要完成融入ISO27001这一标准,这个框架应该是完全“面向对象”的,它会提出明确的要求来规范在任何过程的服务对象,不管是软件还是网络亦还是IDC,它会要求在每一个过程如何考虑信息安全,这样才不会导致标准的分裂与无法统一作业的现象,实施过CMMI与ISO27001与ISO20000的人会发现,这几个标准作用于同一个组织时,你会无以适从,非常难以调和。这个大的“IT管理”标准,是可以分层级与结构化的,只有
6、一个成熟而全面的服务商才可能完全实施并得到这个完整的认证,而象一些仅仅面向服务过程的只需要实施并得到关于服务管理部份的认证,重点在于一个完整的标准会真正统一规范IT业,让全世界的IT组织与人员有一个全面的平台作业。当然这个标准的整合力度与难度也可想而知,但我个人相信随着服务管理方法论的成熟与发展,在一个不久的周期后,人们会发现这一服务管理标准的局限性,最后一定会碰到“天花板”,因为很简单一个逻辑在于:我们需要是IT应用的效益最大化,服务管理过程并不能从根本上改变现状,甚至不能从根本上决定服务的质量(因为服务的质量很大程度是由前端
7、过程决定了),加上其它的纬度的标准要求,造成框架性的割裂,统一标准的面向整个服务对象生命周期的方法论出现是必然的选择。上面谈的问题,基本不是一个IT组织或个人可以完成的事情,除非你有IBM与HP这样的资源与理论力量。那么很现实的问题是,在没有一个这样大而全的框架支持的情况下,我们如何做,才能更好的发挥IT应用的效益呢。我们可以从一个IT提供与服务商的角度来看看,看看我们如何可以建立一个小体制来对应框架的缺失,为了避免服务对象的宽泛而无法聚焦说明,我们就以应用软件类的服务对象为例说明。1)在规划设计时考虑运维问题当在规划设计一个应
8、用系统时,在目前绝大多数的软件型项目中(非套装产品),在软件设计时甚少考虑软件日后的可维护性,也很少会在软件功能设计时为维护提供便利性。事实上合理的情况是,首先要着眼于客户的业务分析,同时要结合日后软件布署、维护、升级、调整。有许多系统设计时连上线布署都未考虑,
此文档下载收益归作者所有