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