Version 16.1 by superadmin on 2021/02/19, 14:43
Show last authors
1 {{box cssClass="floatinginfobox" title="**Contents**"}}
2 {{toc/}}
3 {{/box}}
4
5 (((
6
7 )))
8
9 需要下载 **ITIL 4发布管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“发布”即可。
10
11 [[image:微信截图_20210206234644.png||height="153" width="152"]]
12
13
14 **申明：**
15
16 本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
17
18 请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
19
20
21 翻译：李威  审校：郑中珮  审核：刘晓慧
22
23
24
25 ----
26
27 = **1 关于本文件** =
28
29 本文档为发布管理实践提供了实用指南。它分为五个主要部分，内容包括：
30
31 1. 有关实践的概括信息
32 1. 实践的流程和活动以及它们在服务价值链中的作用
33 1. 实践中涉及的组织和人员
34 1. 支持实践的信息和技术
35 1. 实践中关于合作伙伴和供应商的注意事项
36
37
38 == **1.1 ITIL 4 鉴证方案** ==
39
40 本文档的内容可作为以下课程的一部分检验标准：
41
42 1. ITIL专家 创建，交付和支持
43 1. ITIL专家 高速IT
44
45 有关详细信息，请参阅相关的教学大纲文档。
46
47
48
49 ----
50
51 = **2 基本信息** =
52
53
54 == (% style="color:#666666; font-size:14px" %)**2.1 目的和描述**(%%) ==
55
56
57 |(((
58 关键信息
59
60 发布管理实践的目的是使新的和变更的服务及功能均可用。
61 )))
62
63 发布管理实践是为了确保组织及其服务使用者在符合组织政策和协议的前提下，服务可以正常使用而产生的最佳实践。
64
65 传统场景下，服务组件（包括基础设施、软件和文档等）对用户都是可见并可以访问的。随着基础设施和文档的管理越来越数字化，软件管理的方法和模式需变得更适用于这些类型的服务组件，并在这样几个重点方面影响软件发布的实践与其他实践，比如服务验证与测试、部署管理、软件开发及管理等。
66
67 从客户和用户的旅程角度来看，发布管理支持引入和撤销。对于用户而言，此实践可能支持第一个接触点与服务提供者的交互。初始引入完成后，此实践支持服务交付的更新，这对于实践的成功非常重要。
68
69
70 == **2.2 关键术语和概念** ==
71
72 |(((
73 发布
74
75 使服务或仸何其他配置项的版本或配置项的集合可用。
76 )))
77
78
79 === **2.2.1 发布管理和部署管理** ===
80
81
82 组织应该定义发布和部署管理实践的最佳方法，并明确它在整个组织价值流以及服务关系中的具体角色。
83
84
85 一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产的环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
86
87 另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活劢启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
88
89 |(((
90 CI （持续集成）/ CD（持续部署）和发布管理
91
92 敏捷和DevOps中部署的关键概念包括持续集成、持续交付和持续部署。Martin Fowler 将它们定义为：
93
94 * 持续集成通常是指在软件开发环境中集成、构建和测试代码。
95 * 持续交付扩展了持续集成，涵盖了生产部署的最后阶段。持续交付意味着构建的软件可以随时发布到生产中。
96 * 持续部署是指通过流程并自动投入生产的变更。这样便可以每天进行多个生产部署。
97 * 持续交付意味着可以频繁部署，但部署决策是根据具体情况而定的，通常是因为企业更喜欢较慢的部署速度。持续部署要求完成持续交付。
98
99 在组织中，将发布的连续部署管理作为单独的实践来使用是普遍且有效的。新版本的软件、文档和数字基础设施配置一准备就绪，便会立即部署到运行环境中，然后使用发布管理实践为用户“打开”它们。
100
101 如果使用不带持续部署的持续交付，则部署新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。
102
103 最后，如果组细不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
104 )))
105
106 组织为所有产品和服务或每个产品定义了发布和部署管理实践的方法。这通常由组细的产品体系结构（及其跨产品的一致性）和组织对软件生命周期的管理方法来定义的。
107
108
109 === **2.2.2发布管理的方法，模型和计划** ===
110
111
112 如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于∶
113
114 * 商定的高级方法
115 * 针对用户及发布对象设置规则
116 * 发布单元和打包规则
117 * 推/拉条件
118 * 验证和验收标准
119 * 假设验证和实验的发布使用条款
120
121 产品可能有多个发布管理模型。例如，当产品用于在不同的市场上提供服务，或用于企业和个人服务消费者。
122
123
124 组织对产品的控制范围是影响发布管理模型开发和实践的因素之一。当组织控制整个产品生命周期（包括开发和部署）时，它可以更自由地定义发布管理模型。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常引入组织应该考虑的约束。虽然组织仍然可以决定是否在其服务中包含更新的组件，但是只能在一定程度上进行决定（取决于组件的供应商是否允许继续使用历史版本）。
125
126 |发布单元
127 配置项或部分配置项的预定义集合，它是发布包含的基本大小。
128
129 ===
130 **2.2.3 发布单元** ===
131
132
133 发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源，文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明;但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
134
135 某些发布实例可能包含不完整的发布单元，但这种情况应作为特例∶如紧急发布（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
136
137 重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。发布是面向用户的，发布单元的定义取决于服务的哪些组件会影响到用户使用服务和用户的体验。
138
139 ===
140 **2.2.4 推/拉条件** ===
141
142
143 发布管理模型的开发期间需要做出的决定之一是将服务组件的新版本推向用户，还是由用户拉取最新的版本，或是将多种方法混合使用。
144
145
146 "推"式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，"拉"式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
147
148
149 通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了"拉"或"推"方法。无论对内部和外部用户，都有很多亲和性。这包括∶
150
151 * 在整个用户群中使用单一版本（可维护性，兼容性）
152 * 用户体验更灵活（更好的可视化，灵活的定价选项）
153 * 提供在运行环境中管理多个版本的技术和组织能力
154 * 关键变更（严重的安全漏洞更新这种场景更适合"推"模式）
155 * 功能和其他客户的需求（如果实现了所需的新功能，客户可以要求所有用户进行更新）
156 * 监管要求
157
158
159 === **2.2.5 假设检验和实验** ===
160
161
162 发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
163
164
165 这些实验需要其他实践的共同参与。这包括但不限于∶
166
167 * 基础设施平台管理
168 * 软件开发管理
169 * 部署管理
170 * 架构管理
171 * 服务台
172 * 事件管理
173
174
175 == **2.3 发布管理和部署管理** ==
176
177
178 |(((
179 **发布**
180
181 使服务或任何其他配置项的版本或配置项的集合可用。
182 )))
183
184 组织应该定义发布和部署管理实践的最佳方法，并明确它在整个组织价值流以及服务关系中的具体角色。
185
186 一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
187
188 另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活动启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
189
190
191 |(((
192 CI （持续集成）/ CD（持续部署）和发布管理
193
194 敏捷和DevOps中部署的关键概念包括持续集成、持续交付和持续部署。Martin Fowler 将它们定义为：
195
196 * 持续集成通常是指在软件开发环境中集成、构建和测试代码。
197 * 持续交付扩展了持续集成，涵盖了生产部署的最后阶段。持续交付意味着构建的软件可以随时发布到生产中。
198 * 持续部署是指通过流程并自动投入生产的变更。这样便可以每天进行多个生产部署。持续交付意味着可以频繁部署，但部署决策是根据具体情况而定的，通常是因为企业更喜欢较慢的部署速度。持续部署要求完成持续交付。
199
200 在组织中，将发布的连续部署管理作为单独的实践来使用是普遍且有效的。新版本的软件、文档和数字基础设施配置一准备就绪，便会立即部署到运行环境中，然后使用发布管理实践为用户“打开”它们。
201
202 如果使用不带持续部署的持续交付，则部署新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。
203
204 最后，如果组织不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
205 )))
206
207 组织为所有产品和服务或每个产品定义了发布和部署管理实践的方法。这通常由组织的产品体系结构（及其跨产品的一致性）和组织对软件生命周期的管理方法来定义的。
208
209
210 == **2.4 发布管理的方法、模型和计划** ==
211
212 如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于：
213
214 * 商定的高级方法
215 * 针对用户及发布对象设置规则
216 * 发布单元和打包规则
217 * 推/拉条件
218 * 验证和验收标准
219 * 假设验证和实验的发布使用条款
220
221 产品可能有多个发布管理模型。例如，当产品用于在不同的市场上提供服务，或用于企业和个人服务消费者。
222
223 组织对产品的控制范围是影响发布管理模型开发和实践的因素之一。当组织控制整个产品生命周期（包括开发和部署）时，它可以更自由地定义发布管理模型。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常引入组织应该考虑的约束。虽然组织仍然可以决定是否在其服务中包含更新的组件，但是只能在一定程度上进行决定（取决于组件的供应商是否允许继续使用历史版本）。
224
225 |(((
226 发布单元
227
228 配置项或部分配置项的预定义集合，它是发布包含的基本大小。
229 )))
230
231
232 === **2.4.1 发布单元** ===
233
234 发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源、文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明；但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
235
236 某些发布实例可能包含不完整的发布单元，但这种情况应作为特例：如紧急发布（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
237
238 重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。发布是面向用户的，发布单元的定义取决于服务的哪些组件会影响到用户使用服务和用户的体验。
239
240
241 === **2.4.2 推/拉条件** ===
242
243 发布管理模型的开发期间需要做出的决定之一是将服务组件的新版本推向用户，还是由用户拉取最新的版本，或是将多种方法混合使用。
244
245 “推”式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，“拉”式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
246
247 通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了“拉”或“推”方法。无论对内部和外部用户，都有很多亲和性。这包括：
248
249 * 在整个用户群中使用单一版本（可维护性，兼容性）
250 * 用户体验更灵活（更好的可视化，灵活的定价选项）
251 * 提供在运行环境中管理多个版本的技术和组织能力
252 * 关键变更（严重的安全漏洞更新这种场景更适合“推”模式）
253 * 功能和其他客户的需求（如果实现了所需的新功能，客户可以要求所有用户进行更新）
254 * 监管要求
255
256
257 === **2.4.3 假设检验和实验** ===
258
259 发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
260
261 这些实验需要其他实践的共同参与。这包括但不限于：
262
263 * 基础设施平台管理
264 * 软件开发管理
265 * 部署管理
266 * 架构管理
267 * 服务台
268 * 事件管理
269
270
271 == **2.5 实践的范围** ==
272
273 发布管理实践的范围包括以下内容：
274
275 * 开发和维护组织中新的和变更的服务与组件[[1 >>path:#_bookmark2]]的发布方法
276 * 在规划、实施和评审的各阶段，按照规定的方法管理和协调所有发布实例
277
278 有许多活动和职责范围与发布管理紧密相关，但不属于实践的范围。
279
280 表2.1中列出了其中一些关键领域，其中包括该实践的参考资料。重要的是，ITIL实践是在价值流中使用的工具的集合，应根据情况将它们视需要进行组合。
281
282
283 表2.1其他实践指南中描述的与发布相关的活动
284
285 |**实现价值**|**实践指南**
286 |变更/发布的授权|变更支持
287 |在运行环境部署新的和更改的组件和服务|部署管理
288 |软件开发|软件开发和管理
289 |开发和构建基础架构组件|基础设施和平台管理
290 |用户培训支持和运维工作人员培训|劳动力和人才管理
291 |测试和验证服务和服务组件|服务验证和测试
292 |服务组件的命名和版本控制|服务配置管理
293 |管理与大规模发布的有关的组织变革|组织变革管理
294 |管理项目|项目管理
295
296
297 == **2.6 实践成功因素** ==
298
299 PSF不仅仅是任务或实现价值，因为它包含所有服务管理四维模型的组件。在实践中，
300
301 |(((
302 实践成功因素（PSF）是实践实现其目的所必需的一组复杂的功能集合。
303 )))
304
305 PSF活动和资源的性质可能有所不同，但它们共同确保实践是有效的。
306
307 发布管理实践包含以下PSF：
308
309 * 在组织上建立和维护一套有效的服务和服务组件的发布的方法
310 * 确保在组织的价值流和服务关系的上下文中有效地发布服务和服务组件
311
312
313 === **2.6.1 为组织中的服务和服务组件的发布建立并维护一套有效的方法** ===
314
315 发布管理实践包括为新的和变更的服务和服务组件建立发布的方法和模型。组织可能会结合多种方法，并为他们管理的每个产品定义多个发布管理模型。
316
317 除了组织和产品信息之外，发布模型还由组织及其服务使用者之间的服务关系定义。其中包括以下因素：
318
319 * 内部或外部服务使用者
320 * 个人或公司服务消费
321 * 开箱即用或量身定制服务
322
323 这些因素是如何影响服务的更多详细信息，请参见ITIL®4：驱动利益相关者价值。
324
325 发布管理的方法和模型应具有一定的灵活性，以适应不断变化的情况，例如规模，紧急度或复杂性。可以基于约定的模型为每个发布实例制定计划，以反映发布实例的详细信息。
326
327 发布的方法、模型以及一般的实践应该进行持续改进，不断寻找消除浪费并增加效果和效率的方法。
328
329
330 === **2.6.2 确保在组织的价值流和服务关系的背景中，服务和服务组件的发布是有效的** ===
331
332 要确保有效的发布，可能需要在所有服务管理四维模型中组织资源。
333
334 依赖于发布管理的模型不同，实现发布实例所需的活动和资源差异很大：
335
336 * 为某个国家或地区的所有用户发布移动应用程序的新版本，可以通过更改先前部署的软件版本、相关的发布说明和用户文档来执行；并通知服务提供商组织内的利益相关者，无需采取进一步行动。
337 * 可以将新定制的ERP系统的安装、发布以及用户设备的升级作为一个大型项目进行管理，该项目涉及组织内外的许多团队和实践。
338
339 无论如何，有效的协作，使用自动化方式以及从软件生命周期早期阶段就具备良好的发布模型的规划对于发布的成功至关重要。
340
341 实践专注于确定任务与协调参与者，并提供有关版本发布过程中，使用的程序和技术的建议。因此，在实施过程中，有必要将实践与团队的协作有效结合。
342
343 有效的协调软件开发和管理，基础设施和平台管理，部署管理，服务验证以及测试与发布管理尤为重要。
344
345
346 == **2.7 关键指标** ==
347
348 ITIL实践的效果和表现应该在每个实践所贡献的价值流的背景下进行评估。与任何工具的表现或效果一样，只能在应用范围内评估。但是，工具的设计和质量可能会有很大的差异，这些差异定义了工具在使用过程中的不同能力。
349
350 实践也是如此，应在价值流的背景中评估其效果，但其能力是由资源的设计和质量决定的。有关度量标准，关键性能或绩效指标（KPI）的其他可以帮助实现此目标的技术，请参见度量和报告实践指南。
351
352 发布管理实践的关键指标已映射到PSFs。它们可以被当作价值流的背景中的KPI，以评估发布管理对这些价值流的效果和效率的贡献。表2.2中给出了一些关键指标的示例。
353
354 |**实践成功因素**|(% colspan="2" %)**关键指标**
355 |(((
356 * 在整个组织中建立并维护一套有效的发布服务和服务组件的方法
357 )))|(% colspan="2" %)(((
358 * 利益相关者的满意度，以及向用户介绍新服务和变更服务的方式
359 * 在组织上采用发布管理的协商方法
360 * 重要合作伙伴和服务消费者对发布管理方法和模型的认同
361 * 审计调查结果以及由版本发布引起的外部合规性问题
362 )))
363 |(% colspan="2" %)(((
364 * 确保在组织的价值流和服务关系的背景中执行有效的服务和服务组件发布
365 )))|(((
366 * 利益相关者的满意度与发布实例
367 * 发布成功实例的百分比/ 发布错误/失败的次数
368 * 与发布相关的事件的数量和百分比
369 * 及时/遵守发布日程
370 * 发布待办项吞吐量
371 )))
372
373 表2.2 实践成功因素的关键指标示例
374
375
376 正确选择指标，并将指标汇总/分类为不同组合/分层，可以更轻松的将其持续管理，并应用于价值流，定期评估和持续改进部署管理实践。
377
378 没有单一的最佳解决方案；度量标准将基于组织的总体背景、服务战略和组织的优先级，以及实践所贡献的价值流的目标而定义。
379
380
381
382 ----
383
384 = **3 价值流和流程** =
385
386
387 == **3.1 价值流的贡献** ==
388
389 像ITIL 的其他管理实践一样，发布管理也对多个价值流有贡献。重要的是，价值流永远不会由单个实践形成。发布管理实践与其他实践相结合，才能为消费者提供高质量服务。
390
391
392 图3.1中显示了发布管理实践对服务价值链的贡献点。
393
394 (% style="text-align:center" %)
395 [[image:图片1.png]]
396
397
398 图3 1发布管理对价值链的贡献热力图
399
400
401 实践贡献的主要价值链活动是：
402
403 * 计划
404 * 设计和转换
405 * 获取或构建
406 * 交付和支持
407
408
409 == **3.2 流程** ==
410
411 |(((
412 流程是一组将输入转化为输出的相互关联或交互的活动。流程接受一个或多个已定义的输入，并将其转换为已定义的输出。流程定义了动作的执行顺序及其依赖性。
413 )))
414
415 每个实践可能包含一个或多个流程和活动，这对于实现该实践的目的可能是必需的。
416
417 发布管理实践活动形成两个流程：
418
419 * 发布规划
420 * 发布协调
421
422
423 === **3.2.1 发布规划** ===
424
425 该流程专注于发布方法、模式和复杂发布实例方法的开发，以及发布管理实践的持续改进。它定期执行，并由事件或请求触发，根据模型和程序的有效性，每两到三个月或者更频繁的进行定期审查。该流程包括以下活动，并将以下输入转换为表3.1中所示的输出。
426
427 |**关键输入**|**活动**|**关键输出**
428 |(((
429 * 当前的发布管理方法和模型
430 * 发布记录
431 * 发布评审报告
432 * 政策法规要求
433 * 生产架构
434 * 服务目录
435 * 服务级别协议
436 * 事件记录和报告
437 * IT资产信息
438 * 与供应商、合作伙伴的协议合同
439 * 相关政策和计划（信息安全，连续性，容量，等等。）
440 )))|(((
441 * 生产架构和服务关系分析
442 * 发布管理方法评审和开发
443 * 发布管理模型评审和开发
444 * 发布实例规划
445 * 发布计划沟通
446 )))|(((
447 * 更新的发布管理方法和模型
448 * 发布计划
449 * 发布日程
450 * 改进建议
451 * 变更请求
452 * 更新的知识管理文章
453 * 获取经验
454 )))
455
456 表3.1 发布规划流程的输入活动和输出
457
458
459 图3.2显示了流程的工作流程
460
461 (% style="text-align:center" %)
462 [[image:图片2.png]]
463
464
465 图3.2 发布规划流程的工作流
466
467
468 表3.2提供了流程活动的示例
469
470 |**实现价值**|**普通评审**|**复杂发布实例的规划**
471 |产品架构和服务关系分析|(((
472 发布经理与生产/ 服务所有者、架构师和其他团队一起分析和讨论影响发布方法的新条件或更改条件：
473
474 * 创建/修改一组生产和服务的首选方法
475 * 产品或服务的性质
476 * 组织的架构方法和决策
477 * 主要的发布受众和与他们之间关系，现有的服务级别协议
478 * 组织的风险管理和风险偏好
479 * 合规性，政策和技术机遇与限制
480 * 市场地位和财务条件
481 * 对产品或服务组件的控制级别
482
483 在分析和讨论的基础上，对现有方法提出了更改，或定义了新的发布方法。
484 )))|发布经理与生产/ 服务所有者、架构师和其他团队一起分析并讨论了影响发布实例的因素。
485 |发布管理方法的评审和开发|团队讨论新的发布方法，或对现有发布方法进行更改，并就该方法达成一致。发布方法已开发或更新。|发布经理与生产/服务所有者，架构师和其他团队一起运行现有发布方法，分析其适配性与差距，并选择适用于所讨论的复杂发布实例的最佳方法。
486 |发布管理模式的评审和开发|(((
487 基于新方法或更改后的方法，定义或更新发布模型。例如：
488
489 * 发布程序
490 * 发布权威
491 * 模板计划
492 * 日程模板
493 * 沟通计划模板
494 * 知识文章
495
496 为多个发布实例开发的自动化脚本。
497 )))|(((
498 团队应评估发布实例的风险，同时考虑之前的知识架构，技术债务，服务级别协议和用户关系以及安全性，可用性，连续性，容量和财务限制。
499
500 团队基于最初的待办事项评估，决定使用新的或现有的发布模型。
501 )))
502 |发布实例规划| |(((
503 团队针对发布实例计划以下内容：
504
505 * 目标受众
506 * 发布实例中包含的组件或功能的集合
507 * 启用组件/功能的顺序和方法（例如，使用特性开关），包括假设验证和实验的规划
508 * 验证、接受标准和用户启用（培训，知识共享，账号准备等）
509 * 发布单元和打包规则
510
511 推/拉条件
512 )))
513 |发布计划沟通|为新的或变更的发布计划，日程和程序进行的沟通，并由利益相关者审查，输入服务台和知识管理中。|利益相关者对发布计划和日程的沟通，结果输入服务台和知识管理。
514
515 表3.2 发布规划流程活动的示例
516
517
518 === **3.2.2 发布协调** ===
519
520 该流程包括表3.3中所示的活动，并将输入转换为输出。
521
522 |关键输入|活动|关键输出
523 |(((
524 * 发布管理模型
525 * 发布计划
526 * 发布日程
527 * 环境详情
528 * 已部署到运行环境或为部署准备的服务组件或发布组件
529 * 验收标准
530 )))|(((
531 * 标识适用的模型或计划
532 * 服务组件的验证
533 * 发布程序的验证
534 * 发布执行、发布验证、发布评审
535 )))|(((
536 * 已经发布的服务组件/服务
537 * 发布记录
538 * 发布沟通
539 * 用户，客户和相关团队成员的反馈
540 * 发布评审报告
541 )))
542
543 表3.3 发布协调流程的输入、活动和输出
544
545
546
547 图3.3显示了工作流的流程图
548
549 (% style="text-align:center" %)
550 [[image:图片3.png]]
551
552 图3.3 发布协调流程的工作流程图
553
554
555 表3.4显示了发布协调流程活动。
556
557 表3.4 发布协调流程活动
558
559
560 ----
561
562 = **4 组织和人员** =
563
564
565 == **4.1 角色，能力和职责** ==
566
567 实践指南没有描述实践管理的角色，例如实践所有者，实践领导者或实践教练。实践指南着重于每个专门角色的实践经验。每个组织架构中，对不同角色的命名可能都不同，因此ITIL中定义的任何被推荐的角色都不是强制的。请记住，角色不是职务。一个人可以担任多个角色，一个角色可以分配给多个人。
568
569 流程和活动的背景中描述了角色。每个角色都具有基于表4.1中所示的模型的能力概况。
570
571 |能力代码|描述
572 |L|**领导者** 决策、授权，监督其他活动，提供激励和动力，并评估结果
573 |А|**管理员** 分配任务并确定优先级，保存记录，持续报告并启动基本改进
574 |C|**协调者 /沟通者** 协调多方，维护利益相关者之间的沟通,并开展宣传活动
575 |М|**方法和技巧专家** 设计和实施工作技术、文化步骤、流程咨询、工作分析和持续改进
576 |Т|**技术专家** 提供技术（IT）专业知识并执行基于专家经验的作业
577
578 表4.1能力代码和资料
579
580 在组织中发布管理实践会有一个特定的角色：发布经理。该角色通常是在发布大量产品的组织中，尤其是在需要手动规划和执行发布动作的组织中引入的。在其他组织中，产品或服务所有者可以承担发布经理的职责。
581
582
583 === **4.1.1 发布经理角色** ===
584
585 在定义发布经理角色的情况下，通常将此角色分配给对组织的业务，产品和服务，技术，平台，框架和流程有深入了解的专家。该角色需要全面的规划能力和项目管理技能以及权威来协调团队合作。
586
587 该角色的能力要求是AMCT。该角色通常负责规划、管理和协调整个发布管理实践以及各个发布实例，包括：
588
589 * 审查和开发发布方法和模型
590 * 促进整个组织采用被认可的的发布管理方法和模式
591 * 规划复杂发布方式
592 * 管理和传达发布日程
593 * 确保实践与其他实践保持一致性和协调性
594 * 审查并不断开发新实践
595
596 在某些复杂的组织中，发布经理的部分职责可能委派给发布协调员。
597
598
599 == **4.2 发布管理中涉及的角色活动** ==
600
601 表4.2中列出了发布管理活动中可能涉及的其他角色的示例，以及相关的能力概况和特定技能。
602
603 |实现价值|负责角色|能力简介|具体技能
604 |(% colspan="4" %)发布规划流程
605 |生产架构和服务关系分析|(((
606 企业架构师
607
608 服务负责人
609
610 产品负责人
611
612 关系经理
613
614 开发团队成员
615
616 客户经理
617
618 交付经理
619
620 设师
621 )))|ATC|(((
622 服务关系的知识
623
624 商业分析
625
626 服务架构的知识
627
628 发布和部署方法的知识
629
630 基础架构和平台方面的专业知识
631
632 沟通技巧
633 )))
634 |发布管理方法|(((
635 服务负责人
636
637 产品负责人
638 )))|AMTC|(((
639 服务关系知识
640
641 发布和部署方法的知识
642 )))
643 |评审和开发|(((
644 关系经理
645
646 开发团队成员
647
648 客户经理
649
650 交付经理
651 )))| |(((
652 基础设施和平台方面的专业知识
653
654 沟通技巧
655 )))
656 |发布管理模型评审和开发|(((
657 服务负责人
658
659 产品负责人
660
661 开发团队成员
662
663 客户经理
664
665 交付经理
666 )))|AMTC|(((
667 服务关系的知识
668
669 发布和部署方法的知识
670
671 基础架构和平台方面的专业知识
672
673 沟通技巧
674 )))
675 |发布实例规划| |TA|(((
676 基础架构和平台方面的专业知识
677
678 服务/ 生产的技术知识
679
680 服务架构的知识
681
682 发布和部署方法的知识
683
684 管理服务/ 生产的专业知识
685
686 服务关系的知识
687 )))
688 |发布计划沟通|(((
689 服务负责人
690
691 产品负责人
692
693 关系经理
694
695 客户经理
696
697 交付经理
698 )))|C|(((
699 服务关系知识
700
701 沟通技巧
702
703 营销知识
704 )))
705 |(% colspan="4" %)发布协调流程
706 |确定适用的模型或计划|(((
707 服务负责人
708
709 产品负责人
710
711 开发团队成员
712
713 客户经理
714
715 交付经理
716
717 设计师
718 )))|AT|(((
719 服务/ 产品的管理知识
720
721 用户服务体验
722
723 基础架构和平台方面的专业知识
724
725 发布和部署方法的知识
726
727 服务/ 产品的技术知识
728 )))
729 |服务组件的验证|(((
730 服务负责人
731
732 产品负责人
733
734 开发团队成员
735
736 客户经理
737
738 交付经理
739
740 客户代表
741 )))|TA|(((
742 基础设施和平台方面的专业知识
743
744 发布和部署方法的知识
745
746 服务/ 产品的技术知识
747
748 服务/ 产品的管理专业知识
749 )))
750 |发布程序的验证|(((
751 开发团队成员
752
753 系统管理员
754
755 信息安全专家
756 )))|TA|(((
757 基础架构和平台方面的专业知识
758
759 服务/ 产品的技术知识
760
761 服务/ 产品的管理知识
762 )))
763 |发布执行|(((
764 开发团队成员
765
766 系统管理员
767
768 信息安全专家
769 )))|T|(((
770 基础设施和平台方面的专业知识
771
772 发布和部署方法的知识
773
774 服务/ 产品的技术知识
775 )))
776 |发布验证|(((
777 服务负责人
778
779 产品负责人
780
781 客户经理
782
783 交付经理
784
785 开发团队成员
786
787 客户代表
788
789 用户
790 )))|A|(((
791 服务/ 产品管理的专业知识
792
793 用户的服务体验
794 )))
795 |发布评审|(((
796 服务负责人
797
798 产品负责人
799
800 关系经理
801
802 客户经理
803
804 交付经理
805
806 开发团队成员
807
808 设计师
809
810 客户代表
811
812 用户
813 )))|ATC|(((
814 服务关系的知识
815
816 业务分析
817
818 服务架构的知识
819
820 发布和部署方法的知识
821
822 基础设施和平台方面的专业知识
823
824 服务/产品的技术知识
825
826 沟通技巧
827
828 营销知识
829 )))
830
831 表4.2 发布管理活动涉及的角色示例
832
833
834 == **4.3 组织架构和团队** ==
835
836 只有在发布任务量巨大，或发布场景复杂的组织中，才适合建立指定的发布管理团队。大多数情况下，发布管理不需要专门的团队，只需建立临时的项目团队，或者将发布管理实现高度自动化就可以满足需求。
837
838 但是，在许多情况下，发布经理的角色仍然有用。该角色可以充当教练，以确保发布实践被整个组织采用。根据组织对发布管理的处理方式，此角色可以与部署经理的角色结合。
839
840
841
842 ----
843
844 = **5 信息和技术 ** =
845
846
847 == **5.1 信息交流** ==
848
849 发布管理的效果取决于所使用信息的质量。该信息包括但不限于以下信息：
850
851 1. 生产架构
852 1. 服务消费组织和用户
853 1. 软件开发和管理实践
854 1. 计划的和正在进行的部署
855 1. 正在进行和过去的事件
856 1. 新兴的发布管理技术
857
858 该信息可以采用各种形式。实践的输入和输出的详细列表在第3节中列出。
859
860
861 == **5.2 自动化和工具** ==
862
863 在数字化工作环境中的发布管理是高度自动化的。但是，即使在传统环境中，发布管理实践也可以从自动化中显著受益。在表5.1中，有很多可行且有效的解决方案。
864
865 |实现价值|自动化手段|(% colspan="2" %)关键功能|实践上的影响
866 |(% colspan="5" %)发布计划过程
867 |生产架构和服务关系分析|(((
868 架构工具
869
870 业务分析和建模工具产品/ 服务建模工具
871 )))|(% colspan="2" %)生产/ 服务架构以及关系，连接和约束的可视化|中
872 |发布管理方法评审和开发|(((
873 流程建模工具
874
875 产品/ 服务建模工具
876
877 业务分析工具
878 )))|(% colspan="2" %)对过程与程序的建模，可视化和评估|低
879 |发布管理模式评审和开发|流程建模工具|(% colspan="2" %)对过程与程序的建模，可视化|中
880 |发布实例规划|(((
881 流程建模工具
882
883 发布和部署管理工具
884
885 流水线管理工具
886
887 软件交付和集成工具
888
889 开发环境
890 )))|(% colspan="2" %)自动化发布管理|高
891 |发布计划沟通|(((
892 社交网络
893
894 门户
895
896 知识库工具
897 )))|(% colspan="2" %)自动通信、消息、状态更新|高
898 |(% colspan="5" %)发布协调流程
899 |确定适用的模式或计划|(% colspan="2" %)(((
900 流程建模工具
901
902 发布和部署管理工具
903
904 流水线管理工具
905 )))|流程和过程的建模与可视化|低
906 |服务组件的验证|(((
907 发布和部署管理工具
908
909 流水线管理工具
910
911 软件交付和集成工具
912
913 开发环境
914 )))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
915 |发布程序的验证|(((
916 发布和部署管理工具
917
918 流水线管理工具
919
920 软件交付和集成工具
921
922 开发环境
923 )))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
924 |发布执行|(((
925 发布和部署管理工具
926
927 流水线管理工具
928
929 软件交付和集成工具
930
931 开发环境
932 )))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
933 |发布验证|(((
934 发布和部署管理工具
935
936 流水线管理工具
937
938 软件交付和集成工具
939 )))|(% colspan="2" %)基于预先规划的、已开发的脚本，自动化发布管理|高
940 |发布评审|(((
941 监控工具
942
943 协作工具
944
945 沟通工具
946 )))|(% colspan="2" %)(((
947 提供信息和警告
948
949 知识共享
950
951 问题沟通
952 )))|中
953
954 表5.1 发布管理活动的自动化解决方案
955
956
957
958 ----
959
960 = **6 合作伙伴和供应商** =
961
962 只有很少量的服务是完全由组织自己的资源提供的，绝大多数需要依赖于外部服务。这些外部服务通常是由组织外的第三方供应商提供的（请参阅“ITIL Foundation 2.4：服务关系的模式的ITIL 4版）。
963
964 如前所述，合作伙伴和供应商充当的角色与组织对其产品和服务组件的控制级别有关。如果组织控制整个产品或服务生命周期（包括开发和部署）时，它在做出有关发布管理的决策方面就具有更大的自由度。相反，如果组织的产品或服务依赖于第三方组件，或者开发和部署由供应商管理，那么通常这种情况下，组织必须考虑引入的约束带来的影响了。虽然组织可以决定是否在其服务中引入更新的组件，但在一定程度上还是受到一些限制的。
965
966 组织有时可以将发布管理的某些内容外包。例如，用户沟通，发布的市场推广，用户培训，在假设测试中收集反馈等等。组织应该适当地管理那些合作伙伴和供应商活动，因为它们会直接影响用户的满意度和是否为此服务付费。
967
968 组织之间的关系可能涉及各种级别的整合和形式。（有关组织之间的关系的更多信息，请参见ITIL®Foundation：ITIL 4 Edition的表3.1）。与发布管理中的合作伙伴的集成级别取决于合作的形式，应通过发布管理，供应商管理，关系管理，服务级别管理和其他相关实践来决定和管理合作的形式。
969
970
971
972 ----
973
974 = **7 重要提醒** =
975
976 实践指南中大部分内容都应作为组织在建立和培养自己的实践时可以尝试的不同领域的建议。实践指南是组织可以尝试的的事情的目录，而不是答案的列表。使用ITIL 实践指南的内容时，组织应始终遵循ITIL 指导原则：
977
978 1. 聚焦价值
979 1. 从你所处的地方开始
980 1. 基于反馈迭代推进
981 1. 协作和提升可视化程度
982 1. 通盘思考和工作
983 1. 保持简单实用
984 1. 优化和自动化
985
986 更多有关指导原则及其应用程序的信息，请参见以下内容的第4.3节。
987
988 ITIL®基础：ITIL 4版出版物。
989
990
991
992 ----
993
994 = **8 致谢** =
995
996 AXELOS Ltd非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
997
998
999 == **8.1 作家** ==
1000
1001 Vinod Kumar Agrasala, Konstantin Naryzhny, Roman Jouravlev
1002
1003
1004 == **8.2 审稿人** ==
1005
1006 Oleg Skrynnik Jon Hall Anton Lykov, Samantha Robertson
深圳市艾拓先锋企业管理咨询有限公司