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