Changes for page 1.4.2 服务管理实践
Last modified by superadmin on 2024/04/07, 18:41
Summary
Details
- Page properties
-
- Title
-
... ... @@ -1,0 +1,1 @@ 1 +1.4.2服务管理实践 - Parent
-
... ... @@ -1,0 +1,1 @@ 1 +D 《ITIL 4服务管理认证考试指南》.第1章 ITIL 4学习和实践导读.1\.4ITIL 4的实践方法.WebHome - Content
-
... ... @@ -1,0 +1,77 @@ 1 +服务管理实践大部分上是 ITIL 原有的设计,总体上全面承接了 ITIL v3/2011 版的内容,其中许多实践已经成了业内的事实上标准,我们先看一下: 2 + 3 + 4 +* 可用性管理(Availability management) 5 +* 业务分析(Business analysis) 6 +* 容量与性能管理(Capacity and performance management) 7 +* 变更控制(Change control) 8 +* 事件管理(Incident management) 9 +* IT 资产管理(IT asset management) 10 +* 监控与事态管理(Monitoring and event management) 11 +* 问题管理(Problem management) 12 +* 发布管理(Release management) 13 +* 服务目录管理(Service catalogue management) 14 +* 服务配置管理(Service configuration management) 15 +* 服务连续性管理(Service continuity management) 16 +* 服务设计(Service design) 17 +* 服务台(Service desk) 18 +* 服务级别管理(Service level management) 19 +* 服务请求管理(Service request management) 20 +* 服务验证与测试(Service validation and testing) 21 + 22 + 23 +同样,并非所有的服务实践都要被采用,而是要按照具体业务活动场景来进行科学组合。不过, 从下表可见,如果一个组织能把这些实践都落地了,那已相当伟大。为了便于大家比较,我们制作了一张对应关系表(更详细的比较关系,可以参见 FAQ 章节),把这个部分的内容与 ITIL 以往的版本以及北宙研发的用于一体化运营管理的V-PODAT 进行对应(如下表)。(√表示一致,≈表示有所涉及,空白表示不涉及) 24 + 25 + 26 +表1-2:ITIL 4服务管理实践与标准、方法论等的对应关系表 27 + 28 +|((( 29 +ITIL 4 30 + 31 +服务管理实践 32 +)))|((( 33 + 34 + 35 +ITIL v2 36 +)))|((( 37 + 38 + 39 +ITIL v3/2011 40 +)))|ISO20000 2005/2010|ISO20000 2018|((( 41 + 42 + 43 +V-PODAT 44 +))) 45 +|可用性管理|√|√|√|√|√ 46 +|业务分析| |≈| |≈|√ 47 +|容量与性能管理|√|√|√|√|√ 48 +|变更控制|√|√|√|√|√ 49 +|事件管理|√|√|√|√|√ 50 +|IT资产管理| |≈| |√|√ 51 +|监控与事态管理| |√| | |√ 52 +|问题管理|√|√|√|√|√ 53 +|发布管理|√|√|√|√|√ 54 +|服务目录管理|≈|√| |√|√ 55 +|服务配置管理|√|√|√|√|√ 56 +|服务连续性管理|√|√|≈|√|√ 57 +|服务设计| |≈| |≈|√ 58 +|服务台|√|√| |≈|√ 59 +|服务级别管理|√|√|√|√|√ 60 +|服务请求管理|≈|√|≈|√|√ 61 +|服务验证与测试| |√| | |√ 62 + 63 + 64 +从这张表中可以看到,相比来说,ITIL 4 并没有颠覆以往太多的实践或流程,这是有利于企业平稳过渡的。但我们可以看到,ITIL 4 没有像许多人所说的一样,对 DevOps 的一些方法采用“简单粗暴” 的引用,而是很沉着地继续为服务价值的实现扎扎实实地做贡献。但这不等于说它没有变化,例如下图 : 65 + 66 +| 67 +| |[[image:image-20200615165118-3.jpg]] 68 + 69 +图1-9 敏捷与传统方式下的发布管理 70 + 71 + 72 + 73 +这图表明在发布管理中,应该充分关注不同的发布需求,据此选择不同的模式,是传统瀑布模式, 还是敏捷 /DevOps 模式呢?敏捷 /DevOps 模式可以让我们方便地实现蓝绿部署、金丝雀发布等降低风险的发布方式。之所以 ITIL 4 提出将发布和部署分开,是因为 DevOps 的灰度发布模式已经将发布和部署活动分开了。例如,我们可以通过蓝绿部署做到低风险发布,假定蓝环境是生产环境,而绿环境是类生产环境,首先我们可以在绿环境中部署新版的应用程序(此为部署实践的活动),然后通过路由切换,将蓝环境下线,同时将绿环境上线,让用户可以正式访问(此为发布实践的活动)。 74 + 75 + 76 + 77 +不过需要特别提出的是,在过去的很多年,“炒概念”是一种社会现象,无论是企业还是投资方, 虽然从中牟利者不在少数,但因此受创的恐怕更多。所以我们建议读者应“修身养性”,不是为了“数字化”、“DevOps”、“互联网 +”这些字眼来学习新的方法,而是从业务价值的本质出发, 来看待和逐步掌握这些方法。尤其中国的组织多样性很强,例如银行,它们不仅要面对业务拓展,更面临银监会的监管;又如政府单位没有财务回报的说法,但是为民众提供服务正是政府单位的业务价值。这些才是我们需要关注的价值点。