Changes for page 4.高速IT技术

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 35 added, 0 removed)
  • 1639569697056-454.png
  • 1641700591514-812.png
  • 1641700659017-287.png
  • 1641700683365-399.png
  • 1641700701040-265.png
  • 1641700764097-167.png
  • 1641700825218-144.png
  • 1641700916381-114.png
  • 1641701019297-720.png
  • 1641701038534-675.png
  • 1641701094058-713.png
  • 1641701145033-568.png
  • 1641701202590-318.png
  • 1641701238590-838.png
  • 1641701293452-859.png
  • 1641701355821-388.png
  • 1641701417790-550.png
  • 1641701444463-764.png
  • 1641701509520-551.png
  • 1641701559766-478.png
  • 1641701689758-164.png
  • 1641702469032-780.png
  • 1641702487237-876.png
  • 1641702547499-544.png
  • 1641702577206-162.png
  • 1641702628320-774.png
  • 1641702718413-352.png
  • 1641702752724-340.png
  • 1641702861765-733.png
  • 1641702908935-105.png
  • 1641702956598-898.png
  • 1641703051758-407.png
  • 1641703070463-409.png
  • 1641703105916-225.png
  • 1641703160673-370.png

Details

Page properties

Content

...	...	@@ -1,5 +1,17 @@
1		-= 4. 高速IT技术 =
	1	+
2	2
	3	+
	4	+ [[返回上一章>>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/]]
	5	+
	6	+{{box cssClass="floatinginfobox" title="
	7	+
	8	+**X Contents**"}}
	9	+{{toc/}}
	10	+{{/box}}
	11	+
	12	+= **4. 高速IT技术** =
	13	+
	14	+
3	3	本章介绍了表征HVIT环境特征的一些技术选择。有些通常只在这些环境中发现，而另一些是对HVIT工作至关重要的更通用的技术。选择并不详尽；这些技术是帮助高度数字化的组织实现其苛刻目标的工作方式的示例。
4	4
5	5	本章中的技术根据与五个HVIT目标之一的关系进行分组和描述：
...	...	@@ -15,11 +15,13 @@
15	15
16	16	**ITIL故事：高速IT技术**
17	17
18		-//Su：我们的预订应用程序的更新已成功部署，该更新将改进其在智能手机和设备上的性能。我们计划进一步开发该应用程序，并增加其他功能，例如会员计划、会员链接、优先预订和车辆升级。我们利用并将继续利用许多技术来帮助我们优化工作和聚焦价值。//
	30	+Su：我们的预订应用程序的更新已成功部署，该更新将改进其在智能手机和设备上的性能。我们计划进一步开发该应用程序，并增加其他功能，例如会员计划、会员链接、优先预订和车辆升级。我们利用并将继续利用许多技术来帮助我们优化工作和聚焦价值。
19	19
20	20
	33	+
21	21	== 4.1 有价值的投资技巧 ==
22	22
	36	+
23	23	有价值的投资目标包括识别和证明对业务战略有重大贡献的数字投资。此练习应使您对数字投资的潜在价值、预期成本、投资回报以及其功用的定义标准有很好的了解。尽管不会增加功能的潜在价值，但也应确定功效或非功能性要求。功效确保投资的潜在价值不受中断，使用不当或其他因素的不利影响。
24	24
25	25	有价值的投资是根据市场研究和新产品开发建立的。应当设想新的数字化产品和服务，并根据盈利能力进行评估。产品和服务的实质质量及其发布时间都是获得和保持竞争优势的关键因素。越早设想和评估潜在的投资，就越早实现诸如竞争优势之类的收益。在制定投资决策时，应使用道德原则制定考虑广泛利益干系人的利益。
...	...	@@ -42,15 +42,19 @@
42	42	//Marco：我们的业务策略是通过对技术的明智投资来实现的。因为我们使用敏捷的工作技术，所以我们可以保证我们的功效：我们的代码将始终有效。我们会监控投资情况，以确保我们明智地花钱，并确保应用程序的功能符合客户的需求。//
43	43
44	44
	59	+
45	45	=== 4.1.1 优先级排序技术 ===
46	46
	62	+
47	47	只要工作的需求超出了在预期时间内完成工作的能力，就会发生队列。在理想情况下，组织将没有需求的变化，并且将拥有满足需求所需的适当质量和数量的资源。但是，组织经常需要应对具有固定容量但对服务需求不断变化的问题。这种不平衡会导致需要对工作项进行优先级排序的队列或积压。
48	48
49	49	优先级排序是一项通常与支持和软件开发的工作相关活动（例如，对事件调查优先级或对紧急待办项进行优先级排序），但是它是通用的。
50	50
51	51
	68	+
52	52	==== 4.1.1.1 延迟成本 ====
53	53
	71	+
54	54	进行优先级排序的一种可用技术是估算新服务或改进服务的延迟成本。这指的是如果服务活动或任务被延迟会损失的财务和非财务利益。对延迟成本的理解使从业人员能够根据价值数据而不是凭直觉确定工作的优先级。这适用于在不断变化的环境中对正在进行的工作进行初始优先级划分、持续评估和重新排序。几乎总是，数字化产品和服务的业务重要性证明了估算延迟成本所付出的努力是合理的。
55	55
56	56	延迟成本可以应用于各种级别的决策，例如，产品或服务组合中产品或服务级别的大型投资，产品或服务中功能级别的较小投资或运营任务中。
...	...	@@ -58,8 +58,10 @@
58	58	该技术在HVIT环境中特别有用，因为投资通常更为重要，并且市场条件会迅速变化，这意味着持续评估替代投资的选择很重要。
59	59
60	60
	79	+
61	61	==== 4.1.1.2 买/持有/卖 ====
62	62
	82	+
63	63	可以使用购买/持有/出售技术来管理产品组合（或其他资产）。这涉及评估每种产品并确定三种投资策略中最适合的一种：
64	64
65	65	* **买 **投资以改进或扩展生产。
...	...	@@ -69,8 +69,10 @@
69	69	该技术阐明了开发、维护或淘汰产品的成本与收益之间的差异，以及相关的风险和权衡。它可以帮助决策者明确他们的选择并接受决策的后果。
70	70
71	71
	92	+
72	72	==== 4.1.1.3 其他技巧 ====
73	73
	95	+
74	74	产品/服务所有者还可以考虑其他许多产品优先级排序技术，包括堆叠排名，Kano，净现值（NPV），投资回报率（ROI）以及适合性/可行性/吸引力。
75	75
76	76	图4.1显示了优先级对服务价值链的贡献。表4.1概述了与优先级相关的实践。
...	...	@@ -81,20 +81,13 @@
81	81	图4.1 优先化对服务价值链贡献的热图
82	82
83	83
	106	+
84	84	表4.1 与优先级相关的实践
85	85
86		-(% style="width:781px" %)
87		-|**ITIL管理实践**|(% style="width:536px" %)**与优先次序相关的活动/资源**|(% style="width:95px" %)**影响**
88		-|组合管理|(% style="width:536px" %)持续根据价值优先考虑服务产品，并考虑延迟成本。|(% style="width:95px" %)H
89		-|问题管理|(% style="width:536px" %)计算未解决问题和错误的财务成本，以便确定优先级并指导问题管理工作。将规避措施的成本与长期解决方案的成本进行比较。|(% style="width:95px" %)H
90		-|项目管理|(% style="width:536px" %)计算执行或延迟项目工作的财务影响。|(% style="width:95px" %)H
91		-|软件开发与管理|(% style="width:536px" %)计算延迟工作对新软件功能或较大的基于软件的服务组件的财务影响。决定是获取还是构建软件组件。|(% style="width:95px" %)H
92		-|变更控制|(% style="width:536px" %)计算对服务或服务组件的变更进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
93		-|事件管理|(% style="width:536px" %)计算事故和重大事故的成本，以便优先安排对经济影响最大的工作。|(% style="width:95px" %)M
94		-|发布管理|(% style="width:536px" %)计算对新服务或变更的服务进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
95		-|服务财务管理|(% style="width:536px" %)计算时间值概要文件数据，以提供用于确定服务产品优先级的信息。|(% style="width:95px" %)M
96		-|服务请求管理|(% style="width:536px" %)计算和比较执行或延迟执行请求的财务影响，以便优先安排具有最高收益的工作。|(% style="width:95px" %)L
	109	+[[image:1641700591514-812.png]]
97	97
	111	+
	112	+
98	98	**ITIL故事：优先排序技术**
99	99
100	100	//Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
...	...	@@ -110,8 +110,10 @@
110	110	//我们努力保证令人满意的投资回报。//
111	111
112	112
	128	+
113	113	=== 4.1.2 最小可用的产品服务 ===
114	114
	131	+
115	115	最小可用产品或服务具有足够的功能，以便能够对其进行早期的评估并收集反馈意见，以供将来开发。“ 最小可用”方法是开发产品和服务的有效方法，尤其是当市场动荡并且难以预测的情况下。这与复杂性思维一致，后者认识到某些事情是不可知的，因此不可能设计出具有完整、预先确定需求的产品或服务。当需求未知、不明确或模棱两可时，实验可以确定哪些有效，哪些无效。因此，最小可用方法可以实现有价值的投资，并通过迭代的工作方式促进快速发展。
116	116
117	117	在动荡市场上，很难判断哪种产品或服务产品将是成功的。这种不确定性可以通过最小可用方法解决。产品或服务提供者不应投入大量资源和时间来开发全面的产品或服务，而应该限制他们的工作。他们应该针对刚开发出足以刺激反馈和其他数据的产品或服务，然后可以指出是否以及如何继续进行开发。一旦收集了足够的数据，就可以做出决定，这增加了成功的机会。此外，如果决定停止开发，则产品或服务提供者可以将其资源分配给另一项投资，从而最大程度地减少了最初想法的浪费。
...	...	@@ -130,48 +130,15 @@
130	130	图4.2 热图贡献最小可用的服务价值方法
131	131
132	132
	150	+
133	133	表4.2 与最小可用方法相关的实践
134	134
135		-(% style="width:863px" %)
136		-|**ITIL管理实践**|(% style="width:575px" %)**与最小可用方法相关的活动/资源**|(% style="width:87px" %)**影响**
137		-|架构管理|(% style="width:575px" %)(((
138		-使用最小可用的方法来描述服务、技术、信息或环境体系结构，这将为其他类型
	153	+[[image:1641700659017-287.png]]
139	139
140		-的服务或产品工作创建必要的约束、边界或促成因素。
141		-)))|(% style="width:87px" %)H
142		-|业务分析|(% style="width:575px" %)使用最低可行的方法作为从产品或服务中提取核心业务价值的工具。|(% style="width:87px" %)H
143		-|容量与性能管理|(% style="width:575px" %)(((
144		-使用容量和性能管理作为计算最低可行产品或服务所需的最小资源（服务器数量，服务
	155	+[[image:1641700701040-265.png]]
145	145
146		-台代理数量等）的基础。
147		-)))|(% style="width:87px" %)H
148		-|监控与事态管理|(% style="width:575px" %)(((
149		-使用监控和事态管理作为设计和配置监视和遥测工具的基础，这些工具用于操作和从最低
150	150
151		-限度可行的产品或服务中学习。
152		-)))|(% style="width:87px" %)H
153		-|组合管理|(% style="width:575px" %)(((
154		-使用最小可用产品的概念作为动态决策工具，以支持对产品或服务中的功能组合进行良好
155	155
156		-的投资。
157		-)))|(% style="width:87px" %)H
158		-|项目管理|(% style="width:575px" %)阐明满足业务案例所需的最小输出。|(% style="width:87px" %)H
159		-|服务设计|(% style="width:575px" %)使用最小可用的方法来设计产品或服务的必要客户体验和用户体验元素。|(% style="width:87px" %)H
160		-|服务验证与测试|(% style="width:575px" %)开发测试用例以检查所有服务组件是否支持最低限度的可行产品或服务。|(% style="width:87px" %)H
161		-|软件开发管理|(% style="width:575px" %)使用最小可用方法作为决策工具来优先处理软件功能。|(% style="width:87px" %)H
162		-|架构管理|(% style="width:575px" %)(((
163		-使用最小可用方法作为决策工具来设计，实施基础架构组件上正在进行的工作并确定其优
164		-
165		-先级。
166		-)))|(% style="width:87px" %)M
167		-|服务目录管理|(% style="width:575px" %)(((
168		-使用最小可用方法作为描述所有产品、服务和服务产品的基础，并确保相关受众能够获取
169		-
170		-信息。
171		-)))|(% style="width:87px" %)M
172		-|服务连续性管理|(% style="width:575px" %)设计和建立连续性计划以支持最低限度的可行产品或服务。|(% style="width:87px" %)M
173		-|供应商管理|(% style="width:575px" %)合作伙伴和供应商提供产品和服务时，使用最小可用方法阐明所需的输出。|(% style="width:87px" %)M
174		-
175	175	**ITIL的故事：最小可用产品和服务**
176	176
177	177	//Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
...	...	@@ -179,8 +179,10 @@
179	179	//Solmaz：我们知道我们不了解未来的客户会想要什么。通过迭代，我们可以在每个阶段对产品进行测试，如果出错，可以在不牺牲大量投资的情况下返回以前的成功版本。//
180	180
181	181
	166	+
182	182	=== 4.1.3 产品或服务所有权 ===
183	183
	169	+
184	184	Scrum建议三个角色：产品负责人，开发团队和Scrum主管。产品负责人负责使开发团队生产的产品价值最大化。产品所有权需要建立需求并确定其优先级，并将其传达给开发团队。在这些软件开发团队的背景下，是产品负责人与包括消费者在内的各种利益干系人进行联络和协商。HVIT环境通常是面向产品的，因此产品负责人的概念与HVIT高度相关。产品负责人的概念也适用于服务和服务所有者。
185	185
186	186	产品负责人角色依赖于：
...	...	@@ -202,29 +202,10 @@
202	202
203	203	表4.3 与产品或服务所有权相关的实践
204	204
205		-(% style="width:788px" %)
206		-|**ITIL管理实践**|(% style="width:566px" %)**与产品或服务所有权相关的活动/资源**|(% style="width:63px" %)**影响**
207		-|架构管理|(% style="width:566px" %)(((
208		-产品和服务所有者参与阐明，完善基础架构和平台开发积压工作并确定其优先级，并
	191	+[[image:1641700764097-167.png]]
209	209
210		-决定是否购买市售的基础架构组件和服务。
211		-)))|(% style="width:63px" %)H
212		-|组合管理|(% style="width:566px" %)（软件）产品所有者和产品或服务经理参与评估和确定产品或服务投资建议的优先级。|(% style="width:63px" %)H
213		-|关系管理|(% style="width:566px" %)(((
214		-与利益干系人的互动。
215	215
216		-参与确定客户对新产品或已变更产品和服务的优先级。
217	217
218		-协调客户的需求和反馈。
219		-
220		-参与解决投诉和调解相互矛盾的要求。
221		-)))|(% style="width:63px" %)H
222		-|服务目录管理|(% style="width:566px" %)产品或服务所有者和经理参与发布有关所有产品、服务和服务产品的信息。|(% style="width:63px" %)H
223		-|软件开发管理|(% style="width:566px" %)产品和服务所有者参与阐明，完善和确定软件开发积压的优先次序，并决定是否购买或升级商用软件。|(% style="width:63px" %)H
224		-|项目管理|(% style="width:566px" %)产品和服务所有者及经理参与交付项目工作和管理风险。|(% style="width:63px" %)M
225		-|风险管理|(% style="width:566px" %)产品和服务所有者参与阐明和减轻企业风险。|(% style="width:63px" %)M
226		-|供应商管理|(% style="width:566px" %)产品和服务所有者及管理人员参与阐明需求，组织互动以及与合作伙伴和供应商进行谈判。|(% style="width:63px" %)M
227		-
228	228	**ITIL故事：产品或服务所有权**
229	229
230	230	//Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
...	...	@@ -232,8 +232,10 @@
232	232	//我具有在敏捷开发和业务分析培训方面的经验的技术背景，包括与客户合作所花费的时间。我了解我可以授权的变更级别以及何时需要升级问题。Axle确保我有时间履行自己的职责，并了解我的要求以及产品如何专注于价值。//
233	233
234	234
	202	+
235	235	=== 4.1.4 A / B测试 ===
236	236
	205	+
237	237	很难预测某个功能是否对用户有价值。这个问题通过测量用户行为来收集可靠的数据来解决。但是，当影响因素太多时，几乎不可能将新功能的效果分离出来。因此，需要一个对照组。
238	238
239	239	A / B测试是一项限时实验，其中一组用户（即对照组）提供了旧版本的产品或服务。同时，为另一组用户（实验组）提供了包括新功能的产品或服务的新版本。假设影响两组的所有其他因素均相等，则可以比较两组的测量值，从而收集数据以基于价值的决策。此方法如图4.4所示。
...	...	@@ -261,19 +261,13 @@
261	261	图4.5 A/B测试对服务价值链贡献的热图
262	262
263	263
	233	+
264	264	表4.4 与A/B测试相关的实践
265	265
266		-|**ITIL管理实践**|**与A / B测试相关的活动/资源**|**影响**
267		-|组合管理|确定并优先考虑使用A / B测试数据进行投资的服务、产品和功能。|H
268		-|风险管理|在进行进一步投资之前，使用A / B测试方法确定风险缓解方案的有效性。|H
269		-|服务设计|在进行进一步的投资和设计决策之前，使用A / B测试方法确定客户体验和用户体验原型的有效性。|H
270		-|架构管理|使用A / B测试方法设计和完善技术，信息，产品和服务体系结构。|M
271		-|持续改进|在进行进一步投资之前，使用A / B测试方法确定各种改进方案和计划的有效性。|M
272		-|知识管理|在进行进一步的投资之前，使用A / B测试方法确定不同知识管理，表示以及通讯技术和工的有效性。|M
273		-|组织变革管理|在进行进一步投资之前，使用A / B测试方法确定组织变革的有效性。|M
274		-|问题管理|在进行进一步投资之前，使用A / B测试方法确定规避措施和错误控制方法的有效性。|M
275		-|服务验证与测试|使用A / B测试方法定义和执行服务、验证和产品测试活动。|M
	236	+[[image:1641700825218-144.png]]
276	276
	238	+
	239	+
277	277	**ITIL的故事：A / B测试**
278	278
279	279	//Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
...	...	@@ -283,8 +283,11 @@
283	283	//Su：基于这些结果，我们可以放心发布此新功能。//
284	284
285	285
	249	+
	250	+
286	286	== 4.2 快速研发技术 ==
287	287
	253	+
288	288	快速发展的目标涉及频繁、快速且可靠地实现新的和改进的数字化产品和服务。“ 开发”通常是指产品开发，尽管应用程序开发通常包含在其中。
289	289
290	290	通常，越早交付数字化产品，越早实现价值。但是，有时情况并非如此，应相应地修改时间表；例如，提早交付可能与市场需求不符。将单个产品分成一系列增量交付可加快整体交付速度，并使用户比等待整个产品更早地实现价值。
...	...	@@ -321,13 +321,17 @@
321	321	* 连续测试
322	322	* 看板
323	323
	290	+
	291	+
324	324	**ITIL故事：快速研发的技术**
325	325
326	326	//Solmaz：我们不断开发新的应用功能，并定期且频繁地发布改进和变更。这有助于我们更早地实现价值并尽快收到反馈。它还使我们能够优先考虑开发的新功能和支持工作。因为变更很小，所以它们需要较少的支持，并且服务中断的风险也较少。//
327	327
328	328
	297	+
329	329	=== 4.2.1 基础架构即代码 ===
330	330
	300	+
331	331	基础架构即代码（IaC）支持更快的环境配置，从而有助于更快的开发和更有弹性的运营。虚拟化和虚拟机管理程序技术（通常通过云提供）允许通过编程接口远程创建、修改和删除基础架构项目。如今，使用脚本和配置文件来构建和配置服务器是一种常见的做法。
332	332
333	333	IaC是一种通过使用机器可读的定义文件而不是物理配置硬件组件来管理和配置IT基础架构和平台的方法。然后可以将这些文件存储在版本控制系统中（请参阅第4.3.4节中的版本控制）。
...	...	@@ -344,29 +344,11 @@
344	344
345	345	图4.7 基础设施作为代码对服务价值链的贡献的热图
346	346
347		-‘
348	348
	318	+
349	349	表4.5 与基础设施作为代码相关的实践
350	350
351		-(% style="width:825px" %)
352		-|**ITIL管理实践**|(% style="width:560px" %)**与基础设施作为代码相关的活动/资源**|(% style="width:90px" %)**影响**
353		-|架构管理|(% style="width:560px" %)验证架构决策并比较基础架构解决方案。|(% style="width:90px" %)H
354		-|变更控制|(% style="width:560px" %)启用虚拟基础架构组件的快速配置或停用，以平衡交付速度与治理，风险和合规性需求。|(% style="width:90px" %)H
355		-|部署管理|(% style="width:560px" %)自动化基础架构的部署，确保基础架构和应用程序的部署更快，更重复，更可靠。|(% style="width:90px" %)H
356		-|信息安全管理|(% style="width:560px" %)在虚拟基础架构组件中设计和实施安全策略。|(% style="width:90px" %)H
357		-|IT资产管理|(% style="width:560px" %)跟踪分配给通常快速配置或停用的虚拟基础结构组件的商业软件许可证的使用。|(% style="width:90px" %)H
358		-|知识管理|(% style="width:560px" %)存储虚拟服务器配置文件，并使它们可用于IaC自动化。|(% style="width:90px" %)H
359		-|服务配置管理|(% style="width:560px" %)以适当的粒度级别设计和维护配置管理数据库和关系，以跟踪经常快速调配或退役的虚拟基础架构组件。|(% style="width:90px" %)H
360		-|服务财务管理|(% style="width:560px" %)由于对基础设施的投资减少，资金从资本支出转向运营支出。|(% style="width:90px" %)H
361		-|服务请求管理|(% style="width:560px" %)自动配置或停用虚拟基础架构组件。|(% style="width:90px" %)H
362		-|服务验证与测试|(% style="width:560px" %)设计和维护测试用例，以确保虚拟IaC满足组织要求和策略。|(% style="width:90px" %)H
363		-|软件开发管理|(% style="width:560px" %)开发软件体系结构和代码，以利用虚拟硬件基础结构的快速交付/配置。|(% style="width:90px" %)H
364		-|事件管理|(% style="width:560px" %)利用IaC功能自动化（在适当情况下）事件恢复任务。|(% style="width:90px" %)M
365		-|基础架构管理|(% style="width:560px" %)快速交付/配置虚拟硬件基础架构。|(% style="width:90px" %)M
366		-|问题管理|(% style="width:560px" %)利用IaC功能进行问题检测和错误控制。|(% style="width:90px" %)M
367		-|服务连续性管理|(% style="width:560px" %)设计适当的连续性计划以反映组织对IaC功能的使用。|(% style="width:90px" %)M
368		-|供应商管理|(% style="width:560px" %)选择可以提供IaC功能或利用组织对IaC的投资的供应商。|(% style="width:90px" %)M
369		-|风险管理|(% style="width:560px" %)认识到通过使用IaC引入或减轻的风险。|(% style="width:90px" %)L
	321	+[[image:1641700916381-114.png]]
370	370
371	371	表4.5 列出了与基础设施作为代码相关的实践。
372	372
...	...	@@ -376,8 +376,10 @@
376	376	//Marco：在测试环境下，我们在虚拟机上使用虚拟机监控程序技术创建了多个测试环境。我们想在多个平台上模拟该应用程序的使用。因为我们在开发周期的每个阶段都对代码进行了验证，所以我们知道该应用程序将随着它的增长而继续在不同的设备上运行。//
377	377
378	378
	331	+
379	379	=== 4.2.2 松耦合信息系统架构 ===
380	380
	334	+
381	381	松耦合信息系统架构基于相对较小的独立组件。该架构使工作能够在相对较小的，相对独立的，基于产品或服务的团队和基于平台的团队中完成。通过将系统分解为可以相对独立地开发和管理的部分，团队可以专注于自己的部分并限制与其他团队的互动。基于产品或服务的团队由开发人员和工程师以及代表消费者观点的产品/服务所有者组成。更紧密的协作对快速研发和价值共创都是有益的。它还有助于进行有价值的投资、快速研发和弹性运营（其中IT运维也在团队中出现）。
382	382
383	383	紧密耦合的体系结构（例如在单片信息系统中）的最大问题之一是变更的速度极低，因为许多变更都需要重新设计和重新开发系统的多个部分。实际上，在同一系统上增加更多的团队和员工可能会降低速度，因为这可能导致体系结构级别的组件之间的深度互连过多。
...	...	@@ -399,6 +399,8 @@
399	399	* 它效率更高，导致重新设计和开发产品或服务所需的工作更少。
400	400	* 它使从专注于组件的团队结构切换为基于产品或功能的团队结构。图4.8显示了松散耦合信息系统架构对服务价值链的贡献。表4.6概述了与松散耦合信息系统架构相关的实践。
401	401
	356	+
	357	+
402	402	**ITIL故事：松耦合信息系统架构**
403	403
404	404	//Su：我们在应用程序中使用了松耦合信息系统架构。通过将系统视为相对较小且独立的组件，每个组件上的团队可以独立工作，因为他们了解组件会接收的输入以及工作流中后续组件所需的输出。这减少了不同组件之间的重复、复杂性和相互依赖性//该应用程序。
...	...	@@ -410,32 +410,31 @@
410	410	图4.8 松散耦合信息系统架构对服务价值链贡献的热图
411	411
412	412
	369	+
413	413	表4.6 与松散耦合信息系统架构相关的实践
414	414
415		-(% style="width:718px" %)
416		-|(% style="width:108px" %)**ITIL管理实践**|(% style="width:520px" %)**与松散耦合信息系统架构相关的活动/资源**|(% style="width:87px" %)**影响**
417		-|(% style="width:108px" %)架构管理|(% style="width:520px" %)设计松耦合的服务，技术和信息体系结构。|(% style="width:87px" %)H
418		-|(% style="width:108px" %)业务分析|(% style="width:520px" %)了解消费者需求并将其转化为每个需求的详细需求松耦合服务体系结构的组件。|(% style="width:87px" %)H
419		-|(% style="width:108px" %)部署管理|(% style="width:520px" %)部署的范围和部署模式因以下因素的解耦而减小：系统架构；这使部署更易于管理和复制，并且功能强大自动化的候选人。|(% style="width:87px" %)H
420		-|(% style="width:108px" %)信息安全管理|(% style="width:520px" %)为松散耦合的服务设计和管理信息安全策略、服务组件。|(% style="width:87px" %)H
421		-|(% style="width:108px" %)基础设施及平台管理|(% style="width:520px" %)松耦合基础架构的详细设计，构建，运行和管理和平台组件。|(% style="width:87px" %)H
422		-|(% style="width:108px" %)问题管理|(% style="width:520px" %)研究问题并设计跨越多个松耦合系统的错误控制。|(% style="width:87px" %)H
423		-|(% style="width:108px" %)服务配置管理|(% style="width:520px" %)设计和维护有关各种服务和服务组件的信息，以及他们的相互关系。|(% style="width:87px" %)H
424		-|(% style="width:108px" %)服务级别管理|(% style="width:520px" %)通过与消费者的松耦合架构设计和调整服务级别服务消费方面的期望。|(% style="width:87px" %)H
425		-|(% style="width:108px" %)软件开发管理|(% style="width:520px" %)松耦合软件的详细设计、构建、运行和管理组件。|(% style="width:87px" %)H
426		-|(% style="width:108px" %)变更控制|(% style="width:520px" %)松散耦合的体系结构降低了与应用程序、基础架构变更相关的风险，如果这些变更失败。 较低的风险状况会导致变化在团队级别（而不是部门或组织级别）批准，从而减少了官僚。|(% style="width:87px" %)M
427		-|(% style="width:108px" %)事件管理|(% style="width:520px" %)事件后可以计划调查和解决方案， 以更少的压力和更有效的方式进行演练。服务中断的影响松散耦合的体系结构通常限于无法使用的配置项（CI），而不是其他CI。这是由于系统组件的设计原理应该具有弹性，并且不依赖于其他配置项提供的服务。结果是，事件对客户的影响较小。|(% style="width:87px" %)M
428		-|(% style="width:108px" %)服务财务管理|(% style="width:520px" %)松散耦合的系统体系结构使第三方服务的耦合和解耦更加容易，从而使服务提供商能够利用降价和提供新产品的优势。 这种灵活性还要求服务提供商采用敏捷成本核算模型来有效地切换提供商。|(% style="width:87px" %)M
429		-|(% style="width:108px" %)供应商管理|(% style="width:520px" %)当某些组件松散时，建立合同并管理绩效。耦合体系结构由供应商或外部服务提供商提供。|(% style="width:87px" %)M
430		-|(% style="width:108px" %)战略管理|(% style="width:520px" %)由于投资的原因，将紧密耦合的体系结构去耦是一项战略级决策必要条件以及利用它的潜在运营模式含义（例如引入自治团队）。 这种架构的一个例子是面向服务的可以将第三方服务作为端到端服务的一部分的体系结构。|(% style="width:87px" %)L
	372	+[[image:1641701019297-720.png]]
431	431
	374	+[[image:1641701038534-675.png]]
	375	+
	376	+
	377	+(% class="wikigeneratedid" %)
	378	+=== ===
	379	+
	380	+(% class="wikigeneratedid" %)
	381	+=== ===
	382	+
432	432	=== 4.2.3 复查 ===
433	433
	385	+
434	434	通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
435	435
436	436
	389	+
	390	+
437	437	==== 4.2.3.1 回顾 ====
438	438
	393	+
439	439	在敏捷中，回顾是在迭代（或称为“ 冲刺”）或项目结束时召开的团队会议，以讨论哪些进展顺利，哪些可以改进的方面以及将来如何从中受益。这种快速而频繁的反馈有助于快速研发。回顾可以应用于大多数场景以及需要不断改进的任何区域。为有效起见，应定期安排他们的时间，并由主持人安排参与者的贡献。应确定为持续改进而输入的行动，并委派责任。图4.9显示了回顾对服务价值链的贡献。
440	440
441	441
...	...	@@ -447,26 +447,20 @@
447	447
448	448	表4.7 与回顾相关的实践
449	449
450		-(% style="width:965px" %)
451		-|**ITIL管理实践**|(% style="width:722px" %)**与回顾相关的活动/资源**|(% style="width:77px" %)**影响**
452		-|持续改进|(% style="width:722px" %)定期或在完成时审查持续改进计划的活动和技术，以了解是否正在实现预期的成果。|(% style="width:77px" %)H
453		-|项目管理|(% style="width:722px" %)审查项目工作并汲取经验教训的活动和技术，可以使未来的类似项目受益。|(% style="width:77px" %)H
454		-|服务级别管理|(% style="width:722px" %)定期检查和修改服务水平（以了解如何改进）的活动和技术。|(% style="width:77px" %)H
455		-|软件开发管理|(% style="width:722px" %)定期审查工作以了解如何改进的活动和技术。|(% style="width:77px" %)H
456		-|变更控制|(% style="width:722px" %)定期审查进行变更的有效性和效率以了解如何改进的活动和技术（包括有关创建或暂停标准变更模型的决定）。|(% style="width:77px" %)M
457		-|事件管理|(% style="width:722px" %)定期或在重大事件后回顾事件管理工作的活动和技术，以了解如何改进。|(% style="width:77px" %)M
458		-|问题管理|(% style="width:722px" %)定期检查问题和错误控制以了解如何改进的活动和技术。|(% style="width:77px" %)M
459		-|关系管理|(% style="width:722px" %)定期审查与各种利益干系人之间现有关系的状态和方向的活动和技术。|(% style="width:77px" %)M
460		-|风险管理|(% style="width:722px" %)定期或在触发缓解措施后审查缓解风险的活动和技术，以了解如何提高风险。|(% style="width:77px" %)M
461		-|服务连续性管理|(% style="width:722px" %)从灾难恢复后，审查连续性计划的效率和有效性的活动和技术。|(% style="width:77px" %)M
462		-|服务台|(% style="width:722px" %)定期检查服务台交互的活动和技术，以了解如何改进。|(% style="width:77px" %)M
463		-|供应商管理|(% style="width:722px" %)定期审查与各种合作伙伴和供应商之间现有关系的状态和方向的活动和技巧。|(% style="width:77px" %)M
	405	+[[image:1641701094058-713.png]]
464	464
465	465	表4.7概述了与回顾相关的实践。
466	466
467	467
	410	+(% class="wikigeneratedid" %)
	411	+==== ====
	412	+
	413	+(% class="wikigeneratedid" %)
	414	+==== ====
	415	+
468	468	==== 4.2.3.2 免责的事后反思 ====
469	469
	418	+
470	470	数字化技术具有越来越重要的社会和经济后果，尤其是在HVIT环境中。因此，预防事故变得越来越重要。但是，复杂的系统具有固有的危险性：尽管付出了所有努力，但它们仍将失败。因此，从失效中学习也变得越来越重要。
471	471
472	472	事后检验是事件的正式记录，包括对事件的影响，解决/缓解工作，原因和防止再次发生的措施。当参与者能够分享自己的知识和选择而不必担心声誉和位置时，事后反思的质量会更好。这就是为什么重点关注事件的原因而不是谁引起了事件。这种免责的文化起源于医疗保健和航空业，那里生命受到威胁。免责事后反思与安全性文化和心理安全性密切相关（见第3.2.2.2节）。
...	...	@@ -493,6 +493,7 @@
493	493	图4.10 免责的事后反思对服务价值链的贡献的热图
494	494
495	495
	445	+
496	496	**ITIL的故事：评论**
497	497
498	498	//Marco：使用该应用程序可能会很艰苦，但是回顾会给我们带来好处。我们会定期分析完成的工作，以便了解可以在下一个冲刺中汲取的经验教训。这些是不责怪的事后反思：我们公开且诚实地讨论我们的工作，而不必担心事件的起因会分配给任何团队成员。//
...	...	@@ -500,31 +500,18 @@
500	500
501	501	表4.8 免责的时候反思的实践
502	502
503		-(% style="width:920px" %)
504		-|**ITIL管理实践**|(% style="width:701px" %)**与无指责相关的活动/资源**|(% style="width:80px" %)**影响**
505		-|变更控制|(% style="width:701px" %)调查成功和失败的变更，以发现机会，以提高未来变更的成功率。|(% style="width:80px" %)H
506		-|部署管理|(% style="width:701px" %)调查服务组件的成功和失败部署，以发现机会，以提高未来部署的成功率。|(% style="width:80px" %)H
507		-|事件管理|(% style="width:701px" %)调查事件管理（和重大事件管理）活动，以发现改进的机会。|(% style="width:80px" %)H
508		-|问题管理|(% style="width:701px" %)调整领导方式以检查系统而不是人员。事后回顾可以帮助组织获得有关事件情况的更多信息。这为问题识别和调查提供了更好的信息。|(% style="width:80px" %)H
509		-|项目管理|(% style="width:701px" %)调查项目活动，以吸取经验教训和改进未来项目的机会。|(% style="width:80px" %)H
510		-|发布管理|(% style="width:701px" %)调查服务的成功和失败版本，以发现提高未来版本成功率的机会。|(% style="width:80px" %)H
511		-|持续改进|(% style="width:701px" %)(((
512		-调查持续改进活动，以识别经验教训，了解系统中的变更以及确定增加或保持未来改进成
	453	+[[image:1641701145033-568.png]]
513	513
514		-功的机会。
515		-)))|(% style="width:80px" %)M
516		-|信息安全管理|(% style="width:701px" %)获取有关与安全漏洞和安全事件有关的情况的更多信息。|(% style="width:80px" %)M
517		-|风险管理|(% style="width:701px" %)触发风险缓解措施后，评估其风险，以了解如何改进缓解措施以及对当前和未来风险的应对措施。修改风险记录并探索可能的风险的新领域。|(% style="width:80px" %)M
518		-|服务台|(% style="width:701px" %)调查与外部利益干系人的互动，以发现改进互动和持续沟通的机会。|(% style="width:80px" %)M
519		-|服务验证与测试|(% style="width:701px" %)调查成功和失败的验证和测试活动，以发现提高未来成功率的机会。|(% style="width:80px" %)M
520		-|软件开发管理|(% style="width:701px" %)(((
521		-从回顾中获取经验教训和改进思路。
522	522
523		-让合作伙伴和供应商收集反馈以进行学习注册。
524		-)))|(% style="width:80px" %)M
	456	+(% class="wikigeneratedid" %)
	457	+=== ===
525	525
	459	+(% class="wikigeneratedid" %)
	460	+=== ===
	461	+
526	526	=== 4.2.4 持续业务分析 ===
527	527
	464	+
528	528	瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
529	529
530	530	做出投资决定后，至关重要的是要验证对产品或服务规范、特性和功能所做的任何初始假设。一些供应商忽略了与真实用户尽快进行交互的需要，而是在向客户和用户展示其解决方案之前在开发上花费了几个月甚至几年的时间。通常，采用这种方法时，产品或服务的某些功能是不必要的，某些功能需要进行重大调整，而其他有价值的功能却会丢失。但是，组织的资源和时间已经用完，营销机会正在减少。
...	...	@@ -538,6 +538,7 @@
538	538	图4.11通过迭代方法更快地实现价值
539	539
540	540
	478	+
541	541	过去，需求总是在项目开始时在利益干系人和被分配了临时的、基于项目的任务的业务分析人员之间的正式讨论中定义的。这些要求将成为发展活动的规范。
542	542
543	543	但是，越来越多地基于反馈来开发和改进产品。反馈可以由用户报告或间接观察。需求分析和说明是持续进行的。业务分析通常不再由专门的业务分析人员执行；它是可以与其他角色组合使用的角色。使用这种方法时，由于已经建立了产品架构，因此进一步的开发可能具有挑战性。因此，开发之前的分析应考虑这些未来的问题，并创建一个灵活的架构。开发之后的分析与开发之前的分析不同之处在于，开发后的分析较少关注于创建架构，而更关注于在系统的体系结构约束下有效地工作。
...	...	@@ -545,6 +545,7 @@
545	545	图4.12显示了持续业务分析对服务价值链的贡献。表4.9概述了与持续业务分析相关的实践。
546	546
547	547
	486	+
548	548	**ITIL故事：持续业务分析**
549	549
550	550	//Radhika：ITIL 指导原则对业务中的每个团队都有用。例如，聚焦价值原则可恰好适合业务分析。环境不断变化，开发中的功能优先级可能会变得更高或更低，这取决于价值如何受到影响。例如，影响应用程序使用或数据存储的新法规将自动成为高度优先事项。//
...	...	@@ -556,26 +556,20 @@
556	556	图4.12 持续业务分析对服务价值链贡献的热图
557	557
558	558
	498	+
559	559	表4.9 与持续业务分析相关的实践
560	560
561		-(% style="width:900px" %)
562		-|**ITIL管理实践**|(% style="width:682px" %)**与持续业务分析相关的活动/资源**|(% style="width:96px" %)**影响**
563		-|业务分析|(% style="width:682px" %)持续了解分析客户、市场状况和更广泛的生态系统，以了解他们对组织产品和服务的影响。|(% style="width:96px" %)M
564		-|基础架构管理|(% style="width:682px" %)持续了解分析客户、状况和更广泛的生态系统，以了解他们对组织的基础架构和平台产品的影响。|(% style="width:96px" %)M
565		-|组合管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织投资各种产品和服务的方式的影响。监控正在进行的组合投资，以识别价值或验证价值共创。|(% style="width:96px" %)M
566		-|项目管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统了解它们对组织项目和相关业务案例的影响。|(% style="width:96px" %)M
567		-|关系管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织与外部利益干系人关系的影响。|(% style="width:96px" %)M
568		-|风险管理|(% style="width:682px" %)持续分析内部和外部公司风险，以评估和了解其对组织产品和服务的影响，并设计适当的缓解措施和对策。|(% style="width:96px" %)M
569		-|服务设计|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解其对客户和用户体验组织产品和服务的影响。|(% style="width:96px" %)M
570		-|软件开发管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织软件产品的影响以及正在进行的软件开发工作的优先级。|(% style="width:96px" %)M
571		-|战略管理|(% style="width:682px" %)持续监视和评估客户，市场状况以及更广泛的生态系统，以了解其对组织产品和服务的影响，并相应地调整策略。|(% style="width:96px" %)M
572		-|架构管理|(% style="width:682px" %)持续分析组织内部和外部利益干系人对技术的使用，以了解其对组织的技术，服务和信息体系结构的影响。|(% style="width:96px" %)M
573		-|知识管理|(% style="width:682px" %)不断了解分析客户，市场状况和更广泛的生态系统，以在相关利益干系人之间建立共识。|(% style="width:96px" %)M
574		-|服务连续性管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，它们对组织的连续性和灾难恢复措施的影响。|(% style="width:96px" %)M
575		-|供应商管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以它们对组织与合作伙伴和供应商关系的影响。|(% style="width:96px" %)M
	501	+[[image:1641701202590-318.png]]
576	576
	503	+[[image:1641701238590-838.png]]
	504	+
	505	+
	506	+(% class="wikigeneratedid" %)
	507	+=== ===
	508	+
577	577	=== 4.2.5 持续集成、持续交付和持续部署 ===
578	578
	511	+
579	579	持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
580	580
581	581
...	...	@@ -610,20 +610,7 @@
610	610
611	611	表4.10 与CI/CD最相关的实践
612	612
613		-(% style="width:852px" %)
614		-|**ITIL管理实践**|(% style="width:651px" %)**与CI/CD最相关相关的活动/资源**|(% style="width:84px" %)**影响**
615		-|变更控制|(% style="width:651px" %)可以根据业务需求和期望，使用CI / CD管道来调整组织产品和服务的变化率。|(% style="width:84px" %)H
616		-|部署管理|(% style="width:651px" %)系统地/自动地将特定版本的软件或软件包安装到预定的环境（集成，用户验收测试，生产）。|(% style="width:84px" %)H
617		-|基础机构管理|(% style="width:651px" %)将CI / CD技术用于数字基础架构。|(% style="width:84px" %)H
618		-|发布管理|(% style="width:651px" %)认识到软件的部署和功能的发布通常是有助于计划和管理发布的不同活动。|(% style="width:84px" %)H
619		-|服务配置管理|(% style="width:651px" %)管理代码存储库和构成CI / CD工具链一部分的相关工具，并不断更新CMDB以反映进行了重大（CI级别）变更的时间。|(% style="width:84px" %)H
620		-|服务验证与测试|(% style="width:651px" %)开发自动化测试用例以支持持续的集成活动。|(% style="width:84px" %)H
621		-|软件开发管理|(% style="width:651px" %)使用用于应用程序软件的CI / CD技术。|(% style="width:84px" %)H
622		-|架构管理|(% style="width:651px" %)设计和改进服务，技术和信息体系结构以利用CI / CD功能。容器化是支持CI / CD的体系结构选择。|(% style="width:84px" %)M
623		-|信息安全管理|(% style="width:651px" %)通过减少手工工作来确保遵守信息安全合规。通过利用CI / CD工具来增加自动化的规模和范围，可以通过减少手工工作并改进变更的可追溯性来帮助确保遵守信息安全合规。|(% style="width:84px" %)M
624		-|知识管理|(% style="width:651px" %)不断更新知识库，以确保组织保持对通过CI / CD管道构建和部署的软件的最新了解。|(% style="width:84px" %)M
625		-|服务连续性管理|(% style="width:651px" %)应该建立CI / CD管道以将软件组件推向连续性和灾难恢复系统。|(% style="width:84px" %)M
626		-|风险管理|(% style="width:651px" %)通过使用CI / CD自动化减少某些类型的企业风险的影响。|(% style="width:84px" %)L
	546	+[[image:1641701293452-859.png]]
627	627
628	628
629	629	**ITIL故事：持续集成、持续交付和持续部署**
...	...	@@ -631,41 +631,20 @@
631	631	//Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。//
632	632
633	633
	554	+
634	634	=== 4.2.6 持续测试 ===
635	635
	557	+
636	636	软件测试不仅涉及测试已开发的和可运行的软件。测试是应该在整个软件开发生命周期中进行的工作。表4.11概述了不同类型的测试。
637	637
638	638
639	639	表4.11 软件测试的类型
640	640
641		-(% style="width:813px" %)
642		-|(% style="width:165px" %)测试思路|(% style="width:646px" %)所有软件都源于一个想法，通常是试图解决问题的尝试。 测试该想法有助于从客户角度（基于需求和需求）和业务角度（基于指标，包括增长，收入，转化和用户基础）确定其质量。
643		-|(% style="width:165px" %)测试原型|(% style="width:646px" %)原型，例如史诗，用户故事，验收标准，数据流程图和过程流程图，应进行测试。 检查原型内的信息可以帮助识别与风险和变量有关的歧义，假设和信息。 该信息可用作反馈，以帮助审查和改进伪像。
644		-|(% style="width:165px" %)测试用户体验和用户界面设计|(% style="width:646px" %)原型用于设计活动，编程活动和测试活动。 设计活动产生的设计原型超出了可以测试的范围。 使用相关的原型对界面和体验进行了测试，并且测试结果可能会影响其他原型。
645		-|(% style="width:165px" %)测试架构和代码设计|(% style="width:646px" %)在设计软件体系结构并讨论如何构建它和新功能时，探索性测试可以增强设计和思想。
646		-|(% style="width:165px" %)代码测试|(% style="width:646px" %)代码审查是构建高质量产品的重要组成部分。任何人都应该能够阅读该代码并从不同的角度对其进行测试。单元测试可验证软件的每个单元是否都能正常运行。单元测试通常是自动化的。重要的是要注意，这是软件开发生命周期中的第一点，应该有针对性地加以衡量。
647		-|(% style="width:165px" %)测试操作软件|(% style="width:646px" %)测试操作软件是与测试相关的最常见的活动。开发后，许多敏捷团队都将“测试”作为其工作流中的一种状态。但是，测试不应该成为工作流程中的一种状态。它应该是在软件开发生命周期中进行的一系列结构化活动。
648		-|(% style="width:165px" %)在不同环境测试|(% style="width:646px" %)当涉及测试环境时，基于风险的方法可能是合适的。有很多风险可以测试。其中一些无法在开发环境中进行测试。对于其他人，则需要严格集成的环境来进行测试。某些风险只能在实际生产环境中进行测试。
649		-|(% style="width:165px" %)测试发布管道|(% style="width:646px" %)可以测试管道流程，团队通常会隐式地进行测试，以使其管道尽可能高效和快速地进行增强。这需要对管道测试背后的结构有充分的了解。
650		-|(% style="width:165px" %)生产环境下测试|(% style="width:646px" %)(((
651		-必须在生产环境中对某些风险进行测试，例如性能风险（尤其是用户负载和用户压力风险），用户接受度测试（用户将其与实际软件一样使用系统）和可观察性风险（以测试有效性、可观察性解决方案和实现）。
	563	+[[image:1641701417790-550.png]]
652	652
653		-在生产中进行测试时，目标应该是最大程度地降低影响客户的测试风险。实现这一目标的策略包括：
	565	+[[image:1641701444463-764.png]]
654	654
655		-● **金丝雀发布 **这项新功能最初是针对少数目标用户发布的，后来逐渐增加到所有用户。
656	656
657		-●** 功能开关** 可以将功能隐藏在功能标志的后面，通过打开或关闭该标志可以轻松启用或禁用
658		-
659		-该功能。
660		-
661		-● **蓝/绿部署 **两个相同的生产环境同时运行（一个“蓝色”和一个“绿色”），只有一个环
662		-
663		-境处于活动状态，为所有生产流量提供服务，而另一个用于部署新版本。
664		-
665		-● **自动化的回滚策略 **发生事件时，自动化工具可以快速将发行版恢复为先前版本。
666		-)))
667		-|(% style="width:165px" %)测试生产环境中的服务|(% style="width:646px" %)为已发布的生产软件实现了许多服务，活动和技术，所有这些都可以进行测试。从服务交付的角度来看，测试流程很重要。 例如，在测试用户是否可以访问支持时，重要的是要问用户获得支持有多容易，用户在软件中在什么情况下做到这一点。
668		-
669	669	为了实现持续测试，应制定一些原则，包括：
670	670
671	671	* 测试应该以最低级别进行。
...	...	@@ -684,4 +684,778 @@
684	684	(% style="text-align:center" %)
685	685	[[image:1639234708265-714.png]]
686	686
687		-
	586	+
	587	+图4.14 持续测试对服务价值链贡献的热图
	588	+
	589	+
	590	+表4.12 与持续测试最相关的实践
	591	+
	592	+[[image:1641701509520-551.png]]
	593	+
	594	+
	595	+**ITIL的故事：持续测试**
	596	+
	597	+//Su：我们投放市场的每个产品都经过全面测试，以确保它是符合目 的并适合使用。应用程序的改进没有什么不同。我们测试了//：
	598	+
	599	+●     新功能的初步构想，以确保它们有潜力实现我们的目标
	600	+
	601	+●     史诗、用户故事和接受标准
	602	+
	603	+●     设计界面的改进，以确保它直观且易用
	604	+
	605	+●     代码设计和软件架构，以确保其健壮性
	606	+
	607	+●     修复开发期间引入的错误和故障的代码
	608	+
	609	+●     生产中的系统和软件
	610	+
	611	+//在每个阶段，如果测试表明我们引入了明显的低效或缺陷，我们就会重新考虑以前的决定。//
	612	+
	613	+
	614	+
	615	+
	616	+=== 4.2.7 看板 ===
	617	+
	618	+
	619	+看板是一套原则、实践和常规活动，旨在开发和管理可预测的，有节奏的，持续的工作流程。如果正确应用，它可以极大地加速高质量产品和服务的开发。拉动式触发机制使客户能够通过价值流进行工作。拉动式的工作具有不会被强加于人的优点，从而不必要地增加了工作负担。这在精益团队中很有价值，因为过载是浪费的一种形式。
	620	+
	621	+
	622	+**定义：看板**
	623	+
	624	+一种基于高度可视化基于拉动的工作流程的精益方法，该工作流程通过平衡需求与可用的容量并改进对系统级别瓶颈的处理，来管理和改进整个人系统的工作。
	625	+
	626	+看板的主要做法是：
	627	+
	628	+* 可视化工作
	629	+* 限制进行中的工作
	630	+* 管理流程
	631	+* 明确制定流程政策
	632	+* 实施反馈循环
	633	+* 改进协作
	634	+* 实验性地发展。
	635	+
	636	+有时组织仅使用看板来可视化进行中的工作。尽管使用看板很重要，但这是看板的有限应用。看板的功能取决于整体实施和对工作流程的持续关注。看板示例如图4.15所示。
	637	+
	638	+(% style="text-align:center" %)
	639	+[[image:1639568393888-457.png]]
	640	+
	641	+图4.15 看板的一个例子
	642	+
	643	+
	644	+看板建议定期召开会议，以确保有效的沟通。该系统通常被称为“ 看板节奏”。节奏的频率特定于组织，应根据情况进行定义和调整。会议是：
	645	+
	646	+* 战略评审
	647	+* 运营评审
	648	+* 风险评审
	649	+* 服务交付评审
	650	+* 补充会议
	651	+* 交付规划会议。
	652	+
	653	+图4.16显示了看板对服务价值链的贡献。表4.13概述了与看板相关的实践。
	654	+
	655	+
	656	+
	657	+**ITIL故事：看板**
	658	+
	659	+//Radhika：我们使用看板来可视化我们应用程序的工作流程，以便我们可以跟踪瓶颈。通常可以通过额外的资源或重新设计工作流来消除这些问题。看板的视觉特性使核心开发团队之外的同事和利益干系人能够了解工作的进展情况，从而使他们能够更好地计划并创建更多价值。//
	660	+
	661	+
	662	+(% style="text-align:center" %)
	663	+[[image:1639568494739-564.png]]
	664	+
	665	+图4.16 看板对服务价值链贡献的热图
	666	+
	667	+
	668	+表4.13 与看板相关的实践
	669	+
	670	+[[image:1641701559766-478.png]]
	671	+
	672	+
	673	+(% class="wikigeneratedid" %)
	674	+== ==
	675	+
	676	+(% class="wikigeneratedid" %)
	677	+== ==
	678	+
	679	+== 4.3 弹性运营的技术 ==
	680	+
	681	+
	682	+弹性运营目标涉及确保在需要时可以使用数字化产品。
	683	+
	684	+数字投资的潜在价值仅当投入使用的数字化产品和服务可用时才能实现。满足非功能性要求提供了功效，并降低了问题将严重影响产品和服务的功用的风险。
	685	+
	686	+信息系统越来越依赖于如此众多的组件，以至于行为通常无法被预测或保证。故障安全系统是一种幻想。组织必须为不可避免的和意外的失效做准备。重点不再是在失效之间保持较长的间隔；当不可避免的问题确实发生时，它可以快速恢复服务。这样可以减少对业务运营的干扰。
	687	+
	688	+弹性适用于系统堆栈的所有部分，也适用于管理这些组件部分的组织。只有每个组件都具有弹性时，面向消费者的部件才具有弹性。弹性运营不会增加潜在的价值投资；相反，他们确保可以实现其潜在的价值。由于信息系统很复杂，因此本质上容易出错，因此弹性涉及损害限制。根据系统的性质，损害可以用收入损失、价格降低，产生的成本和声誉损害来表示。例如，当电子商务网站的可用性或性能较差时：
	689	+
	690	+* 如果客户转向其他提供商，收入将会损失
	691	+* 客户满意度降低而产生价格降低的压力
	692	+* 恢复服务，实施规避措施以及与消费者进行沟通会产生成本
	693	+* 当提供者不能很好地处理事件时，会造成声誉损害；例如，不采取适当的行动，不关心，隐瞒信息或不从事件中汲取教训。
	694	+
	695	+IT的消费化导致人们期望随时随地可以使用公司的IT系统。云服务能力可以极大地改进弹性，而云功能的成本仅为本地系统的一小部分。弹性系统和服务不再是一种选择，由于云和IT的消费化，它们已成为现实的期望。
	696	+
	697	+根据可用性、性能和安全性来衡量弹性操作。可用性是两次失效之间的平均时间和恢复服务的平均时间以百分比规范。众所周知，可用性不可靠，不能说明可用性对服务使用者的影响。这也很难衡量；例如，当系统部分可用时。
	698	+
	699	+绩效的测量方法多种多样。例如，网页加载时间、数据查询执行时间或批处理流程完成时间。可以根据安全漏洞来衡量安全，但这仅衡量已检测到的漏洞。更好的指标是控制监控的成熟度，以及分析日志信息以识别风险和漏洞的能力。
	700	+
	701	+可用于实现弹性运营的技术包括：
	702	+
	703	+* 技术债
	704	+* 混沌工程
	705	+* 完成的定义
	706	+* 版本控制
	707	+* 人工智能运营
	708	+* 聊天运营
	709	+* 站点可靠性工程。
	710	+
	711	+**ITIL故事：弹性运营的技术**
	712	+
	713	+//亨利：我们的应用程序必须可靠且一致，否则我们的客户将其视为有缺陷的。如果他们的工作方式需要变更，我们还需要确保我们的团队有应变能力并且可以适应不同的条件。//
	714	+
	715	+
	716	+(% class="wikigeneratedid" %)
	717	+=== ===
	718	+
	719	+=== 4.3.1 技术债 ===
	720	+
	721	+
	722	+**定义：技术债**
	723	+
	724	+通过选择规避措施而不是需要更长时间的系统解决方案来累积待办项的返工。
	725	+
	726	+在软件开发和管理中，技术债是修复不合格（变更）软件所需的返工待办项。通常，当使用软件时，将进行增强和修复。应用这些变更后，除非努力限制损坏，否则软件的质量将会下降。这被称为“软件熵”，它与HVIT密切相关，因为在软件上的大量投资，变更的频率以及需要变更迅速跟上市场需求的需求。
	727	+
	728	+技术债是待办的工作，用于解决在增强或修复软件时引起的损坏。这种损坏通常是由于时间、金钱、知识和技能有限所造成的。例如，在软件出现故障时承受恢复正常服务压力的组织可以应用简单的规避措施来快速解决问题。通常有意在以后对其进行正确修复，但是在许多情况下，这不会发生。预期的“正确修复”可能未正式记录，随后将被遗忘。
	729	+
	730	+技术债也可以在应用程序的初始开发期间发生，在此之前，期限或预算限制导致出现捷径。几乎每个项目都有其遗产，这有时使其捐助者感到惊讶。
	731	+
	732	+技术利益是指由于质量下降而使变更难以进行的软件应用变更所涉及的成本之和，以及由这些缺陷引起的事件成本。只要利息不高，技术债就是可以接受的。但是，它倾向于积累，并且债务越高，涉及的风险就越大。此风险必须加以管理。
	733	+
	734	+减少技术债可以减少事件的发生，因此有助于弹性运营。它还有助于有价值的投资和快速研发。这些收益之间应保持平衡。因此，应谨慎考虑技术债的存在，尽可能对其进行鉴定和量化，评估相关的短期和长期风险，并作为（软件）产品管理的一部分做出适当的决定，包括将预算分配给“偿还技术债“（另请参阅第4.3.7节中的错误预算的概念）。
	735	+
	736	+图4.17显示了技术债对服务价值链的贡献。
	737	+
	738	+(% style="text-align:center" %)
	739	+[[image:1639568670048-316.png]]
	740	+
	741	+
	742	+图4.17 技术债对服务价值链贡献的热图
	743	+
	744	+
	745	+
	746	+表4.14概述了与技术债相关的实践。
	747	+
	748	+[[image:1641701689758-164.png]]
	749	+
	750	+表4.14 与技术债相关的实践
	751	+
	752	+
	753	+
	754	+**ITIL故事：技术债**
	755	+
	756	+//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
	757	+
	758	+//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
	759	+
	760	+
	761	+
	762	+=== 4.3.2 混沌工程 ===
	763	+
	764	+
	765	+**定义：混沌工程**
	766	+
	767	+为了建立对系统承受生产中动荡环境能力的信心而在系统上进行实验的学科。
	768	+
	769	+为了解决分布式系统的不确定性，混沌工程依靠四个基本步骤：
	770	+
	771	+* 定义稳态；这将是普通行为的输出。
	772	+* 假设这种稳定状态将持续下去。
	773	+* 引入反映真实事态的变量。
	774	+* 尝试反驳这个假设。
	775	+
	776	+混沌工程理想应用的原则是：
	777	+
	778	+* **围绕稳态行为进行构建和假设 **关注于可测量的系统输出，而不是系统的属性。
	779	+* **变化的真实世界事态 **混沌变量反映真实世界的事态。必须通过考虑事态的影响或估计频率来定义优先级。
	780	+* **在生产中进行实验 **混沌倾向于直接对生产流量进行实验。
	781	+* **使实验自动化以连续运行 **将自动化构建到系统中以推动业务流程和分析。
	782	+* **最小化爆炸半径 **应该最小化并控制实验的后果。
	783	+
	784	+混沌工程的一些优点是：
	785	+
	786	+* 为团队为随机实例失效做好准备
	787	+* 鼓励冗余
	788	+* 使系统更强大，从而增强了在复杂系统中快速移动的信心
	789	+* 将现实条件引入受控运行中，在弱点引起问题之前就将其发现
	790	+* 在影响生产中的客户之前，主动解决最重要的弱点。
	791	+
	792	+混沌猴子是所谓的猿猴军团中最著名的混沌工程工具集之一。猿猴军团是由Netflix®创建的开源云测试工具的集合。混沌猴子通过禁用某些组件来测试对系统失效的响应，以查看其余系统将如何响应。尽管混沌猴子可能会中断运营，但也有助于它们的长期恢复能力。
	793	+
	794	+
	795	+**定义：混沌猴子**
	796	+
	797	+通过有意地禁用生产中的组件来测试其余系统如何响应中断的方式来测试IT系统的弹性的工具。
	798	+
	799	+混沌猴子的部署导致在已识别的系统组中随机选择的系统终止。这会产生接近自然事件的情况，并测试系统承受失效的能力。猿猴军团的另一个成员，合规性猴子，检查每项服务，以实现架构定义的最佳实践。
	800	+
	801	+猿猴军团的其他成员包括：
	802	+
	803	+* **延迟猴子 **导致人为延迟，以模拟服务降级并检查相关服务是否充分响应。
	804	+* **猴子医生 **进行健康检查以确定不健康的实例，如果所有者不修复根因，则主动将其关闭。
	805	+* **安全猴子 **查找并终止安全违规或漏洞的实例。
	806	+* **看门猴子 **确保云环境没有混乱和浪费。图4.18显示了混沌工程对服务价值链的贡献。表4.15概述了与混沌工程相关的实践。
	807	+
	808	+(% style="text-align:center" %)
	809	+[[image:1639568794032-283.png]]
	810	+
	811	+图4.18 混沌工程对服务价值链贡献的热图
	812	+
	813	+
	814	+表4.15 与混沌工程相关的实践
	815	+
	816	+[[image:1641702469032-780.png]]
	817	+
	818	+[[image:1641702487237-876.png]]
	819	+
	820	+
	821	+ITIL故事：混沌工程
	822	+
	823	+//Radhika：我们需要测试该应用程序的弹性。例如，如果成员资格功能停止工作会怎样？客户仍然可以预定汽车？预订是否仍可以追溯分配到他们的账户？//
	824	+
	825	+//Solmaz：我们使用了混沌猴子工具来了解该应用在胁迫下的工作方式。它使我们能够看到系统可能在哪里崩溃，这意味着我们可以修改代码和软件体系结构以减少或消除薄弱环节。//
	826	+
	827	+
	828	+
	829	+=== 4.3.3 完成的定义 ===
	830	+
	831	+
	832	+**完成的定义**
	833	+
	834	+拟议产品或服务的商定标准清单。
	835	+
	836	+应用程序开发人员通常使用敏捷方法“ 完成的定义”。敏捷社区将“完成”定义为“已经产生了可能发布的软件增量”。在DevOps圈子中，此功能已扩展为“已发布到生产环境”。从端到端的角度来看，这种急需的扩展仍然不足。如果用户使用不当，错误地解释数据，做出次优决策或无法做出好的决定，则释放所需的功能将无用。专注于IT部门的职能可能不是阻止它的责任，而是组织的责任。
	837	+
	838	+因此，对完成的更完整的定义包括操作和使用标准。该技术广泛适用，并且在HVIT环境中经常遇到。
	839	+
	840	+完成的定义描述了有助于产品或服务实用程序的功用标准，以及有助于其修复的非功效标准。应定义这些非功能性标准并与负责操作的人达成一致。因此，包含非功能性标准的完成定义有助于弹性运营，并通过提高可用性共创价值共创，也有助于加快研发速度，因为需要的返工较少。
	841	+
	842	+非功能性标准指定了将要操作，维护和增强系统的人员以及将确保安全和法规合规性的人员所需的质量。这些标准解决了执行和演进所需的质量。功能性标准描述“是什么”，而非功能性标准描述“如何”。完成的定义中指定了质量属性，以便开发和支持团队可以在早期阶段考虑它们。对于开发来说，它们是软件设计约束。
	843	+
	844	+在敏捷软件开发中，“完成”通常意味着具有潜在可部署的软件增量。DevOps将此定义扩展为三类：已部署、已发布和可使用。从共同构服务的角度来看，将工作定义为“完成”的更好方法是用户从其投资中获得期望的成果。不管选择哪种方法，完成的定义都应该是整体的，并着重于价值。
	845	+
	846	+创建完成的定义时应考虑以下方面：
	847	+
	848	+* **应准备好使用环境 **应当验证连续集成框架并使其正常工作。
	849	+* **支持的交付内容应完整 **且接受所有标准、用户故事和测试。
	850	+* **应该有可用的度量标准 **每个发布以验证其满足用户故事和标准（在敏捷世界中被称为“故事点”）非常重要。
	851	+* **代码必须易于理解，可维护并且可以支持将来的变更。**
	852	+
	853	+考虑就绪定义也很有用，它描述了何时可以处理待办项。首字母缩略词“ INVEST”代表有用的标准。项目应为：
	854	+
	855	+* **独立 **自包含，不依赖于其他待办项。
	856	+* **可协商 **进行讨论和微调。
	857	+* **有价值 **关于利益干系人将如何受益的问题应该有明确的说明。
	858	+* **可估计 **范围足以接受可接受的近似值。
	859	+* **足够小 **足以估计并计划到一个时间表中。
	860	+* **可测试 **具有明确的验收标准。
	861	+
	862	+ 弹性测试可验证系统在不同领域是否满足约定的非功能性标准，例如可用性、容量、效率、可维护性、性能、隐私、可靠性、可恢复性和安全性。
	863	+
	864	+ 图4.19显示了完成定义对服务价值链的贡献。表4.16概述了完成定义相关的实践。
	865	+
	866	+
	867	+(% style="text-align:center" %)
	868	+[[image:1639568893041-234.png]]
	869	+
	870	+图4.19 完成定义对服务价值链贡献的热图
	871	+
	872	+
	873	+表4.16 与“完成”定义相关的实践
	874	+
	875	+[[image:1641702547499-544.png]]
	876	+
	877	+[[image:1641702577206-162.png]]
	878	+
	879	+
	880	+**ITIL故事：完成定义**
	881	+
	882	+//Su：该应用程序的交付团队包括来自Alxe汽车租赁部门许多部门人员，当开发人员移交工作代码时，对完成传统定义并不是最有效或最准确的。我们要保证该应用程序的弹性、功效、可维护性、功用和可用性。对我们来说，“完成“是指：//
	883	+
	884	+//●     生产和测试环境已准备就绪//
	885	+
	886	+//●     准备了持续集成框架//
	887	+
	888	+//●     用户故事和测试已得到认可//
	889	+
	890	+//●     度量和指标已被接受并且可以进行测试//
	891	+
	892	+//●     该软件具有可读性、可用性和适应性//
	893	+
	894	+
	895	+
	896	+=== 4.3.4 版本控制 ===
	897	+
	898	+
	899	+**定义：版本控制**
	900	+
	901	+信息系统、产品和服务的来源和人工制品的管理。
	902	+
	903	+版本控制与HVIT特别相关，因为已经在好的版本控制和高IT性能之间建立了强大的关联：它提供了更早的变更前置时间、更频繁的部署以及更快地平均恢复服务时间。
	904	+
	905	+版本控制跟踪在哪些环境中存在哪些版本的源和人工制品。在版本控制系统中存储软件源代码的通用实践扩展为包括IT系统、产品或服务的几乎所有其他重要组件，例如：
	906	+
	907	+* 为每个环境创建和配置基础的脚本，包括开发、测试和生产环境
	908	+* 验收标准、测试用例和测试本身
	909	+* 外部和内部库、模块和组件
	910	+* 有关相互依赖性的信息
	911	+* 部署管道的脚本和配置文件
	912	+* 运行任务的脚本，例如重复操作
	913	+* 文档，包括架构决策
	914	+* 构建和运行系统所需的制品
	915	+* 合同，协议等。
	916	+
	917	+因此，版本控制不仅适用于服务组件（在获取或构建价值链活动中开发/设计和管理），而且还适用于服务级别。适当的版本控制可以收集有关产品或服务所需的每个组件的当前和以前状态的有价值的信息。该信息包括变更的初始状态、变更、变更时间和日期、操作变更的人员以及任何其他澄清和支持信息。版本控制的优点包括：
	918	+
	919	+* 版本控制支持基础架构即代码技术（请参阅第4.2.1节）。
	920	+* 版本控制应用于源代码和产品，可以缩短变更的前置时间、更频繁的部署以及更快的平均恢复服务时间。
	921	+* 版本控制支持的自动化测试与更快的变更前置时间相关。
	922	+* 版本控制是持续交付的前提条件，而持续交付与更频繁的部署相关。
	923	+
	924	+因此，版本控制有助于弹性运营和快速研发。也可以将其视为用于架构的促进因素：一种实践，其中的架构决策不受限制，而是使产品和服务能够持续发展和实现改进点，而无需重新设计和重新开发先前的解决方案。
	925	+
	926	+图4.20显示了版本控制对服务价值链的贡献。表4.17概述了与版本控制相关的实践。
	927	+
	928	+(% style="text-align:center" %)
	929	+[[image:1639568991350-151.png]]
	930	+
	931	+图4.20 版本控制对服务价值链贡献的热图
	932	+
	933	+
	934	+表4.17 与版本控制相关的实践
	935	+
	936	+[[image:1641702628320-774.png]]
	937	+
	938	+
	939	+**ITIL故事：版本控制**
	940	+
	941	+//Marco：我们实行持续集成和持续交付，我们利用版本控制系统地记录我们发布的应用程序的每次迭代，如果发布不稳定，我们可以通过将服务返回到先前的稳定版本来快速还原该服务。//
	942	+
	943	+
	944	+
	945	+=== 4.3.5 人工智能运营 ===
	946	+
	947	+
	948	+**定义：AIOps**
	949	+
	950	+将机器学习和大数据应用于IT运营以获取持续的见解，并通过自动化提供持续的修复和改进。也称为“IT运营的人工智能“或”算法IT运营“。
	951	+
	952	+AIOps旨在将人工智能引入IT运营，以应对基础架构持续发展中的现代趋势所带来的挑战，例如软件定义系统的增长。这些新技术的影响（例如，基础设施的重新配置和重塑速率的增加）需要更自动化和动态的管理技术，这些技术可能在组织的数字化服务上具有重要的影响。
	953	+
	954	+AIOps平台用于增强和部分替代许多主要的IT运营功能，例如可用性和性能监控、失效识别、预测分析以及事态相关性和分析。
	955	+
	956	+AIOps利用数据平台和机器学习，收集观察数据（例如事态、日志文件、运营指标）和参与数据（例如客户请求和服务台票证），并通过对该数据应用认知或算法处理得出见解。
	957	+
	958	+这些见解可用于驱动一些或全部范围的通用输出，例如：
	959	+
	960	+* **问题检测和预测 **帮助服务组织更快地对事件做出响应。
	961	+* **主动的系统维护和调整 **减少了人工和潜在错误。
	962	+* **阈值分析 **可以更准确地了解系统的正常运行范围。
	963	+
	964	+AIOps的应用在很大程度上取决于要分析的数据的可用性，以及数据是否适合进行分析，如果其性质极其复杂，原因和影响之间的相关性较弱，则可能不会。
	965	+
	966	+一些组织还开始在IT运营以外使用AIOps，以使业务管理人员实时了解IT对业务的影响。这样可以使他们随时了解情况，并使他们能够基于实时的相关数据做出决策。
	967	+
	968	+图4.21显示了AIOps对服务价值链的贡献。表4.18概述了与AIOps相关的实践。
	969	+
	970	+(% style="text-align:center" %)
	971	+[[image:1639569057821-522.png]]
	972	+
	973	+图4.21 AIOps对服务价值链贡献的热图
	974	+
	975	+
	976	+表4.18 与AIOps相关的实践
	977	+
	978	+[[image:1641702718413-352.png]]
	979	+
	980	+
	981	+**ITIL故事：AIOps**
	982	+
	983	+Radhika：：成千上万的客户使用该应用程序并租用我们的车辆。这些转换会产生大量数据，这是有关客户需求的丰富信息来源。
	984	+
	985	+Su：我们创建了脚本来分析数据，查找使用模式并优化服务的基础架构。例如，如果数据表明电动汽车的用户正在达到电池充电的终点，则脚本会自动突出显示提示，说明如何为电池充电，以及最近的充电设施的地图。
	986	+
	987	+
	988	+
	989	+=== 4.3.6 聊天运营 ===
	990	+
	991	+
	992	+ChatOps是一个模型，其中人员、工具、流程和自动化都连接在透明的流程中。该模型有助于控制管道和协作。它是即时通信与运营执行的紧密结合：这是一个新兴的运动，促进了多个团队、工具和DevOps平台的集成。通过将工具和平台进行对话来驱动开发。当机器人是团队成员时，可以向他们发送请求并获得即时响应。
	993	+
	994	+ChatOps支持人与工具之间的协作通信，通过消除对重复信息的请求并自动执行一些常规的IT运维操作来减少事件响应时间。
	995	+
	996	+ChatOps的元素包括：
	997	+
	998	+* **聊天平台 **连接利益干系人，团队及其工作系统的服务。
	999	+* **Bots ** ChatOps模型的核心。Bot存在并且可以在协作工具和DevOps工具之间工作。他们接收团队成员的请求，然后通过执行脚本从集成系统中检索信息。
	1000	+* **集成和自动化服务 **ChatOps中的第三方元素。例如，用于问题跟踪：版本控制系统、基础架构即代码、持续集成服务器或监控工具。
	1001	+
	1002	+这款模型变得越来越受欢迎。组织将其聊天平台连接到其构建系统，以便在其持续集成服务器上接收通知并执行和查询过程。相同的模型可以应用于质量保证团队。ChatOps工作流程考虑：
	1003	+
	1004	+* 工作需要
	1005	+* 工作进行中
	1006	+* 工作完成。
	1007	+
	1008	+模型可以促进反馈，改进沟通和交叉培训并增强团队协作。在“聊天”中，人们进行协作和创新，从而推动进步。通过收集知识并确定按计划或预期提供服务的要求，ChatOps使工作人性化。
	1009	+
	1010	+ 这类工具强调了在工具、运营团队和消息传递工具之间需要即时协作。ChatOps是传统聊天的发展，因为它使系统能够加入对话。例如，DevOps或IT和服务管理工具可以将事件或事态通知支持小组。
	1011	+
	1012	+ 图4.22显示了ChatOps对服务价值链的贡献。表4.19概述了与ChatOps相关的实践。
	1013	+
	1014	+(% style="text-align:center" %)
	1015	+[[image:1639569157526-866.png]]
	1016	+
	1017	+图4.22 ChatOps对服务价值链贡献的热图
	1018	+
	1019	+
	1020	+表4.19 与ChatOps相关的实践
	1021	+
	1022	+[[image:1641702752724-340.png]]
	1023	+
	1024	+
	1025	+(% class="wikigeneratedid" %)
	1026	+=== ===
	1027	+
	1028	+(% class="wikigeneratedid" %)
	1029	+=== ===
	1030	+
	1031	+=== 4.3.7 站点可靠性工程 ===
	1032	+
	1033	+
	1034	+**定义：站点可靠性工程**
	1035	+
	1036	+该学科结合了软件工程的各个方面，并将其应用于基础结构和操作问题，旨在创建超可扩展且高度可靠的软件系统。
	1037	+
	1038	+由于高度数字化的组织要求高度弹性的运营，因此站点可靠性工程（SRE）与HVIT特别相关。
	1039	+
	1040	+SRE将软件开发思维方式应用于IT运营，并有助于使开发和运营保持一致。SRE团队将时间分散在执行IT运营、指导IT运营团队以及开发可提高IT系统弹性和性能的软件之间。他们倾向于花费少于一半的时间在琐事工作上（否则，这表明系统存在问题）。
	1041	+
	1042	+琐事被定义为工作，即：
	1043	+
	1044	+* **手动 **需要人工的时间。
	1045	+* **重复性 **一遍又一遍。
	1046	+* **可自动化的 **因为不需要特殊的人工判断，所以可以通过机器来实现。
	1047	+* **战术型 **由中断驱动和被动式驱动，而不是由策略驱动和主动驱动。
	1048	+* **缺乏持久性价值 **并非永久性地改进和服务。
	1049	+* **线性缩放 **与服务的大小、流量或用户的数量成比例地缩放。
	1050	+
	1051	+SRE基于经验表明，系统很复杂，因此会发生故障。因此，在预防故障和减少无法预防的失效的影响之间可以进行权衡，例如通过将系统设计为逐渐降级而不是突然失效。认识到人是复杂系统的适应性要素，并且他们的专业知识与系统的其他部分一样在发生变化，因此失效被认为是学习的机会。
	1052	+
	1053	+从失效中学习并不是专注于根本原因的识别，因为在复杂系统中这是无效的，甚至是不可能的（请参阅第3.2.3.1节）。相反，失效是用来提高团队的集体知识的。它们帮助人们不断地校准其心理模型，以便他们可以更轻松地识别危害，并采取行动将系统保持在可接受的性能范围内。从业人员评估何时应用标准修复程序以及何时需要即兴创作。他们永远无法确定其行动的后果，他们会从反馈中学习有关系统性能如何根据其行动而变化的信息。因为团队应该承担风险，所以不要将责任归咎于责备文化至关重要。虽然算法在机器学习中占有一席之地，例如，启发式算法在处理复杂系统方面更为有效，因此人工判断至关重要。这需要智力，经验和采取行动的动力；和鼓励期望行为的工作场所。
	1054	+
	1055	+在可用性管理中，平衡停机预防和事件解决很重要。相应的关键可用性指标是MTBF和MTRS。系统越复杂，不可避免的失效就越多，这意味着重点应该从预防失效转移到快速恢复服务。正确的平衡因服务而异，具体取决于服务的功效要求和基础系统的特性。在HVIT环境中，系统通常会更复杂，因此，专注于减少MTRS比增加MTBF更有效。
	1056	+
	1057	+平衡对新功能和服务可靠性的投资可能是一项挑战。错误预算是一个功能强大的SRE工具，可在此方面提供帮助。变更往往会导致系统事件。功能的开发工作和稳定性的开发工作需要平衡。错误预算是一种控制机制，可为开发工作分配适当的能力以保持稳定，并确保适当的平衡。当服务接近其错误预算时，产品团队应专注于改进而不是新功能。
	1058	+
	1059	+错误预算表示为100％减去服务的服务水平目标（SLO）。99.9％的SLO服务的错误预算为0.1％。这笔预算应用于改进稳定性。错误预算允许团队根据策略进行自我调整，如果超出错误预算，后果将不堪设想。重要的是，应以影响服务消费者体验的术语表示SLO，而不是内部系统的KPI。
	1060	+
	1061	+SRE对可用性，延迟和性能的改进都有助于恢复操作。图4.23显示了SRE对服务价值链的贡献。
	1062	+
	1063	+表4.20概述了与SRE相关的实践。
	1064	+
	1065	+
	1066	+(% style="text-align:center" %)
	1067	+[[image:1639569226390-186.png]]
	1068	+
	1069	+图4.23 SRE对服务价值链贡献的热图
	1070	+
	1071	+
	1072	+表4.20 与SRE相关的实践
	1073	+
	1074	+[[image:1641702861765-733.png]]
	1075	+
	1076	+
	1077	+**ITIL故事：站点可靠性工程**
	1078	+
	1079	+// Su：我们添加到应用程序的功能越多，它变得越复杂，其中的代码失败的可能性就越大。失败是任何软件平台都不可避免的功能。应用失败的方式可以教会我们如何对其进行重新校准以使其更具弹性。//
	1080	+
	1081	+//Radhika：站点可靠性工程在减少服务故障的需求与减少服务故障之间进行平衡的需求之间取得了平衡。我们越能自动化工作并减少重复的手动操作，代码就越强大。价值共创的技术//
	1082	+
	1083	+
	1084	+
	1085	+== 4.4 价值共创的技术 ==
	1086	+
	1087	+
	1088	+价值共创目标涉及通过服务提供商和服务消费者的紧密合作，从数字化产品价值共创。
	1089	+
	1090	+价值共创是服务消费者有效地使用服务提供商的产品和服务，并从其功用和功效中受益。只有通过从自动化信息系统获得的信息来改进决策（无论是由人，自动化还是AI来完成），才能实现数字投资的回报。因此，用户必须了解数字化产品和信息及其在上下文中的用途。他们应该充分理解该功能以适当地使用它，并能够正确地解释信息以改进决策。最后，人或事必须根据这些决定采取行动；只有这样，价值才能实现。
	1091	+
	1092	+例
	1093	+
	1094	+有人使用叫车应用程序前往机场。他们错误地将指示的到达时间解释为保证而非估计。他们做出错误的决定等待。然后他们会紧张地飞往机场，因为他们可能会错过航班。正确地解释后，这些信息将使他们决定搭乘一辆普通的出租车，因此将具有价值。
	1095	+
	1096	+许多用户没有有效地使用信息系统的功能。他们还会误解系统提供的数据的含义，随后做出次优的决策，因此无法获得所需的IT投资回报。不仅无法实现潜在价值，而且在出现问题时生产率通常会下降。造成的某些损失是由于与弹性操作相关的问题所致，而某些损失是由于服务使用者的滥用所致。这意味着应该优先考虑主动的功能用户支持。在业务环境中，这种形式的支持更适合于位于同一地点的角色，例如充当“价值实现教练”的主动超级用户，而不是远程服务台。
	1097	+
	1098	+“价值共创”是指服务消费者、服务提供商和其他利益干系人的价值。对于服务使用者而言，价值是服务输出促进的成果。对于服务提供商而言，取决于投资的性质，价值可以用不同的术语表示，例如数字化产品和服务的收入、网站流量以及降低的成本和风险。
	1099	+
	1100	+在HVIT环境中，服务使用者经常使用数字化产品和服务，因此期望值更高。消费者需要更直观，响应更快的用户体验和客户体验。服务提供商更好地了解服务消费者如何使用IT服务或数字化产品，他们为他们提供更好的支持。同样，服务消费者对服务提供商如何提供IT服务或数字化产品的了解越多，他们与他们进行有效交互的能力就越强。这些概念说明了服务的共生、共创性的本质。
	1101	+
	1102	+尽管按照定义，数字体验将是基于算法的，但是经验丰富的数字服务消费者希望它也应该是复杂的，并且要尽可能地适应他们的情况。如果这对于数字服务来说太困难了，那么服务消费者将期望与服务提供商的员工有丰富的身体/模拟/人类体验。在数字体验依赖于高级算法的情况下，人类体验则依赖于应对不可预测的情况所需的高级启发式方法。这样的服务交互是社会交互，并且服务可能会因人类交互中的小细节而被破坏。经验丰富的服务提供商和消费者认识到环境和对方的人性。这产生了一种相互经验，在彼此尊重彼此立场的情况下，已经实现了可能的成就。
	1103	+
	1104	+共创不仅与服务交互有关，而且在其中实现价值。这也与消费者参与服务设计和进一步开发有关。敏捷产品所有者与开发团队之间的协作是IT从业人员、业务人员以及某些情况下客户与消费者之间紧密协作的一个很好的例子。这样自成体系的面向产品或服务的团队非常有效。在许多情况下，只有在设计信息系统时考虑到这种工作方式，才能实现这种构造，从而使各个小型团队可以在较大系统的相对隔离的部分上工作而无需太多交互。这需要一个松散耦合的信息系统体系结构（请参阅第4.2.2节）。
	1105	+
	1106	+支持价值共创的一项重要技术是服务体验。
	1107	+
	1108	+
	1109	+**ITIL故事：价值共创的技术**
	1110	+
	1111	+//Henri：我们的目标是为所有利益干系人价值共创，因此，无论表面上发生什么变化，我们都需要确保为预订汽车提供的界面是一致且直观的。该应用程序应无缝响应客户要求，以确保用户获得提供最佳价值的优化服务。//
	1112	+
	1113	+
	1114	+
	1115	+=== 4.4.1 服务体验 ===
	1116	+
	1117	+
	1118	+“服务体验”是指服务消费者对服务的评价是基于服务的“技术”输出以及从人的角度看待它的方式这一事实。这意味着服务提供商应该越来越意识到消费者的需求以及他们可用来价值共创的资源。不会被动地获得服务：价值共创需要消费者的努力。服务提供者和使用者必须动态地响应彼此的行为，并尽可能地容纳异常。
	1119	+
	1120	+当在一些具有数字功能的组织中，业务和IT融合为一个组织实体时，就不再需要业务和IT实体。因此，也不再需要管理业务与IT的关系。“业务人员”和“ IT人员”向同一管理人员报告，具有相同的目标，并且通常在物理上位于同一地点。当采用敏捷或Scrum的工作方式时，有一个相对独立的团队致力于一个产品，则业务人员和IT人员在同一团队中，产品所有者代表业务利益。产品负责人经常管理与外部客户和其他利益干系人的关系。这些其他利益干系人包括寻求协同作用的其他产品所有者；例如知识和资源共享。
	1121	+
	1122	+数据分析和机器学习可以极大地促进关系管理。信息安全和道德也同样重要。客户体验管理和客户旅程是值得考虑的其他主题。
	1123	+
	1124	+有关服务关系和服务体验的更多详细信息，请参见ITIL4：推动利益干系人价值。图4.24显示了服务经验对服务价值链的贡献。
	1125	+
	1126	+表4.21概述了与服务经验相关的实践。
	1127	+
	1128	+
	1129	+(% style="text-align:center" %)
	1130	+[[image:1639569323167-699.png]]
	1131	+
	1132	+
	1133	+图4.24 服务体验对服务价值链贡献的热图
	1134	+
	1135	+
	1136	+表4.21 与服务体验相关的实践
	1137	+
	1138	+[[image:1641702908935-105.png]]
	1139	+
	1140	+
	1141	+**ITIL故事：服务体验**
	1142	+
	1143	+//Su：在Axle汽车租赁公司，业务与IT之间没有鸿沟。开发团队协作以提供可响应客户需求的服务体验。我们使用应用程序和车辆中的数据来指导服务的优化和自动化。该应用程序是可定制的，因此用户可以根据自己的需求优化服务。//
	1144	+
	1145	+
	1146	+
	1147	+
	1148	+== 4.5 保证合规的技术 ==
	1149	+
	1150	+
	1151	+保证合规目标涉及确保服务提供和服务使用在治理，风险和合规性方面符合公司和法规指令。除了确保合规性之外，确保责任人员实现合规性也很重要。
	1152	+
	1153	+尽管外部需求可能保持不变，但是对于启用数字化技术的组织来说，可能会有其他更合适的方式来实现它们。
	1154	+
	1155	+高速往往与冒险息息相关，从商业角度看，这些风险可能是必要的。矛盾的是，组织可能承担的最大风险之一就是没有承担足够的风险。
	1156	+
	1157	+但是，必须证明风险是合理的，并且组织必须遵守内部规则和外部法规。必须确保理事机构遵守其指示。保证合规性可以确保对治理，风险和合规性问题负责并受其影响的人们放心，因为他们知道组织在这些约束条件下会更加自信。
	1158	+
	1159	+关于治理，从业者不治理而是被治理。他们在治理框架内运营，并且必须了解适用的限制以及如何在该框架内采取行动。从业者的见识和判断会影响他们的行为。他们越有洞察力，他们的判断能力越强，从业人员就越有能力判断何时有必要在合理的相关收益和风险下偏离规则。这就要求从业者理解约束背后的思想。
	1160	+
	1161	+保证合规可以通过（不存在）安全漏洞、监管机构罚款、宣传不佳、内部和外部审计师要求采取的措施以及确保与治理，风险和合规性问题相符的措施成本来衡量保证的符合性。
	1162	+
	1163	+可以用来保证合规的技术包括：
	1164	+
	1165	+* DevOps审核防御工具包
	1166	+* 开发安全
	1167	+* 同行评审
	1168	+
	1169	+**ITIL故事：保证合规的技术**
	1170	+
	1171	+//Henri：与所有道德企业一样，Axle完全遵守法律法规。我们利用保证合规的技术，因为有时IT进步如此之快，以致可以忽略或延迟遵从性要求。我们敬业的治理团队只是我们关注合规性要求变化的方式之一。//
	1172	+
	1173	+
	1174	+
	1175	+=== 4.5.1 DevOps审核防御工具包 ===
	1176	+
	1177	+
	1178	+DevOps审核防御工具包17是指南，解决了DevOps社区中新的、更流畅的工作模式所引起的IT与审核之间的紧张关系。它有助于向审计师证明IT部门了解业务风险并正在适当地减轻风险。该工具包建议了一些技术，这些技术可以降低风险，并在IT部门和审计师之间建立共同的观点和共识。因此，它有助于保证合规。通过减少不必要的官僚主义，它也为快速发展做出了贡献。
	1179	+
	1180	+DevOps审核防御工具包与HVIT有关，因为HVIT的某些原理和技术似乎与常规合规性要求相抵触。但是，通常情况下，这是寻找获得所需结果的其他方法的情况。内部法规源自外部要求，通常可以找到替代的内部法规。但是，使审核员参与此过程非常重要。
	1181	+
	1182	+图4.25显示了DevOps Audit Defense Toolkit对服务价值链的贡献。表4.22概述了与DevOpsAudit Defense Toolkit相关的实践。
	1183	+
	1184	+(% style="text-align:center" %)
	1185	+[[image:1639569448205-317.png]]
	1186	+
	1187	+图4.25 DevOps审计防御工具包对服务价值链贡献的热图
	1188	+
	1189	+
	1190	+表4.22 DevOps审计防御工具包与之相关的实践
	1191	+
	1192	+[[image:1641702956598-898.png]]
	1193	+
	1194	+
	1195	+
	1196	+=== 4.5.2 开发安全 ===
	1197	+
	1198	+
	1199	+大多数组织都有专门的信息安全团队，该团队执行风险评估并定义策略，规程和控制。在高速环境中，信息安全已尽可能集成到开发和运营的日常工作中，并将对过程控制的依赖转移到验证前提条件（例如员工的专业知识和完整性）上。安全员的角色从“维持治安”转变为使其他人能够采取必要措施。
	1200	+
	1201	+“ DevSecOps”是指将与安全相关的活动集成到应用程序开发和IT运营的日常工作中。在整个DevOps流程中，跨文化，自动化，指标和共享（CAMS或CALMS加上精益）的四个支柱都内置了安全性。
	1202	+
	1203	+
	1204	+定义：职责整合
	1205	+
	1206	+由于已应用其他控件，因此一个人容易执行欺诈或错误的任务。这是职责分离（或隔离）的替代方法。
	1207	+
	1208	+传统上，职责是分开的，以减少欺诈和错误的风险；例如，未经测试和未经授权的代码将被部署到生产中的风险。但是，这可能会导致延迟和人们所认为的官僚主义感到挫败。职责分离本身并不是目标，而是实现目标的一种方法。还可以使用其他方法来实现相同的目标，因此可以在保持相同保证水平的同时整合职责。
	1209	+
	1210	+信息安全严重取决于整个组织中人员的行为。受过良好培训且遵循信息安全策略和其他控制措施的员工可以帮助检测、预防和纠正安全事件。训练有素训练或工作动力不足的员工可能是一个主要漏洞。
	1211	+
	1212	+支持信息安全管理需要许多过程和过程。这些包括：
	1213	+
	1214	+* 安全事件管理流程
	1215	+* 风险管理过程
	1216	+* 控制评审和审核过程
	1217	+* 身份和访问管理过程
	1218	+* 事态管理
	1219	+* 渗透测试，漏洞扫描等过程
	1220	+* 用于管理与安全相关的变更（例如防火墙配置变更）的过程。这种处理安全性的集成方法有助于保证合规。
	1221	+
	1222	+**案例分析**
	1223	+
	1224	+大型音乐流媒体服务提供商依赖于能够快速交付。它不断提高以保持其领先状态。它的工作方式和操作模型基于速度和持续改进。即将发生的法律地位变更引入了新的合规性要求，从而触发了其运营模式的变更。
	1225	+
	1226	+特别是，其财务系统受到有关职责分离和审计追踪的必要控制的影响。流程和相关工具需要变更。最初，这受到自治团队的抵制，他们为自己的工作方式感到自豪。
	1227	+
	1228	+为了克服这种阻力，团队将面临挑战并拥有解决方案的所有权。提出新法规是生活中的事实：企业成长的自然结果。由于团队习惯于具有很大的自治权，因此可以信任他们发现如何遵守法规，而又不影响流程和敏捷性。内部审计团队和过程工具团队会为他们提供专家帮助。
	1229	+
	1230	+每个团队都开发自己的流程和流程工具配置，并与主要利益干系人进行交互。尽管对于所有团队而言，方法的多样性可能不如一劳永逸的解决方案有效，但好处显而易见。有更好的流程，因为每个团队都遵循自己的特定流程。而且，重要的是，每个团队对遵守控制措施负有全部责任。这创造了可持续的利益。
	1231	+
	1232	+从此案例中获得的主要经验是：
	1233	+
	1234	+* 发挥团队优势在这种情况下，责任受到欢迎。对于较少自治的团队，可能需要另一种方法。
	1235	+* 着眼于外部法规，而不是如何将其转化为内部政策和约束条件。通常，可以采用其他方法来实现相同的合规性。这需要内部审计团队的灵活性。
	1236	+
	1237	+图4.26显示了DevSecOps对服务价值链的贡献。
	1238	+
	1239	+表4.23列出了与DevSecOps相关的实践。
	1240	+
	1241	+
	1242	+(% style="text-align:center" %)
	1243	+[[image:1639569550207-851.png]]
	1244	+
	1245	+图4.26 DevSecOps对服务价值链贡献的热图
	1246	+
	1247	+
	1248	+表4.23 与DevSecOps相关的实践
	1249	+
	1250	+[[image:1641703051758-407.png]]
	1251	+
	1252	+[[image:1641703070463-409.png]]
	1253	+
	1254	+
	1255	+//ITIL故事：DevSecOps//
	1256	+
	1257	+//Henri：数据的完整性和安全性是Axle汽车租赁团队工作方式的基础。快速工作以高节奏提供新的应用程序功能时，存在引入安全漏洞的风险，这些漏洞可能会被利用。//
	1258	+
	1259	+//Marco：我们所有的员工都接受过培训，以了解他们的行为如何危害我们的安全。他们遵循安全流程，可以检测，预防和纠正安全事件。//
	1260	+
	1261	+
	1262	+
	1263	+=== 4.5.3 同行评审 ===
	1264	+
	1265	+
	1266	+**定义：同行评审**
	1267	+
	1268	+同一领域的其他人对一件科学或其他专业作品的判断。当应用于软件开发时，工作产品的开发人员和一个或多个同事将对其进行检查，以评估其技术含量和质量。这有助于保证合规。
	1269	+
	1270	+
	1271	+(% style="text-align:center" %)
	1272	+[[image:1639569657674-856.png]]
	1273	+
	1274	+图4.27 同行评审形式谱
	1275	+
	1276	+
	1277	+基于在工程行业中的同行评审的价值，许多行业专家已将其视为非常理想的开发实践。经验表明，如果开发过程包含同行评审，则可以较早地消除问题（缺陷）。这些审核与测试一样有效，甚至比测试更有效。
	1278	+
	1279	+同行评审提供了一种纪律严明的工程实践，用于检测和纠正设计产品中的缺陷。在软件工程和其他工程学科（包括电气，土木，机械和消防工程）中，它也是提高设计过程质量和生产率的最有效方法之一。
	1280	+
	1281	+在同行评审过程中收集的数据用于纠正缺陷，以及评估和改进开发过程本身。
	1282	+
	1283	+同行评审方法可以包括以下一项或多项：
	1284	+
	1285	+* 检查
	1286	+* 团队审查
	1287	+* 演练
	1288	+* 结对编程
	1289	+* 同行检查
	1290	+* 传送
	1291	+* 临时审查。
	1292	+
	1293	+这些方法按形式顺序在图4.27中进行了说明。此外，表4.24概述了不同类型的同行评议中通常包括的活动（摘自Wiegers，2002年；经纽约皮尔森教育公司许可转载）。
	1294	+
	1295	+表4.24 在不同的同行评审方法中的活动
	1296	+
	1297	+[[image:1641703105916-225.png]]
	1298	+
	1299	+
	1300	+图4.28显示了同行评审对服务价值链的贡献。
	1301	+
	1302	+(% style="text-align:center" %)
	1303	+[[image:1639569697056-454.png]]
	1304	+
	1305	+图4.28 同行评审对服务价值链贡献的热图
	1306	+
	1307	+
	1308	+表4.25 与同行评审相关的实践
	1309	+
	1310	+[[image:1641703160673-370.png]]
	1311	+
	1312	+
	1313	+表4.25概述了同行评审相关的实践。
	1314	+
	1315	+
	1316	+
	1317	+
	1318	+**ITIL故事：同行评审**
	1319	+
	1320	+//Su：我们的应用程序开发团队协同工作，并定期进行定期的同行评审。我们从同事的专业知识和经验中受益匪浅，他们会互相回顾彼此的工作，并在问题到达实际环境之前发现并纠正问题。//
	1321	+
	1322	+//索尔玛兹：我们倡导开放，无责的文化，这意味着个人在与同行分享工作时会感到自在。这有助于构建强大，有影响力的服务，为所有利益干系人创造价值。//
	1323	+
	1324	+
	1325	+
	1326	+
	1327	+== 4.6 小结 ==
	1328	+
	1329	+
	1330	+在第2章中，描述了实现高速IT的五个重要组织目标。为了支持实现这些目标，组织可以采用多种技术和模型。其中一些是最近开发的，而其他一些则是根据以前采用的运营模型和管理方法改编的。第4章探讨了一些流行且重要的技术。
	1331	+
	1332	+在本章中，这些技术围绕高速目标进行了分组。但是，它们中的大多数在一定程度上有助于实现多个目标。HVIT技术在许多实践中普遍适用。为了帮助在实践中采用它们，提供了它们对服务价值链的相对贡献的热图。
	1333	+
	1334	+请从业者将此章视为一个多功能工具集，并根据上下文和所执行的工作任务来应用这些工具。实施此处描述的技术不应仅作为目标。应始终将它们视为实现组织目标的手段。这适用于本出版物的其他章节以及总体上的ITIL：应采用并改编这些工具以满足组织的需求。
	1335	+
	1336	+
	1337	+
	1338	+**结论**
	1339	+
	1340	+数字化技术已经打破了许多行业的业务，带来了新的机遇和新的挑战。商业产品、服务和运营都发生了重大变化，即所谓的数字化转型，而这种变化需要采用新的IT和业务管理方法。
	1341	+
	1342	+为了满足这些要求，已经开发了许多方法，技术和工具。这些的数量和种类以及决定如何最好地使用它们会带来挑战，并且选择合适的方法并不总是容易的。除了对产品、服务和运营的变更之外，数字化转型还涉及文化和组织上的变革，这些变革自身都有困难。
	1343	+
	1344	+业务和IT领域的领导者和从业者应该了解数字化转型的前景，并能够定义目标，采用有效的行为模式并采用适当的技术来取得成功。
	1345	+
	1346	+该出版物概述了数字化转型以及高速业务和IT管理的关键概念。它提出了一组目标和行为模式，这些目标和行为模式将帮助企业转型，使其从数字化技术中获得最大收益。最后，它描述了可以支持每个目标的有用技术和方法的集合。ITIL SVS提供了一个整体结构，将有助于高速IT的实际应用。
	1347	+
	1348	+为了充分利用ITIL 4：高速IT，应与ITIL管理实践指南一起进行研究，该指南可在线获得，并为所有34种实践提供详细的实用建议。它们包括可在所有ITIL 4出版物中应用的动手指南。
	1349	+
	1350	+所有ITIL出版物都是整体出版物，并且注重价值。它们解决了服务管理的四个方面，并以一种能够为组织，其客户和其他利益干系人创造价值的方式帮助管理资源。
	1351	+
	1352	+//ITIL4：指导、计划和改进：//为使产品和服务管理与当今的业务需求保持一致，推动成功的组织转型以及将持续改进融入组织的各个层次的文化提供了指导。
	1353	+
	1354	+//ITIL4：驱动利益干系人的价值：//包含有关建立、维护和发展有效服务关系的指南。它带领组织以服务提供者和服务使用者的身份进行服务之旅，帮助他们在每个步骤进行有效的交互和沟通。
	1355	+
	1356	+//ITIL4：创建、交付和支持：//提供有关产品和服务管理的文化和团队管理方面的指南，并概述了支持服务管理的各种工具和技术。它演示了如何将管理实践集成到端到端的价值流中。
	1357	+
	1358	+
	1359	+
	1360	+[[返回上一章>>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/]]

1639569697056-454.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+60.6 KB

Content

1641700591514-812.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+85.4 KB

Content

1641700659017-287.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+77.7 KB

Content

1641700683365-399.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+60.7 KB

Content

1641700701040-265.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+55.3 KB

Content

1641700764097-167.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+78.1 KB

Content

1641700825218-144.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+81.9 KB

Content

1641700916381-114.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+96.1 KB

Content

1641701019297-720.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+81.3 KB

Content

1641701038534-675.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+65.8 KB

Content

1641701094058-713.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+99.1 KB

Content

1641701145033-568.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+103.2 KB

Content

1641701202590-318.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+81.6 KB

Content

1641701238590-838.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+66.8 KB

Content

1641701293452-859.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+93.1 KB

Content

1641701355821-388.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+104.7 KB

Content

1641701417790-550.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+120.9 KB

Content

1641701444463-764.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+83.7 KB

Content

1641701509520-551.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+93.9 KB

Content

1641701559766-478.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+60.2 KB

Content

1641701689758-164.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+110.4 KB

Content

1641702469032-780.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+83.0 KB

Content

1641702487237-876.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+45.7 KB

Content

1641702547499-544.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+102.0 KB

Content

1641702577206-162.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+59.5 KB

Content

1641702628320-774.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+90.2 KB

Content

1641702718413-352.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+108.8 KB

Content

1641702752724-340.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+73.6 KB

Content

1641702861765-733.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+122.8 KB

Content

1641702908935-105.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+93.1 KB

Content

1641702956598-898.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+74.3 KB

Content

1641703051758-407.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+117.4 KB

Content

1641703070463-409.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+64.7 KB

Content

1641703105916-225.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+34.0 KB

Content

1641703160673-370.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+82.9 KB

Content