Changes for page 服务管理实践 - 07 发布

Last modified by roll tech on 2024/12/30, 17:25

From version < 18.1 >

edited by superadmin
on 2021/02/19, 16:12

To version < 16.1 >

edited by superadmin
on 2021/02/19, 14:43

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -35,7
          +35,6 @@
 . 实践中关于合作伙伴和供应商的注意事项
--
  == **1.1 ITIL 4 鉴证方案** ==
  本文档的内容可作为以下课程的一部分检验标准：
@@ -52,7
          +52,7 @@
  = **2 基本信息** =
--== (% style="color: rgb(102, 102, 102); font-size: 14px" %)**2.1 目的和描述**(%%) ==
++== (% style="color:#666666; font-size:14px" %)**2.1 目的和描述**(%%) ==
  |(((
@@ -79,8
          +79,10 @@
  === **2.2.1 发布管理和部署管理** ===
++
  组织应该定义发布和部署管理实践的最佳方法，并明确它在整个组织价值流以及服务关系中的具体角色。
++
  一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产的环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
  另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活劢启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
@@ -107,6
          +107,7 @@
  === **2.2.2发布管理的方法，模型和计划** ===
++
  如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于∶
  *  商定的高级方法
@@ -118,13
          +118,15 @@
  产品可能有多个发布管理模型。例如，当产品用于在不同的市场上提供服务，或用于企业和个人服务消费者。
++
  组织对产品的控制范围是影响发布管理模型开发和实践的因素之一。当组织控制整个产品生命周期（包括开发和部署）时，它可以更自由地定义发布管理模型。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常引入组织应该考虑的约束。虽然组织仍然可以决定是否在其服务中包含更新的组件，但是只能在一定程度上进行决定（取决于组件的供应商是否允许继续使用历史版本）。
  |发布单元
  配置项或部分配置项的预定义集合，它是发布包含的基本大小。
++===
++**2.2.3 发布单元** ===
--=== **2.2.3 发布单元** ===
  发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源，文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明;但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
@@ -132,13
          +132,16 @@
  重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。发布是面向用户的，发布单元的定义取决于服务的哪些组件会影响到用户使用服务和用户的体验。
++===
++**2.2.4 推/拉条件** ===
--=== **2.2.4 推/拉条件** ===
  发布管理模型的开发期间需要做出的决定之一是将服务组件的新版本推向用户，还是由用户拉取最新的版本，或是将多种方法混合使用。
++
  "推"式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，"拉"式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
++
  通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了"拉"或"推"方法。无论对内部和外部用户，都有很多亲和性。这包括∶
  * 在整个用户群中使用单一版本（可维护性，兼容性）
@@ -149,11
          +149,12 @@
  * 监管要求
--
  === **2.2.5 假设检验和实验** ===
++
  发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
++
  这些实验需要其他实践的共同参与。这包括但不限于∶
  * 基础设施平台管理
@@ -164,8
          +164,104 @@
  * 事件管理
--== **2.3 实践的范围** ==
++== **2.3 发布管理和部署管理** ==
++
++|(((
++**发布**
++
++使服务或任何其他配置项的版本或配置项的集合可用。
++)))
++
++组织应该定义发布和部署管理实践的最佳方法，并明确它在整个组织价值流以及服务关系中的具体角色。
++
++一种方法是将发布和部署活动结合在一起。一旦服务组件被发布到生产环境中，用户便可以去使用。生产环境中不同版本的相同组件很少有共存的情况，就算在某一时间点共同存在，也不会持续很久。发布和部署活动（以及产品的整个生命周期）之间没有明确的边界。这种方法通常应用于硬件服务组件和大型独立的软件系统。
++
++另一种在敏捷开发模式、现代架构以及基于云的解决方案中比较适用。通过这种方法，可以在发布活动启动之前将新版本的软件部署到生产环境，然后再发布给部分或所有用户。在这种情况下，发布管理活动只需将重点放在启用服务上，便可以简单的实现发布的目的（例如，在存储库中更改应用的状态，指定的用户就可以进行下载操作了），另外降低复杂的人工操作的故障率（例如，训练用户降低风险并增加版本发布的有效性）。
++
++
++|(((
++CI （持续集成）/ CD（持续部署）和发布管理
++
++敏捷和DevOps中部署的关键概念包括持续集成、持续交付和持续部署。Martin Fowler 将它们定义为：
++
++* 持续集成通常是指在软件开发环境中集成、构建和测试代码。
++* 持续交付扩展了持续集成，涵盖了生产部署的最后阶段。持续交付意味着构建的软件可以随时发布到生产中。
++* 持续部署是指通过流程并自动投入生产的变更。这样便可以每天进行多个生产部署。持续交付意味着可以频繁部署，但部署决策是根据具体情况而定的，通常是因为企业更喜欢较慢的部署速度。持续部署要求完成持续交付。
++
++在组织中，将发布的连续部署管理作为单独的实践来使用是普遍且有效的。新版本的软件、文档和数字基础设施配置一准备就绪，便会立即部署到运行环境中，然后使用发布管理实践为用户“打开”它们。
++
++如果使用不带持续部署的持续交付，则部署新的和更改的发布组件可以在相应的价值流中作为单个步骤进行同步和管理。
++
++最后，如果组织不使用持续交付或持续部署，则发布管理活动更可能与部署管理结合使用。
++)))
++
++组织为所有产品和服务或每个产品定义了发布和部署管理实践的方法。这通常由组织的产品体系结构（及其跨产品的一致性）和组织对软件生命周期的管理方法来定义的。
++
++
++== **2.4 发布管理的方法、模型和计划** ==
++
++如果组织管理不同的架构产品，则可能会定义不同的发布管理方法。一旦就特定产品达成一致，就可以开发特定于产品的发布管理模型。该模型包括但不限于：
++
++* 商定的高级方法
++* 针对用户及发布对象设置规则
++* 发布单元和打包规则
++* 推/拉条件
++* 验证和验收标准
++* 假设验证和实验的发布使用条款
++
++产品可能有多个发布管理模型。例如，当产品用于在不同的市场上提供服务，或用于企业和个人服务消费者。
++
++组织对产品的控制范围是影响发布管理模型开发和实践的因素之一。当组织控制整个产品生命周期（包括开发和部署）时，它可以更自由地定义发布管理模型。相反，如果组织的服务基于第三方组件，或者开发和部署由供应商管理，则通常引入组织应该考虑的约束。虽然组织仍然可以决定是否在其服务中包含更新的组件，但是只能在一定程度上进行决定（取决于组件的供应商是否允许继续使用历史版本）。
++
++|(((
++发布单元
++
++配置项或部分配置项的预定义集合，它是发布包含的基本大小。
++)))
++
++
++=== **2.4.1 发布单元** ===
++
++发布单元可能包括不同类型的软件组件，用户设备以及其他硬件资源、文档。对于新用户而言，用于服务的初始发布的发布单元可以不同于用于更新同一服务的发布单元。但是，可能会建议甚至强制要求组件的某些组合。例如，每个更新都应包括为用户准备的版本发布说明；但是，在某些情况下，用户设备应在用户最初使用发布之后进行更新。
++
++某些发布实例可能包含不完整的发布单元，但这种情况应作为特例：如紧急发布（紧急更新），或者过于复杂且已定义了不切实际的发布单元。
++
++重要的是要记住，发布单元可能不同于部署单元，后者定义了通常一起部署的组件。发布是面向用户的，发布单元的定义取决于服务的哪些组件会影响到用户使用服务和用户的体验。
++
++
++=== **2.4.2 推/拉条件** ===
++
++发布管理模型的开发期间需要做出的决定之一是将服务组件的新版本推向用户，还是由用户拉取最新的版本，或是将多种方法混合使用。
++
++“推”式方法意味着在未经用户特定许可的情况下为用户启用了新的或变更的服务组件，用户必须使用这些版本。相比之下，“拉”式方法为用户提供了新的组件和服务，但是用户可以自己决定是否使用新的版本或坚持使用较旧的版本，甚至直接不使用这个服务。
++
++通常，组织不会采用单一方法。一般会为了更好地满足工作条件，定义了“拉”或“推”方法。无论对内部和外部用户，都有很多亲和性。这包括：
++
++* 在整个用户群中使用单一版本（可维护性，兼容性）
++* 用户体验更灵活（更好的可视化，灵活的定价选项）
++* 提供在运行环境中管理多个版本的技术和组织能力
++* 关键变更（严重的安全漏洞更新这种场景更适合“推”模式）
++* 功能和其他客户的需求（如果实现了所需的新功能，客户可以要求所有用户进行更新）
++* 监管要求
++
++
++=== **2.4.3 假设检验和实验** ===
++
++发布管理可用于验证假设和实验。当一个组织需要用一个样本用户群体来测试一个假设时，可以将可测试的服务发布给该组样本用户（有时称为治疗组）。这种方法被社会网络等大众服务提供商广泛使用，但也适用于小用户群体。相关技术包括蓝/绿发布，金丝雀发布和A/B测试等。
++
++这些实验需要其他实践的共同参与。这包括但不限于：
++
++* 基础设施平台管理
++* 软件开发管理
++* 部署管理
++* 架构管理
++* 服务台
++* 事件管理
++
++
++== **2.5 实践的范围** ==
++
  发布管理实践的范围包括以下内容：
  * 开发和维护组织中新的和变更的服务与组件[[1 >>path:#_bookmark2]]的发布方法
@@ -190,7
          +190,7 @@
  |管理项目|项目管理
--== **2.4 实践成功因素** ==
++== **2.6 实践成功因素** ==
  PSF不仅仅是任务或实现价值，因为它包含所有服务管理四维模型的组件。在实践中，
@@ -206,7
          +206,7 @@
  * 确保在组织的价值流和服务关系的上下文中有效地发布服务和服务组件
--=== **2.4.1 为组织中的服务和服务组件的发布建立并维护一套有效的方法** ===
++=== **2.6.1 为组织中的服务和服务组件的发布建立并维护一套有效的方法** ===
  发布管理实践包括为新的和变更的服务和服务组件建立发布的方法和模型。组织可能会结合多种方法，并为他们管理的每个产品定义多个发布管理模型。
@@ -223,7
          +223,7 @@
  发布的方法、模型以及一般的实践应该进行持续改进，不断寻找消除浪费并增加效果和效率的方法。
--=== **2.4.2 确保在组织的价值流和服务关系的背景中，服务和服务组件的发布是有效的** ===
++=== **2.6.2 确保在组织的价值流和服务关系的背景中，服务和服务组件的发布是有效的** ===
  要确保有效的发布，可能需要在所有服务管理四维模型中组织资源。
@@ -239,7
          +239,7 @@
  有效的协调软件开发和管理，基础设施和平台管理，部署管理，服务验证以及测试与发布管理尤为重要。
--== **2.5 关键指标** ==
++== **2.7 关键指标** ==
  ITIL实践的效果和表现应该在每个实践所贡献的价值流的背景下进行评估。与任何工具的表现或效果一样，只能在应用范围内评估。但是，工具的设计和质量可能会有很大的差异，这些差异定义了工具在使用过程中的不同能力。
@@ -439,6
          +439,7 @@
  表3.3 发布协调流程的输入、活动和输出
++
  图3.3显示了工作流的流程图
  (% style="text-align:center" %)
@@ -449,30
          +449,6 @@
  表3.4显示了发布协调流程活动。
--(% style="width:783px" %)
--|(% colspan="2" rowspan="1" %)活动|(% colspan="2" style="width:435px" %)软件组件的自动化发布|(% colspan="3" rowspan="1" style="width:493px" %)复杂发布项目
--|(% colspan="2" rowspan="1" %)确定适用的模型或计划|(% colspan="2" style="width:435px" %)基于生产或服务、目标环境或开发团队，发布流水线需要按照自动化发布模型和计划有条不紊的执行。|(% colspan="3" rowspan="1" style="width:493px" %)(((
--生产/ 服务负责人和开发团队一起评估已更改服务组件是否可以发布。
--
--团队评估发布实例与现有服务之间的相互依赖性，评估发布的风险（包括技术债务影响），并选择使用的合适发布模型。
--
--团队可以根据发布模型要求进行更新。
--)))
--|(% colspan="2" rowspan="1" %)服务组件的验证|(% colspan="2" style="width:435px" %)发布实例组件运行预置的组件测试。在CI 流水线中，提交的每个软件变更都需要通过自动化测试。|(% colspan="3" rowspan="1" style="width:493px" %)基于发布模型进行组件验证，也可以基于风险评估和技术债务进行一些其他的测试。
--|(% colspan="3" style="width:59px" %)服务组件的验证|(% colspan="2" style="width:277px" %)验证可以自动将组件发布给开发团队或者测试用户组，进行功能测试，或者发布给专门的用户组进行非功能测试，例如体验测试、安全测试、性能测试。|(% colspan="2" style="width:395px" %)如果某些组件未根据模型部署，则验证还需要额外触发其他构建，部署或测试动作。
--|(% colspan="3" style="width:59px" %)发布程序的验证|(% colspan="2" style="width:277px" %)根据组件属性自动选择发布规程。|(% colspan="2" style="width:395px" %)所选模型的发布过程将针对发布实例进行验证。只有满足所选发布模型的所有要求（全部所需的资源可用，过程已准备好运行），发布程序才会开始执行。
--|(% colspan="3" style="width:59px" %)发布执行|(% colspan="2" style="width:277px" %)根据预定义脚本执行的发布（例如，能将包含新特性的组件或环境路由到部分被授予权限的用户组），并自动通知受影响的用户组。|(% colspan="2" style="width:395px" %)基于事件触发（例如，项目团队决策，生产/ 服务经理批准或消费者请求）执行发布，并结合其他相关实践。内部和外部团队都可能参与其中。
--|(% colspan="3" style="width:59px" %)发布验证|(% colspan="2" style="width:277px" %)自动化脚本验证所有功能特性/组件均已发布。|(% colspan="2" style="width:395px" %)发布团队和专用用户检查是否所有功能/组件已发布。
--|(% colspan="3" style="width:59px" %)发布评审|(% colspan="2" style="width:277px" %)(((
--开发团队会分析自动发布流程的任何异常和日志。
--
--开发团队运行调试器，更新知识库并记录所汲取的教训。
--)))|(% colspan="2" style="width:395px" %)(((
--反馈来自用户组。
--
--发布团队运行发布调试器，更新知识库并记录汲取的经验教训。最终的发布评审报告可能会触发发布规划过程。
--)))
--
  表3.4 发布协调流程活动

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司