4. 高速IT技术

本章介绍了表征HVIT环境特征的一些技术选择。有些通常只在这些环境中发现，而另一些是对HVIT工作至关重要的更通用的技术。选择并不详尽；这些技术是帮助高度数字化的组织实现其苛刻目标的工作方式的示例。

本章中的技术根据与五个HVIT目标之一的关系进行分组和描述：

• 有价值的投资
• 快速研发
• 弹性运营
• 共同创造价值
• 保证合规

尽管此处列出的技术是根据这些目标分组的，但一种技术通常会支持多个目标。每种技术都可以在多种ITIL管理实践的背景下使用，并且在以下各节的结尾是一张表格，列出了所讨论的技术与哪些实践有关，并概述了该技术如何促进每种实践。每种技术都有一个热点图，可以大致表明每种ITIL服务价值链活动受该技术影响的程度。

ITIL故事：高速IT技术

Su：我们的预订应用程序的更新已成功部署，该更新将改进其在智能手机和设备上的性能。我们计划进一步开发该应用程序，并增加其他功能，例如会员计划、会员链接、优先预订和车辆升级。我们利用并将继续利用许多技术来帮助我们优化工作和聚焦价值。

4.1 有价值的投资技巧

有价值的投资目标包括识别和证明对业务战略有重大贡献的数字投资。此练习应使您对数字投资的潜在价值、预期成本、投资回报以及其功用的定义标准有很好的了解。尽管不会增加功能的潜在价值，但也应确定功效或非功能性要求。功效确保投资的潜在价值不受中断，使用不当或其他因素的不利影响。

有价值的投资是根据市场研究和新产品开发建立的。应当设想新的数字化产品和服务，并根据盈利能力进行评估。产品和服务的实质质量及其发布时间都是获得和保持竞争优势的关键因素。越早设想和评估潜在的投资，就越早实现诸如竞争优势之类的收益。在制定投资决策时，应使用道德原则制定考虑广泛利益干系人的利益。

在证明投资的合理性和批准性之后继续评估投资也很重要，因为可能存在更有价值的投资选择。有关替代投资的信息越早可用，就越可以重新评估当前的投资。

在商业组织中进行有价值的投资通常意味着通过增加销售和提高价格，减少资本和运营支出或降低风险来获得更多收入。在非营利组织中，有价值的投资并不专注于收入，而是与其特定于组织的主要目标有关。有价值的投资可以通过销售收入和成本来衡量，也可以通过在投资实现过程中开发的能力来衡量。投资的价值只有在实现回报后才能确定。当供应商、消费者和其他利益干系人共同创造价值时，就会发生这种情况。

在数字化组织中，IT驱动并推动了业务发展。因此，至关重要的是不断评估IT不断发展的潜力以及获得战略优势。这方面主要关注点应该是投资计划的内在质量以及可以对其进行识别、评估、设计、开发和部署投资计划的速度。在确定潜在投资之前，总会有一段时间不了解，这可能与机会或需求有关。越早确定技术发展并评估其业务潜力，就可以越早做出投资决定。

可用于实现有价值的投资的技术包括：

• 优先级技术
• 最小可用的产品和服务
• 产品或服务所有权
• A / B测试

ITIL故事：有价值的投资技术

Marco：我们的业务策略是通过对技术的明智投资来实现的。因为我们使用敏捷的工作技术，所以我们可以保证我们的功效：我们的代码将始终有效。我们会监控投资情况，以确保我们明智地花钱，并确保应用程序的功能符合客户的需求。

4.1.1 优先级排序技术

只要工作的需求超出了在预期时间内完成工作的能力，就会发生队列。在理想情况下，组织将没有需求的变化，并且将拥有满足需求所需的适当质量和数量的资源。但是，组织经常需要应对具有固定容量但对服务需求不断变化的问题。这种不平衡会导致需要对工作项进行优先级排序的队列或积压。

优先级排序是一项通常与支持和软件开发的工作相关活动（例如，对事件调查优先级或对紧急待办项进行优先级排序），但是它是通用的。

4.1.1.1 延迟成本

进行优先级排序的一种可用技术是估算新服务或改进服务的延迟成本。这指的是如果服务活动或任务被延迟会损失的财务和非财务利益。对延迟成本的理解使从业人员能够根据价值数据而不是凭直觉确定工作的优先级。这适用于在不断变化的环境中对正在进行的工作进行初始优先级划分、持续评估和重新排序。几乎总是，数字化产品和服务的业务重要性证明了估算延迟成本所付出的努力是合理的。

延迟成本可以应用于各种级别的决策，例如，产品或服务组合中产品或服务级别的大型投资，产品或服务中功能级别的较小投资或运营任务中。

该技术在HVIT环境中特别有用，因为投资通常更为重要，并且市场条件会迅速变化，这意味着持续评估替代投资的选择很重要。

4.1.1.2 买/持有/卖

可以使用购买/持有/出售技术来管理产品组合（或其他资产）。这涉及评估每种产品并确定三种投资策略中最适合的一种：

• 买 投资以改进或扩展生产。
• 持有 只要费用可以承受，就尽可能少地花钱来维护产品。
• 卖 投资以淘汰，减少或更换产品。

该技术阐明了开发、维护或淘汰产品的成本与收益之间的差异，以及相关的风险和权衡。它可以帮助决策者明确他们的选择并接受决策的后果。

4.1.1.3 其他技巧

产品/服务所有者还可以考虑其他许多产品优先级排序技术，包括堆叠排名，Kano，净现值（NPV），投资回报率（ROI）以及适合性/可行性/吸引力。

图4.1显示了优先级对服务价值链的贡献。表4.1概述了与优先级相关的实践。

图4.1 优先化对服务价值链贡献的热图

表4.1 与优先级相关的实践

ITIL故事：优先排序技术

Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。

Radhika：正当我们进行市场推广时，我们意识到我们应用程序中的已知错误正在引起不良的宣传。因此，延迟修复的成本大于添加新功能的价值。

Su：我们使用购买/持有/出售技术来计划产品套件中的投资：

• 购买我们投资了该应用程序，以改进体验并扩展其功能。
• 保留必须保留在我们网站上预订的选项，因为客户仍在使用它。但是，我们选择最小化对它的投资。
• 出售少数客户仍希望通过传真进行预订。我们停用了此功能，与客户一起将其转换为更现代的通信模式。

我们努力保证令人满意的投资回报。

4.1.2 最小可用的产品服务

最小可用产品或服务具有足够的功能，以便能够对其进行早期的评估并收集反馈意见，以供将来开发。“ 最小可用”方法是开发产品和服务的有效方法，尤其是当市场动荡并且难以预测的情况下。这与复杂性思维一致，后者认识到某些事情是不可知的，因此不可能设计出具有完整、预先确定需求的产品或服务。当需求未知、不明确或模棱两可时，实验可以确定哪些有效，哪些无效。因此，最小可用方法可以实现有价值的投资，并通过迭代的工作方式促进快速发展。

在动荡市场上，很难判断哪种产品或服务产品将是成功的。这种不确定性可以通过最小可用方法解决。产品或服务提供者不应投入大量资源和时间来开发全面的产品或服务，而应该限制他们的工作。他们应该针对刚开发出足以刺激反馈和其他数据的产品或服务，然后可以指出是否以及如何继续进行开发。一旦收集了足够的数据，就可以做出决定，这增加了成功的机会。此外，如果决定停止开发，则产品或服务提供者可以将其资源分配给另一项投资，从而最大程度地减少了最初想法的浪费。

最小可用产品或服务通常具有三个关键特征：

• 它具有足够的价值，人们愿意使用或购买它。
• 它证明了留住那些早期采用者的潜在好处。
• 它提供了一个反馈循环以指导未来的发展。
• 图4.2显示了最小可用方法对服务价值链的贡献的热图。表4.2概述了与最小可用方法相关的实践。

图4.2 热图贡献最小可用的服务价值方法

表4.2 与最小可用方法相关的实践

ITIL的故事：最小可用产品和服务

Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。

Solmaz：我们知道我们不了解未来的客户会想要什么。通过迭代，我们可以在每个阶段对产品进行测试，如果出错，可以在不牺牲大量投资的情况下返回以前的成功版本。

4.1.3 产品或服务所有权

Scrum建议三个角色：产品负责人，开发团队和Scrum主管。产品负责人负责使开发团队生产的产品价值最大化。产品所有权需要建立需求并确定其优先级，并将其传达给开发团队。在这些软件开发团队的背景下，是产品负责人与包括消费者在内的各种利益干系人进行联络和协商。HVIT环境通常是面向产品的，因此产品负责人的概念与HVIT高度相关。产品负责人的概念也适用于服务和服务所有者。

产品负责人角色依赖于：

• 技能和经验 产品负责人需要具备利益干系人管理、需求分析、市场研究、客户细分等方面的技能。具有业务分析或产品管理背景的产品负责人通常具有这些技能，并且他们可能只需要短期学习就能熟悉敏捷的工作方式。但是，成为产品负责人的技术人员可能需要更多培训。
• 权限 产品负责人至少必须能够识别和传达短期优先事项，而无需长时间或不必要的辩论。组织应信任产品负责人使用其权限。
• 合法性 产品负责人还具有需求的合法性。直接的客户联系人和第一手体验将增强这种合法性，并为他们提供有效地确定优先级所需的知识。
• 时间 产品负责人需要时间来履行职责，包括思考故事、筛选和编辑待办项、拜访利益干系人、分析反馈、与团队合作、评估交付后收益的实现以及反思进度和当前状态他们的项目。

产品或服务的所有权是所有价值链活动的关键部分，并助于有价值的投资。图4.3显示了产品或服务所有权对服务价值链的贡献。

表4.3概述了与产品或服务所有权相关的实践。

图4.3 产品或服务所有权对服务价值链贡献的热图

表4.3 与产品或服务所有权相关的实践

ITIL故事：产品或服务所有权

Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。

我具有在敏捷开发和业务分析培训方面的经验的技术背景，包括与客户合作所花费的时间。我了解我可以授权的变更级别以及何时需要升级问题。Axle确保我有时间履行自己的职责，并了解我的要求以及产品如何专注于价值。

4.1.4 A / B测试

很难预测某个功能是否对用户有价值。这个问题通过测量用户行为来收集可靠的数据来解决。但是，当影响因素太多时，几乎不可能将新功能的效果分离出来。因此，需要一个对照组。

A / B测试是一项限时实验，其中一组用户（即对照组）提供了旧版本的产品或服务。同时，为另一组用户（实验组）提供了包括新功能的产品或服务的新版本。假设影响两组的所有其他因素均相等，则可以比较两组的测量值，从而收集数据以基于价值的决策。此方法如图4.4所示。

A / B测试有助于项目组合管理实践。投资组合管理的本质是在资金和资源的限制下进行正确的投资。项目组合管理适用于各种级别，包括产品或服务中功能的“组合”。A / B测试有助于确定功能的哪个版本最有价值。因此，它有助于有价值的投资。

图4.4 有时间限制的A/B测试实验

例

组织的市场营销部门希望通过添加生产的简短视频来变更组织网站上的产品描述。该部门确信，这款新功能将大大提高转换率，目前转换率为2.5％（也就是说，有2.5％的访客将产品添加到他们的购物车中）。如果该功能是在未进行A / B测试的情况下实现的，并且转换率有所提高，则无法说出这种增加是否是由于这一特定的变更引起的。此指标可能同时受到多种因素的影响，例如针对该产品的新广告系列。市场营销部门决定进行A / B 测试。将为一个实验组用户显示一个带有视频的产品页面，向一个对照组用户显示一个不带视频的产品页面的先前版本。通过比较治疗组和对照组的转化率，更容易判断变化的效果。

由于HVIT环境通常面向产品，并且在无法预测的市场中承受时间压力，因此A / B测试与HVIT特别相关。

图4.5显示了A/B测试对服务价值链的贡献。表4.4概述了与A / B测试相关的实践。

图4.5 A/B测试对服务价值链贡献的热图

表4.4 与A/B测试相关的实践

ITIL的故事：A / B测试

Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。

Marco：为了评估此新功能对我们客户的价值，我们进行了A / B 测试：50％的客户可以升级，而50％的客户没有。结果是结论性的：有机会时，有70％的客户升级了车辆。在免费升级一次的汽车中，有20％选择在下次预订时租用更高规格的汽车。

Su：基于这些结果，我们可以放心发布此新功能。

4.2 快速研发技术

快速发展的目标涉及频繁、快速且可靠地实现新的和改进的数字化产品和服务。“ 开发”通常是指产品开发，尽管应用程序开发通常包含在其中。

通常，越早交付数字化产品，越早实现价值。但是，有时情况并非如此，应相应地修改时间表；例如，提早交付可能与市场需求不符。将单个产品分成一系列增量交付可加快整体交付速度，并使用户比等待整个产品更早地实现价值。

除了快速和频繁之外，交付还必须可靠。但是，有时最好在有容量时快速交付产品或服务，或快速恢复服务，而不是等待提供更可靠的产品或服务。在这些情况下，平均服务恢复时间（MTRS）通常比平均失效间隔时间（MTBF）更好。

快速研发没有内在价值；它的价值与正在开发的价值有关。在商业组织中，它可以通过缩短产品上市时间和客户时间来实现更快的投资回报。通常，这是用更多的销售收入来表示的，因为收入流开始得较早。它也可以用网站访问量或注册邮件的潜在客户数量来表示。

快速研发可以根据每单位时间应用程序（变更）的大小来衡量。应用程序的大小可以用技术单位（例如代码行）或功能型单位（例如故事点或功能点）表示。比较生产效率时应谨慎，因为它取决于许多因素：例如，非功能型的需求未反映在故事点中。当为应用程序和团队的特定组合指定条件时，比较生产效率更有意义。

组织通常将重点放在应用程序的快速研发上，因为这就是功能和价值所在。但是，同样重要的是相关组件也要快速研发或交付。这些请求包括服务请求，例如提供设备、提供访问权限、设置新邮箱或商业智能（BI）报告。

跟踪预期开发时间的可预测性也很有用；例如，通过记录何时报告偏离计划的情况。管理人员应鼓励人们尽快报告潜在的延迟。这是期望的行为。

为了迅速实现业务价值，在业务压力下敏捷开发团队尽可能频繁地交付可能可部署的软件增量。不幸的是，对于实际的部署，这些发行版通常必须等待数天，数周甚至是数月，这通常是价值流中最长的延迟。这通常是由于对批准和部署采取了广泛谨慎的方法。通常，批准流程是变更顾问委员进行的评估，仅在计划的日期开会。实际的部署也经常按照时间表进行。因此，快速研发和弹性运营之间可能存在冲突。

这种方法背后的想法是变更具有潜在的破坏性，因此应谨慎控制。由于快速变化和谨慎变化是截然相反的目标，因此开发团队和IT运维通常无法有效地协作，因此IT和服务管理的从业人员必须缩小差距。

这种张力基于熟悉的心理模型，其中变更破坏了稳定性，而稳定性控制变更发生的变化：变化越少，稳定性的风险就越低。最近，出现了另一种思维方式。变更大小的减少会减少中断的风险。较小的变更还意味着变更可以更频繁地发生。通过更频繁地进行变更，可以提高组织的变更能力。变更能力的提高反过来又降低了中断的风险。图4.6演示了变更大小的影响。

DevOps社区已经接受了这种思维方式，并且已经开发了适当的实践和支持技术。研究发现，在部署频率、变更准备时间和变更失效率方面的高性能与版本控制、持续交付和自动化测试相关。研究还表明，在团队中基于同行评审的变更批准的风险不比使用变更顾问委员会的风险低。

图4.6 影响大小的变更可用于实现快速研发的技术包括：

• 基础架构即代码
• 松耦合信息系统架构
• 评论
• 持续业务分析
• 持续集成/持续交付
• 连续测试
• 看板

ITIL故事：快速研发的技术

Solmaz：我们不断开发新的应用功能，并定期且频繁地发布改进和变更。这有助于我们更早地实现价值并尽快收到反馈。它还使我们能够优先考虑开发的新功能和支持工作。因为变更很小，所以它们需要较少的支持，并且服务中断的风险也较少。

4.2.1 基础架构即代码

基础架构即代码（IaC）支持更快的环境配置，从而有助于更快的开发和更有弹性的运营。虚拟化和虚拟机管理程序技术（通常通过云提供）允许通过编程接口远程创建、修改和删除基础架构项目。如今，使用脚本和配置文件来构建和配置服务器是一种常见的做法。

IaC是一种通过使用机器可读的定义文件而不是物理配置硬件组件来管理和配置IT基础架构和平台的方法。然后可以将这些文件存储在版本控制系统中（请参阅第4.3.4节中的版本控制）。

幂等性的概念是IaC的关键。这意味着部署命令始终将目标环境配置为指定的状态，而不管它以前是什么状态。这可以通过重新配置目标环境或用新的环境来实现。为此，需要对环境描述进行变更，并创建新版本的配置模型。该代码经过验证和测试，以防止常见的部署问题。发布流水线执行配置模型，从而产生新的（重新）配置的目标环境。如果需要变更，则编辑源，而不编辑目标。Vagrant、Ansible、Puppet和Docker等工具支持整个流程。基础架构即服务（IaaS）和平台即服务（PaaS）等基于云的解决方案使用IaC定义来动态配置和删除环境。然后，团队可以根据需求可靠地配置多个测试环境。这使他们能够在开发周期的早期阶段在类似生产环境中测试应用程序。

选择使用IaC而不是传统的物理配置是一项架构设计决策，影响深远。架构的本质是选择要使用的构件或资源，以及如何使用它们。基础架构和平台的数字化可以更快，更可靠地配置所有必要的环境，例如开发、测试和生产，从而有助于快速研发和部署。这对于实现弹性运营也同样重要，因为它可以从某些事件中更快地恢复，并通过减少人为的错误来防止其他事件，例如手动错误配置和配置漂移。IaC效率更高，因为它具有较少的可重复手动操作，从而通过降低基础架构成本来促进宝贵的投资。

图4.7显示了IaC对服务价值链的贡献。

图4.7 基础设施作为代码对服务价值链的贡献的热图

‘

表4.5 与基础设施作为代码相关的实践

表4.5 列出了与基础设施作为代码相关的实践。

ITIL故事：基础架构即代码

Marco：在测试环境下，我们在虚拟机上使用虚拟机监控程序技术创建了多个测试环境。我们想在多个平台上模拟该应用程序的使用。因为我们在开发周期的每个阶段都对代码进行了验证，所以我们知道该应用程序将随着它的增长而继续在不同的设备上运行。

4.2.2 松耦合信息系统架构

松耦合信息系统架构基于相对较小的独立组件。该架构使工作能够在相对较小的，相对独立的，基于产品或服务的团队和基于平台的团队中完成。通过将系统分解为可以相对独立地开发和管理的部分，团队可以专注于自己的部分并限制与其他团队的互动。基于产品或服务的团队由开发人员和工程师以及代表消费者观点的产品/服务所有者组成。更紧密的协作对快速研发和价值共创都是有益的。它还有助于进行有价值的投资、快速研发和弹性运营（其中IT运维也在团队中出现）。

紧密耦合的体系结构（例如在单片信息系统中）的最大问题之一是变更的速度极低，因为许多变更都需要重新设计和重新开发系统的多个部分。实际上，在同一系统上增加更多的团队和员工可能会降低速度，因为这可能导致体系结构级别的组件之间的深度互连过多。

一个密切相关的技术是应用程序绞杀。这可用于逐渐围绕旧应用创建新应用，然后用新代码慢慢替换旧代码。当无法重构应用程序（在不变更其功能的情况下重构代码）并且必须替换它时，这很有用。此技术可能会损害性能和可靠性，因此，如果使用此技术，则需要仔细的监督实施。

微服务和容器化等技术通常与松耦合的体系结构相关。

定义

• 微服务 面向服务的体系架构的一种变体，其中应用程序被设计和开发为一组小型的、松散耦合的服务，每个服务都在自己的流程中运行并使用轻量级机制进行通信。
• 容器化 将软件打包为标准化的轻型，独立，可执行单元以进行开发，运输和部署的技术。

松散耦合的信息系统体系架构的优点包括：

• 它有助于更快的开发和更频繁的变更。
• 它支持演进架构。
• 它效率更高，导致重新设计和开发产品或服务所需的工作更少。
• 它使从专注于组件的团队结构切换为基于产品或功能的团队结构。图4.8显示了松散耦合信息系统架构对服务价值链的贡献。表4.6概述了与松散耦合信息系统架构相关的实践。

ITIL故事：松耦合信息系统架构

Su：我们在应用程序中使用了松耦合信息系统架构。通过将系统视为相对较小且独立的组件，每个组件上的团队可以独立工作，因为他们了解组件会接收的输入以及工作流中后续组件所需的输出。这减少了不同组件之间的重复、复杂性和相互依赖性该应用程序。

图4.8 松散耦合信息系统架构对服务价值链贡献的热图

表4.6 与松散耦合信息系统架构相关的实践

4.2.3 复查

通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。

4.2.3.1 回顾

在敏捷中，回顾是在迭代（或称为“ 冲刺”）或项目结束时召开的团队会议，以讨论哪些进展顺利，哪些可以改进的方面以及将来如何从中受益。这种快速而频繁的反馈有助于快速研发。回顾可以应用于大多数场景以及需要不断改进的任何区域。为有效起见，应定期安排他们的时间，并由主持人安排参与者的贡献。应确定为持续改进而输入的行动，并委派责任。图4.9显示了回顾对服务价值链的贡献。

图4.9 回顾对服务价值链贡献的热图

表4.7 与回顾相关的实践

表4.7概述了与回顾相关的实践。

4.2.3.2 免责的事后反思

数字化技术具有越来越重要的社会和经济后果，尤其是在HVIT环境中。因此，预防事故变得越来越重要。但是，复杂的系统具有固有的危险性：尽管付出了所有努力，但它们仍将失败。因此，从失效中学习也变得越来越重要。

事后检验是事件的正式记录，包括对事件的影响，解决/缓解工作，原因和防止再次发生的措施。当参与者能够分享自己的知识和选择而不必担心声誉和位置时，事后反思的质量会更好。这就是为什么重点关注事件的原因而不是谁引起了事件。这种免责的文化起源于医疗保健和航空业，那里生命受到威胁。免责事后反思与安全性文化和心理安全性密切相关（见第3.2.2.2节）。

定义：事后反思

对事件之前的情况和事件的非判断性描述和分析。

事后反思不仅对事件涉及的人员有用，还应与可能从结果中受益的其他人共享和阅读。与透明度和脆弱性建立信任并帮助价值共创，与包括消费者在内的广大社区分享研究结果也很重要。

与事后反思相关的良好行为包括：

• 作为'日常业务'的一部分进行事后反思的操作，并非例外
• 关注于引起事件的原因，而不是谁
• 广泛透明地共享结果，以学习和建立信任。

图4.10显示了免责事后反思对服务价值链的贡献。表4.8概述了与免责的事后反思相关的实践。

图4.10 免责的事后反思对服务价值链的贡献的热图

ITIL的故事：评论

Marco：使用该应用程序可能会很艰苦，但是回顾会给我们带来好处。我们会定期分析完成的工作，以便了解可以在下一个冲刺中汲取的经验教训。这些是不责怪的事后反思：我们公开且诚实地讨论我们的工作，而不必担心事件的起因会分配给任何团队成员。

表4.8 免责的时候反思的实践

4.2.4 持续业务分析

瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。

做出投资决定后，至关重要的是要验证对产品或服务规范、特性和功能所做的任何初始假设。一些供应商忽略了与真实用户尽快进行交互的需要，而是在向客户和用户展示其解决方案之前在开发上花费了几个月甚至几年的时间。通常，采用这种方法时，产品或服务的某些功能是不必要的，某些功能需要进行重大调整，而其他有价值的功能却会丢失。但是，组织的资源和时间已经用完，营销机会正在减少。

一种更好的开发方法是尽早实现反馈循环。正确的反馈循环可以提供有关产品或服务开发方向的有价值的信息。为了使反馈循环有用，迭代开发非常重要。为此可以使用最小可用方法（请参阅第4.1.2节）。图4.11说明了这一概念。

图4.11通过迭代方法更快地实现价值

过去，需求总是在项目开始时在利益干系人和被分配了临时的、基于项目的任务的业务分析人员之间的正式讨论中定义的。这些要求将成为发展活动的规范。

但是，越来越多地基于反馈来开发和改进产品。反馈可以由用户报告或间接观察。需求分析和说明是持续进行的。业务分析通常不再由专门的业务分析人员执行；它是可以与其他角色组合使用的角色。使用这种方法时，由于已经建立了产品架构，因此进一步的开发可能具有挑战性。因此，开发之前的分析应考虑这些未来的问题，并创建一个灵活的架构。开发之后的分析与开发之前的分析不同之处在于，开发后的分析较少关注于创建架构，而更关注于在系统的体系结构约束下有效地工作。

图4.12显示了持续业务分析对服务价值链的贡献。表4.9概述了与持续业务分析相关的实践。

ITIL故事：持续业务分析

Radhika：ITIL 指导原则对业务中的每个团队都有用。例如，聚焦价值原则可恰好适合业务分析。环境不断变化，开发中的功能优先级可能会变得更高或更低，这取决于价值如何受到影响。例如，影响应用程序使用或数据存储的新法规将自动成为高度优先事项。

图4.12 持续业务分析对服务价值链贡献的热图

表4.9 与持续业务分析相关的实践

4.2.5 持续集成、持续交付和持续部署

持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。

定义

• 持续集成 一种在软件开发环境中集成、构建和测试代码的方法。
• 持续交付 一种软件开发的方法，其中可以随时将软件发布到生产环境中。可以进行频繁部署，但是部署的决定要视具体情况而定，通常是因为组织更喜欢较慢的部署速度。
• 持续部署 一种软件开发的方法，其中的变更会通过流水线进行，并自动放入生产环境中，从而每天可以进行多个生产部署。持续部署依赖持续交付。

CI / CD有助于快速研发，并且由于部署更可靠，因此有助于弹性运营。

持续集成是每次提交代码时在构建和代码测试过程中实现的自动化，从而导致对版本控制进行变更。持续集成通过将变更合并到集中共享的代码存储库中，在软件开发社区中促进了代码共享的实践。代码提交触发自动构建功能，以从共享的版本控制存储库和构建，测试中提取最新的代码提交，并验证完整的主分支（即主干）。

由于软件开发具有隔离性，因此持续集成已成为一种惯性时间内，因此开发人员需要在变更与开发团队其余代码之间保持恒定的集成点。漫长的等待周期会导致合并冲突，解决路径困难的错误，不同的代码策略以及重复的工作。持续集成的主要目的之一是使主分支免受异常和错误的影响。软件开发团队可以建立分支机构策略，以确保主分支符合某些预先约定和预先授权的质量标准。

持续交付的重点在是构建和测试新版本并将其发布到生产环境的过程。这需要阶段发布环境，阶段发布环境已成为发布流水线的一部分，以自动化基础设施配置和新版本的部署。

持续交付是一种精益实践。其目标是保持无事故的生产环境正常运行。这是通过发现从版本控制存储库中的新代码的可用性到包装管理（用于部署）的最短路径来实现的。

持续交付依赖于部署模型的渐进部署环的概念。第一个部署环通常是组织的内部IT团队或其他相关的内部用户组访问的生产环境中的“ 金丝雀发布”。连续的部署循环欢迎更多的用户。这些后续的部署循环可能需要关键决策者的批准。如果组织使用这些循环进行部署，则通常采用相同的方法进行发布管理。

另一个部署模型使用“ 蓝绿部署”的概念，即现有版本在一个生产环境（称为“蓝色”）中运行，而新的版本部署到相同的“绿色” 环境。通常，负载平衡用于将有限数量的用户重定向到“绿色” 版本。如果出现事件，则可以将流量重新路由到“蓝色” 版本。否则，“绿色” 环境成为默认的，而“蓝色” 环境用于下一个部署。

图4.13显示了CI / CD对服务价值链的贡献。表4.10概述了CI / CD最相关的实践。

图4.13 CI/CD对服务价值链贡献的热图

表4.10 与CI/CD最相关的实践

ITIL故事：持续集成、持续交付和持续部署

Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。

4.2.6 持续测试

软件测试不仅涉及测试已开发的和可运行的软件。测试是应该在整个软件开发生命周期中进行的工作。表4.11概述了不同类型的测试。

表4.11 软件测试的类型

为了实现持续测试，应制定一些原则，包括：

• 测试应该以最低级别进行。
• 外部依存关系最少的测试应该受到青睐。
• 编写一次即可在任何地方运行，包括在生产系统中。
• 产品的设计应具有可测试性。
• 测试代码是产品代码;只有可靠的测试才能生存。
• 测试基础架构是共享的服务。
• 测试的所有权跟随产品所有权。
• 在生产中应进行故障注入和混沌工程测试服务弹性
• 不可靠的测试应消除。

图4.14显示了持续测试对服务价值链的贡献。表4.12概述了与持续测试最相关的实践。