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