文档更改1.4.2 服务管理实践

由 superadmin 于 2024/04/07, 18:41 最后修改

从版本< 8.1 >

由superadmin编辑
在2024/03/28, 17:36上

到版本

由superadmin编辑
在2024/03/21, 16:03上

< >

修改评论该版本没有评论

Raw
已渲染

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -1,347
          +1,75 @@
--(% class="wikigeneratedid" id="H8FD456DEFF1A1.4ITIL476845B9E8DF565B96CD5A096058BFB4E0B4E009875" %)
--[[返回：1.4 ITIL 4 的实践方法>>url:https://www.itil4hub.cn/bin/view/D%20%E3%80%8AITIL%204%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E8%AE%A4%E8%AF%81%E8%80%83%E8%AF%95%E6%8C%87%E5%8D%97%E3%80%8B/%E7%AC%AC1%E7%AB%A0%20ITIL%204%E5%AD%A6%E4%B9%A0%E5%92%8C%E5%AE%9E%E8%B7%B5%E5%AF%BC%E8%AF%BB/1.4ITIL%204%E7%9A%84%E5%AE%9E%E8%B7%B5%E6%96%B9%E6%B3%95/]]    [[阅读下一页>>https://www.itil4hub.cn/bin/view/D%20%E3%80%8AITIL%204%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E8%AE%A4%E8%AF%81%E8%80%83%E8%AF%95%E6%8C%87%E5%8D%97%E3%80%8B/%E7%AC%AC1%E7%AB%A0%20ITIL%204%E5%AD%A6%E4%B9%A0%E5%92%8C%E5%AE%9E%E8%B7%B5%E5%AF%BC%E8%AF%BB/1.4ITIL%204%E7%9A%84%E5%AE%9E%E8%B7%B5%E6%96%B9%E6%B3%95/1.4.3%E6%8A%80%E6%9C%AF%E7%AE%A1%E7%90%86%E5%AE%9E%E8%B7%B5/]]
++服务管理实践大部分上是 ITIL 原有的设计，总体上全面承接了 ITIL v3/2011 版的内容，其中许多实践已经成了业内的事实上标准，我们先看一下：
--======   ======
++* 可用性管理（Availability management）
++* 业务分析（Business analysis）
++* 容量与性能管理（Capacity and performance management）
++* 变更控制（Change control）
++* 事件管理（Incident management）
++* IT 资产管理（IT asset management）
++* 监控与事态管理（Monitoring and event management）
++* 问题管理（Problem management）
++* 发布管理（Release management）
++* 服务目录管理（Service catalogue management）
++* 服务配置管理（Service configuration management）
++* 服务连续性管理（Service continuity management）
++* 服务设计（Service design）
++* 服务台（Service desk）
++* 服务级别管理（Service level management）
++* 服务请求管理（Service request management）
++* 服务验证与测试（Service validation and testing）
--====== 服务管理实践大部分上是 ITIL 原有的设计，总体上全面承接了 ITIL v3/2011 版的内容，其中许多实践已经成了业内的事实上标准，我们先看一下： ======
++同样，并非所有的服务实践都要被采用，而是要按照具体业务活动场景来进行科学组合。不过， 从下表可见，如果一个组织能把这些实践都落地了，那已相当伟大。为了便于大家比较，我们制作了一张对应关系表（更详细的比较关系，可以参见 FAQ 章节），把这个部分的内容与 ITIL 以往的版本以及北宙研发的用于一体化运营管理的V-PODAT 进行对应（如下表）。（√表示一致，≈表示有所涉及，空白表示不涉及）
--======   ======
--* (((
--====== 可用性管理（Availability management） ======
--)))
--* (((
--====== 业务分析（Business analysis） ======
--)))
--* (((
--====== 容量与性能管理（Capacity and performance management） ======
--)))
--* (((
--====== 变更控制（Change control） ======
--)))
--* (((
--====== 事件管理（Incident management） ======
--)))
--* (((
--====== IT 资产管理（IT asset management） ======
--)))
--* (((
--====== 监控与事态管理（Monitoring and event management） ======
--)))
--* (((
--====== 问题管理（Problem management） ======
--)))
--* (((
--====== 发布管理（Release management） ======
--)))
--* (((
--====== 服务目录管理（Service catalogue management） ======
--)))
--* (((
--====== 服务配置管理（Service configuration management） ======
--)))
--* (((
--====== 服务连续性管理（Service continuity management） ======
--)))
--* (((
--====== 服务设计（Service design） ======
--)))
--* (((
--====== 服务台（Service desk） ======
--)))
--* (((
--====== 服务级别管理（Service level management） ======
--)))
--* (((
--====== 服务请求管理（Service request management） ======
--)))
--* (((
--====== 服务验证与测试（Service validation and testing） ======
++表1-2：ITIL 4服务管理实践与标准、方法论等的对应关系表
--
--)))
--
--====== 同样，并非所有的服务实践都要被采用，而是要按照具体业务活动场景来进行科学组合。不过， 从下表可见，如果一个组织能把这些实践都落地了，那已相当伟大。为了便于大家比较，我们制作了一张对应关系表（更详细的比较关系，可以参见 FAQ 章节），把这个部分的内容与 ITIL 以往的版本以及北宙研发的用于一体化运营管理的V-PODAT 进行对应（如下表）。（√表示一致，≈表示有所涉及，空白表示不涉及） ======
--
--
--======   ======
--
--====== 表1-2：ITIL 4服务管理实践与标准、方法论等的对应关系表 ======
--
  |(((
--====== ITIL 4 ======
++ITIL 4
--====== 服务管理实践 ======
++服务管理实践
  )))|(((
--======   ======
++
--====== ITIL v2 ======
++ITIL v2
  )))|(((
--======   ======
++
--====== ITIL v3/2011 ======
--)))|(((
--====== ISO20000 2005/2010 ======
--)))|(((
--====== ISO20000 2018 ======
--)))|(((
--======   ======
++ITIL v3/2011
++)))|ISO20000 2005/2010|ISO20000 2018|(((
++
--====== V-PODAT ======
++V-PODAT
  )))
--|(((
--====== 可用性管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 业务分析 ======
--)))|(((
--======   ======
--)))|(((
--====== ≈ ======
--)))|(((
--======   ======
--)))|(((
--====== ≈ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 容量与性能管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 变更控制 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 事件管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== IT资产管理 ======
--)))|(((
--======   ======
--)))|(((
--====== ≈ ======
--)))|(((
--======   ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 监控与事态管理 ======
--)))|(((
--======   ======
--)))|(((
--====== √ ======
--)))|(((
--======   ======
--)))|(((
--======   ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 问题管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 发布管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务目录管理 ======
--)))|(((
--====== ≈ ======
--)))|(((
--====== √ ======
--)))|(((
--======   ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务配置管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务连续性管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== ≈ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务设计 ======
--)))|(((
--======   ======
--)))|(((
--====== ≈ ======
--)))|(((
--======   ======
--)))|(((
--====== ≈ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务台 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--======   ======
--)))|(((
--====== ≈ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务级别管理 ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务请求管理 ======
--)))|(((
--====== ≈ ======
--)))|(((
--====== √ ======
--)))|(((
--====== ≈ ======
--)))|(((
--====== √ ======
--)))|(((
--====== √ ======
--)))
--|(((
--====== 服务验证与测试 ======
--)))|(((
--======   ======
--)))|(((
--====== √ ======
--)))|(((
--======   ======
--)))|(((
--======   ======
--)))|(((
--====== √ ======
--)))
++|可用性管理|√|√|√|√|√
++|业务分析| |≈| |≈|√
++|容量与性能管理|√|√|√|√|√
++|变更控制|√|√|√|√|√
++|事件管理|√|√|√|√|√
++|IT资产管理| |≈| |√|√
++|监控与事态管理| |√| | |√
++|问题管理|√|√|√|√|√
++|发布管理|√|√|√|√|√
++|服务目录管理|≈|√| |√|√
++|服务配置管理|√|√|√|√|√
++|服务连续性管理|√|√|≈|√|√
++|服务设计| |≈| |≈|√
++|服务台|√|√| |≈|√
++|服务级别管理|√|√|√|√|√
++|服务请求管理|≈|√|≈|√|√
++|服务验证与测试| |√| | |√
--======   ======
++从这张表中可以看到，相比来说，ITIL 4 并没有颠覆以往太多的实践或流程，这是有利于企业平稳过渡的。但我们可以看到，ITIL 4 没有像许多人所说的一样，对 DevOps 的一些方法采用“简单粗暴” 的引用，而是很沉着地继续为服务价值的实现扎扎实实地做贡献。但这不等于说它没有变化，例如下图 ：
--====== 从这张表中可以看到，相比来说，ITIL 4 并没有颠覆以往太多的实践或流程，这是有利于企业平稳过渡的。但我们可以看到，ITIL 4 没有像许多人所说的一样，对 DevOps 的一些方法采用“简单粗暴” 的引用，而是很沉着地继续为服务价值的实现扎扎实实地做贡献。但这不等于说它没有变化，例如下图 ： ======
++|
++| |[[image:image-20200615165118-3.jpg]]
++图1-9 敏捷与传统方式下的发布管理
--|(((
--======   ======
--)))
--|(((
--======   ======
--)))|(((
--====== [[image:image-20200615165118-3.jpg]] ======
--)))
--====== 图1-9 敏捷与传统方式下的发布管理 ======
++这图表明在发布管理中，应该充分关注不同的发布需求，据此选择不同的模式，是传统瀑布模式， 还是敏捷 /DevOps 模式呢？敏捷 /DevOps 模式可以让我们方便地实现蓝绿部署、金丝雀发布等降低风险的发布方式。之所以 ITIL 4 提出将发布和部署分开，是因为 DevOps 的灰度发布模式已经将发布和部署活动分开了。例如，我们可以通过蓝绿部署做到低风险发布，假定蓝环境是生产环境，而绿环境是类生产环境，首先我们可以在绿环境中部署新版的应用程序（此为部署实践的活动），然后通过路由切换，将蓝环境下线，同时将绿环境上线，让用户可以正式访问（此为发布实践的活动）。
--======   ======
--======   ======
--====== 这图表明在发布管理中，应该充分关注不同的发布需求，据此选择不同的模式，是传统瀑布模式， 还是敏捷 /DevOps 模式呢？敏捷 /DevOps 模式可以让我们方便地实现蓝绿部署、金丝雀发布等降低风险的发布方式。之所以 ITIL 4 提出将发布和部署分开，是因为 DevOps 的灰度发布模式已经将发布和部署活动分开了。例如，我们可以通过蓝绿部署做到低风险发布，假定蓝环境是生产环境，而绿环境是类生产环境，首先我们可以在绿环境中部署新版的应用程序（此为部署实践的活动），然后通过路由切换，将蓝环境下线，同时将绿环境上线，让用户可以正式访问（此为发布实践的活动）。 ======
--
--
--======   ======
--
--======   ======
--
--====== 不过需要特别提出的是，在过去的很多年，“炒概念”是一种社会现象，无论是企业还是投资方， 虽然从中牟利者不在少数，但因此受创的恐怕更多。所以我们建议读者应“修身养性”，不是为了“数字化”、“DevOps”、“互联网 +”这些字眼来学习新的方法，而是从业务价值的本质出发， 来看待和逐步掌握这些方法。尤其中国的组织多样性很强，例如银行，它们不仅要面对业务拓展，更面临银监会的监管；又如政府单位没有财务回报的说法，但是为民众提供服务正是政府单位的业务价值。这些才是我们需要关注的价值点。 ======
--
--
--
--[[返回：1.4 ITIL 4 的实践方法>>url:https://www.itil4hub.cn/bin/view/D%20%E3%80%8AITIL%204%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E8%AE%A4%E8%AF%81%E8%80%83%E8%AF%95%E6%8C%87%E5%8D%97%E3%80%8B/%E7%AC%AC1%E7%AB%A0%20ITIL%204%E5%AD%A6%E4%B9%A0%E5%92%8C%E5%AE%9E%E8%B7%B5%E5%AF%BC%E8%AF%BB/1.4ITIL%204%E7%9A%84%E5%AE%9E%E8%B7%B5%E6%96%B9%E6%B3%95/]]    [[阅读下一页>>https://www.itil4hub.cn/bin/view/D%20%E3%80%8AITIL%204%E6%9C%8D%E5%8A%A1%E7%AE%A1%E7%90%86%E8%AE%A4%E8%AF%81%E8%80%83%E8%AF%95%E6%8C%87%E5%8D%97%E3%80%8B/%E7%AC%AC1%E7%AB%A0%20ITIL%204%E5%AD%A6%E4%B9%A0%E5%92%8C%E5%AE%9E%E8%B7%B5%E5%AF%BC%E8%AF%BB/1.4ITIL%204%E7%9A%84%E5%AE%9E%E8%B7%B5%E6%96%B9%E6%B3%95/1.4.3%E6%8A%80%E6%9C%AF%E7%AE%A1%E7%90%86%E5%AE%9E%E8%B7%B5/]]
++不过需要特别提出的是，在过去的很多年，“炒概念”是一种社会现象，无论是企业还是投资方， 虽然从中牟利者不在少数，但因此受创的恐怕更多。所以我们建议读者应“修身养性”，不是为了“数字化”、“DevOps”、“互联网 +”这些字眼来学习新的方法，而是从业务价值的本质出发， 来看待和逐步掌握这些方法。尤其中国的组织多样性很强，例如银行，它们不仅要面对业务拓展，更面临银监会的监管；又如政府单位没有财务回报的说法，但是为民众提供服务正是政府单位的业务价值。这些才是我们需要关注的价值点。

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司