Version 44.1 by superadmin on 2024/04/12, 10:22
Show last authors
1
2
3
4 **申明：**
5
6 本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注微信公众号：**ITILXF**，并回复“**发布管理**”即可。
7
8 {{box cssClass="floatinginfobox" title="**Contents**"}}
9 {{toc/}}
10 {{/box}}
11
12 (((
13
14 )))
15
16 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
17
18
19 翻译：李威  审校：郑中珮  审核：刘晓慧
20
21
22
23 ----
24
25 = **1 关于本文件** =
26
27 本文档为发布管理实践提供了实用指南。它分为五个主要部分，内容包括：
28
29 1. 有关实践的概括信息
30 1. 实践的流程和活动以及它们在服务价值链中的作用
31 1. 实践中涉及的组织和人员
32 1. 支持实践的信息和技术
33 1. 实践中关于合作伙伴和供应商的注意事项
34
35 == **1.1 ITIL 4 鉴证方案** ==
36
37 本文档的内容可作为以下课程的一部分检验标准：
38
39 1. ITIL专家 创建，交付和支持
40 1. ITIL专家 高速IT
41
42 有关详细信息，请参阅相关的教学大纲文档。
43
44
45
46 ----
47
48 = **2 基本信息** =
49
50
51 == (% style="color:#666666; font-size:14px" %)**2.1 目的和描述**(%%) ==
52
53
54 |(((
55 关键信息
56
57 发布管理实践的目的是使新的和变更的服务及功能均可用。
58 )))
59
60 发布管理实践是为了确保组织及其服务使用者在符合组织政策和协议的前提下，服务可以正常使用而产生的最佳实践。
61
62 传统场景下，服务组件（包括基础设施、软件和文档等）对用户都是可见并可以访问的。随着基础设施和文档的管理越来越数字化，软件管理的方法和模式需变得更适用于这些类型的服务组件，并在这样几个重点方面影响软件发布的实践与其他实践，比如服务验证与测试、部署管理、软件开发及管理等。
63
64 从客户和用户的旅程角度来看，发布管理支持引入和撤销。对于用户而言，此实践可能支持第一个接触点与服务提供者的交互。初始引入完成后，此实践支持服务交付的更新，这对于实践的成功非常重要。
65
66
67 == **2.2 关键术语和概念** ==
68
69 |(((
70 发布
71
72 使服务或仸何其他配置项的版本或配置项的集合可用。
73 )))
74
75 === **2.2.1 发布管理和部署管理** ===
76
77 组织应该定义发布和部署管理实践的最佳方法，并明确它在整个组织价值流以及服务关系中的具体角色。
78
79 一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产的环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
80
81 另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活劢启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
82
83 |(((
84 CI （持续集成）/ CD（持续部署）和发布管理
85
86 敏捷和DevOps中部署的关键概念包括持续集成、持续交付和持续部署。Martin Fowler 将它们定义为：
87
88 * 持续集成通常是指在软件开发环境中集成、构建和测试代码。
89 * 持续交付扩展了持续集成，涵盖了生产部署的最后阶段。持续交付意味着构建的软件可以随时发布到生产中。
90 * 持续部署是指通过流程并自动投入生产的变更。这样便可以每天进行多个生产部署。
91 * 持续交付意味着可以频繁部署，但部署决策是根据具体情况而定的，通常是因为企业更喜欢较慢的部署速度。持续部署要求完成持续交付。
92
93 在组织中，将发布的连续部署管理作为单独的实践来使用是普遍且有效的。新版本的软件、文档和数字基础设施配置一准备就绪，便会立即部署到运行环境中，然后使用发布管理实践为用户“打开”它们。
94
95 如果使用不带持续部署的持续交付，则部署新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。
96
97 最后，如果组细不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
98 )))
99
100 组织为所有产品和服务或每个产品定义了发布和部署管理实践的方法。这通常由组细的产品体系结构（及其跨产品的一致性）和组织对软件生命周期的管理方法来定义的。
101
102
103 === **2.2.2发布管理的方法，模型和计划** ===
104
105 如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于∶
106
107 * 商定的高级方法
108 * 针对用户及发布对象设置规则
109 * 发布单元和打包规则
110 * 推/拉条件
111 * 验证和验收标准
112 * 假设验证和实验的发布使用条款
113
114 产品可能有多个发布管理模型。例如，当产品用于在不同的市场上提供服务，或用于企业和个人服务消费者。
115
116 组织对产品的控制范围是影响发布管理模型开发和实践的因素之一。当组织控制整个产品生命周期（包括开发和部署）时，它可以更自由地定义发布管理模型。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常引入组织应该考虑的约束。虽然组织仍然可以决定是否在其服务中包含更新的组件，但是只能在一定程度上进行决定（取决于组件的供应商是否允许继续使用历史版本）。
117
118 |发布单元
119 配置项或部分配置项的预定义集合，它是发布包含的基本大小。
120
121 === **2.2.3 发布单元** ===
122
123 发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源，文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明;但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
124
125 某些发布实例可能包含不完整的发布单元，但这种情况应作为特例∶如紧急发布（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
126
127 重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。发布是面向用户的，发布单元的定义取决于服务的哪些组件会影响到用户使用服务和用户的体验。
128
129
130 === **2.2.4 推/拉条件** ===
131
132 发布管理模型的开发期间需要做出的决定之一是将服务组件的新版本推向用户，还是由用户拉取最新的版本，或是将多种方法混合使用。
133
134 "推"式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，"拉"式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
135
136 通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了"拉"或"推"方法。无论对内部和外部用户，都有很多亲和性。这包括∶
137
138 * 在整个用户群中使用单一版本（可维护性，兼容性）
139 * 用户体验更灵活（更好的可视化，灵活的定价选项）
140 * 提供在运行环境中管理多个版本的技术和组织能力
141 * 关键变更（严重的安全漏洞更新这种场景更适合"推"模式）
142 * 功能和其他客户的需求（如果实现了所需的新功能，客户可以要求所有用户进行更新）
143 * 监管要求
144
145 === **2.2.5 假设检验和实验** ===
146
147 发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
148
149 这些实验需要其他实践的共同参与。这包括但不限于∶
150
151 * 基础设施平台管理
152 * 软件开发管理
153 * 部署管理
154 * 架构管理
155 * 服务台
156 * 事件管理
157
158 == **2.3 实践的范围** ==
159
160 发布管理实践的范围包括以下内容：
161
162 * 开发和维护组织中新的和变更的服务与组件[[1 >>path:#_bookmark2]]的发布方法
163 * 在规划、实施和评审的各阶段，按照规定的方法管理和协调所有发布实例
164
165 有许多活动和职责范围与发布管理紧密相关，但不属于实践的范围。
166
167 表2.1中列出了其中一些关键领域，其中包括该实践的参考资料。重要的是，ITIL实践是在价值流中使用的工具的集合，应根据情况将它们视需要进行组合。
168
169
170 表2.1其他实践指南中描述的与发布相关的活动
171
172 (% style="width:461px" %)
173 |(% style="width:287px" %)**实现价值**|(% style="width:172px" %)**实践指南**
174 |(% style="width:287px" %)变更/发布的授权|(% style="width:172px" %)变更支持
175 |(% style="width:287px" %)在运行环境部署新的和更改的组件和服务|(% style="width:172px" %)部署管理
176 |(% style="width:287px" %)软件开发|(% style="width:172px" %)软件开发和管理
177 |(% style="width:287px" %)开发和构建基础架构组件|(% style="width:172px" %)基础设施和平台管理
178 |(% style="width:287px" %)用户培训支持和运维工作人员培训|(% style="width:172px" %)劳动力和人才管理
179 |(% style="width:287px" %)测试和验证服务和服务组件|(% style="width:172px" %)服务验证和测试
180 |(% style="width:287px" %)服务组件的命名和版本控制|(% style="width:172px" %)服务配置管理
181 |(% style="width:287px" %)管理与大规模发布的有关的组织变革|(% style="width:172px" %)组织变革管理
182 |(% style="width:287px" %)管理项目|(% style="width:172px" %)项目管理
183
184 == **2.4 实践成功因素** ==
185
186 PSF不仅仅是任务或实现价值，因为它包含所有服务管理四维模型的组件。在实践中，
187
188 |(((
189 实践成功因素（PSF）是实践实现其目的所必需的一组复杂的功能集合。
190 )))
191
192 PSF活动和资源的性质可能有所不同，但它们共同确保实践是有效的。
193
194 发布管理实践包含以下PSF：
195
196 * 在组织上建立和维护一套有效的服务和服务组件的发布的方法
197 * 确保在组织的价值流和服务关系的上下文中有效地发布服务和服务组件
198
199 === **2.4.1 为组织中的服务和服务组件的发布建立并维护一套有效的方法** ===
200
201 发布管理实践包括为新的和变更的服务和服务组件建立发布的方法和模型。组织可能会结合多种方法，并为他们管理的每个产品定义多个发布管理模型。
202
203 除了组织和产品信息之外，发布模型还由组织及其服务使用者之间的服务关系定义。其中包括以下因素：
204
205 * 内部或外部服务使用者
206 * 个人或公司服务消费
207 * 开箱即用或量身定制服务
208
209 这些因素是如何影响服务的更多详细信息，请参见ITIL®4：驱动利益相关者价值。
210
211 发布管理的方法和模型应具有一定的灵活性，以适应不断变化的情况，例如规模，紧急度或复杂性。可以基于约定的模型为每个发布实例制定计划，以反映发布实例的详细信息。
212
213 发布的方法、模型以及一般的实践应该进行持续改进，不断寻找消除浪费并增加效果和效率的方法。
214
215
216 === **2.4.2 确保在组织的价值流和服务关系的背景中，服务和服务组件的发布是有效的** ===
217
218 要确保有效的发布，可能需要在所有服务管理四维模型中组织资源。
219
220 依赖于发布管理的模型不同，实现发布实例所需的活动和资源差异很大：
221
222 * 为某个国家或地区的所有用户发布移动应用程序的新版本，可以通过更改先前部署的软件版本、相关的发布说明和用户文档来执行；并通知服务提供商组织内的利益相关者，无需采取进一步行动。
223 * 可以将新定制的ERP系统的安装、发布以及用户设备的升级作为一个大型项目进行管理，该项目涉及组织内外的许多团队和实践。
224
225 无论如何，有效的协作，使用自动化方式以及从软件生命周期早期阶段就具备良好的发布模型的规划对于发布的成功至关重要。
226
227 实践专注于确定任务与协调参与者，并提供有关版本发布过程中，使用的程序和技术的建议。因此，在实施过程中，有必要将实践与团队的协作有效结合。
228
229 有效的协调软件开发和管理，基础设施和平台管理，部署管理，服务验证以及测试与发布管理尤为重要。
230
231
232 == **2.5 关键指标** ==
233
234 ITIL实践的效果和表现应该在每个实践所贡献的价值流的背景下进行评估。与任何工具的表现或效果一样，只能在应用范围内评估。但是，工具的设计和质量可能会有很大的差异，这些差异定义了工具在使用过程中的不同能力。
235
236 实践也是如此，应在价值流的背景中评估其效果，但其能力是由资源的设计和质量决定的。有关度量标准，关键性能或绩效指标（KPI）的其他可以帮助实现此目标的技术，请参见度量和报告实践指南。
237
238 发布管理实践的关键指标已映射到PSFs。它们可以被当作价值流的背景中的KPI，以评估发布管理对这些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。
239
240 [[image:1642240011095-997.png]]
241
242 表2.2 实践成功因素的关键指标示例
243
244
245 正确选择指标，并将指标汇总/分类为不同组合/分层，可以更轻松的将其持续管理，并应用于价值流，定期评估和持续改进部署管理实践。
246
247 没有单一的最佳解决方案；度量标准将基于组织的总体背景、服务战略和组织的优先级，以及实践所贡献的价值流的目标而定义。
248
249
250
251 ----
252
253 = **3 价值流和流程** =
254
255
256 == **3.1 价值流的贡献** ==
257
258 像ITIL 的其他管理实践一样，发布管理也对多个价值流有贡献。重要的是，价值流永远不会由单个实践形成。发布管理实践与其他实践相结合，才能为消费者提供高质量服务。
259
260
261 图3.1中显示了发布管理实践对服务价值链的贡献点。
262
263 (% style="text-align:center" %)
264 [[image:图片1.png]]
265
266
267 图3 1发布管理对价值链的贡献热力图
268
269
270 实践贡献的主要价值链活动是：
271
272 * 计划
273 * 设计和转换
274 * 获取或构建
275 * 交付和支持
276
277 == **3.2 流程** ==
278
279 |(((
280 流程是一组将输入转化为输出的相互关联或交互的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了动作的执行顺序及其依赖性。
281 )))
282
283 每个实践可能包含一个或多个流程和活动，这对于实现该实践的目的可能是必需的。
284
285 发布管理实践活动形成两个流程：
286
287 * 发布规划
288 * 发布协调
289
290 === **3.2.1 发布规划** ===
291
292 该流程专注于发布方法、模式和复杂发布实例方法的开发，以及发布管理实践的持续改进。它定期执行，并由事件或请求触发，根据模型和程序的有效性，每两到三个月或者更频繁的进行定期审查。该流程包括以下活动，并将以下输入转换为表3.1中所示的输出。
293
294 [[image:1642240036250-400.png]]
295
296 表3.1 发布规划流程的输入活动和输出
297
298
299 图3.2显示了流程的工作流程
300
301 (% style="text-align:center" %)
302 [[image:图片2.png]]
303
304
305 图3.2 发布规划流程的工作流
306
307
308 表3.2提供了流程活动的示例
309
310 [[image:1642240074677-906.png]]
311
312 [[image:1642240097221-887.png]]
313
314 表3.2 发布规划流程活动的示例
315
316
317 === **3.2.2 发布协调** ===
318
319 该流程包括表3.3中所示的活动，并将输入转换为输出。
320
321 [[image:1642240130577-172.png]]
322
323 表3.3 发布协调流程的输入、活动和输出
324
325
326 图3.3显示了工作流的流程图
327
328 (% style="text-align:center" %)
329 [[image:图片3.png]]
330
331 图3.3 发布协调流程的工作流程图
332
333
334 表3.4显示了发布协调流程活动。
335
336 [[image:1642240258566-538.png]]
337
338 [[image:1642240275124-982.png]]
339
340 表3.4 发布协调流程活动
341
342
343
344 ----
345
346 = **4 组织和人员** =
347
348
349 == **4.1 角色，能力和职责** ==
350
351 实践指南没有描述实践管理的角色，例如实践所有者，实践领导者或实践教练。实践指南着重于每个专门角色的实践经验。每个组织架构中，对不同角色的命名可能都不同，因此ITIL中定义的任何被推荐的角色都不是强制的。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
352
353 流程和活动的背景中描述了角色。每个角色都具有基于表4.1中所示的模型的能力概况。
354
355 (% style="width:638px" %)
356 |(% style="width:101px" %)能力代码|(% style="width:535px" %)描述
357 |(% style="width:101px" %)L|(% style="width:535px" %)**领导者** 决策、授权，监督其他活动，提供激励和动力，并评估结果
358 |(% style="width:101px" %)А|(% style="width:535px" %)**管理员** 分配任务并确定优先级，保存记录，持续报告并启动基本改进
359 |(% style="width:101px" %)C|(% style="width:535px" %)**协调者 /沟通者** 协调多方，维护利益相关者之间的沟通,并开展宣传活动
360 |(% style="width:101px" %)М|(% style="width:535px" %)**方法和技巧专家** 设计和实施工作技术、文化步骤、流程咨询、工作分析和持续改进
361 |(% style="width:101px" %)Т|(% style="width:535px" %)**技术专家** 提供技术（IT）专业知识并执行基于专家经验的作业
362
363 表4.1能力代码和资料
364
365 在组织中发布管理实践会有一个特定的角色：发布经理。该角色通常是在发布大量产品的组织中，尤其是在需要手动规划和执行发布动作的组织中引入的。在其他组织中，产品或服务所有者可以承担发布经理的职责。
366
367
368 === **4.1.1 发布经理角色** ===
369
370 在定义发布经理角色的情况下，通常将此角色分配给对组织的业务，产品和服务，技术，平台，框架和流程有深入了解的专家。该角色需要全面的规划能力和项目管理技能以及权威来协调团队合作。
371
372 该角色的能力要求是AMCT。该角色通常负责规划、管理和协调整个发布管理实践以及各个发布实例，包括：
373
374 * 审查和开发发布方法和模型
375 * 促进整个组织采用被认可的的发布管理方法和模式
376 * 规划复杂发布方式
377 * 管理和传达发布日程
378 * 确保实践与其他实践保持一致性和协调性
379 * 审查并不断开发新实践
380
381 在某些复杂的组织中，发布经理的部分职责可能委派给发布协调员。
382
383
384 == **4.2 发布管理中涉及的角色活动** ==
385
386 表4.2中列出了发布管理活动中可能涉及的其他角色的示例，以及相关的能力概况和特定技能。
387
388 [[image:1642240419389-329.png]]
389
390 [[image:1642240444678-913.png]]
391
392 [[image:1642240486034-848.png]]
393
394 [[image:1642240520226-663.png]]
395
396 [[image:1642240611466-247.png]]
397
398 表4.2 发布管理活动涉及的角色示例
399
400
401 == **4.3 组织架构和团队** ==
402
403 只有在发布任务量巨大，或发布场景复杂的组织中，才适合建立指定的发布管理团队。大多数情况下，发布管理不需要专门的团队，只需建立临时的项目团队，或者将发布管理实现高度自动化就可以满足需求。
404
405 但是，在许多情况下，发布经理的角色仍然有用。该角色可以充当教练，以确保发布实践被整个组织采用。根据组织对发布管理的处理方式，此角色可以与部署经理的角色结合。
406
407
408
409 ----
410
411 = **5 信息和技术 ** =
412
413
414 == **5.1 信息交流** ==
415
416 发布管理的效果取决于所使用信息的质量。该信息包括但不限于以下信息：
417
418 1. 生产架构
419 1. 服务消费组织和用户
420 1. 软件开发和管理实践
421 1. 计划的和正在进行的部署
422 1. 正在进行和过去的事件
423 1. 新兴的发布管理技术
424
425 该信息可以采用各种形式。实践的输入和输出的详细列表在第3节中列出。
426
427
428 == **5.2 自动化和工具** ==
429
430 在数字化工作环境中的发布管理是高度自动化的。但是，即使在传统环境中，发布管理实践也可以从自动化中显著受益。在表5.1中，有很多可行且有效的解决方案。
431
432 [[image:1642240671717-163.png]]
433
434 [[image:1642240721417-774.png]]
435
436 [[image:1642240743263-782.png]]
437
438 表5.1 发布管理活动的自动化解决方案
439
440
441
442 ----
443
444 = **6 合作伙伴和供应商** =
445
446 只有很少量的服务是完全由组织自己的资源提供的，绝大多数需要依赖于外部服务。这些外部服务通常是由组织外的第三方供应商提供的（请参阅“ITIL Foundation 2.4：服务关系的模式的ITIL 4版）。
447
448 如前所述，合作伙伴和供应商充当的角色与组织对其产品和服务组件的控制级别有关。如果组织控制整个产品或服务生命周期（包括开发和部署）时，它在做出有关发布管理的决策方面就具有更大的自由度。相反，如果组织的产品或服务依赖于第三方组件，或者开发和部署由供应商管理，那么通常这种情况下，组织必须考虑引入的约束带来的影响了。虽然组织可以决定是否在其服务中引入更新的组件，但在一定程度上还是受到一些限制的。
449
450 组织有时可以将发布管理的某些内容外包。例如，用户沟通，发布的市场推广，用户培训，在假设测试中收集反馈等等。组织应该适当地管理那些合作伙伴和供应商活动，因为它们会直接影响用户的满意度和是否为此服务付费。
451
452 组织之间的关系可能涉及各种级别的整合和形式。（有关组织之间的关系的更多信息，请参见ITIL®Foundation：ITIL 4 Edition的表3.1）。与发布管理中的合作伙伴的集成级别取决于合作的形式，应通过发布管理，供应商管理，关系管理，服务级别管理和其他相关实践来决定和管理合作的形式。
453
454
455
456 ----
457
458 = **7 重要提醒** =
459
460 实践指南中大部分内容都应作为组织在建立和培养自己的实践时可以尝试的不同领域的建议。实践指南是组织可以尝试的的事情的目录，而不是答案的列表。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则：
461
462 * 聚焦价值
463 * 从你所处的地方开始
464 * 基于反馈迭代推进
465 * 协作和提升可视化程度
466 * 通盘思考和工作
467 * 保持简单实用
468 * 优化和自动化
469
470 更多有关指导原则及其应用程序的信息，请参见以下内容的第4.3节。
471
472 ITIL®基础：ITIL 4版出版物。
473
474
475
476 ----
477
478 = **8 致谢** =
479
480 AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
481
482
483 == **8.1 作家** ==
484
485 Vinod Kumar Agrasala, Konstantin Naryzhny, Roman Jouravlev
486
487
488 == **8.2 审稿人** ==
489
490 Oleg Skrynnik Jon Hall Anton Lykov, Samantha Robertson
深圳市艾拓先锋企业管理咨询有限公司