Wiki源代码服务管理实践 - 09 服务配置
由 superadmin 于 2024/12/25, 15:39 最后修改
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{info}} | ||
| 2 | |||
| 3 | {{/info}} | ||
| 4 | |||
| 5 | |||
| 6 | **申明:** | ||
| 7 | |||
| 8 | 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译,国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号:**ITILXF**,并回复“**服务配置管理**”即可。 | ||
| 9 | |||
| 10 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
| 11 | {{toc/}} | ||
| 12 | {{/box}} | ||
| 13 | |||
| 14 | ((( | ||
| 15 | |||
| 16 | ))) | ||
| 17 | |||
| 18 | 请注意,ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作,我们并不拥有包括原著以及中文发行文件的任何版权,所有版权均为Axoles持有,读者在使用这些文件(含本中文翻译版本)时需完全遵守Axoles 和 TSO所申明的所有版权要求。 | ||
| 19 | |||
| 20 | |||
| 21 | 翻译:赵同辉 审校:马建召 审核:姚凯 | ||
| 22 | |||
| 23 | |||
| 24 | |||
| 25 | ---- | ||
| 26 | |||
| 27 | = **1 关于本文档** = | ||
| 28 | |||
| 29 | 本文为服务配置管理实践提供了实践指导,分为五个主要部分,涵盖: | ||
| 30 | |||
| 31 | * 本实践的基本信息 | ||
| 32 | * 本实践相关的流程和活动及其在服务价值链中的作用 | ||
| 33 | * 参与本实践的组织和人员 | ||
| 34 | * 支持本实践的信息和技术 | ||
| 35 | * 对本实践的合作伙伴和供应商的考虑 | ||
| 36 | |||
| 37 | == **1.1 ITIL 4资格认证计划** == | ||
| 38 | |||
| 39 | 本文中的部分内容可作为以下教学大纲的一部分以供检查: | ||
| 40 | |||
| 41 | * ITIL专家创建、交付和支持 | ||
| 42 | * ITIL专家交付利益干系人价值 | ||
| 43 | |||
| 44 | 详情请参考各部分教学大纲。 | ||
| 45 | |||
| 46 | |||
| 47 | |||
| 48 | ---- | ||
| 49 | |||
| 50 | = **2 基本信息** = | ||
| 51 | |||
| 52 | |||
| 53 | == **2.1 目的和描述** == | ||
| 54 | |||
| 55 | * **关键信息** | ||
| 56 | |||
| 57 | 服务配置管理实践的目的是确保有关服务的配置以及支持服务的配置项准确和可靠的信息在需要之时和需要之处可用。这些信息包括如何配置配置项以及配置项之间的关系。 | ||
| 58 | |||
| 59 | 组织使用资源创建和交付产品和服务。这些资源可能属于组织,或者可以作为组织消费服务的一部分被使用。服务配置管理实践收集和管理关于各种资源的信息,这些资源通常包括硬件、软件、网络、建筑物、人员、供应商、产品、服务和文档。实践范围内的资源称为配置项。 | ||
| 60 | |||
| 61 | |||
| 62 | * **定义:配置项**(Configuration Item, CI) | ||
| 63 | |||
| 64 | 为了提供IT服务而需要管理的任何组件。 | ||
| 65 | |||
| 66 | 服务配置管理实践的主要目的是高效地为组织提供有用信息,该管理实践控制范围内的组件应根据有用性和效率定义。影响此实践的主要因素是配置信息的有用性以及获取和维护这些信息的成本。 | ||
| 67 | |||
| 68 | |||
| 69 | **提示** | ||
| 70 | |||
| 71 | 不能单独管理的资源通常不被视为 CI。例如,分析人员用于管理事件的知识很重要,但可能不被视为 CI。同时,虚拟服务器或网络等虚拟资源可能是 CI并且需要作为物理资源进行类似地管理。 | ||
| 72 | |||
| 73 | 服务配置管理实践关注对产品和服务管理重要的资源,并不关心这些资源是组织的资产还是作为第三方服务一部分提供的资产。这两组资源可能采用不同的生命周期模型和控制(参见第2.2.2节)。 | ||
| 74 | |||
| 75 | 服务配置管理实践涉及识别和记录配置项之间的关联关系,通常会生成模型(称为服务配置模型,服务资源模型或职能型和财务服务模型)。这些模型可以专注于服务体系架构的各个方面以及组件之间的关系,代表了不同层次的抽象,从高级功能模型(如图 2.1中所示)到物理与数字化 CI之间关联关系的精确映射。 | ||
| 76 | |||
| 77 | (% style="text-align:center" %) | ||
| 78 | [[image:图片5.png]] | ||
| 79 | |||
| 80 | 图 2.1 高级服务配置模型 | ||
| 81 | |||
| 82 | |||
| 83 | 服务配置模型的使用方式多种多样,包括: | ||
| 84 | |||
| 85 | * 影响分析 | ||
| 86 | * 因果分析 | ||
| 87 | * 风险分析 | ||
| 88 | * 成本分摊 | ||
| 89 | * 可用性分析和规划 | ||
| 90 | |||
| 91 | 服务配置模型的设计和维护应符合利益干系人需求。 | ||
| 92 | |||
| 93 | 服务配置管理实践是一种高度自动化的实践,依赖于收集、维护和控制的大量配置数据,通常包括构建、维护和呈现复杂的配置模型。实践涉及从多个来源收集数据,将其集成并以一种有意义的方式呈现。服务配置管理专用工具通常与监控、发现、分析和记录系统一起使用。 | ||
| 94 | |||
| 95 | 此实践通常允许配置信息与其他实践(包括事件管理、变更支持、问题管理、监控和事态管理和服务请求管理实践等)进行管理记录集成。但是,某些配置模型很难或无法自动执行,需要手动进行数据维护和/或关系映射。示例包括用户数据、组织结构、与供应商和合作伙伴的合同等。在设计和改进实践时,应考虑手动工作相关的成本以及自动化和集成的成本。 | ||
| 96 | |||
| 97 | |||
| 98 | == **2.2 术语和概念** == | ||
| 99 | |||
| 100 | |||
| 101 | === **2.2.1 CI分类** === | ||
| 102 | |||
| 103 | 服务配置管理实践主要集中在以下类型的资源: | ||
| 104 | |||
| 105 | * 信息和技术: | ||
| 106 | |||
| 107 | 1. 各种类型的设备和装置 | ||
| 108 | 1. 应用程序和信息系统,包括主副版本和分发版本、单独的安装、许可证、源代码和代码 制品等 | ||
| 109 | 1. 虚拟基础设施,包括镜像、配置脚本、计算机、网络、机器监视器(machine monitors,)等 | ||
| 110 | 1. 数据库和数据,包括文档化的知识、记录和报告 | ||
| 111 | |||
| 112 | * 供应商和合同: | ||
| 113 | |||
| 114 | 1. 服务 | ||
| 115 | 1. 服务目录和服务产品 | ||
| 116 | 1. 合同和协议 | ||
| 117 | 1. 记录和报告 | ||
| 118 | 1. 主要联系人 | ||
| 119 | 1. 位置 | ||
| 120 | |||
| 121 | * 组织和人员 | ||
| 122 | |||
| 123 | 1. 组织单位 | ||
| 124 | 1. 位置 | ||
| 125 | 1. 员工、角色和联系人 | ||
| 126 | 1. 价值流和流程 | ||
| 127 | 1. 记录的价值流、流程和程序 | ||
| 128 | 1. 这些资源和其他相关资源通常相互映射,并映射到组织的产品、产品供应和服务。配置信息还包括: | ||
| 129 | |||
| 130 | * 服务消费者及与组织服务相关的资源,包括: | ||
| 131 | |||
| 132 | 1. 顾客 | ||
| 133 | 1. 用户 | ||
| 134 | 1. 位置 | ||
| 135 | 1. 组织单位 | ||
| 136 | 1. 信息和技术 | ||
| 137 | |||
| 138 | * 服务协议及其他相关文件 | ||
| 139 | |||
| 140 | 不同类型的 CI具有不同的关键属性,可能具有不同的生命周期阶段并来自组织不同级别的控制。这些差异通常反映在CI信息的收集、存储、控制并呈现在他们的生命周期中。 | ||
| 141 | |||
| 142 | 有关CI组或类型的配置信息可以像单个CI一样进行管理。例如,设备的特定模型或应用程序版本中的已知错误可能是一个组属性,级联到属于该组的每个CI。 | ||
| 143 | |||
| 144 | |||
| 145 | === **2.2.2 CI模型** === | ||
| 146 | |||
| 147 | CI 生命周期模型使CI信息处理标准化、优化、和(可能的情况下)自动化。CI生命周期模型为特定类型的CI定义: | ||
| 148 | |||
| 149 | * 配置项类型所有者 | ||
| 150 | * 命名和标记(如果适用) | ||
| 151 | * 关键组与个体属性 | ||
| 152 | * 关键关系(分类法和职能型) | ||
| 153 | * 关键生命周期阶段 | ||
| 154 | * CI识别、持续控制、验证和审计的程序和/或指南 | ||
| 155 | * 遵循模型的责任 | ||
| 156 | * 关键利益干系人(对配置信息感兴趣)及其需求 | ||
| 157 | * 提供配置信息的关键报告和仪表板(如果适用) | ||
| 158 | |||
| 159 | 配置项类型所有者管理资源,通常称为资源所有者或经理,负责开发和维护 CI 模型。 | ||
| 160 | |||
| 161 | |||
| 162 | === **2.2.3 数字化环境中的服务配置管理** === | ||
| 163 | |||
| 164 | 由于数字化基础设施解决方案(如架构即代码、虚拟的服务器和虚拟网络以及各种云服务)的日益采用,出现了新型 CIs和CI关系。例如,硬件服务器和在其上运行的虚拟机之间关系的信息可能与服务模型的上下文相关,因此期望通过服务配置管理实践提供这些信息。 | ||
| 165 | |||
| 166 | 这些关系通常由虚拟机监测器 (Virtual Machine Monitor, VMM,也称为虚拟监视器)系统管理。但是,这些信息是应该直接从VMM系统获取还是应该导入配置管理系统(Configuration Management System, CMS)还存在一些争议。类似的问题也适用于虚拟网络、环境配置脚本和其他虚拟解决方案管理方法。 | ||
| 167 | |||
| 168 | 没有正确的答案,也没有建议的解决方案定义哪些资源应该位于服务配置管理实践控制之下。这些决策应受关键因素的驱动:配置信息对利益干系人的可用性以及获取和维护这些信息的成本。 | ||
| 169 | |||
| 170 | 例如,仅关心虚拟机和服务器之间关系的利益干系人是这些服务器和虚拟机的管理员,那么将 VMM数据紧密集成到CMS的投资是不值得的,因为关键利益干系人可以直接从VMM系统访问需要的信息。但是,如果其他利益干系人需要此数据且成本合理,则所需的数据可能会与CMS集成。 | ||
| 171 | |||
| 172 | |||
| 173 | === **2.2.4 配置管理系统和数据库** === | ||
| 174 | |||
| 175 | 服务配置管理实践涉及不同来源的大量数据,并取决于以可靠、经济高效的方式收集、集成、处理和呈现这些数据的能力。CMS 旨在满足这一需求。由于实践的数据源众多,CMS通常是一个复杂的系统,结合了一个或多个专业解决方案并与配置数据源的集成。 | ||
| 176 | |||
| 177 | |||
| 178 | * **定义:配置管理系统** | ||
| 179 | |||
| 180 | 用于支持服务配置管理实践的一组工具、数据和信息。 | ||
| 181 | |||
| 182 | CMS的一个关键功能是保持和管理CI记录以及它们之间的关系。这通常是用一个或多个配置管理数据库(Configuration Management Database, CMDBS)实现。 | ||
| 183 | |||
| 184 | |||
| 185 | * **定义:配置管理数据库** | ||
| 186 | |||
| 187 | 在整个生命周期中存储配置记录并维护配置记录之间的关系的数据库。 | ||
| 188 | |||
| 189 | 有时术语“CMS”和“CMDB”可以互换使用,通常使用CMS。 | ||
| 190 | |||
| 191 | |||
| 192 | === **2.2.5 CI核查和审计** === | ||
| 193 | |||
| 194 | 作为决策的重要信息来源,CI 记录和配置模型需要不断接受核查和定期审计。 | ||
| 195 | |||
| 196 | 服务配置数据应: | ||
| 197 | |||
| 198 | * 反映CI的实际属性、状态和关系 | ||
| 199 | * 突出显示与基线配置的偏差 | ||
| 200 | * 提供足够的数据恢复或重新创建已批准的配置 | ||
| 201 | |||
| 202 | * **定义:基线配置** | ||
| 203 | |||
| 204 | 已经过正式审查和同意的产品、服务或基础设施的配置它是进一步活动的基础,如使用、开发和规划。 | ||
| 205 | |||
| 206 | 服务配置管理实践确保在生命周期的每个阶段都在CMDB中捕获相关的CI 数据。实践应确保正确的变更配置项并及时同步到CMDB中。为此,CI记录应尽可能保持自动化。自动化提高了配置数据的可靠性,减少了对验证的需求(但并没有消除验证)。 | ||
| 207 | |||
| 208 | |||
| 209 | * **定义:验证** | ||
| 210 | |||
| 211 | 确保新的或变更的IT服务、流程、规划或其他交付物符合完整、准确和可靠的设计规范的活动。 | ||
| 212 | |||
| 213 | 在此实践中,验证是一个持续的活动,用于识别和校正CMDB中的数据与实际环境和/或批准的配置之间的差异和偏离。在许多情况下,验证可以在很大程度上实现自动化,例如检查CMDB数据(包括 CIs 和关系)是否完整、正确和合规。 | ||
| 214 | |||
| 215 | |||
| 216 | * **定义:盘点** | ||
| 217 | |||
| 218 | 为构建或验证CMDB数据而执行的数据收集和整理活动。 | ||
| 219 | |||
| 220 | 根据范围内的CI类型和可用的自动化工具,通过使用和其他系统集成的发现工具或手动收集有关组织资源状况的数据执行盘点。CMDB指示应该找到的内容,而盘点显示发现的内容。通过验证识别和解决CMDB和盘点之间的差异。验证数据时,盘点可能有助于: | ||
| 221 | |||
| 222 | * 识别和调查组织中未注册的CIS | ||
| 223 | * 识别和记录未注册的授权变更(通常表示CI控制无效) | ||
| 224 | * 识别、调查、恢复或用其他方式处理未经授权的变更 | ||
| 225 | |||
| 226 | 处理实际配置信息和已记录的配置信息之间的差异有不同的方法。关键的挑战是确保CMDB中的数据反映组织资源的状况,并确保此状况正确(意味着没有未经授权的变更)。可能的解决方案包括: | ||
| 227 | |||
| 228 | * 根据调查结果,仔细调查组织资源或配置数据的每个发现和更正 | ||
| 229 | * (半)自动更新CMDB以反映事实情况,无论情况是否得到授权(此方法将未授权变更的调查与CMDB验证分离)根据最新的配置基线半自动化地纠正实际情况,不调查差异的来源(这更适用于数字化资源,在物理资源上可能很难做到) | ||
| 230 | |||
| 231 | 这些解决方案并不是相互排斥的,可以根据需要组合。 | ||
| 232 | |||
| 233 | 组织也可以正式审计配置数据。这些审计通常与IT资产审计结合(请参阅 IT资产管理实践指南)。 | ||
| 234 | |||
| 235 | |||
| 236 | * **定义:CMDB审计** | ||
| 237 | |||
| 238 | 对组织的配置项进行计划的、结构化的和文档化的检查,旨在评估范围内CMDB数据的准确性。 | ||
| 239 | |||
| 240 | 审计是CMDB 验证工具之一,是一项已计划的需要资源的验证工作。CMDB审计通常以项目方式组织和管理,并且与任何项目一样,应是合理的且并在批准后才能启动。 | ||
| 241 | |||
| 242 | 验证是服务配置管理实践不可或缺的一部分。为了确保配置数据有效可靠,验证是必要的。 | ||
| 243 | |||
| 244 | |||
| 245 | == **2.3 范围** == | ||
| 246 | |||
| 247 | 服务配置管理实践确保所选择的CI类型: | ||
| 248 | |||
| 249 | * 提供和维护值得信赖的配置数据,包括更新配置数据以反映 CI 的状态、属性和关系的持续变化 | ||
| 250 | * 提供相关和准确的报告以支持决策 | ||
| 251 | * CI 生命周期与其他实践结合 | ||
| 252 | |||
| 253 | 服务配置管理实践未包含几个活动和责任领域,尽管这几个领域仍与服务配置管理密切相关。在某些情况下,实践依赖于这些活动。表2.2中列出了这些内容以及相关的实践指南。请务必记住,ITIL实践仅仅是在特定价值流中使用的工具集合,应根据具体情况进行必要的组合。 | ||
| 254 | |||
| 255 | |活动|实践指南 | ||
| 256 | |管理IT资产和IT资产数据|IT资产管理 | ||
| 257 | |管理与供应商和合作伙伴的合同|供应商管理 | ||
| 258 | |确保只对CI进行授权的变更|变更支持 | ||
| 259 | |组织产品和服务体系架构的定义与管理|架构管理 | ||
| 260 | |||
| 261 | 表2.1 其他实践指南中描述的与服务配置管理实践相关的活动 | ||
| 262 | |||
| 263 | |||
| 264 | == **2.4 实践成功因素** == | ||
| 265 | |||
| 266 | |||
| 267 | * **定义:实践成功因素** | ||
| 268 | |||
| 269 | 实践的复杂职能型组件,是实践实现其目的必需的。 | ||
| 270 | |||
| 271 | 实践的成功因素不仅仅是一项任务或活动,包含了服务管理四维模型的所有组件。活动的性质和实践中的资源可能有所不同,但共同确保实践有效。 | ||
| 272 | |||
| 273 | 服务配置管理实践包括以下成功因素: | ||
| 274 | |||
| 275 | * 确保组织拥有其产品和服务的相关配置信息 | ||
| 276 | * 确保提供配置信息的成本不断优化 | ||
| 277 | |||
| 278 | === **2.4.1 确保组织拥有其产品和服务的相关配置信息** === | ||
| 279 | |||
| 280 | 服务配置管理实践的重点是确保相关的配置信息被捕获、维护,并在需要时提供给利益干系人。 | ||
| 281 | |||
| 282 | 通常,受益于配置信息的利益干系人在其他管理实践和组织价值流更广泛的场景中使用配置信息。 | ||
| 283 | |||
| 284 | 如第2.1节所列,配置信息的主要用途包括: | ||
| 285 | |||
| 286 | * 影响分析 | ||
| 287 | * 因果分析 | ||
| 288 | * 风险分析 | ||
| 289 | * 成本分摊 | ||
| 290 | * 可用性分析和规划 | ||
| 291 | |||
| 292 | 表 2.2 提供了将这些用途映射到管理实践的一些示例。这些和其他使用配置信息的方法适用于每个 实践和价值流。但是,每种情况下都应该有理由向 CMDB 添加更多的数据或增加其复杂性。需要考虑的主要问题包括: | ||
| 293 | |||
| 294 | * 这些信息是否可以从其他渠道获得 | ||
| 295 | * 这些信息对于决策是关键的还是可选的 | ||
| 296 | * 在CMDB中包含这些信息的初始和持续成本是多少 | ||
| 297 | * 这些信息多久需要一次 | ||
| 298 | * 这些信息需要多久可以提供 | ||
| 299 | |||
| 300 | [[image:1642256818795-757.png]] | ||
| 301 | |||
| 302 | [[image:1642256847834-633.png]] | ||
| 303 | |||
| 304 | 表 2.2 将用途映射到管理实践 | ||
| 305 | |||
| 306 | |||
| 307 | 在某些情况下,基于请求检索配置数据比让数据永久可用更有效。 | ||
| 308 | |||
| 309 | 这些注意事项适用于一系列CI类型、属性、关系和生命周期阶段。 | ||
| 310 | |||
| 311 | |||
| 312 | * **关键信息** | ||
| 313 | |||
| 314 | 配置信息应与组织的需求相关。在CMDB中包括所有可用的数据或盲目地关注其他组织的示例没有好处。服务配置管理实践与该实践提供的信息一样有价值,是准确、最新、可靠、易懂、易于使用的相关信息。 | ||
| 315 | |||
| 316 | 收集、管理和提供配置信息活动无法在隔离中执行。请务必确保服务配置管理实践的相关元素包含在组织的价值流中,并始终按照组织的方法应用于服务配置管理。 | ||
| 317 | |||
| 318 | 遵循优化和自动化的指导原则,应优化例行的发现、盘点、验证任务并使其自动化,简化工作负载,从而提高实践的有效性和效率。 | ||
| 319 | |||
| 320 | 本着保持简单实用的指导原则,服务配置管理实践不应成为官僚的控制系统。相反,该实践应该通过方便、有用的形式提供有价值的信息简化工作。信息的提供通常涉及其他实践(包括供应商管理和服务台实践)管理的渠道。实践的有效集成对于配置信息使用者获得积极的体验至关重要。 | ||
| 321 | |||
| 322 | |||
| 323 | === **2.4.2 确保提供配置信息的成本不断优化** === | ||
| 324 | |||
| 325 | 服务配置管理实践为其他实践提供信息,在大多数组织的价值流中充当支持实践。但是,该实践不太可能为核心价值创建活动的价值流做出贡献。这意味着确保配置信息的成本不断优化非常重要。 | ||
| 326 | |||
| 327 | 成本优化可以通过多种方式实现,但驱动优化的一个好方法是遵循ITIL 指导原则,如表2.3所述。 | ||
| 328 | |||
| 329 | (% style="width:511px" %) | ||
| 330 | |(% style="width:116px" %)指导原则|(% style="width:393px" %)描述 | ||
| 331 | |(% style="width:116px" %)聚焦价值|(% style="width:393px" %)只包括利益干系人需求的相关信息 | ||
| 332 | |(% style="width:116px" %)从你所处的地方开始|(% style="width:393px" %)使用可用的信息源,除非新的源和工具是正当的,否则应避免添加。 | ||
| 333 | |(% style="width:116px" %)基于反馈迭代推进|(% style="width:393px" %)定期评审信息并确认其相关性,根据需要调整CMDB范围 | ||
| 334 | |(% style="width:116px" %)协作和提升可视化程度|(% style="width:393px" %)解释和推广配置信息的可用来源及最佳使用方法,然后提供更高效的使用提示和技巧 | ||
| 335 | |(% style="width:116px" %)通盘思考和工作|(% style="width:393px" %)决策时考虑数据的其他来源,不要试图把一切都放在CMDB中 | ||
| 336 | |(% style="width:116px" %)保持简单实用|(% style="width:393px" %)以最方便的方式提供相关信息,避免复杂的接口和报告 | ||
| 337 | |(% style="width:116px" %)优化和自动化|(% style="width:393px" %)持续优化消耗资源的实践活动。自动执行CMDB验证、数据集合、关系发现和其他活动。 | ||
| 338 | |||
| 339 | 表2.3 ITIL 指导原则和配置信息成本的持续优化 | ||
| 340 | |||
| 341 | |||
| 342 | == **2.5 关键指标** == | ||
| 343 | |||
| 344 | 应在价值流的背景中评估ITIL实践的效果和性能或绩效,每个实践都贡献了价值流。与任何工具的性能或绩效一样,实践的性能或绩效只能在其应用程序的背景内评估。但是,在设计和质量方面工具可能有很大差异,这些差异定义了工具根据用途使用时的潜力或者有效的能力。有关指标、关键绩效指标 (KPI) 以及其他可以帮助实现这一问题的技术的进一步指南,请参阅“度量和报告实践指南”。 | ||
| 345 | |||
| 346 | 服务配置管理实践的关键指标映射到PSF,可以用作价值流背景中的KPIs,以评估实践对这些价值流的效果和效率的贡献。表2.4中给出了一些示例。 | ||
| 347 | |||
| 348 | (% style="width:495px" %) | ||
| 349 | |(% style="width:240px" %)实践成功因素|(% style="width:252px" %)关键指标 | ||
| 350 | |(% style="width:240px" %)((( | ||
| 351 | 确保组织拥有关于其产品 | ||
| 352 | |||
| 353 | 和服务的相关配置信息 | ||
| 354 | )))|(% style="width:252px" %)((( | ||
| 355 | 利益干系人对配置信息的满意度 | ||
| 356 | |||
| 357 | 利益干系人对服务配置管理接口、规程和报告的满意度 | ||
| 358 | |||
| 359 | 由于配置信息不足或不正确而做出的错误决策的数量和影响 | ||
| 360 | |||
| 361 | CMDB中不正确数据的数量和影响 | ||
| 362 | |||
| 363 | 在此期间验证的CMDB数据的百分比 | ||
| 364 | ))) | ||
| 365 | |(% style="width:240px" %)确保提供配置信息的成本不断优化|(% style="width:252px" %)服务配置管理的直接成本 | ||
| 366 | |||
| 367 | 表2.4 实践成功因素的关键指标示例 | ||
| 368 | |||
| 369 | |||
| 370 | 将指标正确汇总到复杂指标中,将使数据更易于持续管理价值流,并且定期评估和持续改进服务配置管理实践。没有单一的最佳解决方案。指标将基于组织整体的服务战略和优先级,以及实践所贡献的价值流的目标。 | ||
| 371 | |||
| 372 | |||
| 373 | |||
| 374 | ---- | ||
| 375 | |||
| 376 | = **3 价值流和流程** = | ||
| 377 | |||
| 378 | |||
| 379 | == **3.1 价值流贡献** == | ||
| 380 | |||
| 381 | 与任何其他 ITIL 管理实践一样,服务配置管理实践有助于实现多个价值流。请务必记住,价值流从不是为单个实践形成的。服务配置管理实践与其他实践结合,为消费者提供高质量服务。实践贡献的主要价值链活动有: | ||
| 382 | |||
| 383 | * 交付和支持 | ||
| 384 | * 设计和转换 | ||
| 385 | * 获取/构建 | ||
| 386 | * 改进 | ||
| 387 | |||
| 388 | 图 3.1显示了服务配置管理实践对服务价值链的贡献。 | ||
| 389 | |||
| 390 | (% style="text-align:center" %) | ||
| 391 | [[image:6.png]] | ||
| 392 | |||
| 393 | 图 3.1 服务配置管理对价值链活动贡献的热力图 | ||
| 394 | |||
| 395 | |||
| 396 | == **3.2 流程** == | ||
| 397 | |||
| 398 | 每个实践可以包括一个或多个可能是实现该实践的目的所必需的流程和活动。 | ||
| 399 | |||
| 400 | |||
| 401 | * **定义:流程** | ||
| 402 | |||
| 403 | 将输入转换为输出的一组相互关联或交互的活动。流程接收一个或多个定义的输出,并转换成定义的输出。流程定义了动作序列及依赖关系。 | ||
| 404 | |||
| 405 | 服务配置管理活动分为三个流程: | ||
| 406 | |||
| 407 | * 管理服务配置管理的通用方法 | ||
| 408 | * 捕获、管理和提供配置信息 | ||
| 409 | * 验证配置数据 | ||
| 410 | |||
| 411 | === **3.2.1 管理服务配置管理的通用方法** === | ||
| 412 | |||
| 413 | 该流程专注于为在组织中管理配置信息建立高效的方法,包括表3.1中列出的活动,并将输入转换为输出。 | ||
| 414 | |||
| 415 | (% style="width:465px" %) | ||
| 416 | |(% style="width:96px" %)关键输入|(% style="width:174px" %)活动|(% style="width:192px" %)关键输出 | ||
| 417 | |(% style="width:96px" %)((( | ||
| 418 | 组织架构 | ||
| 419 | |||
| 420 | 利益干系人需求 | ||
| 421 | |||
| 422 | 组织结构 | ||
| 423 | |||
| 424 | 组织的产品组合 | ||
| 425 | |||
| 426 | 监控数据 | ||
| 427 | |||
| 428 | 实践记录 | ||
| 429 | )))|(% style="width:174px" %)((( | ||
| 430 | 分析利益干系人需求 | ||
| 431 | |||
| 432 | 定义并同意服务配置管理方法 | ||
| 433 | |||
| 434 | 沟通并将服务配置管理方法集成到组织的价值流中 | ||
| 435 | |||
| 436 | 评审并调整服务配置管理方法和规程 | ||
| 437 | )))|(% style="width:192px" %)((( | ||
| 438 | 服务配置管理方法 | ||
| 439 | |||
| 440 | CMDB | ||
| 441 | |||
| 442 | 服务配置管理沟通与知识管理材料 | ||
| 443 | |||
| 444 | 变更请求和实施方案 | ||
| 445 | |||
| 446 | 服务配置管理方法绩效报告 | ||
| 447 | ))) | ||
| 448 | |||
| 449 | 表 3.1 管理服务配置管理流程通用方法的活动和输出 | ||
| 450 | |||
| 451 | |||
| 452 | 图 3.2 显示了该流程的工作流程图。 | ||
| 453 | |||
| 454 | (% style="text-align:center" %) | ||
| 455 | [[image:1613723095722-848.png]] | ||
| 456 | |||
| 457 | 图3.2 管理服务配置管理通用方法的工作流程 | ||
| 458 | |||
| 459 | |||
| 460 | 表3.2提供了流程活动示例。 | ||
| 461 | |||
| 462 | [[image:1642256984745-916.png]] | ||
| 463 | |||
| 464 | [[image:1642257023241-859.png]] | ||
| 465 | |||
| 466 | [[image:1642257041583-539.png]] | ||
| 467 | |||
| 468 | 表 3.2 管理服务配置管理流程通用方法的活动 | ||
| 469 | |||
| 470 | |||
| 471 | === **3.2.2 捕获、管理和提供配置信息** === | ||
| 472 | |||
| 473 | 此流程专注于更新、维护和提供配置信息,包括表 3.3 中列出的活动,并将输入转换为输出。 | ||
| 474 | |||
| 475 | (% style="width:415px" %) | ||
| 476 | |(% style="width:125px" %)关键输入|(% style="width:133px" %)活动|(% style="width:155px" %)关键输出 | ||
| 477 | |(% style="width:125px" %)((( | ||
| 478 | 服务配置管理方法 | ||
| 479 | |||
| 480 | 配置数据 | ||
| 481 | |||
| 482 | 配置信息请求 | ||
| 483 | |||
| 484 | 服务管理记录 | ||
| 485 | )))|(% style="width:133px" %)((( | ||
| 486 | 分析资源并识别CI | ||
| 487 | |||
| 488 | 确认CI模型 | ||
| 489 | |||
| 490 | 遵循CI模型 | ||
| 491 | |||
| 492 | 管理异常 | ||
| 493 | |||
| 494 | 评审CI模型 | ||
| 495 | )))|(% style="width:155px" %)((( | ||
| 496 | 更新CMDB | ||
| 497 | |||
| 498 | 利益干系人的配置信息 | ||
| 499 | |||
| 500 | 异常报告 | ||
| 501 | |||
| 502 | CI模型评审报告 | ||
| 503 | ))) | ||
| 504 | |||
| 505 | 表 3.3捕获、管理和提供配置信息流程的输入、活动和输出 | ||
| 506 | |||
| 507 | |||
| 508 | 图3.3显示了该流程的工作流程图 | ||
| 509 | |||
| 510 | (% style="text-align:center" %) | ||
| 511 | [[image:图片7.png]] | ||
| 512 | |||
| 513 | 图3.3 捕获,管理和提供配置信息流程的工作流 | ||
| 514 | |||
| 515 | |||
| 516 | 表3.4 提供了流程活动的示例。 | ||
| 517 | |||
| 518 | (% style="width:582px" %) | ||
| 519 | |(% style="width:92px" %)活动|(% style="width:488px" %)示例 | ||
| 520 | |(% style="width:92px" %)分析资源并识别CI|(% style="width:488px" %)在发现现有CI中的新资源、资源类型或变更后,资源所有者或配置库管理员可识别相关的CI模型。如有疑问,资源所有者会将问题升级到配置经理。 | ||
| 521 | |(% style="width:92px" %)确认CI模型|(% style="width:488px" %)配置经理会评审情况,确认CI模型,或建议另一种情况。如果需要,配置经理可能建议调整选定的CI模型。 | ||
| 522 | |(% style="width:92px" %)遵循CI模型|(% style="width:488px" %)((( | ||
| 523 | 资源所有者、配置经理和/或配置库管理员遵循选定的模型。这通常包括: | ||
| 524 | |||
| 525 | 1. 在CI生命周期的每个阶段捕获和更新CMDB中的CI 数据 | ||
| 526 | 1. 确保持续验证CMDB 数据 | ||
| 527 | 1. 向相关利益干系人提供最新的CI信息 | ||
| 528 | ))) | ||
| 529 | |(% style="width:92px" %)管理异常|(% style="width:488px" %)((( | ||
| 530 | 如果CI 生命周期期间发生异常,则配置经理和资源所有者按照组织的服务配置管理方法处理。 | ||
| 531 | |||
| 532 | 偏离商定的规程应该很少。请务必确保持续合规并维护控制。 | ||
| 533 | |||
| 534 | 例外情况可能包括CI 模型中未包含的非标准应对式请求配置信息。 | ||
| 535 | |||
| 536 | 更多信息请参阅知识管理实践指南的第3.2.2节。 | ||
| 537 | |||
| 538 | 异常情况应记录在案,以便在评审服务配置管理方法、CI模型和规程时使用。 | ||
| 539 | ))) | ||
| 540 | |(% style="width:92px" %)评审CI模型|(% style="width:488px" %)在出现重大异常或经常发生的情况下,配置经理和配置团队将评审CI模型,根据收集的反馈,评审需求、CI记录、验证报告和新的优化机会并更新CI模型。 | ||
| 541 | |||
| 542 | 表 3.4 捕获,管理和提供配置信息流程的活动 | ||
| 543 | |||
| 544 | |||
| 545 | === **3.2.3 验证配置数据** === | ||
| 546 | |||
| 547 | 此流程专注于保持配置数据完整、正确且合规,包括表 3.5 中列出的活动,并将输入转换为输出。 | ||
| 548 | |||
| 549 | (% style="width:399px" %) | ||
| 550 | |(% style="width:131px" %)关键输入|(% style="width:149px" %)活动|(% style="width:115px" %)关键输出 | ||
| 551 | |(% style="width:131px" %)((( | ||
| 552 | 服务配置管理方法 | ||
| 553 | |||
| 554 | CMDB | ||
| 555 | |||
| 556 | 盘点数据 | ||
| 557 | |||
| 558 | 异常报告 | ||
| 559 | |||
| 560 | 以前的CMDB验证报告 | ||
| 561 | )))|(% style="width:149px" %)((( | ||
| 562 | 识别CI模型 | ||
| 563 | |||
| 564 | 验证配置数据 | ||
| 565 | |||
| 566 | 评审验证输出 | ||
| 567 | |||
| 568 | 定义并实施纠正措施 | ||
| 569 | |||
| 570 | 撰写并沟通CMDB验证报告 | ||
| 571 | )))|(% style="width:115px" %)((( | ||
| 572 | 更新CMDB | ||
| 573 | |||
| 574 | 变更请求 | ||
| 575 | |||
| 576 | 改进措施 | ||
| 577 | |||
| 578 | CMDB验证报告 | ||
| 579 | ))) | ||
| 580 | |||
| 581 | 表 3.5 验证配置数据流程的输入、活动和输出 | ||
| 582 | |||
| 583 | |||
| 584 | 图 3.4显示该流程的工作流程图。 | ||
| 585 | |||
| 586 | (% style="text-align:center" %) | ||
| 587 | [[image:图片8.png]] | ||
| 588 | |||
| 589 | 图 3.4验证配置数据流程的工作流程 | ||
| 590 | |||
| 591 | |||
| 592 | 表3.6 提供该流程活动的示例。 | ||
| 593 | |||
| 594 | (% style="width:578px" %) | ||
| 595 | |(% style="width:127px" %)活动|(% style="width:449px" %)示例 | ||
| 596 | |(% style="width:127px" %)识别CI模型|(% style="width:449px" %)配置经理识别适用于组织资源的CI模型,确认CI的验证规程,并分配和沟通验证活动责任。 | ||
| 597 | |(% style="width:127px" %)验证配置数据|(% style="width:449px" %)根据沟通的规程,负责验证规程的团队收集盘点数据。配置经理和 CI 所有者将盘点数据与 CMDB 数据比较。这种比较应尽可能自动进行。 | ||
| 598 | |(% style="width:127px" %)评审验证输出|(% style="width:449px" %)所有CMDB数据不完整、不正确或非合规以及资源中的未经授权的变更,必须由配置经理、资源所有者或根据CI模型分配的其他人审查。 | ||
| 599 | |(% style="width:127px" %)定义并实施纠正措施|(% style="width:449px" %)配置经理、资源所有者或根据 CI 模型分配的其他人同意、记录和沟通CMDB和/或组织资源的纠正措施。也可以建议CI 模型和/或服务配置管理方法的改进措施。 | ||
| 600 | |(% style="width:127px" %)撰写并沟通CMDB 验证报告|(% style="width:449px" %)配置经理、资源所有者或根据 CI 模型分配的其他人员撰写并沟通 CMDB 验证报告并提交相关利益干系人。此报告应包括建议的纠正和改进措施。 | ||
| 601 | |||
| 602 | 表 3.6 验证配置数据流程的活动 | ||
| 603 | |||
| 604 | |||
| 605 | |||
| 606 | ---- | ||
| 607 | |||
| 608 | = **4 组织和人员** = | ||
| 609 | |||
| 610 | |||
| 611 | == **4.1角色、能力和责任** == | ||
| 612 | |||
| 613 | 实践指南不描述实践管理角色,如实践所有者、实践负责人或实践教练。相反,指南关注每个实践所特有的专家角色。每个角色的结构和命名可能因组织而异,因此不应强制,甚至不应推荐ITIL中定义的任何角色。记住,角色并非职位。一个人可以承担多个角色,一个角色也可以分配给多个人员。 | ||
| 614 | |||
| 615 | 流程和活动的情景中描述了角色。每个角色都具有基于表 4.1 所示模型的能力配置文件。 | ||
| 616 | |||
| 617 | (% style="width:430px" %) | ||
| 618 | |(% style="width:88px" %)能力代码|(% style="width:339px" %)能力类型(活动和技能) | ||
| 619 | |(% style="width:88px" %)L|(% style="width:339px" %)**领导者 **决策,授权,监督其他活动,提供激励和动机,并评估结果。 | ||
| 620 | |(% style="width:88px" %)А|(% style="width:339px" %)**管理员 **分配任务并确定优先级、保持记录、持续报告,并启动基本改进。 | ||
| 621 | |(% style="width:88px" %)C|(% style="width:339px" %)**协调者/沟通者** 协调多方,维护利益相关者之间的沟通,并开展宣传活动。 | ||
| 622 | |(% style="width:88px" %)М|(% style="width:339px" %)**方法和技巧专家** 设计和实施工作技术、文件化步骤、流程咨询、工作分析和持续改进。 | ||
| 623 | |(% style="width:88px" %)Т|(% style="width:339px" %)**技术专家** 提供技术(IT)专业知识和基于专家经验的工作。 | ||
| 624 | |||
| 625 | 表4.1能力代码和资料 | ||
| 626 | |||
| 627 | |||
| 628 | 负责大多数服务配置活动的关键角色是资源所有者和配置经理。表4.2中列出了负责服务配置管理活动的其他角色示例,以及相关的能力资料和特定技能。 | ||
| 629 | |||
| 630 | [[image:1642257218049-641.png]] | ||
| 631 | |||
| 632 | [[image:1642257236292-552.png]] | ||
| 633 | |||
| 634 | [[image:1642257259351-904.png]] | ||
| 635 | |||
| 636 | [[image:1642257307733-443.png]] | ||
| 637 | |||
| 638 | [[image:1642257340299-835.png]] | ||
| 639 | |||
| 640 | 表4.2 负责服务配置管理活动的角色示例 | ||
| 641 | |||
| 642 | |||
| 643 | === **4.1.1 配置经理** === | ||
| 644 | |||
| 645 | 服务配置管理实践的关键角色是配置经理(有时称为领导配置协调者)。 | ||
| 646 | |||
| 647 | 配置经理负责监督范围内所有CI的服务配置管理方法和 CI 模型。在许多组织中,配置经理角色由专人执行。在多个地点运营或涵盖多个行业的大型组织中,配置经理由配置协调者团队提供支持,二者职责非常相似,但专注于特定的领域、行业或组织的其他部分。 | ||
| 648 | |||
| 649 | 配置经理角色通常负责: | ||
| 650 | |||
| 651 | * 管理服务配置管理方法 | ||
| 652 | * 沟通服务配置管理方法和规程 | ||
| 653 | * 将服务配置管理方法集成到价值流中 | ||
| 654 | * 决定是否在范围内包含新的资源和资源类型 | ||
| 655 | * 异常管理 | ||
| 656 | * 确保遵循CI模型 | ||
| 657 | * 确保CMDB包含有效的数据 | ||
| 658 | * 确保组织符合实践的相关要求,(如果适用) | ||
| 659 | * 优化和自动化实践 | ||
| 660 | * 报告服务配置管理绩效 | ||
| 661 | |||
| 662 | === **4.1.2 配置库管理员** === | ||
| 663 | |||
| 664 | 一些组织介绍了配置库管理员的角色。此角色侧重于手动更新配置数据,持续和定期验证CMDB,并处理配置信息的临时请求。 | ||
| 665 | |||
| 666 | 此角色在自动化水平低但需求高的组织中非常重要,适用于应对非标准的配置信息。此角色很少得到专用资源的支持,并且可能由资源所有者担任。 | ||
| 667 | |||
| 668 | |||
| 669 | === **4.1.3 资源所有者** === | ||
| 670 | |||
| 671 | 资源所有者(有时称为资源保管人)是一个确保正确使用组织中的资源或资源组的人员或团队,确保在组织的实践和价值流的背景中相关的CI模型在资源的整个生命周期中始终被应用。 | ||
| 672 | |||
| 673 | |||
| 674 | == **4.2 组织结构和团队** == | ||
| 675 | |||
| 676 | 两个团队支持此实践。大型组织拥有配置经理和配置协调者专业团队,以及专注于服务配置管理实践的专家。当需要具体专业知识时,外部顾问可以支持此团队,通常会评审并更新服务配置管理方法。 | ||
| 677 | |||
| 678 | 小型组织中配置管理专家团队是虚拟的,包括要执行其他角色和任务的人员。在要评审并转换实践时,团队可以作为项目进行协调,正在进行的活动嵌入到其他实践和价值流中。 | ||
| 679 | |||
| 680 | 为了评审并更新服务配置管理方法,组建一个更广泛的配置团队代表多个利益相干系人。这可能包括: | ||
| 681 | |||
| 682 | * 配置经理 | ||
| 683 | * 实践所有者 | ||
| 684 | * 产品所有者 | ||
| 685 | * 服务所有者 | ||
| 686 | * 资源所有者 | ||
| 687 | * 项目经理 | ||
| 688 | * 其他利益干系人或代表 | ||
| 689 | |||
| 690 | ---- | ||
| 691 | |||
| 692 | = **5 信息和技术** = | ||
| 693 | |||
| 694 | |||
| 695 | == **5.1信息交换** == | ||
| 696 | |||
| 697 | 服务配置管理实践的效果基于所用信息的质量。此信息包括但不限于以下信息: | ||
| 698 | |||
| 699 | * 组织战略 | ||
| 700 | * 组织架构 | ||
| 701 | * 组织的投资组合 | ||
| 702 | * 利益干系人对配置信息的需求 | ||
| 703 | * 适用法规的要求 | ||
| 704 | * 来自内部和外部来源的配置数据 | ||
| 705 | * 技术趋势 | ||
| 706 | * 来自实践管理的CI相关记录 | ||
| 707 | * 财务数据 | ||
| 708 | * IT资产数据 | ||
| 709 | |||
| 710 | 这些信息可以采用各种形式。这取决于CI类型、组织要求和服务配置管理自动化。实践的关键输入和输出在第3节中列出。 | ||
| 711 | |||
| 712 | |||
| 713 | == **5.2自动化工具** == | ||
| 714 | |||
| 715 | 确保在CI的每个状态变更时更新配置数据,实现CMDB自动化。通常捕获配置数据对于服务配置管理实践非常重要。如果自动化是可能的和有效的,则可能涉及表 5.1 中概述的解决方案。 | ||
| 716 | |||
| 717 | CMS 解决方案通常是集成服务管理工具的一部分,或专为简单的集成而设计,确保实践之间有效地交换配置信息。通常,CMS 解决方案的关键功能包括 CI 发现、更新、关系建模、影响评估、数据运行状况检查和验证,以及与外部数据源的广泛集成。 | ||
| 718 | |||
| 719 | [[image:1642257398835-311.png]] | ||
| 720 | |||
| 721 | [[image:1642257417195-840.png]] | ||
| 722 | |||
| 723 | [[image:1642257440889-426.png]] | ||
| 724 | |||
| 725 | [[image:1642257486882-852.png]] | ||
| 726 | |||
| 727 | [[image:1642257505312-463.png]] | ||
| 728 | |||
| 729 | 表 5.1 服务配置管理活动的自动化解决方案 | ||
| 730 | |||
| 731 | |||
| 732 | |||
| 733 | ---- | ||
| 734 | |||
| 735 | = **6 合作伙伴和供应商** = | ||
| 736 | |||
| 737 | 很少有服务是仅使用组织自己的资源交付的。大多数(如果不是全部)依赖于其他服务。这些服务通常由组织之外的第三方提供(请参阅ITIL 基础 :ITIL 4版 第2.4节:服务关系模型)。这意味着组织会不断处理作为第三方服务一部分提供的资源。同样,组织的资源被服务使用者广泛使用。这要求服务关系生态系统成员之间对服务配置管理实践进行有效协调。确切的协调水平取决于服务关系的类型。关系越近,信任度越高,则越可以共享更多的配置信息,并且可以一起执行管理活动。至少,要在组织之间建立有限的配置数据交换,最多可以考虑使用广泛的集成或共享CMS。合作伙伴和供应商集成到组织中通常可以访问组织的CMS,这样就可以有效地承担相应的角色。 | ||
| 738 | |||
| 739 | |||
| 740 | |||
| 741 | ---- | ||
| 742 | |||
| 743 | = **7 重要提醒** = | ||
| 744 | |||
| 745 | 实践指南的大部分内容应视为组织在建立和培育自身实践相关领域时可考虑的建议。实践指南是组织可以考虑的主题目录而非答案列表。在使用ITIL实践指南的内容时,各组织应始终遵循ITIL指导原则: | ||
| 746 | |||
| 747 | * 聚焦价值 | ||
| 748 | * 从你所处的地方开始 | ||
| 749 | * 基于反馈迭代推进 | ||
| 750 | * 协作和提升可视化程度 | ||
| 751 | * 通盘思考和工作 | ||
| 752 | * 保持简单实用 | ||
| 753 | * 优化和自动化 | ||
| 754 | |||
| 755 | 关于指导原则及其应用的更多信息,请参见ITIL Foundation:ITIL 4出版物第4.3节。 | ||
| 756 | |||
| 757 | |||
| 758 | |||
| 759 | ---- | ||
| 760 | |||
| 761 | = **8 致谢** = | ||
| 762 | |||
| 763 | AXELOS有限公司感谢所有为该指南的开发做出贡献的人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员: | ||
| 764 | |||
| 765 | |||
| 766 | == **8.1 作者** == | ||
| 767 | |||
| 768 | Tatiana Peftieva, Roman Jouravlev. | ||
| 769 | |||
| 770 | |||
| 771 | == **8.2 贡献者** == | ||
| 772 | |||
| 773 | Anton Lykov, Evgeniy Shilov. | ||
| 774 | |||
| 775 | |||
| 776 | == **8.3审阅者** == | ||
| 777 | |||
| 778 | Dinara Adyrbai, Graham Heard, Antonina Klentsova, Anton Lykov, Irina Matantseva. |