Last modified by roll tech on 2024/12/30, 17:25
From version < 40.1 >
edited by superadmin
on 2022/01/15, 17:59
To version < 9.1 >
edited by superadmin
on 2021/02/18, 22:20
< >
Change comment: 上传新附件微信截图_20210206234644.png

Summary

Details

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