文档更改4.高速IT技术

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

从版本< 72.1

由superadmin编辑
在2024/04/03, 17:15上

到版本

由superadmin编辑
在2024/03/07, 19:39上

修改评论 Update document after refactoring.

Raw
已渲染

Summary

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

Details

Page properties

Content

@@ -3,15
          +3,12 @@
    [[返回上一章>>http://itil4hub.cn/bin/view/ITIL%204%E3%80%8A%E9%AB%98%E9%80%9FIT%E3%80%8BHVIT/3.%E9%AB%98%E9%80%9FIT%E6%96%87%E5%8C%96/]]
--{{box cssClass="floatinginfobox" title="
--
--**X Contents**"}}
++{{box cssClass="floatinginfobox" title="**X Contents**"}}
  {{toc/}}
  {{/box}}
--= **4. 高速IT技术** =
++= 4. 高速IT技术 =
--
  本章介绍了表征HVIT环境特征的一些技术选择。有些通常只在这些环境中发现，而另一些是对HVIT工作至关重要的更通用的技术。选择并不详尽；这些技术是帮助高度数字化的组织实现其苛刻目标的工作方式的示例。
  本章中的技术根据与五个HVIT目标之一的关系进行分组和描述：
@@ -27,13
          +27,11 @@
  **ITIL故事：高速IT技术**
--Su：我们的预订应用程序的更新已成功部署，该更新将改进其在智能手机和设备上的性能。我们计划进一步开发该应用程序，并增加其他功能，例如会员计划、会员链接、优先预订和车辆升级。我们利用并将继续利用许多技术来帮助我们优化工作和聚焦价值。
++//Su：我们的预订应用程序的更新已成功部署，该更新将改进其在智能手机和设备上的性能。我们计划进一步开发该应用程序，并增加其他功能，例如会员计划、会员链接、优先预订和车辆升级。我们利用并将继续利用许多技术来帮助我们优化工作和聚焦价值。//
--
  == 4.1 有价值的投资技巧 ==
--
  有价值的投资目标包括识别和证明对业务战略有重大贡献的数字投资。此练习应使您对数字投资的潜在价值、预期成本、投资回报以及其功用的定义标准有很好的了解。尽管不会增加功能的潜在价值，但也应确定功效或非功能性要求。功效确保投资的潜在价值不受中断，使用不当或其他因素的不利影响。
  有价值的投资是根据市场研究和新产品开发建立的。应当设想新的数字化产品和服务，并根据盈利能力进行评估。产品和服务的实质质量及其发布时间都是获得和保持竞争优势的关键因素。越早设想和评估潜在的投资，就越早实现诸如竞争优势之类的收益。在制定投资决策时，应使用道德原则制定考虑广泛利益干系人的利益。
@@ -56,19
          +56,15 @@
  //Marco：我们的业务策略是通过对技术的明智投资来实现的。因为我们使用敏捷的工作技术，所以我们可以保证我们的功效：我们的代码将始终有效。我们会监控投资情况，以确保我们明智地花钱，并确保应用程序的功能符合客户的需求。//
--
  === 4.1.1 优先级排序技术 ===
--
  只要工作的需求超出了在预期时间内完成工作的能力，就会发生队列。在理想情况下，组织将没有需求的变化，并且将拥有满足需求所需的适当质量和数量的资源。但是，组织经常需要应对具有固定容量但对服务需求不断变化的问题。这种不平衡会导致需要对工作项进行优先级排序的队列或积压。
  优先级排序是一项通常与支持和软件开发的工作相关活动（例如，对事件调查优先级或对紧急待办项进行优先级排序），但是它是通用的。
--
  ==== 4.1.1.1 延迟成本 ====
--
  进行优先级排序的一种可用技术是估算新服务或改进服务的延迟成本。这指的是如果服务活动或任务被延迟会损失的财务和非财务利益。对延迟成本的理解使从业人员能够根据价值数据而不是凭直觉确定工作的优先级。这适用于在不断变化的环境中对正在进行的工作进行初始优先级划分、持续评估和重新排序。几乎总是，数字化产品和服务的业务重要性证明了估算延迟成本所付出的努力是合理的。
  延迟成本可以应用于各种级别的决策，例如，产品或服务组合中产品或服务级别的大型投资，产品或服务中功能级别的较小投资或运营任务中。
@@ -76,10
          +76,8 @@
  该技术在HVIT环境中特别有用，因为投资通常更为重要，并且市场条件会迅速变化，这意味着持续评估替代投资的选择很重要。
--
  ==== 4.1.1.2 买/持有/卖 ====
--
  可以使用购买/持有/出售技术来管理产品组合（或其他资产）。这涉及评估每种产品并确定三种投资策略中最适合的一种：
  * **买 **投资以改进或扩展生产。
@@ -89,10
          +89,8 @@
  该技术阐明了开发、维护或淘汰产品的成本与收益之间的差异，以及相关的风险和权衡。它可以帮助决策者明确他们的选择并接受决策的后果。
--
  ==== 4.1.1.3 其他技巧 ====
--
  产品/服务所有者还可以考虑其他许多产品优先级排序技术，包括堆叠排名，Kano，净现值（NPV），投资回报率（ROI）以及适合性/可行性/吸引力。
  图4.1显示了优先级对服务价值链的贡献。表4.1概述了与优先级相关的实践。
@@ -103,13
          +103,11 @@
  图4.1 优先化对服务价值链贡献的热图
--
  表4.1 与优先级相关的实践
  [[image:1641700591514-812.png]]
--
  **ITIL故事：优先排序技术**
  //Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
@@ -125,10
          +125,8 @@
  //我们努力保证令人满意的投资回报。//
--
  === 4.1.2 最小可用的产品服务 ===
--
  最小可用产品或服务具有足够的功能，以便能够对其进行早期的评估并收集反馈意见，以供将来开发。“ 最小可用”方法是开发产品和服务的有效方法，尤其是当市场动荡并且难以预测的情况下。这与复杂性思维一致，后者认识到某些事情是不可知的，因此不可能设计出具有完整、预先确定需求的产品或服务。当需求未知、不明确或模棱两可时，实验可以确定哪些有效，哪些无效。因此，最小可用方法可以实现有价值的投资，并通过迭代的工作方式促进快速发展。
  在动荡市场上，很难判断哪种产品或服务产品将是成功的。这种不确定性可以通过最小可用方法解决。产品或服务提供者不应投入大量资源和时间来开发全面的产品或服务，而应该限制他们的工作。他们应该针对刚开发出足以刺激反馈和其他数据的产品或服务，然后可以指出是否以及如何继续进行开发。一旦收集了足够的数据，就可以做出决定，这增加了成功的机会。此外，如果决定停止开发，则产品或服务提供者可以将其资源分配给另一项投资，从而最大程度地减少了最初想法的浪费。
@@ -147,7
          +147,6 @@
  图4.2 热图贡献最小可用的服务价值方法
--
  表4.2 与最小可用方法相关的实践
  [[image:1641700659017-287.png]]
@@ -155,7
          +155,6 @@
  [[image:1641700701040-265.png]]
--
  **ITIL的故事：最小可用产品和服务**
  //Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
@@ -163,10
          +163,8 @@
  //Solmaz：我们知道我们不了解未来的客户会想要什么。通过迭代，我们可以在每个阶段对产品进行测试，如果出错，可以在不牺牲大量投资的情况下返回以前的成功版本。//
--
  === 4.1.3 产品或服务所有权 ===
--
  Scrum建议三个角色：产品负责人，开发团队和Scrum主管。产品负责人负责使开发团队生产的产品价值最大化。产品所有权需要建立需求并确定其优先级，并将其传达给开发团队。在这些软件开发团队的背景下，是产品负责人与包括消费者在内的各种利益干系人进行联络和协商。HVIT环境通常是面向产品的，因此产品负责人的概念与HVIT高度相关。产品负责人的概念也适用于服务和服务所有者。
  产品负责人角色依赖于：
@@ -191,7
          +191,6 @@
  [[image:1641700764097-167.png]]
--
  **ITIL故事：产品或服务所有权**
  //Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
@@ -199,10
          +199,8 @@
  //我具有在敏捷开发和业务分析培训方面的经验的技术背景，包括与客户合作所花费的时间。我了解我可以授权的变更级别以及何时需要升级问题。Axle确保我有时间履行自己的职责，并了解我的要求以及产品如何专注于价值。//
--
  === 4.1.4 A / B测试 ===
--
  很难预测某个功能是否对用户有价值。这个问题通过测量用户行为来收集可靠的数据来解决。但是，当影响因素太多时，几乎不可能将新功能的效果分离出来。因此，需要一个对照组。
  A / B测试是一项限时实验，其中一组用户（即对照组）提供了旧版本的产品或服务。同时，为另一组用户（实验组）提供了包括新功能的产品或服务的新版本。假设影响两组的所有其他因素均相等，则可以比较两组的测量值，从而收集数据以基于价值的决策。此方法如图4.4所示。
@@ -230,13
          +230,11 @@
  图4.5 A/B测试对服务价值链贡献的热图
--
  表4.4 与A/B测试相关的实践
  [[image:1641700825218-144.png]]
--
  **ITIL的故事：A / B测试**
  //Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
@@ -246,11
          +246,8 @@
  //Su：基于这些结果，我们可以放心发布此新功能。//
--
--
  == 4.2 快速研发技术 ==
--
  快速发展的目标涉及频繁、快速且可靠地实现新的和改进的数字化产品和服务。“ 开发”通常是指产品开发，尽管应用程序开发通常包含在其中。
  通常，越早交付数字化产品，越早实现价值。但是，有时情况并非如此，应相应地修改时间表；例如，提早交付可能与市场需求不符。将单个产品分成一系列增量交付可加快整体交付速度，并使用户比等待整个产品更早地实现价值。
@@ -287,17
          +287,13 @@
  * 连续测试
  * 看板
--
--
  **ITIL故事：快速研发的技术**
  //Solmaz：我们不断开发新的应用功能，并定期且频繁地发布改进和变更。这有助于我们更早地实现价值并尽快收到反馈。它还使我们能够优先考虑开发的新功能和支持工作。因为变更很小，所以它们需要较少的支持，并且服务中断的风险也较少。//
--
  === 4.2.1 基础架构即代码 ===
--
  基础架构即代码（IaC）支持更快的环境配置，从而有助于更快的开发和更有弹性的运营。虚拟化和虚拟机管理程序技术（通常通过云提供）允许通过编程接口远程创建、修改和删除基础架构项目。如今，使用脚本和配置文件来构建和配置服务器是一种常见的做法。
  IaC是一种通过使用机器可读的定义文件而不是物理配置硬件组件来管理和配置IT基础架构和平台的方法。然后可以将这些文件存储在版本控制系统中（请参阅第4.3.4节中的版本控制）。
@@ -315,7
          +315,6 @@
  图4.7 基础设施作为代码对服务价值链的贡献的热图
--
  表4.5 与基础设施作为代码相关的实践
  [[image:1641700916381-114.png]]
@@ -328,10
          +328,8 @@
  //Marco：在测试环境下，我们在虚拟机上使用虚拟机监控程序技术创建了多个测试环境。我们想在多个平台上模拟该应用程序的使用。因为我们在开发周期的每个阶段都对代码进行了验证，所以我们知道该应用程序将随着它的增长而继续在不同的设备上运行。//
--
  === 4.2.2 松耦合信息系统架构 ===
--
  松耦合信息系统架构基于相对较小的独立组件。该架构使工作能够在相对较小的，相对独立的，基于产品或服务的团队和基于平台的团队中完成。通过将系统分解为可以相对独立地开发和管理的部分，团队可以专注于自己的部分并限制与其他团队的互动。基于产品或服务的团队由开发人员和工程师以及代表消费者观点的产品/服务所有者组成。更紧密的协作对快速研发和价值共创都是有益的。它还有助于进行有价值的投资、快速研发和弹性运营（其中IT运维也在团队中出现）。
  紧密耦合的体系结构（例如在单片信息系统中）的最大问题之一是变更的速度极低，因为许多变更都需要重新设计和重新开发系统的多个部分。实际上，在同一系统上增加更多的团队和员工可能会降低速度，因为这可能导致体系结构级别的组件之间的深度互连过多。
@@ -353,8
          +353,6 @@
  * 它效率更高，导致重新设计和开发产品或服务所需的工作更少。
  * 它使从专注于组件的团队结构切换为基于产品或功能的团队结构。图4.8显示了松散耦合信息系统架构对服务价值链的贡献。表4.6概述了与松散耦合信息系统架构相关的实践。
--
--
  **ITIL故事：松耦合信息系统架构**
  //Su：我们在应用程序中使用了松耦合信息系统架构。通过将系统视为相对较小且独立的组件，每个组件上的团队可以独立工作，因为他们了解组件会接收的输入以及工作流中后续组件所需的输出。这减少了不同组件之间的重复、复杂性和相互依赖性//该应用程序。
@@ -366,7
          +366,6 @@
  图4.8 松散耦合信息系统架构对服务价值链贡献的热图
--
  表4.6 与松散耦合信息系统架构相关的实践
  [[image:1641701019297-720.png]]
@@ -374,23
          +374,13 @@
  [[image:1641701038534-675.png]]
--(% class="wikigeneratedid" %)
--===   ===
--
--(% class="wikigeneratedid" %)
--===   ===
--
  === 4.2.3 复查 ===
--
  通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
--
--
  ==== 4.2.3.1 回顾 ====
--
  在敏捷中，回顾是在迭代（或称为“ 冲刺”）或项目结束时召开的团队会议，以讨论哪些进展顺利，哪些可以改进的方面以及将来如何从中受益。这种快速而频繁的反馈有助于快速研发。回顾可以应用于大多数场景以及需要不断改进的任何区域。为有效起见，应定期安排他们的时间，并由主持人安排参与者的贡献。应确定为持续改进而输入的行动，并委派责任。图4.9显示了回顾对服务价值链的贡献。
@@ -407,15
          +407,8 @@
  表4.7概述了与回顾相关的实践。
--(% class="wikigeneratedid" %)
--====   ====
--
--(% class="wikigeneratedid" %)
--====   ====
--
  ==== 4.2.3.2 免责的事后反思 ====
--
  数字化技术具有越来越重要的社会和经济后果，尤其是在HVIT环境中。因此，预防事故变得越来越重要。但是，复杂的系统具有固有的危险性：尽管付出了所有努力，但它们仍将失败。因此，从失效中学习也变得越来越重要。
  事后检验是事件的正式记录，包括对事件的影响，解决/缓解工作，原因和防止再次发生的措施。当参与者能够分享自己的知识和选择而不必担心声誉和位置时，事后反思的质量会更好。这就是为什么重点关注事件的原因而不是谁引起了事件。这种免责的文化起源于医疗保健和航空业，那里生命受到威胁。免责事后反思与安全性文化和心理安全性密切相关（见第3.2.2.2节）。
@@ -442,7
          +442,6 @@
  图4.10 免责的事后反思对服务价值链的贡献的热图
--
  **ITIL的故事：评论**
  //Marco：使用该应用程序可能会很艰苦，但是回顾会给我们带来好处。我们会定期分析完成的工作，以便了解可以在下一个冲刺中汲取的经验教训。这些是不责怪的事后反思：我们公开且诚实地讨论我们的工作，而不必担心事件的起因会分配给任何团队成员。//
@@ -453,15
          +453,8 @@
  [[image:1641701145033-568.png]]
--(% class="wikigeneratedid" %)
--===   ===
--
--(% class="wikigeneratedid" %)
--===   ===
--
  === 4.2.4 持续业务分析 ===
--
  瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
  做出投资决定后，至关重要的是要验证对产品或服务规范、特性和功能所做的任何初始假设。一些供应商忽略了与真实用户尽快进行交互的需要，而是在向客户和用户展示其解决方案之前在开发上花费了几个月甚至几年的时间。通常，采用这种方法时，产品或服务的某些功能是不必要的，某些功能需要进行重大调整，而其他有价值的功能却会丢失。但是，组织的资源和时间已经用完，营销机会正在减少。
@@ -475,7
          +475,6 @@
  图4.11通过迭代方法更快地实现价值
--
  过去，需求总是在项目开始时在利益干系人和被分配了临时的、基于项目的任务的业务分析人员之间的正式讨论中定义的。这些要求将成为发展活动的规范。
  但是，越来越多地基于反馈来开发和改进产品。反馈可以由用户报告或间接观察。需求分析和说明是持续进行的。业务分析通常不再由专门的业务分析人员执行；它是可以与其他角色组合使用的角色。使用这种方法时，由于已经建立了产品架构，因此进一步的开发可能具有挑战性。因此，开发之前的分析应考虑这些未来的问题，并创建一个灵活的架构。开发之后的分析与开发之前的分析不同之处在于，开发后的分析较少关注于创建架构，而更关注于在系统的体系结构约束下有效地工作。
@@ -483,7
          +483,6 @@
  图4.12显示了持续业务分析对服务价值链的贡献。表4.9概述了与持续业务分析相关的实践。
--
  **ITIL故事：持续业务分析**
  //Radhika：ITIL 指导原则对业务中的每个团队都有用。例如，聚焦价值原则可恰好适合业务分析。环境不断变化，开发中的功能优先级可能会变得更高或更低，这取决于价值如何受到影响。例如，影响应用程序使用或数据存储的新法规将自动成为高度优先事项。//
@@ -495,7
          +495,6 @@
  图4.12 持续业务分析对服务价值链贡献的热图
--
  表4.9 与持续业务分析相关的实践
  [[image:1641701202590-318.png]]
@@ -503,12
          +503,8 @@
  [[image:1641701238590-838.png]]
--(% class="wikigeneratedid" %)
--===   ===
--
  === 4.2.5 持续集成、持续交付和持续部署 ===
--
  持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
@@ -551,10
          +551,8 @@
  //Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。//
--
  === 4.2.6 持续测试 ===
--
  软件测试不仅涉及测试已开发的和可运行的软件。测试是应该在整个软件开发生命周期中进行的工作。表4.11概述了不同类型的测试。
@@ -611,11
          +611,8 @@
  //在每个阶段，如果测试表明我们引入了明显的低效或缺陷，我们就会重新考虑以前的决定。//
--
--
  === 4.2.7 看板 ===
--
  看板是一套原则、实践和常规活动，旨在开发和管理可预测的，有节奏的，持续的工作流程。如果正确应用，它可以极大地加速高质量产品和服务的开发。拉动式触发机制使客户能够通过价值流进行工作。拉动式的工作具有不会被强加于人的优点，从而不必要地增加了工作负担。这在精益团队中很有价值，因为过载是浪费的一种形式。
@@ -653,7
          +653,6 @@
  图4.16显示了看板对服务价值链的贡献。表4.13概述了与看板相关的实践。
--
  **ITIL故事：看板**
  //Radhika：我们使用看板来可视化我们应用程序的工作流程，以便我们可以跟踪瓶颈。通常可以通过额外的资源或重新设计工作流来消除这些问题。看板的视觉特性使核心开发团队之外的同事和利益干系人能够了解工作的进展情况，从而使他们能够更好地计划并创建更多价值。//
@@ -670,15
          +670,8 @@
  [[image:1641701559766-478.png]]
--(% class="wikigeneratedid" %)
--==   ==
--
--(% class="wikigeneratedid" %)
--==   ==
--
  == 4.3 弹性运营的技术 ==
--
  弹性运营目标涉及确保在需要时可以使用数字化产品。
  数字投资的潜在价值仅当投入使用的数字化产品和服务可用时才能实现。满足非功能性要求提供了功效，并降低了问题将严重影响产品和服务的功用的风险。
@@ -708,17
          +708,14 @@
  * 聊天运营
  * 站点可靠性工程。
++
  **ITIL故事：弹性运营的技术**
  //亨利：我们的应用程序必须可靠且一致，否则我们的客户将其视为有缺陷的。如果他们的工作方式需要变更，我们还需要确保我们的团队有应变能力并且可以适应不同的条件。//
--(% class="wikigeneratedid" %)
--===   ===
--
  === 4.3.1 技术债 ===
--
  **定义：技术债**
  通过选择规避措施而不是需要更长时间的系统解决方案来累积待办项的返工。
@@ -742,7
          +742,6 @@
  图4.17 技术债对服务价值链贡献的热图
--
  表4.14概述了与技术债相关的实践。
  [[image:1641701689758-164.png]]
@@ -750,7
          +750,6 @@
  表4.14 与技术债相关的实践
--
  **ITIL故事：技术债**
  //Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
@@ -758,10
          +758,8 @@
  //Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
--
  === 4.3.2 混沌工程 ===
--
  **定义：混沌工程**
  为了建立对系统承受生产中动荡环境能力的信心而在系统上进行实验的学科。
@@ -825,10
          +825,8 @@
  //Solmaz：我们使用了混沌猴子工具来了解该应用在胁迫下的工作方式。它使我们能够看到系统可能在哪里崩溃，这意味着我们可以修改代码和软件体系结构以减少或消除薄弱环节。//
--
  === 4.3.3 完成的定义 ===
--
  **完成的定义**
  拟议产品或服务的商定标准清单。
@@ -892,10
          +892,8 @@
  //●     该软件具有可读性、可用性和适应性//
--
  === 4.3.4 版本控制 ===
--
  **定义：版本控制**
  信息系统、产品和服务的来源和人工制品的管理。
@@ -941,10
          +941,8 @@
  //Marco：我们实行持续集成和持续交付，我们利用版本控制系统地记录我们发布的应用程序的每次迭代，如果发布不稳定，我们可以通过将服务返回到先前的稳定版本来快速还原该服务。//
--
  === 4.3.5 人工智能运营 ===
--
  **定义：AIOps**
  将机器学习和大数据应用于IT运营以获取持续的见解，并通过自动化提供持续的修复和改进。也称为“IT运营的人工智能“或”算法IT运营“。
@@ -985,10
          +985,8 @@
  Su：我们创建了脚本来分析数据，查找使用模式并优化服务的基础架构。例如，如果数据表明电动汽车的用户正在达到电池充电的终点，则脚本会自动突出显示提示，说明如何为电池充电，以及最近的充电设施的地图。
--
  === 4.3.6 聊天运营 ===
--
  ChatOps是一个模型，其中人员、工具、流程和自动化都连接在透明的流程中。该模型有助于控制管道和协作。它是即时通信与运营执行的紧密结合：这是一个新兴的运动，促进了多个团队、工具和DevOps平台的集成。通过将工具和平台进行对话来驱动开发。当机器人是团队成员时，可以向他们发送请求并获得即时响应。
  ChatOps支持人与工具之间的协作通信，通过消除对重复信息的请求并自动执行一些常规的IT运维操作来减少事件响应时间。
@@ -1022,15
          +1022,8 @@
  [[image:1641702752724-340.png]]
--(% class="wikigeneratedid" %)
--===   ===
--
--(% class="wikigeneratedid" %)
--===   ===
--
  === 4.3.7 站点可靠性工程 ===
--
  **定义：站点可靠性工程**
  该学科结合了软件工程的各个方面，并将其应用于基础结构和操作问题，旨在创建超可扩展且高度可靠的软件系统。
@@ -1081,10
          +1081,8 @@
  //Radhika：站点可靠性工程在减少服务故障的需求与减少服务故障之间进行平衡的需求之间取得了平衡。我们越能自动化工作并减少重复的手动操作，代码就越强大。价值共创的技术//
--
  == 4.4 价值共创的技术 ==
--
  价值共创目标涉及通过服务提供商和服务消费者的紧密合作，从数字化产品价值共创。
  价值共创是服务消费者有效地使用服务提供商的产品和服务，并从其功用和功效中受益。只有通过从自动化信息系统获得的信息来改进决策（无论是由人，自动化还是AI来完成），才能实现数字投资的回报。因此，用户必须了解数字化产品和信息及其在上下文中的用途。他们应该充分理解该功能以适当地使用它，并能够正确地解释信息以改进决策。最后，人或事必须根据这些决定采取行动；只有这样，价值才能实现。
@@ -1111,10
          +1111,8 @@
  //Henri：我们的目标是为所有利益干系人价值共创，因此，无论表面上发生什么变化，我们都需要确保为预订汽车提供的界面是一致且直观的。该应用程序应无缝响应客户要求，以确保用户获得提供最佳价值的优化服务。//
--
  === 4.4.1 服务体验 ===
--
  “服务体验”是指服务消费者对服务的评价是基于服务的“技术”输出以及从人的角度看待它的方式这一事实。这意味着服务提供商应该越来越意识到消费者的需求以及他们可用来价值共创的资源。不会被动地获得服务：价值共创需要消费者的努力。服务提供者和使用者必须动态地响应彼此的行为，并尽可能地容纳异常。
  当在一些具有数字功能的组织中，业务和IT融合为一个组织实体时，就不再需要业务和IT实体。因此，也不再需要管理业务与IT的关系。“业务人员”和“ IT人员”向同一管理人员报告，具有相同的目标，并且通常在物理上位于同一地点。当采用敏捷或Scrum的工作方式时，有一个相对独立的团队致力于一个产品，则业务人员和IT人员在同一团队中，产品所有者代表业务利益。产品负责人经常管理与外部客户和其他利益干系人的关系。这些其他利益干系人包括寻求协同作用的其他产品所有者；例如知识和资源共享。
@@ -1143,11
          +1143,8 @@
  //Su：在Axle汽车租赁公司，业务与IT之间没有鸿沟。开发团队协作以提供可响应客户需求的服务体验。我们使用应用程序和车辆中的数据来指导服务的优化和自动化。该应用程序是可定制的，因此用户可以根据自己的需求优化服务。//
--
--
  == 4.5 保证合规的技术 ==
--
  保证合规目标涉及确保服务提供和服务使用在治理，风险和合规性方面符合公司和法规指令。除了确保合规性之外，确保责任人员实现合规性也很重要。
  尽管外部需求可能保持不变，但是对于启用数字化技术的组织来说，可能会有其他更合适的方式来实现它们。
@@ -1171,10
          +1171,8 @@
  //Henri：与所有道德企业一样，Axle完全遵守法律法规。我们利用保证合规的技术，因为有时IT进步如此之快，以致可以忽略或延迟遵从性要求。我们敬业的治理团队只是我们关注合规性要求变化的方式之一。//
--
  === 4.5.1 DevOps审核防御工具包 ===
--
  DevOps审核防御工具包17是指南，解决了DevOps社区中新的、更流畅的工作模式所引起的IT与审核之间的紧张关系。它有助于向审计师证明IT部门了解业务风险并正在适当地减轻风险。该工具包建议了一些技术，这些技术可以降低风险，并在IT部门和审计师之间建立共同的观点和共识。因此，它有助于保证合规。通过减少不必要的官僚主义，它也为快速发展做出了贡献。
  DevOps审核防御工具包与HVIT有关，因为HVIT的某些原理和技术似乎与常规合规性要求相抵触。但是，通常情况下，这是寻找获得所需结果的其他方法的情况。内部法规源自外部要求，通常可以找到替代的内部法规。但是，使审核员参与此过程非常重要。
@@ -1192,10
          +1192,8 @@
  [[image:1641702956598-898.png]]
--
  === 4.5.2 开发安全 ===
--
  大多数组织都有专门的信息安全团队，该团队执行风险评估并定义策略，规程和控制。在高速环境中，信息安全已尽可能集成到开发和运营的日常工作中，并将对过程控制的依赖转移到验证前提条件（例如员工的专业知识和完整性）上。安全员的角色从“维持治安”转变为使其他人能够采取必要措施。
  “ DevSecOps”是指将与安全相关的活动集成到应用程序开发和IT运营的日常工作中。在整个DevOps流程中，跨文化，自动化，指标和共享（CAMS或CALMS加上精益）的四个支柱都内置了安全性。
@@ -1259,10
          +1259,8 @@
  //Marco：我们所有的员工都接受过培训，以了解他们的行为如何危害我们的安全。他们遵循安全流程，可以检测，预防和纠正安全事件。//
--
  === 4.5.3 同行评审 ===
--
  **定义：同行评审**
  同一领域的其他人对一件科学或其他专业作品的判断。当应用于软件开发时，工作产品的开发人员和一个或多个同事将对其进行检查，以评估其技术含量和质量。这有助于保证合规。
@@ -1313,8
          +1313,6 @@
  表4.25概述了同行评审相关的实践。
--
--
  **ITIL故事：同行评审**
  //Su：我们的应用程序开发团队协同工作，并定期进行定期的同行评审。我们从同事的专业知识和经验中受益匪浅，他们会互相回顾彼此的工作，并在问题到达实际环境之前发现并纠正问题。//
@@ -1322,11
          +1322,8 @@
  //索尔玛兹：我们倡导开放，无责的文化，这意味着个人在与同行分享工作时会感到自在。这有助于构建强大，有影响力的服务，为所有利益干系人创造价值。//
--
--
  == 4.6 小结 ==
--
  在第2章中，描述了实现高速IT的五个重要组织目标。为了支持实现这些目标，组织可以采用多种技术和模型。其中一些是最近开发的，而其他一些则是根据以前采用的运营模型和管理方法改编的。第4章探讨了一些流行且重要的技术。
  在本章中，这些技术围绕高速目标进行了分组。但是，它们中的大多数在一定程度上有助于实现多个目标。HVIT技术在许多实践中普遍适用。为了帮助在实践中采用它们，提供了它们对服务价值链的相对贡献的热图。

粤ICP备17056641号

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