文档更改4.高速IT技术

由 superadmin 于 2024/04/03, 17:15 最后修改

从版本< 56.1 >

由superadmin编辑
在2022/01/09, 12:14上

到版本

由superadmin编辑
在2022/01/09, 12:15上

< >

修改评论该版本没有评论

Raw
已渲染

Summary

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

Details

Page properties

Content

@@ -92,18
          +92,9 @@
  表4.1 与优先级相关的实践
--(% style="width:781px" %)
--|**ITIL管理实践**|(% style="width:536px" %)**与优先次序相关的活动/资源**|(% style="width:95px" %)**影响**
--|组合管理|(% style="width:536px" %)持续根据价值优先考虑服务产品，并考虑延迟成本。|(% style="width:95px" %)H
--|问题管理|(% style="width:536px" %)计算未解决问题和错误的财务成本，以便确定优先级并指导问题管理工作。将规避措施的成本与长期解决方案的成本进行比较。|(% style="width:95px" %)H
--|项目管理|(% style="width:536px" %)计算执行或延迟项目工作的财务影响。|(% style="width:95px" %)H
--|软件开发与管理|(% style="width:536px" %)计算延迟工作对新软件功能或较大的基于软件的服务组件的财务影响。决定是获取还是构建软件组件。|(% style="width:95px" %)H
--|变更控制|(% style="width:536px" %)计算对服务或服务组件的变更进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
--|事件管理|(% style="width:536px" %)计算事故和重大事故的成本，以便优先安排对经济影响最大的工作。|(% style="width:95px" %)M
--|发布管理|(% style="width:536px" %)计算对新服务或变更的服务进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
--|服务财务管理|(% style="width:536px" %)计算时间值概要文件数据，以提供用于确定服务产品优先级的信息。|(% style="width:95px" %)M
--|服务请求管理|(% style="width:536px" %)计算和比较执行或延迟执行请求的财务影响，以便优先安排具有最高收益的工作。|(% style="width:95px" %)L
++[[image:1641700591514-812.png]]
++
  **ITIL故事：优先排序技术**
  //Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
@@ -141,46
          +141,11 @@
  表4.2 与最小可用方法相关的实践
--(% style="width:863px" %)
--|**ITIL管理实践**|(% style="width:575px" %)**与最小可用方法相关的活动/资源**|(% style="width:87px" %)**影响**
--|架构管理|(% style="width:575px" %)(((
--使用最小可用的方法来描述服务、技术、信息或环境体系结构，这将为其他类型
++[[image:1641700659017-287.png]]
--的服务或产品工作创建必要的约束、边界或促成因素。
--)))|(% style="width:87px" %)H
--|业务分析|(% style="width:575px" %)使用最低可行的方法作为从产品或服务中提取核心业务价值的工具。|(% style="width:87px" %)H
--|容量与性能管理|(% style="width:575px" %)(((
--使用容量和性能管理作为计算最低可行产品或服务所需的最小资源（服务器数量，服务
++[[image:1641700701040-265.png]]
--台代理数量等）的基础。
--)))|(% style="width:87px" %)H
--|监控与事态管理|(% style="width:575px" %)(((
--使用监控和事态管理作为设计和配置监视和遥测工具的基础，这些工具用于操作和从最低
--限度可行的产品或服务中学习。
--)))|(% style="width:87px" %)H
--|组合管理|(% style="width:575px" %)(((
--使用最小可用产品的概念作为动态决策工具，以支持对产品或服务中的功能组合进行良好
--
--的投资。
--)))|(% style="width:87px" %)H
--|项目管理|(% style="width:575px" %)阐明满足业务案例所需的最小输出。|(% style="width:87px" %)H
--|服务设计|(% style="width:575px" %)使用最小可用的方法来设计产品或服务的必要客户体验和用户体验元素。|(% style="width:87px" %)H
--|服务验证与测试|(% style="width:575px" %)开发测试用例以检查所有服务组件是否支持最低限度的可行产品或服务。|(% style="width:87px" %)H
--|软件开发管理|(% style="width:575px" %)使用最小可用方法作为决策工具来优先处理软件功能。|(% style="width:87px" %)H
--|架构管理|(% style="width:575px" %)(((
--使用最小可用方法作为决策工具来设计，实施基础架构组件上正在进行的工作并确定其优
--
--先级。
--)))|(% style="width:87px" %)M
--|服务目录管理|(% style="width:575px" %)(((
--使用最小可用方法作为描述所有产品、服务和服务产品的基础，并确保相关受众能够获取
--
--信息。
--)))|(% style="width:87px" %)M
--|服务连续性管理|(% style="width:575px" %)设计和建立连续性计划以支持最低限度的可行产品或服务。|(% style="width:87px" %)M
--|供应商管理|(% style="width:575px" %)合作伙伴和供应商提供产品和服务时，使用最小可用方法阐明所需的输出。|(% style="width:87px" %)M
--
  **ITIL的故事：最小可用产品和服务**
  //Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
@@ -211,29
          +211,9 @@
  表4.3 与产品或服务所有权相关的实践
--(% style="width:788px" %)
--|**ITIL管理实践**|(% style="width:566px" %)**与产品或服务所有权相关的活动/资源**|(% style="width:63px" %)**影响**
--|架构管理|(% style="width:566px" %)(((
--产品和服务所有者参与阐明，完善基础架构和平台开发积压工作并确定其优先级，并
++[[image:1641700764097-167.png]]
--决定是否购买市售的基础架构组件和服务。
--)))|(% style="width:63px" %)H
--|组合管理|(% style="width:566px" %)（软件）产品所有者和产品或服务经理参与评估和确定产品或服务投资建议的优先级。|(% style="width:63px" %)H
--|关系管理|(% style="width:566px" %)(((
--与利益干系人的互动。
--参与确定客户对新产品或已变更产品和服务的优先级。
--
--协调客户的需求和反馈。
--
--参与解决投诉和调解相互矛盾的要求。
--)))|(% style="width:63px" %)H
--|服务目录管理|(% style="width:566px" %)产品或服务所有者和经理参与发布有关所有产品、服务和服务产品的信息。|(% style="width:63px" %)H
--|软件开发管理|(% style="width:566px" %)产品和服务所有者参与阐明，完善和确定软件开发积压的优先次序，并决定是否购买或升级商用软件。|(% style="width:63px" %)H
--|项目管理|(% style="width:566px" %)产品和服务所有者及经理参与交付项目工作和管理风险。|(% style="width:63px" %)M
--|风险管理|(% style="width:566px" %)产品和服务所有者参与阐明和减轻企业风险。|(% style="width:63px" %)M
--|供应商管理|(% style="width:566px" %)产品和服务所有者及管理人员参与阐明需求，组织互动以及与合作伙伴和供应商进行谈判。|(% style="width:63px" %)M
--
  **ITIL故事：产品或服务所有权**
  //Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
@@ -272,18
          +272,9 @@
  表4.4 与A/B测试相关的实践
--(% style="width:1031px" %)
--|**ITIL管理实践**|(% style="width:747px" %)**与A / B测试相关的活动/资源**|(% style="width:103px" %)**影响**
--|组合管理|(% style="width:747px" %)确定并优先考虑使用A / B测试数据进行投资的服务、产品和功能。|(% style="width:103px" %)H
--|风险管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定风险缓解方案的有效性。|(% style="width:103px" %)H
--|服务设计|(% style="width:747px" %)在进行进一步的投资和设计决策之前，使用A / B测试方法确定客户体验和用户体验原型的有效性。|(% style="width:103px" %)H
--|架构管理|(% style="width:747px" %)使用A / B测试方法设计和完善技术，信息，产品和服务体系结构。|(% style="width:103px" %)M
--|持续改进|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定各种改进方案和计划的有效性。|(% style="width:103px" %)M
--|知识管理|(% style="width:747px" %)在进行进一步的投资之前，使用A / B测试方法确定不同知识管理，表示以及通讯技术和工的有效性。|(% style="width:103px" %)M
--|组织变革管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定组织变革的有效性。|(% style="width:103px" %)M
--|问题管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定规避措施和错误控制方法的有效性。|(% style="width:103px" %)M
--|服务验证与测试|(% style="width:747px" %)使用A / B测试方法定义和执行服务、验证和产品测试活动。|(% style="width:103px" %)M
++[[image:1641700825218-144.png]]
++
  **ITIL的故事：A / B测试**
  //Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
@@ -354,29
          +354,10 @@
  图4.7 基础设施作为代码对服务价值链的贡献的热图
--‘
  表4.5 与基础设施作为代码相关的实践
--(% style="width:825px" %)
--|**ITIL管理实践**|(% style="width:560px" %)**与基础设施作为代码相关的活动/资源**|(% style="width:90px" %)**影响**
--|架构管理|(% style="width:560px" %)验证架构决策并比较基础架构解决方案。|(% style="width:90px" %)H
--|变更控制|(% style="width:560px" %)启用虚拟基础架构组件的快速配置或停用，以平衡交付速度与治理，风险和合规性需求。|(% style="width:90px" %)H
--|部署管理|(% style="width:560px" %)自动化基础架构的部署，确保基础架构和应用程序的部署更快，更重复，更可靠。|(% style="width:90px" %)H
--|信息安全管理|(% style="width:560px" %)在虚拟基础架构组件中设计和实施安全策略。|(% style="width:90px" %)H
--|IT资产管理|(% style="width:560px" %)跟踪分配给通常快速配置或停用的虚拟基础结构组件的商业软件许可证的使用。|(% style="width:90px" %)H
--|知识管理|(% style="width:560px" %)存储虚拟服务器配置文件，并使它们可用于IaC自动化。|(% style="width:90px" %)H
--|服务配置管理|(% style="width:560px" %)以适当的粒度级别设计和维护配置管理数据库和关系，以跟踪经常快速调配或退役的虚拟基础架构组件。|(% style="width:90px" %)H
--|服务财务管理|(% style="width:560px" %)由于对基础设施的投资减少，资金从资本支出转向运营支出。|(% style="width:90px" %)H
--|服务请求管理|(% style="width:560px" %)自动配置或停用虚拟基础架构组件。|(% style="width:90px" %)H
--|服务验证与测试|(% style="width:560px" %)设计和维护测试用例，以确保虚拟IaC满足组织要求和策略。|(% style="width:90px" %)H
--|软件开发管理|(% style="width:560px" %)开发软件体系结构和代码，以利用虚拟硬件基础结构的快速交付/配置。|(% style="width:90px" %)H
--|事件管理|(% style="width:560px" %)利用IaC功能自动化（在适当情况下）事件恢复任务。|(% style="width:90px" %)M
--|基础架构管理|(% style="width:560px" %)快速交付/配置虚拟硬件基础架构。|(% style="width:90px" %)M
--|问题管理|(% style="width:560px" %)利用IaC功能进行问题检测和错误控制。|(% style="width:90px" %)M
--|服务连续性管理|(% style="width:560px" %)设计适当的连续性计划以反映组织对IaC功能的使用。|(% style="width:90px" %)M
--|供应商管理|(% style="width:560px" %)选择可以提供IaC功能或利用组织对IaC的投资的供应商。|(% style="width:90px" %)M
--|风险管理|(% style="width:560px" %)认识到通过使用IaC引入或减轻的风险。|(% style="width:90px" %)L
++[[image:1641700916381-114.png]]
  表4.5 列出了与基础设施作为代码相关的实践。
@@ -422,23
          +422,11 @@
  表4.6 与松散耦合信息系统架构相关的实践
--(% style="width:718px" %)
--|(% style="width:108px" %)**ITIL管理实践**|(% style="width:520px" %)**与松散耦合信息系统架构相关的活动/资源**|(% style="width:87px" %)**影响**
--|(% style="width:108px" %)架构管理|(% style="width:520px" %)设计松耦合的服务，技术和信息体系结构。|(% style="width:87px" %)H
--|(% style="width:108px" %)业务分析|(% style="width:520px" %)了解消费者需求并将其转化为每个需求的详细需求松耦合服务体系结构的组件。|(% style="width:87px" %)H
--|(% style="width:108px" %)部署管理|(% style="width:520px" %)部署的范围和部署模式因以下因素的解耦而减小：系统架构；这使部署更易于管理和复制，并且功能强大自动化的候选人。|(% style="width:87px" %)H
--|(% style="width:108px" %)信息安全管理|(% style="width:520px" %)为松散耦合的服务设计和管理信息安全策略、服务组件。|(% style="width:87px" %)H
--|(% style="width:108px" %)基础设施及平台管理|(% style="width:520px" %)松耦合基础架构的详细设计，构建，运行和管理和平台组件。|(% style="width:87px" %)H
--|(% style="width:108px" %)问题管理|(% style="width:520px" %)研究问题并设计跨越多个松耦合系统的错误控制。|(% style="width:87px" %)H
--|(% style="width:108px" %)服务配置管理|(% style="width:520px" %)设计和维护有关各种服务和服务组件的信息，以及他们的相互关系。|(% style="width:87px" %)H
--|(% style="width:108px" %)服务级别管理|(% style="width:520px" %)通过与消费者的松耦合架构设计和调整服务级别服务消费方面的期望。|(% style="width:87px" %)H
--|(% style="width:108px" %)软件开发管理|(% style="width:520px" %)松耦合软件的详细设计、构建、运行和管理组件。|(% style="width:87px" %)H
--|(% style="width:108px" %)变更控制|(% style="width:520px" %)松散耦合的体系结构降低了与应用程序、基础架构变更相关的风险，如果这些变更失败。 较低的风险状况会导致变化在团队级别（而不是部门或组织级别）批准，从而减少了官僚。|(% style="width:87px" %)M
--|(% style="width:108px" %)事件管理|(% style="width:520px" %)事件后可以计划调查和解决方案， 以更少的压力和更有效的方式进行演练。服务中断的影响松散耦合的体系结构通常限于无法使用的配置项（CI），而不是其他CI。这是由于系统组件的设计原理应该具有弹性，并且不依赖于其他配置项提供的服务。结果是，事件对客户的影响较小。|(% style="width:87px" %)M
--|(% style="width:108px" %)服务财务管理|(% style="width:520px" %)松散耦合的系统体系结构使第三方服务的耦合和解耦更加容易，从而使服务提供商能够利用降价和提供新产品的优势。 这种灵活性还要求服务提供商采用敏捷成本核算模型来有效地切换提供商。|(% style="width:87px" %)M
--|(% style="width:108px" %)供应商管理|(% style="width:520px" %)当某些组件松散时，建立合同并管理绩效。耦合体系结构由供应商或外部服务提供商提供。|(% style="width:87px" %)M
--|(% style="width:108px" %)战略管理|(% style="width:520px" %)由于投资的原因，将紧密耦合的体系结构去耦是一项战略级决策必要条件以及利用它的潜在运营模式含义（例如引入自治团队）。 这种架构的一个例子是面向服务的可以将第三方服务作为端到端服务的一部分的体系结构。|(% style="width:87px" %)L
++[[image:1641701019297-720.png]]
++[[image:1641701038534-675.png]]
++
++
  === 4.2.3 复查 ===
  通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
@@ -457,20
          +457,7 @@
  表4.7 与回顾相关的实践
--(% style="width:965px" %)
--|**ITIL管理实践**|(% style="width:722px" %)**与回顾相关的活动/资源**|(% style="width:77px" %)**影响**
--|持续改进|(% style="width:722px" %)定期或在完成时审查持续改进计划的活动和技术，以了解是否正在实现预期的成果。|(% style="width:77px" %)H
--|项目管理|(% style="width:722px" %)审查项目工作并汲取经验教训的活动和技术，可以使未来的类似项目受益。|(% style="width:77px" %)H
--|服务级别管理|(% style="width:722px" %)定期检查和修改服务水平（以了解如何改进）的活动和技术。|(% style="width:77px" %)H
--|软件开发管理|(% style="width:722px" %)定期审查工作以了解如何改进的活动和技术。|(% style="width:77px" %)H
--|变更控制|(% style="width:722px" %)定期审查进行变更的有效性和效率以了解如何改进的活动和技术（包括有关创建或暂停标准变更模型的决定）。|(% style="width:77px" %)M
--|事件管理|(% style="width:722px" %)定期或在重大事件后回顾事件管理工作的活动和技术，以了解如何改进。|(% style="width:77px" %)M
--|问题管理|(% style="width:722px" %)定期检查问题和错误控制以了解如何改进的活动和技术。|(% style="width:77px" %)M
--|关系管理|(% style="width:722px" %)定期审查与各种利益干系人之间现有关系的状态和方向的活动和技术。|(% style="width:77px" %)M
--|风险管理|(% style="width:722px" %)定期或在触发缓解措施后审查缓解风险的活动和技术，以了解如何提高风险。|(% style="width:77px" %)M
--|服务连续性管理|(% style="width:722px" %)从灾难恢复后，审查连续性计划的效率和有效性的活动和技术。|(% style="width:77px" %)M
--|服务台|(% style="width:722px" %)定期检查服务台交互的活动和技术，以了解如何改进。|(% style="width:77px" %)M
--|供应商管理|(% style="width:722px" %)定期审查与各种合作伙伴和供应商之间现有关系的状态和方向的活动和技巧。|(% style="width:77px" %)M
++[[image:1641701094058-713.png]]
  表4.7概述了与回顾相关的实践。
@@ -510,29
          +510,9 @@
  表4.8 免责的时候反思的实践
--(% style="width:920px" %)
--|**ITIL管理实践**|(% style="width:701px" %)**与无指责相关的活动/资源**|(% style="width:80px" %)**影响**
--|变更控制|(% style="width:701px" %)调查成功和失败的变更，以发现机会，以提高未来变更的成功率。|(% style="width:80px" %)H
--|部署管理|(% style="width:701px" %)调查服务组件的成功和失败部署，以发现机会，以提高未来部署的成功率。|(% style="width:80px" %)H
--|事件管理|(% style="width:701px" %)调查事件管理（和重大事件管理）活动，以发现改进的机会。|(% style="width:80px" %)H
--|问题管理|(% style="width:701px" %)调整领导方式以检查系统而不是人员。事后回顾可以帮助组织获得有关事件情况的更多信息。这为问题识别和调查提供了更好的信息。|(% style="width:80px" %)H
--|项目管理|(% style="width:701px" %)调查项目活动，以吸取经验教训和改进未来项目的机会。|(% style="width:80px" %)H
--|发布管理|(% style="width:701px" %)调查服务的成功和失败版本，以发现提高未来版本成功率的机会。|(% style="width:80px" %)H
--|持续改进|(% style="width:701px" %)(((
--调查持续改进活动，以识别经验教训，了解系统中的变更以及确定增加或保持未来改进成
++[[image:1641701145033-568.png]]
--功的机会。
--)))|(% style="width:80px" %)M
--|信息安全管理|(% style="width:701px" %)获取有关与安全漏洞和安全事件有关的情况的更多信息。|(% style="width:80px" %)M
--|风险管理|(% style="width:701px" %)触发风险缓解措施后，评估其风险，以了解如何改进缓解措施以及对当前和未来风险的应对措施。修改风险记录并探索可能的风险的新领域。|(% style="width:80px" %)M
--|服务台|(% style="width:701px" %)调查与外部利益干系人的互动，以发现改进互动和持续沟通的机会。|(% style="width:80px" %)M
--|服务验证与测试|(% style="width:701px" %)调查成功和失败的验证和测试活动，以发现提高未来成功率的机会。|(% style="width:80px" %)M
--|软件开发管理|(% style="width:701px" %)(((
--从回顾中获取经验教训和改进思路。
--让合作伙伴和供应商收集反馈以进行学习注册。
--)))|(% style="width:80px" %)M
--
  === 4.2.4 持续业务分析 ===
  瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
@@ -568,22
          +568,11 @@
  表4.9 与持续业务分析相关的实践
--(% style="width:900px" %)
--|**ITIL管理实践**|(% style="width:682px" %)**与持续业务分析相关的活动/资源**|(% style="width:96px" %)**影响**
--|业务分析|(% style="width:682px" %)持续了解分析客户、市场状况和更广泛的生态系统，以了解他们对组织产品和服务的影响。|(% style="width:96px" %)M
--|基础架构管理|(% style="width:682px" %)持续了解分析客户、状况和更广泛的生态系统，以了解他们对组织的基础架构和平台产品的影响。|(% style="width:96px" %)M
--|组合管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织投资各种产品和服务的方式的影响。监控正在进行的组合投资，以识别价值或验证价值共创。|(% style="width:96px" %)M
--|项目管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统了解它们对组织项目和相关业务案例的影响。|(% style="width:96px" %)M
--|关系管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织与外部利益干系人关系的影响。|(% style="width:96px" %)M
--|风险管理|(% style="width:682px" %)持续分析内部和外部公司风险，以评估和了解其对组织产品和服务的影响，并设计适当的缓解措施和对策。|(% style="width:96px" %)M
--|服务设计|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解其对客户和用户体验组织产品和服务的影响。|(% style="width:96px" %)M
--|软件开发管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织软件产品的影响以及正在进行的软件开发工作的优先级。|(% style="width:96px" %)M
--|战略管理|(% style="width:682px" %)持续监视和评估客户，市场状况以及更广泛的生态系统，以了解其对组织产品和服务的影响，并相应地调整策略。|(% style="width:96px" %)M
--|架构管理|(% style="width:682px" %)持续分析组织内部和外部利益干系人对技术的使用，以了解其对组织的技术，服务和信息体系结构的影响。|(% style="width:96px" %)M
--|知识管理|(% style="width:682px" %)不断了解分析客户，市场状况和更广泛的生态系统，以在相关利益干系人之间建立共识。|(% style="width:96px" %)M
--|服务连续性管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，它们对组织的连续性和灾难恢复措施的影响。|(% style="width:96px" %)M
--|供应商管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以它们对组织与合作伙伴和供应商关系的影响。|(% style="width:96px" %)M
++[[image:1641701202590-318.png]]
++[[image:1641701238590-838.png]]
++
++
  === 4.2.5 持续集成、持续交付和持续部署 ===
  持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
@@ -620,21
          +620,9 @@
  表4.10 与CI/CD最相关的实践
--(% style="width:852px" %)
--|**ITIL管理实践**|(% style="width:651px" %)**与CI/CD最相关相关的活动/资源**|(% style="width:84px" %)**影响**
--|变更控制|(% style="width:651px" %)可以根据业务需求和期望，使用CI / CD管道来调整组织产品和服务的变化率。|(% style="width:84px" %)H
--|部署管理|(% style="width:651px" %)系统地/自动地将特定版本的软件或软件包安装到预定的环境（集成，用户验收测试，生产）。|(% style="width:84px" %)H
--|基础机构管理|(% style="width:651px" %)将CI / CD技术用于数字基础架构。|(% style="width:84px" %)H
--|发布管理|(% style="width:651px" %)认识到软件的部署和功能的发布通常是有助于计划和管理发布的不同活动。|(% style="width:84px" %)H
--|服务配置管理|(% style="width:651px" %)管理代码存储库和构成CI / CD工具链一部分的相关工具，并不断更新CMDB以反映进行了重大（CI级别）变更的时间。|(% style="width:84px" %)H
--|服务验证与测试|(% style="width:651px" %)开发自动化测试用例以支持持续的集成活动。|(% style="width:84px" %)H
--|软件开发管理|(% style="width:651px" %)使用用于应用程序软件的CI / CD技术。|(% style="width:84px" %)H
--|架构管理|(% style="width:651px" %)设计和改进服务，技术和信息体系结构以利用CI / CD功能。容器化是支持CI / CD的体系结构选择。|(% style="width:84px" %)M
--|信息安全管理|(% style="width:651px" %)通过减少手工工作来确保遵守信息安全合规。通过利用CI / CD工具来增加自动化的规模和范围，可以通过减少手工工作并改进变更的可追溯性来帮助确保遵守信息安全合规。|(% style="width:84px" %)M
--|知识管理|(% style="width:651px" %)不断更新知识库，以确保组织保持对通过CI / CD管道构建和部署的软件的最新了解。|(% style="width:84px" %)M
--|服务连续性管理|(% style="width:651px" %)应该建立CI / CD管道以将软件组件推向连续性和灾难恢复系统。|(% style="width:84px" %)M
--|风险管理|(% style="width:651px" %)通过使用CI / CD自动化减少某些类型的企业风险的影响。|(% style="width:84px" %)L
++[[image:1641701293452-859.png]]
++
  **ITIL故事：持续集成、持续交付和持续部署**
  //Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。//
@@ -647,34
          +647,11 @@
  表4.11 软件测试的类型
--(% style="width:813px" %)
--|(% style="width:165px" %)测试思路|(% style="width:646px" %)所有软件都源于一个想法，通常是试图解决问题的尝试。 测试该想法有助于从客户角度（基于需求和需求）和业务角度（基于指标，包括增长，收入，转化和用户基础）确定其质量。
--|(% style="width:165px" %)测试原型|(% style="width:646px" %)原型，例如史诗，用户故事，验收标准，数据流程图和过程流程图，应进行测试。 检查原型内的信息可以帮助识别与风险和变量有关的歧义，假设和信息。 该信息可用作反馈，以帮助审查和改进伪像。
--|(% style="width:165px" %)测试用户体验和用户界面设计|(% style="width:646px" %)原型用于设计活动，编程活动和测试活动。 设计活动产生的设计原型超出了可以测试的范围。 使用相关的原型对界面和体验进行了测试，并且测试结果可能会影响其他原型。
--|(% style="width:165px" %)测试架构和代码设计|(% style="width:646px" %)在设计软件体系结构并讨论如何构建它和新功能时，探索性测试可以增强设计和思想。
--|(% style="width:165px" %)代码测试|(% style="width:646px" %)代码审查是构建高质量产品的重要组成部分。任何人都应该能够阅读该代码并从不同的角度对其进行测试。单元测试可验证软件的每个单元是否都能正常运行。单元测试通常是自动化的。重要的是要注意，这是软件开发生命周期中的第一点，应该有针对性地加以衡量。
--|(% style="width:165px" %)测试操作软件|(% style="width:646px" %)测试操作软件是与测试相关的最常见的活动。开发后，许多敏捷团队都将“测试”作为其工作流中的一种状态。但是，测试不应该成为工作流程中的一种状态。它应该是在软件开发生命周期中进行的一系列结构化活动。
--|(% style="width:165px" %)在不同环境测试|(% style="width:646px" %)当涉及测试环境时，基于风险的方法可能是合适的。有很多风险可以测试。其中一些无法在开发环境中进行测试。对于其他人，则需要严格集成的环境来进行测试。某些风险只能在实际生产环境中进行测试。
--|(% style="width:165px" %)测试发布管道|(% style="width:646px" %)可以测试管道流程，团队通常会隐式地进行测试，以使其管道尽可能高效和快速地进行增强。这需要对管道测试背后的结构有充分的了解。
--|(% style="width:165px" %)生产环境下测试|(% style="width:646px" %)(((
--必须在生产环境中对某些风险进行测试，例如性能风险（尤其是用户负载和用户压力风险），用户接受度测试（用户将其与实际软件一样使用系统）和可观察性风险（以测试有效性、可观察性解决方案和实现）。
++[[image:1641701417790-550.png]]
--在生产中进行测试时，目标应该是最大程度地降低影响客户的测试风险。实现这一目标的策略包括：
++[[image:1641701444463-764.png]]
--● **金丝雀发布 **这项新功能最初是针对少数目标用户发布的，后来逐渐增加到所有用户。
--●** 功能开关** 可以将功能隐藏在功能标志的后面，通过打开或关闭该标志可以轻松启用或禁用
--
--该功能。
--
--● **蓝/绿部署 **两个相同的生产环境同时运行（一个“蓝色”和一个“绿色”），只有一个环
--
--境处于活动状态，为所有生产流量提供服务，而另一个用于部署新版本。
--
--● **自动化的回滚策略 **发生事件时，自动化工具可以快速将发行版恢复为先前版本。
--)))
--|(% style="width:165px" %)测试生产环境中的服务|(% style="width:646px" %)为已发布的生产软件实现了许多服务，活动和技术，所有这些都可以进行测试。从服务交付的角度来看，测试流程很重要。 例如，在测试用户是否可以访问支持时，重要的是要问用户获得支持有多容易，用户在软件中在什么情况下做到这一点。
--
  为了实现持续测试，应制定一些原则，包括：
  * 测试应该以最低级别进行。
@@ -699,16
          +699,9 @@
  表4.12 与持续测试最相关的实践
--(% style="width:834px" %)
--|**ITIL管理实践**|(% style="width:641px" %)**与持续测试相关的活动/资源**|(% style="width:79px" %)**影响**
--|架构管理|(% style="width:641px" %)设计和改进服务，技术和信息架构，以利用CI / CD功能|(% style="width:79px" %)H
--|服务验证与测试|(% style="width:641px" %)在整个开发生命周期中，将持续进行单元，集成和回归测试。这包括应用程序单元测试，基础结构服务测试，功能/非功能测试，canary版本，蓝/绿测试以及基础结构安全性测试。|(% style="width:79px" %)H
--|部署管理|(% style="width:641px" %)导致连续测试失败的变更或部署会触发团队的告警线。然后，团队成员蜂拥而至以解决问题。|(% style="width:79px" %)M
--|信息安全管理|(% style="width:641px" %)通过减少手工工作来确保遵守信息安全合规。利用自动化测试工具，可以减少手工工作并提高变更的可追溯性，从而有助于确保遵守信息安全合规。|(% style="width:79px" %)M
--|问题管理|(% style="width:641px" %)自动化测试有助于验证问题的解决方案，已知错误的存在或规避措施的有效性。|(% style="width:79px" %)M
--|服务连续性管理|(% style="width:641px" %)自动化测试可以加速提供从灾难中恢复所需的技术资源。|(% style="width:79px" %)M
--|风险管理|(% style="width:641px" %)使用测试自动化减少某些类型的企业风险的影响。|(% style="width:79px" %)L
++[[image:1641701509520-551.png]]
++
  **ITIL的故事：持续测试**
  //Su：我们投放市场的每个产品都经过全面测试，以确保它是符合目 的并适合使用。应用程序的改进没有什么不同。我们测试了//：
@@ -780,18
          +780,9 @@
  表4.13 与看板相关的实践
--(% style="width:804px" %)
--|**ITIL管理实践**|(% style="width:524px" %)**与看板相关的活动/资源**|(% style="width:70px" %)**影响**
--|变更控制|(% style="width:524px" %)通过限制进行中的工作，可视化并改进对服务和服务组件的变更流程。|(% style="width:70px" %)H
--|持续改进|(% style="width:524px" %)可视化并改进SVS中的改进流程。|(% style="width:70px" %)H
--|项目管理|(% style="width:524px" %)可视化并改进跨项目和团队的工作流程。|(% style="width:70px" %)H
--|发布管理|(% style="width:524px" %)可视化并提高发布给消费者的质量。|(% style="width:70px" %)H
--|软件开发管理|(% style="width:524px" %)可视化和改进新的或变更的软件组件进入实时环境的流程。|(% style="width:70px" %)H
--|事件管理|(% style="width:524px" %)通过限制进行中的工作来可视化并提高事件解决的速度和质量。|(% style="width:70px" %)M
--|组合管理|(% style="width:524px" %)可视化并改进整个投资组合管道中的投资流程。|(% style="width:70px" %)M
--|问题管理|(% style="width:524px" %)通过限制进行中的工作来可视化并改进问题和错误控制。|(% style="width:70px" %)M
--|供应商管理|(% style="width:524px" %)可视化供应商的入职/离职进度。|(% style="width:70px" %)M
++[[image:1641701559766-478.png]]
++
  == 4.3 弹性运营的技术 ==
  弹性运营目标涉及确保在需要时可以使用数字化产品。
@@ -823,6
          +823,7 @@
  * 聊天运营
  * 站点可靠性工程。
++
  **ITIL故事：弹性运营的技术**
  //亨利：我们的应用程序必须可靠且一致，否则我们的客户将其视为有缺陷的。如果他们的工作方式需要变更，我们还需要确保我们的团队有应变能力并且可以适应不同的条件。//
@@ -846,39
          +846,27 @@
  图4.17显示了技术债对服务价值链的贡献。
--表4.14概述了与技术债相关的实践。
++(% style="text-align:center" %)
++[[image:1639568670048-316.png]]
--**ITIL故事：技术债**
++图4.17 技术债对服务价值链贡献的热图
--//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
--//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
++表4.14概述了与技术债相关的实践。
++[[image:1641701689758-164.png]]
--(% style="text-align:center" %)
--[[image:1639568670048-316.png]]
++表4.14 与技术债相关的实践
--图4.17 技术债对服务价值链贡献的热图
++**ITIL故事：技术债**
--表4.14 与技术债相关的实践
++//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
--(% style="width:702px" %)
--|**ITIL管理实践**|(% style="width:545px" %)**与技术债相关的活动/资源**|(% style="width:70px" %)**影响**
--|事件管理|(% style="width:545px" %)解决事件和管理事件需要了解现有的技术债及其解决方案。|(% style="width:70px" %)H
--|基础架构管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
--|知识管理|(% style="width:545px" %)确保所有相关的利益干系人都可以访问最新信息。|(% style="width:70px" %)H
--|组合管理|(% style="width:545px" %)决定是否投资资源来解决实时产品和服务中存在的技术债，并了解对投资对未来产品和服务的影响。评估技术债，以便可以将新的投资组合项目引入现有资产池。评估当前投资组合项目的技术债，以防止价值流失。|(% style="width:70px" %)H
--|问题管理|(% style="width:545px" %)应用问题控制和错误控制方法来管理技术债。|(% style="width:70px" %)H
--|软件开发管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
--|业务分析|(% style="width:545px" %)了解技术债对需求和解决方案表达的影响。|(% style="width:70px" %)M
--|持续改进|(% style="width:545px" %)确定优先顺序和管理减少技术债的工作。|(% style="width:70px" %)M
--|信息安全管理|(% style="width:545px" %)信息安全控制的设计，实施和改进受现有技术债的影响。信息安全控制还可能导致技术债的产生，这需要得到承认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
--|项目管理|(% style="width:545px" %)计划和执行项目受现有技术债的影响。 项目还可能导致技术债的产生，需要承认这一债务并将其传达给所有相关的利益干系人。|(% style="width:70px" %)M
--|风险管理|(% style="width:545px" %)认识到技术债对新的或现有的企业风险的影响；减轻风险可能会产生技术债，需要予以确认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
--|服务台|(% style="width:545px" %)与需要事件和请求协助的外部用户进行交流，需要了解现有的技术债以及为解决该问题而计划的工作。|(% style="width:70px" %)M
++//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
++
  === 4.3.2 混沌工程 ===
  **定义：混沌工程**

粤ICP备17056641号

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