文档更改1.4.2 服务管理实践
由 superadmin 于 2024/04/07, 18:41 最后修改
修改评论
上传新附件image-20200615165118-1.jpg
Summary
Details
- Page properties
-
- 标题
-
... ... @@ -1,1 +1,0 @@ 1 -1.4.2服务管理实践 - 父
-
... ... @@ -1,1 +1,0 @@ 1 -D 《ITIL 4服务管理认证考试指南》.第1章 ITIL 4学习和实践导读.1\.4ITIL 4的实践方法.WebHome - Content
-
... ... @@ -1,77 +1,0 @@ 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”、“互联网 +”这些字眼来学习新的方法,而是从业务价值的本质出发, 来看待和逐步掌握这些方法。尤其中国的组织多样性很强,例如银行,它们不仅要面对业务拓展,更面临银监会的监管;又如政府单位没有财务回报的说法,但是为民众提供服务正是政府单位的业务价值。这些才是我们需要关注的价值点。
- image-20200615165118-2.jpg
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin - Size
-
... ... @@ -1,1 +1,0 @@ 1 -869 bytes - Content
- image-20200615165118-3.jpg
-
- Author
-
... ... @@ -1,1 +1,0 @@ 1 -XWiki.superadmin - Size
-
... ... @@ -1,1 +1,0 @@ 1 -37.5 KB - Content