ITIL 4官方核心著作
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | **申明：** | ||
| 2 | |||
| 3 | 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众 | ||
| 4 | 多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信 | ||
| 5 | 公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。 | ||
| 6 | |||
| 7 | |||
| 8 | 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为AXELOS持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守AXELOS 和 TSO所申明的所有版权要求。 | ||
| 9 | |||
| 10 | |||
| 11 | 本文档翻译工作参与人员： | ||
| 12 | |||
| 13 | 翻译：郑中珮 | ||
| 14 | |||
| 15 | 审校：赵同辉 | ||
| 16 | |||
| 17 | |||
| 18 | 审核：汤维 | ||
| 19 | |||
| 20 | 总审：长河 | ||
| 21 | |||
| 22 | 统筹：常宏 | ||
| 23 | |||
| 24 | |||
| 25 | |||
| 26 | ---- | ||
| 27 | |||
| 28 | {{box cssClass="floatinginfobox" title="**Contents**"}} | ||
| 29 | {{toc/}} | ||
| 30 | {{/box}} | ||
| 31 | |||
| 32 | = **1 关于本文件** = | ||
| 33 | |||
| 34 | 本文档为部署管理实践提供了实用指南。它分为五个主要部分，内容包括： | ||
| 35 | |||
| 36 | * 有关实践基本信息 | ||
| 37 | * 本实践相关的流程和活动及其在服务价值链中的作用 | ||
| 38 | * 实践中涉及的组织和人员 | ||
| 39 | * 支持实践的信息和技术 | ||
| 40 | * 实践中合作伙伴和供应商的注意事项 | ||
| 41 | |||
| 42 | == **1.1 ITIL®4 鉴证方案** == | ||
| 43 | |||
| 44 | 本文的选定内容可以作为以下课程的一部分检验标准： | ||
| 45 | |||
| 46 | * ITIL专家：创建、交付和支持 | ||
| 47 | * ITIL专家：高速IT | ||
| 48 | |||
| 49 | 有关详细信息，请参考教学大纲文档。 | ||
| 50 | |||
| 51 | |||
| 52 | |||
| 53 | ---- | ||
| 54 | |||
| 55 | = **2 一般信息** = | ||
| 56 | |||
| 57 | |||
| 58 | == **2 1 目的和描述** == | ||
| 59 | |||
| 60 | |((( | ||
| 61 | **关键信息** | ||
| 62 | ))) | ||
| 63 | |部署管理实践的目的是将新的或更改的硬件、软件、文档、流程或任何其他组件迁移到生产环境中。它还可能涉及将组件部署到其他环境以进行测试或预发布。 | ||
| 64 | |||
| 65 | 部署管理实践负责将服务或服务组件迁移到指定的环境。此实践支持从不同的环境(包括开发、集成、准生产、生产、测试或演示环境)部署或移除服务组件。 | ||
| 66 | |||
| 67 | 该实践通常应用于组织控制的商定范围内的数字化和物理的IT组件，包括软件，硬件，文档，许可证和数据。 | ||
| 68 | |||
| 69 | |||
| 70 | == **2.2 术语和概念** == | ||
| 71 | |||
| 72 | |||
| 73 | === 2.2.1 环境 === | ||
| 74 | |||
| 75 | 部署管理实践支持在各环境之间迁移产品、服务和服务组件。 | ||
| 76 | |||
| 77 | |||
| 78 | 服务组件的生命周期可能因其类型和采购方法而异。组织中受控环境的数量和用途也可能有所不同。表2.1提供了开发软件组织的示例环境列表。 | ||
| 79 | |||
| 80 | |环境|目的 | ||
| 81 | |开发/集成|开发和集成软件 | ||
| 82 | |测试|测试服务组件 | ||
| 83 | |预发布|测试版本，包括产品，服务和其他配置项 | ||
| 84 | |准生产/生产|向服务消费者提供IT服务 | ||
| 85 | |||
| 86 | 表2.1开发软件组织的示例环境列表 | ||
| 87 | |||
| 88 | 对于组织以外的产品和组件，开发环境可能不受组织控制。对于交付给组织以外的服务消费者的产品和服务，对实际环境的控制可能是有限的。其他变化也是可能的。 | ||
| 89 | |||
| 90 | |||
| 91 | === 2.2.2 持续集成、持续交付和持续部署（CI / CD） === | ||
| 92 | |||
| 93 | 在敏捷和DevOps中部署的关键概念是： | ||
| 94 | |||
| 95 | * 持续集成：在软件开发环境中集成、构建和测试代码。 | ||
| 96 | * 持续交付：持续交付意味着构建好的软件可以随时发布到生产环境中。频繁的部署是可能的，但是部署的决定是根据具体情况做出的，通常是因为组织偏向于较低的部署速率。 | ||
| 97 | * 持续部署：更改会通过流水线自动发布到生产环境中，而（支持）每天可以进行多次生产部署。持续部署依赖持续交付。 | ||
| 98 | |||
| 99 | 这些方法得到了软件开发和管理、服务验证和测试、部署管理、基础设施和平台管理、发布管理实践的支持。这些实践涉及特定的技能、流程、过程、自动化工具以及与第三方的协议。它们支持持续集成、持续交付和持续部署的流水线。这也会影响其他实践的设计，例如服务配置管理、监控和事态管理、事件管理等。 | ||
| 100 | |||
| 101 | == **2.3 范围** == | ||
| 102 | |||
| 103 | 部署管理实践的范围包括： | ||
| 104 | |||
| 105 | * 产品、服务和服务组件在受控环境（例如开发、准生产、测试和预发布环境）之间 的有效迁移。 | ||
| 106 | * 从指定环境中有效地移除产品，服务和服务组件。 | ||
| 107 | |||
| 108 | 这些添加、修改和删除可以是由以下经授权的变更/发布而触发： | ||
| 109 | |||
| 110 | * 服务的新增或变更请求 | ||
| 111 | * 新功能或版本的发布 | ||
| 112 | * 技术和操作上的变更 | ||
| 113 | * 第三方变更请求 | ||
| 114 | * 服务下线和移除 | ||
| 115 | * 支持或故障排除 | ||
| 116 | * 服务请求 | ||
| 117 | |||
| 118 | 有几个活动和职责尽管与部署密切相关，但未被包含在部署管理中。表2.2中列出了这些内容以及它们的实践引用出处。重要的是要记住，ITIL实践仅仅是在特定价值流中使用的工具集合；它们应当根据具体场景做必要的组合。 | ||
| 119 | |||
| 120 | |**活动**|**实践指南** | ||
| 121 | |授权的变更/发布|变更支持 | ||
| 122 | |向用户提供准生产环境中的服务和组件|发布管理 | ||
| 123 | |开发软件|软件开发和管理 | ||
| 124 | |((( | ||
| 125 | 开发和构建基础设施组件 | ||
| 126 | |||
| 127 | 准备和维护目标环境以进行部署 | ||
| 128 | )))|基础设施和平台管理 | ||
| 129 | |((( | ||
| 130 | 提供要部署的IT资产 | ||
| 131 | |||
| 132 | 维护授权的服务组件存储库 | ||
| 133 | )))|IT资产管理 | ||
| 134 | |测试和验证服务以及服务组件|服务验证和测试 | ||
| 135 | |命名，版本控制，和控制服务组件|服务配置管理 | ||
| 136 | |||
| 137 | 表2.2其他实践指南中描述的与部署相关的活动 | ||
| 138 | |||
| 139 | |||
| 140 | == **2 4 实践成功因素** == | ||
| 141 | |||
| 142 | |**定义：实践成功因素** | ||
| 143 | |实践中为实现其目的所需的复杂功能组件。 | ||
| 144 | |||
| 145 | 实践的成功因素不仅仅是一项任务或活动，它包含服务管理四维模型的所有组件。活动的性质和实践中的资源可能有所不同，但它们共同确保实践有效。 | ||
| 146 | |||
| 147 | 部署管理实践包含以下成功因素： | ||
| 148 | |||
| 149 | * 在组织上建立和维护有效的服务和服务组件部署方法 | ||
| 150 | * 确保组织在特定价值流中的服务和服务组件部署有效 | ||
| 151 | |||
| 152 | === 2.4.1 为组织中的服务和服务组件的部署建立和维护有效的方法 === | ||
| 153 | |||
| 154 | 部署管理实践包括定义并同意一种或几种部署产品、服务和组件时要使用的模型。这些模型可以使用一种部署方法，也可以组合使用多种部署方法，具体取决于它们的特定服务和需求以及所部署的服务组件的大小、类型和影响。 | ||
| 155 | |||
| 156 | 可以定义模型来部署类似类型的服务或服务组件。可以基于以下因素来定义此类部署模型： | ||
| 157 | |||
| 158 | * 自动化注意事项 | ||
| 159 | * 成本/资源限制 | ||
| 160 | * 部署的预期频率 | ||
| 161 | * 客户需求变更率 | ||
| 162 | * 技术变更率 | ||
| 163 | * 组件缺陷风险 | ||
| 164 | * 组件来源 | ||
| 165 | * 用户的采用行为和偏好 | ||
| 166 | * 技术变化对服务消费者的可见性 | ||
| 167 | |||
| 168 | 基于这些和其他相关的注意事项，组织定义了一组用于部署不同服务组件的模型。这些模型可以描述服务管理四维模型中各方面的不同解决方案。表2.3概述了一些示例模型。 | ||
| 169 | |||
| 170 | |部署模型适用性|组织和人员|信息和技术|价值流和流程|合作伙伴和供应商 | ||
| 171 | |提供给外部服务使用者的服务的硬件组件|服务提供者应该安排一个交付团队来运输和安装组件|((( | ||
| 172 | 一系列工具可用于 | ||
| 173 | |||
| 174 | 自动化硬件安装的 | ||
| 175 | |||
| 176 | 采购、开票、用户 | ||
| 177 | |||
| 178 | 通讯和调度 | ||
| 179 | )))|可以由新的或更改的价值流触发安装订单，这些流包括获得和安装新硬件的明确授权。|(% rowspan="2" %)双方同意，可以使用第三方运输，交付和安装服务提供程序 | ||
| 180 | |从供应商处获得的服务的硬件组件|根据供应商合同中的交货和安装条款，获取硬件和确保其正确安装应明确定义|((( | ||
| 181 | 供应商目录可用于订购组件，以及存储和提供最新的安装手册。 | ||
| 182 | |||
| 183 | 一个配置管理工具应该用硬件随附的文档填充，包括记录和文档，例如质保证明，维护计划等 | ||
| 184 | )))|价值流设计期间应考虑供应商活动，例如发票和运输。各方之间的接口需要在合同中建立 | ||
| 185 | |提供软件组件的服务到外部服务消费者|服务提供者可以让工作人员进行路演来向服务的消费者推广新的软件组件并促进变更认知|使用自动化部署工具集进行软件的使用或订购|((( | ||
| 186 | 服务提供者在组件部署前可以实施额外的控制，例如质量保证，安全管控或商用； | ||
| 187 | |||
| 188 | 至关重要的是这些控制是在部分自动化或全自动化的部署管道中进行 | ||
| 189 | )))|((( | ||
| 190 | 合作伙伴可以进行如下部署实践，例如为保证软件可用性 | ||
| 191 | |||
| 192 | 由供应商将软件部署至消费者 | ||
| 193 | |||
| 194 | 环境进行的额外定制测试 | ||
| 195 | ))) | ||
| 196 | |内部进行的软件组件服务开发|DevOps团队可能会执行软件部署|持续集成和持续部署流水线工具集可用于部署软件到受控环境|服务提供者组织必须再部署过程中建立组织控制确保控制不过度|第三方可以执行部署模型的某些步骤；例如，环境配置活动 | ||
| 197 | |||
| 198 | (% class="wikigeneratedid" id="H88682.34E0D540C670D52A17EC44EF6768490E87F72793A4F8B6A21578B" %) | ||
| 199 | **表2.3 不同服务组件的部署示例模型** | ||
| 200 | |||
| 201 | 部署模型还定义了通过受控环境进行部署的流程、所涉各方的责任、部署触发器以及在值流中与其他实践活动的交互。 | ||
| 202 | |||
| 203 | 这些模型应足够灵活以适应不断变化的情况，例如部署的规模，紧急度或复杂性。 | ||
| 204 | |||
| 205 | 部署模型以及一般的部署管理实践应该作为持续改进的主体，以消除浪费并提高有效性和效率。 | ||
| 206 | |||
| 207 | |||
| 208 | === 2.4.2 确保在组织的价值流背景中有效部署服务和服务组件 === | ||
| 209 | |||
| 210 | 确保有效部署要求在所有服务管理四维模型协调资源。 | ||
| 211 | |||
| 212 | 部署的有效性和效率在很大程度上依赖于可用的相关资源、技能、技术、工具和基础架构。在部署中有效地使用技术和自动化可以提高实践的一致性、敏捷性和效率。 | ||
| 213 | |||
| 214 | 为了使变更/发布成功，至关重要的是在整个迁移过程中都必须保持变更/发布的服务或服务组件的完整性。任何未经授权的手动、流程或技术错误的变更都会对变更和发布的目标与结果产生负面影响，这通常会对组织造成严重影响。 | ||
| 215 | |||
| 216 | 服务迁移的成功取决于对变更和发布的有效管理，而这反过来又依赖于符合需求和目标的及时部署。必须有效地管理部署与变更和发布要求的一致性，以及进度和成本等关键方面的一致性。 | ||
| 217 | |||
| 218 | |||
| 219 | == **2.5 关键指标** == | ||
| 220 | |||
| 221 | 应该在每个实践所贡献的价值流的背景内评估ITIL实践的有效性和绩效。与任何工具的性能一样，实践的绩效只能在其应用的背景中进行评估。但是，工具可以在设计和质量上有很大的不同，这些不同定义了工具根据其用途使用时的潜力或能力。有关度量标准、关键绩效指标（KPI）和其他技术的进一步指导，请参见度量和报告实践指南。 | ||
| 222 | |||
| 223 | 部署管理实践的关键指标已映射到其PSF。在价值流中，它们可以用作KPI以评估部署管理对这些价值流的效果和效率的贡献。表2.4中给出了一些关键指标的示例。 | ||
| 224 | |||
| 225 | |**实践成功因素**|**关键指标** | ||
| 226 | |((( | ||
| 227 | 为组织中的服务和服务组件的部署建立和维护有效的方法 | ||
| 228 | |||
| 229 | 确保在组织的价值流背景中有效地部署服务和服务组件 | ||
| 230 | )))|((( | ||
| 231 | * 利益相关者的满意度级别，以及部署所支持的产品和服务的变更比率 | ||
| 232 | * 组织对商定部署方法的采用率 | ||
| 233 | * 关键合作伙伴和服务消费者对部署方法的适应程度 | ||
| 234 | * 部署引起的审计结果和外部合规性问题的数量 | ||
| 235 | * 利益相关者对部署前置时间的满意度水平 | ||
| 236 | * 成功部署的百分比/部署错误/失败的次数 | ||
| 237 | * 与部署相关的事件数量/百分比 | ||
| 238 | * 及时/遵守部署计划 | ||
| 239 | * 部署待办项吞吐量 | ||
| 240 | * 利益相关者对部署质量的满意度水平 | ||
| 241 | ))) | ||
| 242 | |||
| 243 | = **3 价值流和流程** = | ||
| 244 | |||
| 245 | |||
| 246 | == **3.1 价值流的贡献** == | ||
| 247 | |||
| 248 | 像任何其他ITIL 管理实践一样，部署管理实践有助于实现多个价值流。重要的是要记住，价值流永远不会由单个实践形成。部署管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是： | ||
| 249 | |||
| 250 | * 获取和构建 | ||
| 251 | * 设计和转换 | ||
| 252 | |||
| 253 | 图3.1中显示了部署管理实践对服务价值链的贡献。 | ||
| 254 | |||
| 255 | |||
| 256 | (% style="text-align:center" %) | ||
| 257 | [[image:1639625344385-230.png]] | ||
| 258 | |||
| 259 | 图3.1 部署管理实践对价值链活动贡献的热力图 | ||
| 260 | |||
| 261 | |||
| 262 | == **3.2 流程** == | ||
| 263 | |||
| 264 | 每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。 | ||
| 265 | |||
| 266 | 部署管理活动分为两个流程： | ||
| 267 | |||
| 268 | * 部署 | ||
| 269 | * 部署模型开发和评审 | ||
| 270 | |||
| 271 | === 3.2.1 部署流程 === | ||
| 272 | |||
| 273 | 该流程包括表3.1中列出的活动，并将输入转换为输出。 | ||
| 274 | |||
| 275 | |**关键输入**|**活动**|**关键输出** | ||
| 276 | |((( | ||
| 277 | 部署需求和期望 | ||
| 278 | |||
| 279 | 环境细节 | ||
| 280 | |||
| 281 | 服务组件/发布组件 | ||
| 282 | |||
| 283 | ITAM和最终媒介库授权的硬件和软件组件 | ||
| 284 | |||
| 285 | 验收标准 | ||
| 286 | )))|((( | ||
| 287 | 部署规划 | ||
| 288 | |||
| 289 | 服务组件验证 | ||
| 290 | |||
| 291 | 目标环境验证 | ||
| 292 | |||
| 293 | 部署执行 | ||
| 294 | |||
| 295 | 部署验证 | ||
| 296 | )))|((( | ||
| 297 | 部署的服务组件/版本 | ||
| 298 | |||
| 299 | 部署记录 | ||
| 300 | |||
| 301 | 部署通讯 | ||
| 302 | |||
| 303 | 变更支持，发布管理，服务验证和测试，项目管理等方面的反馈和输入 | ||
| 304 | |||
| 305 | 更新引入程序 | ||
| 306 | |||
| 307 | 客户知识库, 服务台数据 | ||
| 308 | ))) | ||
| 309 | |||
| 310 | 表3.1 部署流程的输入、活动和输出 | ||
| 311 | |||
| 312 | |||
| 313 | (% style="text-align:center" %) | ||
| 314 | [[image:1639626238930-292.png]] | ||
| 315 | |||
| 316 | (% style="text-align:center" %) | ||
| 317 | [[image:1639626257396-465.png]] | ||
| 318 | |||
| 319 | 图 3.2 部署流程的工作流程图 | ||
| 320 | |||
| 321 | |||
| 322 | 在采用CI / CD框架的Agile或DevOps 环境中，许多活动将以自动化方式执行，而无需人工干预。表3.3提供了流程活动的示例。 | ||
| 323 | |||
| 324 | [[image:1639626327892-612.png]] | ||
| 325 | |||
| 326 | [[image:1639626349273-735.png]] | ||
| 327 | |||
| 328 | 表3.3 部署的活动流程 | ||
| 329 | |||
| 330 | |||
| 331 | === 3.2.2 部署模型开发和评审流程 === | ||
| 332 | |||
| 333 | 这个流程的重点是不断改进部署管理实践、部署模型和部署过程。它可以定期执行，也可以由部署效率低下的部署失败触发，并突出其他改进机会。常规审查可能每三个月一次或更频繁地进行，这取决于现有模型和程序的有效性。 | ||
| 334 | |||
| 335 | 该流程包括表3.4中列出的活动，并将输入转换为输出： | ||
| 336 | |||
| 337 | |**关键输入**|**活动**|**关键输出** | ||
| 338 | |((( | ||
| 339 | * 当前的部署模型和过程 | ||
| 340 | * 部署记录 | ||
| 341 | |||
| 342 | * 部署失败报告 | ||
| 343 | * 政策法规要求 | ||
| 344 | * 发布信息 | ||
| 345 | * 配置信息 | ||
| 346 | * IT资产信息 | ||
| 347 | * 与消费者和供应商/合作伙伴的SLA | ||
| 348 | * 容量和性能信息 | ||
| 349 | * 连续性政策和计划 | ||
| 350 | * 安全政策和计划 | ||
| 351 | )))|((( | ||
| 352 | * 部署模型规划 | ||
| 353 | * 部署模型实施 | ||
| 354 | |||
| 355 | * 部署模型测试 | ||
| 356 | * 部署评审和 | ||
| 357 | * 部署记录分析 | ||
| 358 | * 部署模型改进启动 | ||
| 359 | * 部署模型更新和通讯 | ||
| 360 | )))|((( | ||
| 361 | * 更新的部署模型和过程 | ||
| 362 | * 部署模型和过程更新通信 | ||
| 363 | * 变更请求 | ||
| 364 | * 改进倡议 | ||
| 365 | * 部署评审报告 | ||
| 366 | * 更新的知识管理文章 | ||
| 367 | * 经验教训 | ||
| 368 | ))) | ||
| 369 | |||
| 370 | 表3.4 部署模型开发和评审流程的输入，活动和输出 | ||
| 371 | |||
| 372 | |||
| 373 | 图3.3显示了流程的工作流程图。 | ||
| 374 | |||
| 375 | (% style="text-align:center" %) | ||
| 376 | [[image:1639625576513-733.png]] | ||
| 377 | |||
| 378 | |||
| 379 | 图 3.3 部署模型开发和评审的工作流程 | ||
| 380 | |||
| 381 | |||
| 382 | 表3.5提供了流程活动的示例。 | ||
| 383 | |||
| 384 | |**活动**|**描述** | ||
| 385 | |部署模型计划|当产品遵循类似的低风险、高成功率部署模式，并且有方法可以消除浪费并减少部署交付时间时，部署经理可以选择定义新的部署模型。部署模型应该减少人员对部署的参与和控制。 | ||
| 386 | |部署模型实施|部署经理安排适当的流水线工具进行配置，以支持新的模型，例如访问设置、代码支持或分支过程。或者，如果自动部署工具不适用，则部署经理会建立适当的指导原则并将其传达给相关的团队和各方。 | ||
| 387 | |部署模型测试|部署经理对新的部署模型进行了测试，以确保正确的边界处理和工作流程。在无法进行测试的地方，部署经理监测模型的首次实时运行。 | ||
| 388 | |部署评审和部署失败记录分析|部署经理与服务所有者和其他相关利益相关者一起，对选定的部署或部署失败进行评审。他们发现优化部署模型和部署过程的机会。 | ||
| 389 | |部署模型改进启动|如果部署模型和过程包含在变更支持的范围内，则部署经理将要处理的改进倡议注册到持续改进实践的过程中，或者发起变更请求。 | ||
| 390 | |((( | ||
| 391 | 部署模型 | ||
| 392 | |||
| 393 | 更新和通讯 | ||
| 394 | )))|((( | ||
| 395 | 如果部署模型成功更新，则将其传达给 | ||
| 396 | |||
| 397 | 相关的利益方。这通常由部署经理和/或服务或资源所有者完成。 | ||
| 398 | ))) | ||
| 399 | |||
| 400 | 表3.5 部署模型开发和评审流程的活动 | ||
| 401 | |||
| 402 | |||
| 403 | |||
| 404 | |||
| 405 | ---- | ||
| 406 | |||
| 407 | = **4 组织和人员** = | ||
| 408 | |||
| 409 | |||
| 410 | == **4.1 角色，能力和责任** == | ||
| 411 | |||
| 412 | 实践指南没有描述实践管理的角色，例如实践所有者、实践领导者或实践教练。相反，他们专注于每种实践的专门角色。每个角色的结构和命名都可能因组织而异，因此ITIL中定义的任何角色都不应被视为强制性的，甚至不应被推荐。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。 | ||
| 413 | |||
| 414 | 流程和活动的背景中描述了角色。每个角色都具有基于表4.1中所示的模型的能力概况。 | ||
| 415 | |||
| 416 | |能力编码|能力侧写（活动和技能） | ||
| 417 | |L|**领导者**，决策、授权、监督其他活动，提供激励和动力，并评估结果 | ||
| 418 | |А|**管理员**，分配任务并确定优先级，保留记录，持续报告，并启动基本改进 | ||
| 419 | |C|**协调者/沟通者**，协调多方，维护利益相关者之间的沟通，并开展宣传活动 | ||
| 420 | |М|**方法和技术专家**，设计和实施工作技术，文件化步骤，流程咨询、工作分析和持续改进 | ||
| 421 | |Т|**技术专家**，提供技术（IT）专业知识并执行基于专业知识的任务 | ||
| 422 | |||
| 423 | 表4.1能力代码和资料 | ||
| 424 | |||
| 425 | 在组织中可以找到两个特定于实践的角色：部署经理和部署实践人员。这些角色通常在部署数量很高的组织中引入。在其他组织中，这些角色可以与开发，运营，IT资产团队等中担负相关职责的其他角色合并或分配给其他角色。 | ||
| 426 | |||
| 427 | |||
| 428 | === 4.1.1 部署经理角色 === | ||
| 429 | |||
| 430 | 部署经理角色需要对组织的业务，产品和服务，技术，平台，框架以及流程有深入的了解。这个角色需要强有力的规划和项目管理技能以及协调团队合作的能力和权威。此角色的能力概要是LACM。该角色通常负责部署管理实践过程的规划、管理以及协调，以及各个版本的部署，包括： | ||
| 431 | |||
| 432 | * 计划部署 | ||
| 433 | * 确保部署计划与变更/ 发布计划、需求和目标保持一致 | ||
| 434 | * 规划、协调并确保有效完成部署所需的可用资源 | ||
| 435 | * 有效管理多个部署之间的重叠或冲突 | ||
| 436 | * 实施和保持有效的控制和治理，以确保整个部署实践中组件的完整性 | ||
| 437 | * 管理和/或确保其他实践和利益相关者之间的有效接口并进行协调 | ||
| 438 | * 管理和优化部署资源，以确保管理部署的可用性、能力和容量达到最佳水平 | ||
| 439 | * 依据定义的KPI，监视、报告、分析和改进部署性能 | ||
| 440 | |||
| 441 | 在更复杂的组织中，某些部署管理职责可能被委派给部署协调员、团队负责人或其他任何类似的角色。 | ||
| 442 | |||
| 443 | |||
| 444 | === 4.1.2 部署实践人员角色 === | ||
| 445 | |||
| 446 | 部署实践人员角色需要强大的技术技能和有效的团队合作精神。该角色的能力概要是TAC。这个角色通常负责根据适用的需求、目标和对象，对目标环境进行有效的部署，包括： | ||
| 447 | |||
| 448 | * 获得、维护和不断提高部署技术方面所需的技能和能力 | ||
| 449 | * 参与和协助部署规划 | ||
| 450 | * 在整个部署实践中确保组件的完整性 | ||
| 451 | * 管理和协调部署文档、记录和通讯，包括用于培训目的 | ||
| 452 | * 与其他实践和利益相关者进行协调，并促进小组之间的交流 | ||
| 453 | * 验证并向利益相关者提供部署反馈 | ||
| 454 | * 根据定义的KPI，监控、报告、分析和改进部署性能或绩效 | ||
| 455 | |||
| 456 | 在某些组织环境中，根据部署和平台的类型和要求，组织产品和服务的复杂性等，部署实践人员角色可以分为多个类别和级别。 | ||
| 457 | |||
| 458 | |||
| 459 | === 4.1.3 部署管理活动中涉及的角色 === | ||
| 460 | |||
| 461 | 表4.1中列出了部署管理活动中可能涉及的其他角色的示例，以及相关的能力概况和特定技能。表4.2负责部署管理活动的角色示例 | ||
| 462 | |||
| 463 | |活动|负责角色|能力简介|具体技能 | ||
| 464 | |(% colspan="4" %)部署流程 | ||
| 465 | |部署规划|((( | ||
| 466 | 服务负责人 | ||
| 467 | |||
| 468 | 产品负责人 | ||
| 469 | |||
| 470 | 开发团队成员 | ||
| 471 | |||
| 472 | 技术专家 | ||
| 473 | |||
| 474 | 服务台客服 | ||
| 475 | |||
| 476 | 任务经理交付经理 | ||
| 477 | |||
| 478 | 用户 | ||
| 479 | )))|ACMT|((( | ||
| 480 | 了解部署对服务级别、用户体验和环境的影响 | ||
| 481 | |||
| 482 | 良好的沟通和跨团队协调能力 | ||
| 483 | |||
| 484 | 熟悉部署模型 | ||
| 485 | |||
| 486 | 了解技术服务设计，配套基础设施和平台，开发工具 | ||
| 487 | ))) | ||
| 488 | |服务组件的验证|((( | ||
| 489 | 技术专家 | ||
| 490 | |||
| 491 | 部署经理 | ||
| 492 | |||
| 493 | 开发团队成员 | ||
| 494 | |||
| 495 | 服务负责人 | ||
| 496 | |||
| 497 | 产品负责人 | ||
| 498 | )))|T|熟悉服务和组件 | ||
| 499 | |((( | ||
| 500 | 目标 | ||
| 501 | |||
| 502 | 环境 | ||
| 503 | |||
| 504 | 验证 | ||
| 505 | )))|((( | ||
| 506 | 技术专家 | ||
| 507 | |||
| 508 | 部署 | ||
| 509 | |||
| 510 | 经理 | ||
| 511 | |||
| 512 | 开发团队成员 | ||
| 513 | |||
| 514 | 系统管理员 | ||
| 515 | |||
| 516 | 基础架构团队成员 | ||
| 517 | |||
| 518 | 服务负责人 | ||
| 519 | |||
| 520 | 产品负责人 | ||
| 521 | )))|TC|熟悉环境和基础设施 | ||
| 522 | |部署执行|((( | ||
| 523 | 技术专家 | ||
| 524 | |||
| 525 | 部署经理 | ||
| 526 | |||
| 527 | 开发团队成员 | ||
| 528 | |||
| 529 | 系统管理员 | ||
| 530 | |||
| 531 | 基础架构团队成员 | ||
| 532 | )))|TM|((( | ||
| 533 | 了解服务设计技术，支持的基础架构和平台，开发工具 | ||
| 534 | |||
| 535 | 熟悉部署模型 | ||
| 536 | ))) | ||
| 537 | |部署验证|((( | ||
| 538 | 技术专家 | ||
| 539 | |||
| 540 | 部署经理 | ||
| 541 | |||
| 542 | 开发团队成员 | ||
| 543 | |||
| 544 | 系统管理员 | ||
| 545 | |||
| 546 | 基础架构团队成员 | ||
| 547 | |||
| 548 | 服务负责人 | ||
| 549 | |||
| 550 | 产品负责人 | ||
| 551 | |||
| 552 | 用户 | ||
| 553 | )))|TC|((( | ||
| 554 | 了解服务和组件的技术设计 | ||
| 555 | |||
| 556 | 对服务绩效，服务级别和用户体验有很好的了解 | ||
| 557 | ))) | ||
| 558 | |(% colspan="4" %)部署模型开发和评审流程 | ||
| 559 | |部署模型规划|((( | ||
| 560 | 部署经理 | ||
| 561 | |||
| 562 | 服务负责人 | ||
| 563 | |||
| 564 | 产品负责人 | ||
| 565 | )))|CAT|((( | ||
| 566 | 了解服务设计、资源配置和业务影响 | ||
| 567 | |||
| 568 | 熟悉现有部署活动 | ||
| 569 | ))) | ||
| 570 | |((( | ||
| 571 | 部署模型 | ||
| 572 | |||
| 573 | 的实现 | ||
| 574 | )))|((( | ||
| 575 | 部署经理 | ||
| 576 | |||
| 577 | 服务负责人 | ||
| 578 | |||
| 579 | 产品负责人 | ||
| 580 | )))|TCL|((( | ||
| 581 | 部署流水线工具知识 | ||
| 582 | |||
| 583 | 了解持续改进和变更支持的实践 | ||
| 584 | ))) | ||
| 585 | |部署模型测试|((( | ||
| 586 | 部署经理 | ||
| 587 | |||
| 588 | 服务负责人 | ||
| 589 | |||
| 590 | 产品负责人 | ||
| 591 | )))|TCL|((( | ||
| 592 | 熟悉工作流的测试实践 | ||
| 593 | |||
| 594 | 熟悉服务级别要求、需求、承担的义务 | ||
| 595 | |||
| 596 | 了解部署模型和方法；分析能力 | ||
| 597 | ))) | ||
| 598 | |部署评审和部署记录分析|((( | ||
| 599 | 部署经理 | ||
| 600 | |||
| 601 | 服务负责人 | ||
| 602 | |||
| 603 | 产品负责人 | ||
| 604 | |||
| 605 | 供应商 | ||
| 606 | )))|TCL|((( | ||
| 607 | 了解服务设计、资源配置和业务影响 | ||
| 608 | |||
| 609 | 熟悉部署模型 | ||
| 610 | |||
| 611 | 熟悉服务级别要求和需求、承担的义务 | ||
| 612 | |||
| 613 | 了解部署模型和方法；分析能力 | ||
| 614 | ))) | ||
| 615 | |部署模型改进启动|((( | ||
| 616 | 部署经理 | ||
| 617 | |||
| 618 | 服务负责人 | ||
| 619 | |||
| 620 | 产品负责人 | ||
| 621 | )))|TMC|((( | ||
| 622 | 了解服务设计、资源配置、业务影响和服务级别水平 | ||
| 623 | |||
| 624 | 熟悉部署模型、诊断工具和方法 | ||
| 625 | |||
| 626 | 了解持续改进和变更支持的实践 | ||
| 627 | ))) | ||
| 628 | |部署模型更新和通讯|((( | ||
| 629 | 部署经理 | ||
| 630 | |||
| 631 | 服务负责人 | ||
| 632 | |||
| 633 | 产品负责人 | ||
| 634 | |||
| 635 | 服务台客服 | ||
| 636 | )))|CA|通讯程序和工具的知识 | ||
| 637 | |||
| 638 | == **4.2 组织结构和团队** == | ||
| 639 | |||
| 640 | 指定的部署管理团队是不同寻常的，除非是在具有大量和复杂部署的大型组织中。角色通常由技术/运营团队处理。 | ||
| 641 | |||
| 642 | 在DevOps 环境中，部署通常通过使用部署管线通过连续的部署实践/ 框架实现自动化。然而，部署经理的角色通常仍然适用。部署经理将掌控整个实践以及部署的各个方面。该角色可以独立设立，也可以与其他相关的合适角色（例如发布经理）结合使用。 | ||
| 643 | |||
| 644 | |||
| 645 | |||
| 646 | |||
| 647 | ---- | ||
| 648 | |||
| 649 | = **5 信息和技术** = | ||
| 650 | |||
| 651 | |||
| 652 | == **5.1 信息交流** == | ||
| 653 | |||
| 654 | 部署管理实践的效果取决于所使用信息的质量。该信息包括但不限于以下信息： | ||
| 655 | |||
| 656 | * 服务组件和资产的授权存储库，如IT资产数据库和DML | ||
| 657 | * 资产和配置 | ||
| 658 | * 变更和发布计划 | ||
| 659 | * 部署通信 | ||
| 660 | * 部署文档和记录 | ||
| 661 | * 部署计划 | ||
| 662 | * 部署指标和报告 | ||
| 663 | * 部署的每个阶段的进入、退出和验收标准 | ||
| 664 | * 来自部署的反馈 | ||
| 665 | * 部署期间发现的问题和错误 | ||
| 666 | * 部署范围内的平台和环境 | ||
| 667 | * 产品和服务及其架构和设计 | ||
| 668 | * 有关变更和发布的需求和期望 | ||
| 669 | * 利益干系人需求，期望和联系方式 | ||
| 670 | |||
| 671 | 该信息可以采用各种形式。实践的关键输入和输出在第3节中列出。 | ||
| 672 | |||
| 673 | |||
| 674 | == **5.2 自动化和工具** == | ||
| 675 | |||
| 676 | 在大多数情况下，部署管理实践可以从自动化中受益匪浅。敏捷和DevOps环境中的部署主要面向自动化和技术。 | ||
| 677 | |||
| 678 | 如果部署可以实现自动化且行之有效，那么它可能涉及表5.1中概述的解决方案。 | ||
| 679 | |||
| 680 | [[image:1639625798477-746.png]] | ||
| 681 | |||
| 682 | [[image:1639625868838-906.png]] | ||
| 683 | |||
| 684 | [[image:1639625893341-491.png]] | ||
| 685 | |||
| 686 | 表5.1 部署管理活动的自动化解决方案 | ||
| 687 | |||
| 688 | |||
| 689 | |||
| 690 | ---- | ||
| 691 | |||
| 692 | = **6 合作伙伴和供应商** = | ||
| 693 | |||
| 694 | |||
| 695 | == **6.1 部署实践的采购注意事项** == | ||
| 696 | |||
| 697 | 仅使用组织自己的资源提供的服务很少。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL 基础 ：ITIL 4版 第2.4节：服务关系模型）。支持服务引入的关系和依赖关系在服务设计、体系结构管理和供应商管理的ITIL实践中进行了描述。 | ||
| 698 | |||
| 699 | 了解组织如何依赖第三方组件以及如何与包括部署管理实践在内的许多活动的关键供应商和合作伙伴建立有效的协作至关重要。 | ||
| 700 | |||
| 701 | 在具有多个供应商的环境中，了解每个组织的部署活动的范围和边界以及它们之间的交互方式非常重要。大多数组织都有用于部署的流程，标准工具和详细过程通常会为其提供支持，以确保一致地部署软件。对于不同的环境，通常会有不同的流程。 | ||
| 702 | |||
| 703 | 部署管理实践的许多领域可以通过有效的外包来实现，这可能涉及人员、能力、工具、流程和服务。 | ||
| 704 | |||
| 705 | 部署管理及其PSF可以通过多种形式的选择性和司法性采购来实现和增强，包括表6.1中概述的形式。 | ||
| 706 | |||
| 707 | |**发包区域**|**细节** | ||
| 708 | |人|在部署管理活动是手动的情况下，资源可以从合作伙伴那里获取。关键注意事项包括部署计划，内部资源的可用性，成本等。 | ||
| 709 | |技术/非技术技能和能力|在许多部署管理活动中，外包特定技能，包括技术能力（关于特定系统、技术、平台）和非技术能力（规划、管理和执行能力）非常有用，甚至是必需的。关键考虑因素包括技术/服务环境的多样性和复杂性，动态的技术环境、缺乏适当的内部资源等。 | ||
| 710 | |外包部署管理|在某些情况下，从合作伙伴那里获取整个部署管理实践可能是必要或有用的。 | ||
| 711 | |部署工具和技术|通过采用工具和技术，可以增强部署管理实践的多个领域。除少数情况外，这些技术、工具和工具链均来自特定的生产/ 服务提供者。 | ||
| 712 | |||
| 713 | 表6.1 部署管理实践中的外包 | ||
| 714 | |||
| 715 | |||
| 716 | |||
| 717 | |||
| 718 | ---- | ||
| 719 | |||
| 720 | = **7 重要提醒** = | ||
| 721 | |||
| 722 | 实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的主题目录，而不是答案列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则： | ||
| 723 | |||
| 724 | * 聚焦价值 | ||
| 725 | * 从你所处的地方开始 | ||
| 726 | * 基于反馈迭代推进 | ||
| 727 | * 协作和提升可视化程度 | ||
| 728 | * 通盘思考和工作 | ||
| 729 | * 保持简单实用 | ||
| 730 | * 优化和自动化 | ||
| 731 | |||
| 732 | 有关指导原则及其应用程序的更多信息，请参见ITIL Foundation：ITIL 4 Edition的4.3节。 | ||
| 733 | |||
| 734 | |||
| 735 | |||
| 736 | |||
| 737 | ---- | ||
| 738 | |||
| 739 | = **8 致谢** = | ||
| 740 | |||
| 741 | AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下方面： | ||
| 742 | |||
| 743 | |||
| 744 | == **8.1 作者** == | ||
| 745 | |||
| 746 | Vinod Kumar Agrasala, Roman Jouravlev, Konstantin Naryzhny. | ||
| 747 | |||
| 748 | |||
| 749 | == **8.2 审稿人** == | ||
| 750 | |||
| 751 | Jon Hall, Anton Lykov, Samantha Robertson, Oleg Skrynnik. |