Changes for page 4.高速IT技术

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Attachments (0 modified, 20 added, 0 removed)
  • 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

Details

Page properties

Content

...	...	@@ -1,3 +1,12 @@
	1	+
	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="**X Contents**"}}
	7	+{{toc/}}
	8	+{{/box}}
	9	+
1	1	= 4. 高速IT技术 =
2	2
3	3	本章介绍了表征HVIT环境特征的一些技术选择。有些通常只在这些环境中发现，而另一些是对HVIT工作至关重要的更通用的技术。选择并不详尽；这些技术是帮助高度数字化的组织实现其苛刻目标的工作方式的示例。
...	...	@@ -83,18 +83,9 @@
83	83
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
	95	+[[image:1641700591514-812.png]]
97	97
	97	+
98	98	**ITIL故事：优先排序技术**
99	99
100	100	//Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
...	...	@@ -132,46 +132,11 @@
132	132
133	133	表4.2 与最小可用方法相关的实践
134	134
135		-(% style="width:863px" %)
136		-|**ITIL管理实践**|(% style="width:575px" %)**与最小可用方法相关的活动/资源**|(% style="width:87px" %)**影响**
137		-|架构管理|(% style="width:575px" %)(((
138		-使用最小可用的方法来描述服务、技术、信息或环境体系结构，这将为其他类型
	135	+[[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		-使用容量和性能管理作为计算最低可行产品或服务所需的最小资源（服务器数量，服务
	137	+[[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		-
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：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
...	...	@@ -202,29 +202,9 @@
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		-产品和服务所有者参与阐明，完善基础架构和平台开发积压工作并确定其优先级，并
	170	+[[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		-
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：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
...	...	@@ -263,17 +263,9 @@
263	263
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
	211	+[[image:1641700825218-144.png]]
276	276
	213	+
277	277	**ITIL的故事：A / B测试**
278	278
279	279	//Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
...	...	@@ -344,29 +344,10 @@
344	344
345	345	图4.7 基础设施作为代码对服务价值链的贡献的热图
346	346
347		-‘
348	348
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
	287	+[[image:1641700916381-114.png]]
370	370
371	371	表4.5 列出了与基础设施作为代码相关的实践。
372	372
...	...	@@ -412,23 +412,11 @@
412	412
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
	333	+[[image:1641701019297-720.png]]
431	431
	335	+[[image:1641701038534-675.png]]
	336	+
	337	+
432	432	=== 4.2.3 复查 ===
433	433
434	434	通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
...	...	@@ -447,20 +447,7 @@
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
	356	+[[image:1641701094058-713.png]]
464	464
465	465	表4.7概述了与回顾相关的实践。
466	466
...	...	@@ -500,29 +500,9 @@
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		-调查持续改进活动，以识别经验教训，了解系统中的变更以及确定增加或保持未来改进成
	396	+[[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
525		-
526	526	=== 4.2.4 持续业务分析 ===
527	527
528	528	瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
...	...	@@ -558,22 +558,11 @@
558	558
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
	434	+[[image:1641701202590-318.png]]
576	576
	436	+[[image:1641701238590-838.png]]
	437	+
	438	+
577	577	=== 4.2.5 持续集成、持续交付和持续部署 ===
578	578
579	579	持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
...	...	@@ -610,21 +610,9 @@
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
	475	+[[image:1641701293452-859.png]]
627	627
	477	+
628	628	**ITIL故事：持续集成、持续交付和持续部署**
629	629
630	630	//Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。//
...	...	@@ -637,34 +637,11 @@
637	637
638	638	表4.11 软件测试的类型
639	639
640		-(% style="width:813px" %)
641		-|(% style="width:165px" %)测试思路|(% style="width:646px" %)所有软件都源于一个想法，通常是试图解决问题的尝试。 测试该想法有助于从客户角度（基于需求和需求）和业务角度（基于指标，包括增长，收入，转化和用户基础）确定其质量。
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		-必须在生产环境中对某些风险进行测试，例如性能风险（尤其是用户负载和用户压力风险），用户接受度测试（用户将其与实际软件一样使用系统）和可观察性风险（以测试有效性、可观察性解决方案和实现）。
	490	+[[image:1641701417790-550.png]]
651	651
652		-在生产中进行测试时，目标应该是最大程度地降低影响客户的测试风险。实现这一目标的策略包括：
	492	+[[image:1641701444463-764.png]]
653	653
654		-● **金丝雀发布 **这项新功能最初是针对少数目标用户发布的，后来逐渐增加到所有用户。
655	655
656		-●** 功能开关** 可以将功能隐藏在功能标志的后面，通过打开或关闭该标志可以轻松启用或禁用
657		-
658		-该功能。
659		-
660		-● **蓝/绿部署 **两个相同的生产环境同时运行（一个“蓝色”和一个“绿色”），只有一个环
661		-
662		-境处于活动状态，为所有生产流量提供服务，而另一个用于部署新版本。
663		-
664		-● **自动化的回滚策略 **发生事件时，自动化工具可以快速将发行版恢复为先前版本。
665		-)))
666		-|(% style="width:165px" %)测试生产环境中的服务|(% style="width:646px" %)为已发布的生产软件实现了许多服务，活动和技术，所有这些都可以进行测试。从服务交付的角度来看，测试流程很重要。 例如，在测试用户是否可以访问支持时，重要的是要问用户获得支持有多容易，用户在软件中在什么情况下做到这一点。
667		-
668	668	为了实现持续测试，应制定一些原则，包括：
669	669
670	670	* 测试应该以最低级别进行。
...	...	@@ -689,15 +689,7 @@
689	689
690	690	表4.12 与持续测试最相关的实践
691	691
692		-(% style="width:834px" %)
693		-|**ITIL管理实践**|(% style="width:641px" %)**与持续测试相关的活动/资源**|(% style="width:79px" %)**影响**
694		-|架构管理|(% style="width:641px" %)设计和改进服务，技术和信息架构，以利用CI / CD功能|(% style="width:79px" %)H
695		-|服务验证与测试|(% style="width:641px" %)在整个开发生命周期中，将持续进行单元，集成和回归测试。这包括应用程序单元测试，基础结构服务测试，功能/非功能测试，canary版本，蓝/绿测试以及基础结构安全性测试。|(% style="width:79px" %)H
696		-|部署管理|(% style="width:641px" %)导致连续测试失败的变更或部署会触发团队的告警线。然后，团队成员蜂拥而至以解决问题。|(% style="width:79px" %)M
697		-|信息安全管理|(% style="width:641px" %)通过减少手工工作来确保遵守信息安全合规。利用自动化测试工具，可以减少手工工作并提高变更的可追溯性，从而有助于确保遵守信息安全合规。|(% style="width:79px" %)M
698		-|问题管理|(% style="width:641px" %)自动化测试有助于验证问题的解决方案，已知错误的存在或规避措施的有效性。|(% style="width:79px" %)M
699		-|服务连续性管理|(% style="width:641px" %)自动化测试可以加速提供从灾难中恢复所需的技术资源。|(% style="width:79px" %)M
700		-|风险管理|(% style="width:641px" %)使用测试自动化减少某些类型的企业风险的影响。|(% style="width:79px" %)L
	519	+[[image:1641701509520-551.png]]
701	701
702	702
703	703	**ITIL的故事：持续测试**
...	...	@@ -730,13 +730,13 @@
730	730
731	731	看板的主要做法是：
732	732
733		-1. 可视化工作
734		-1. 限制进行中的工作
735		-1. 管理流程
736		-1. 明确制定流程政策
737		-1. 实施反馈循环
738		-1. 改进协作
739		-1. 实验性地发展。
	552	+* 可视化工作
	553	+* 限制进行中的工作
	554	+* 管理流程
	555	+* 明确制定流程政策
	556	+* 实施反馈循环
	557	+* 改进协作
	558	+* 实验性地发展。
740	740
741	741	有时组织仅使用看板来可视化进行中的工作。尽管使用看板很重要，但这是看板的有限应用。看板的功能取决于整体实施和对工作流程的持续关注。看板示例如图4.15所示。
742	742
...	...	@@ -771,17 +771,7 @@
771	771
772	772	表4.13 与看板相关的实践
773	773
774		-(% style="width:804px" %)
775		-|**ITIL管理实践**|(% style="width:524px" %)**与看板相关的活动/资源**|(% style="width:70px" %)**影响**
776		-|变更控制|(% style="width:524px" %)通过限制进行中的工作，可视化并改进对服务和服务组件的变更流程。|(% style="width:70px" %)H
777		-|持续改进|(% style="width:524px" %)可视化并改进SVS中的改进流程。|(% style="width:70px" %)H
778		-|项目管理|(% style="width:524px" %)可视化并改进跨项目和团队的工作流程。|(% style="width:70px" %)H
779		-|发布管理|(% style="width:524px" %)可视化并提高发布给消费者的质量。|(% style="width:70px" %)H
780		-|软件开发管理|(% style="width:524px" %)可视化和改进新的或变更的软件组件进入实时环境的流程。|(% style="width:70px" %)H
781		-|事件管理|(% style="width:524px" %)通过限制进行中的工作来可视化并提高事件解决的速度和质量。|(% style="width:70px" %)M
782		-|组合管理|(% style="width:524px" %)可视化并改进整个投资组合管道中的投资流程。|(% style="width:70px" %)M
783		-|问题管理|(% style="width:524px" %)通过限制进行中的工作来可视化并改进问题和错误控制。|(% style="width:70px" %)M
784		-|供应商管理|(% style="width:524px" %)可视化供应商的入职/离职进度。|(% style="width:70px" %)M
	593	+[[image:1641701559766-478.png]]
785	785
786	786
787	787	== 4.3 弹性运营的技术 ==
...	...	@@ -839,38 +839,25 @@
839	839
840	840	图4.17显示了技术债对服务价值链的贡献。
841	841
842		-表4.14概述了与技术债相关的实践。
	651	+(% style="text-align:center" %)
	652	+[[image:1639568670048-316.png]]
843	843
844	844
845		-**ITIL故事：技术债**
	655	+图4.17 技术债对服务价值链贡献的热图
846	846
847		-//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
848	848
849		-//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
	658	+表4.14概述了与技术债相关的实践。
850	850
	660	+[[image:1641701689758-164.png]]
851	851
852		-(% style="text-align:center" %)
853		-[[image:1639568670048-316.png]]
	662	+表4.14 与技术债相关的实践
854	854
855		-图4.17 技术债对服务价值链贡献的热图
856	856
	665	+**ITIL故事：技术债**
857	857
858		-表4.14 与技术债相关的实践
	667	+//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
859	859
860		-(% style="width:702px" %)
861		-|**ITIL管理实践**|(% style="width:545px" %)**与技术债相关的活动/资源**|(% style="width:70px" %)**影响**
862		-|事件管理|(% style="width:545px" %)解决事件和管理事件需要了解现有的技术债及其解决方案。|(% style="width:70px" %)H
863		-|基础架构管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
864		-|知识管理|(% style="width:545px" %)确保所有相关的利益干系人都可以访问最新信息。|(% style="width:70px" %)H
865		-|组合管理|(% style="width:545px" %)决定是否投资资源来解决实时产品和服务中存在的技术债，并了解对投资对未来产品和服务的影响。评估技术债，以便可以将新的投资组合项目引入现有资产池。评估当前投资组合项目的技术债，以防止价值流失。|(% style="width:70px" %)H
866		-|问题管理|(% style="width:545px" %)应用问题控制和错误控制方法来管理技术债。|(% style="width:70px" %)H
867		-|软件开发管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
868		-|业务分析|(% style="width:545px" %)了解技术债对需求和解决方案表达的影响。|(% style="width:70px" %)M
869		-|持续改进|(% style="width:545px" %)确定优先顺序和管理减少技术债的工作。|(% style="width:70px" %)M
870		-|信息安全管理|(% style="width:545px" %)信息安全控制的设计，实施和改进受现有技术债的影响。信息安全控制还可能导致技术债的产生，这需要得到承认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
871		-|项目管理|(% style="width:545px" %)计划和执行项目受现有技术债的影响。 项目还可能导致技术债的产生，需要承认这一债务并将其传达给所有相关的利益干系人。|(% style="width:70px" %)M
872		-|风险管理|(% style="width:545px" %)认识到技术债对新的或现有的企业风险的影响；减轻风险可能会产生技术债，需要予以确认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
873		-|服务台|(% style="width:545px" %)与需要事件和请求协助的外部用户进行交流，需要了解现有的技术债以及为解决该问题而计划的工作。|(% style="width:70px" %)M
	669	+//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
874	874
875	875
876	876	=== 4.3.2 混沌工程 ===
...	...	@@ -918,7 +918,6 @@
918	918	* **安全猴子 **查找并终止安全违规或漏洞的实例。
919	919	* **看门猴子 **确保云环境没有混乱和浪费。图4.18显示了混沌工程对服务价值链的贡献。表4.15概述了与混沌工程相关的实践。
920	920
921		-
922	922	(% style="text-align:center" %)
923	923	[[image:1639568794032-283.png]]
924	924
...	...	@@ -927,31 +927,30 @@
927	927
928	928	表4.15 与混沌工程相关的实践
929	929
930		-(% style="width:990px" %)
931		-|**ITIL管理实践**|(% style="width:785px" %)**与混沌工程相关的活动/资源**|(% style="width:70px" %)**影响**
932		-|持续改进|(% style="width:785px" %)使用混沌工程作为提高服务质量的最有效工具之一。|(% style="width:70px" %)H
933		-|基础架构管理|(% style="width:785px" %)设计基础架构和平台，以提供足够的弹性和冗余来处理混乱的工程工具导致的意外中断。为混乱的工程提供有关服务组件和备份活动的信息。|(% style="width:70px" %)H
934		-|服务连续性管理|(% style="width:785px" %)设计具有足够弹性和冗余性的服务连续性措施，以应对混乱的工程工具导致的意外中断。 持续监控弹性的连续性计划，措施和机制。|(% style="width:70px" %)H
935		-|服务级别管理|(% style="width:785px" %)在设计和运行测试时，必须考虑业务连续性策略，服务水平协议以及为服务降级建立的明确标准，以防人为破坏超过可接受的水平。|(% style="width:70px" %)H
936		-|软件开发管理|(% style="width:785px" %)混沌工程工具本身就是需要开发（或配置）和管理的软件应用程序。软件的设计和架构应具有足够的弹性和冗余性。|(% style="width:70px" %)H
937		-|架构管理|(% style="width:785px" %)(((
	725	+(% style="width:912px" %)
	726	+|**ITIL管理实践**|(% style="width:677px" %)**与混沌工程相关的活动/资源**|(% style="width:97px" %)**影响**
	727	+|持续改进|(% style="width:677px" %)使用混沌工程作为提高服务质量的最有效工具之一。|(% style="width:97px" %)H
	728	+|基础架构管理|(% style="width:677px" %)设计基础架构和平台，以提供足够的弹性和冗余来处理混乱的工程工具导致的意外中断。为混乱的工程提供有关服务组件和备份活动的信息。|(% style="width:97px" %)H
	729	+|服务连续性管理|(% style="width:677px" %)设计具有足够弹性和冗余性的服务连续性措施，以应对混乱的工程工具导致的意外中断。 持续监控弹性的连续性计划，措施和机制。|(% style="width:97px" %)H
	730	+|服务级别管理|(% style="width:677px" %)在设计和运行测试时，必须考虑业务连续性策略，服务水平协议以及为服务降级建立的明确标准，以防人为破坏超过可接受的水平。|(% style="width:97px" %)H
	731	+|软件开发管理|(% style="width:677px" %)混沌工程工具本身就是需要开发（或配置）和管理的软件应用程序。软件的设计和架构应具有足够的弹性和冗余性。|(% style="width:97px" %)H
	732	+|架构管理|(% style="width:677px" %)(((
938	938	通过混乱的工程促进弹性基础设施的建设。
939	939
940	940	考虑服务和组件之间的交互以支持需求。
941		-)))|(% style="width:70px" %)M
942		-|容量与性能管理|(% style="width:785px" %)运行此类测试时，应捕获性能信息。因此，应确定改进措施，以确保为最佳性能，可伸缩性和容量设计服务。|(% style="width:70px" %)M
943		-|事件管理|(% style="width:785px" %)团队可以使用混乱的工程工具练习响应故障并从中断中恢复。他们必须准备好在不影响用户的情况下管理事件。冗余和自动化应内置于流程中。|(% style="width:70px" %)M
944		-|度量与报告|(% style="width:785px" %)混沌工程测试涉及实验和假设，将有助于收集和分析数据以进行计划和预测。结果支持连续性业务战略。|(% style="width:70px" %)M
945		-|监控与事态管理|(% style="width:785px" %)可以设置监视和事态管理工具来标记由混乱的工程工具策划的中断，或者监视服务质量而不是技术组件。|(% style="width:70px" %)M
946		-|组织变革管理|(% style="width:785px" %)混沌工程将有助于确保在现场环境中的契动与合作。|(% style="width:70px" %)M
947		-|问题管理|(% style="width:785px" %)通过引入随机失效并寻找服务/组件中的潜在缺陷来主动检测问题。从混乱的工程工具中收集的数据可以帮助识别需要调查和修复的潜在问题。|(% style="width:70px" %)M
948		-|服务配置管理|(% style="width:785px" %)CMDB和代码存储库应具有高可用性和准确的信息（与服务连续性管理定义的恢复点目保持一致），以帮助组织从中断中快速恢复。|(% style="width:70px" %)M
949		-|服务设计|(% style="width:785px" %)混沌工程测试原理可以帮助架构师设计更具弹性的系统并改进用户体验。|(% style="width:70px" %)M
950		-|服务台|(% style="width:785px" %)必须将有关测试的情况通知服务台团队，并准备好在不影响用户的情况下管理事件。|(% style="width:70px" %)M
951		-|服务验证与测试|(% style="width:785px" %)混沌工程测试原理可以帮助评估服务的可靠性。架构师应专注于服务中断。|(% style="width:70px" %)M
952		-|风险管理|(% style="width:785px" %)通过使用混乱的工程工具和方法来提高组织的弹性和健壮性，可以减轻某些类型的组织风险。|(% style="width:70px" %)L
	736	+)))|(% style="width:97px" %)M
	737	+|容量与性能管理|(% style="width:677px" %)运行此类测试时，应捕获性能信息。因此，应确定改进措施，以确保为最佳性能，可伸缩性和容量设计服务。|(% style="width:97px" %)M
	738	+|事件管理|(% style="width:677px" %)团队可以使用混乱的工程工具练习响应故障并从中断中恢复。他们必须准备好在不影响用户的情况下管理事件。冗余和自动化应内置于流程中。|(% style="width:97px" %)M
	739	+|度量与报告|(% style="width:677px" %)混沌工程测试涉及实验和假设，将有助于收集和分析数据以进行计划和预测。结果支持连续性业务战略。|(% style="width:97px" %)M
	740	+|监控与事态管理|(% style="width:677px" %)可以设置监视和事态管理工具来标记由混乱的工程工具策划的中断，或者监视服务质量而不是技术组件。|(% style="width:97px" %)M
	741	+|组织变革管理|(% style="width:677px" %)混沌工程将有助于确保在现场环境中的契动与合作。|(% style="width:97px" %)M
	742	+|问题管理|(% style="width:677px" %)通过引入随机失效并寻找服务/组件中的潜在缺陷来主动检测问题。从混乱的工程工具中收集的数据可以帮助识别需要调查和修复的潜在问题。|(% style="width:97px" %)M
	743	+|服务配置管理|(% style="width:677px" %)CMDB和代码存储库应具有高可用性和准确的信息（与服务连续性管理定义的恢复点目保持一致），以帮助组织从中断中快速恢复。|(% style="width:97px" %)M
	744	+|服务设计|(% style="width:677px" %)混沌工程测试原理可以帮助架构师设计更具弹性的系统并改进用户体验。|(% style="width:97px" %)M
	745	+|服务台|(% style="width:677px" %)必须将有关测试的情况通知服务台团队，并准备好在不影响用户的情况下管理事件。|(% style="width:97px" %)M
	746	+|服务验证与测试|(% style="width:677px" %)混沌工程测试原理可以帮助评估服务的可靠性。架构师应专注于服务中断。|(% style="width:97px" %)M
	747	+|风险管理|(% style="width:677px" %)通过使用混乱的工程工具和方法来提高组织的弹性和健壮性，可以减轻某些类型的组织风险。|(% style="width:97px" %)L
953	953
954		-
955	955	ITIL故事：混沌工程
956	956
957	957	//Radhika：我们需要测试该应用程序的弹性。例如，如果成员资格功能停止工作会怎样？客户仍然可以预定汽车？预订是否仍可以追溯分配到他们的账户？//
...	...	@@ -1024,7 +1024,6 @@
1024	1024	|服务目录管理|(% style="width:601px" %)发行新功能，产品或服务时，服务目录必须被更新。|(% style="width:70px" %)L
1025	1025	|服务台|(% style="width:601px" %)在完成的定义中指定质量属性，以便开发和支持团队可以在早期阶段考虑他们。|(% style="width:70px" %)L
1026	1026
1027		-
1028	1028	**ITIL故事：完成定义**
1029	1029
1030	1030	//Su：该应用程序的交付团队包括来自Alxe汽车租赁部门许多部门人员，当开发人员移交工作代码时，对完成传统定义并不是最有效或最准确的。我们要保证该应用程序的弹性、功效、可维护性、功用和可用性。对我们来说，“完成“是指：//
...	...	@@ -1092,7 +1092,6 @@
1092	1092	|服务连续性管理|(% style="width:689px" %)了解服务组件新版本的影响；并且如果可行，将它们传播到服务连续性和灾难恢复计划中。|(% style="width:91px" %)M
1093	1093	|服务请求管理|(% style="width:689px" %)使用版本控制的软件或硬件组件存储库来快速满足要求。|(% style="width:91px" %)M
1094	1094
1095		-
1096	1096	**ITIL故事：版本控制**
1097	1097
1098	1098	//Marco：我们实行持续集成和持续交付，我们利用版本控制系统地记录我们发布的应用程序的每次迭代，如果发布不稳定，我们可以通过将服务返回到先前的稳定版本来快速还原该服务。//
...	...	@@ -1130,22 +1130,21 @@
1130	1130
1131	1131	表4.18 与AIOps相关的实践
1132	1132
1133		-(% style="width:1004px" %)
1134		-|(% style="width:99px" %)**ITIL管理实践**|(% style="width:799px" %)**与AIOps相关的活动/资源**|(% style="width:103px" %)**影响**
1135		-|(% style="width:99px" %)容量与性能管理|(% style="width:799px" %)AIOps提供了识别模式和异常，确定资产的容量和利用率以及规划未来产品或服务的容量能。|(% style="width:103px" %)H
1136		-|(% style="width:99px" %)事件管理|(% style="width:799px" %)事件管理数据可受益于AIOps工具提供的高度自动化的功能，这些功能可增强手动工作。使用从不同系统合并的上下文预先分析的数据解决关联事件。|(% style="width:103px" %)H
1137		-|(% style="width:99px" %)基础架构管理|(% style="width:799px" %)AIOps工具可以自动执行基础结构和平台资源的大部分日常管理。|(% style="width:103px" %)H
1138		-|(% style="width:99px" %)监控与事态管理|(% style="width:799px" %)AIOps工具可以帮助关联来自多个监视工具的大量数据集。他们可以更好地理解IT环境。 AIOps通过一组集成的业务和运营指标来实现价值共创，从而降低了运营事态或事件的发生频率，因为它们是可以预测和预防的。AIOps通过替换以筒仓为中心的IT监视工具，并监视价值流中所有层的应用程序的运行状况和性能，来帮助优化IT并降低IT成本。|(% style="width:103px" %)H
1139		-|(% style="width:99px" %)变更控制|(% style="width:799px" %)AIOP支持在每个设备级别可视化依赖项详细信息。|(% style="width:103px" %)M
1140		-|(% style="width:99px" %)IT资产管理|(% style="width:799px" %)AIOps可以收集具有逻辑和物理属性的动态库存信息。|(% style="width:103px" %)M
1141		-|(% style="width:99px" %)度量与报告|(% style="width:799px" %)AIOps为度量提供数据，以评估性能和法规遵从性。它还有助于自动执行报告任务。|(% style="width:103px" %)M
1142		-|(% style="width:99px" %)问题管理|(% style="width:799px" %)来自AIOps工具的信息可以帮助识别和调查问题和错误，以及自动化和监视规避措施的应用。们还可以基于预处理和合并的数据来帮助主动检测问题。|(% style="width:103px" %)M
1143		-|(% style="width:99px" %)服务配置管理|(% style="width:799px" %)AIOps数据可用于检测配置项的变更，从而帮助识别未经授权的变更。|(% style="width:103px" %)M
1144		-|(% style="width:99px" %)服务台|(% style="width:799px" %)来自AIOps工具的信息可以支持与外部利益干系人的互动。AIOps可帮助组织在问题发生主动进行计划，发现问题及其业务影响。AIOps还可以根据合并的数据和已识别的趋势对用户查询进行明智的分类。|(% style="width:103px" %)M
1145		-|(% style="width:99px" %)劳动力和人才管理|(% style="width:799px" %)在整个IT团队中实施AIOps故障孤岛的组织可以使经验不足的员工提高生产力，发展技能和效率。|(% style="width:103px" %)M
1146		-|(% style="width:99px" %)知识管理|(% style="width:799px" %)IT流程，运营，性能结果和数据处理算法的知识的组合支持关键的业务功能。|(% style="width:103px" %)L
	925	+(% style="width:904px" %)
	926	+|(% style="width:99px" %)**ITIL管理实践**|(% style="width:724px" %)**与AIOps相关的活动/资源**|(% style="width:77px" %)**影响**
	927	+|(% style="width:99px" %)容量与性能管理|(% style="width:724px" %)AIOps提供了识别模式和异常，确定资产的容量和利用率以及规划未来产品或服务的容量能。|(% style="width:77px" %)H
	928	+|(% style="width:99px" %)事件管理|(% style="width:724px" %)事件管理数据可受益于AIOps工具提供的高度自动化的功能，这些功能可增强手动工作。使用从不同系统合并的上下文预先分析的数据解决关联事件。|(% style="width:77px" %)H
	929	+|(% style="width:99px" %)基础架构管理|(% style="width:724px" %)AIOps工具可以自动执行基础结构和平台资源的大部分日常管理。|(% style="width:77px" %)H
	930	+|(% style="width:99px" %)监控与事态管理|(% style="width:724px" %)AIOps工具可以帮助关联来自多个监视工具的大量数据集。他们可以更好地理解IT环境。 AIOps通过一组集成的业务和运营指标来实现价值共创，从而降低了运营事态或事件的发生频率，因为它们是可以预测和预防的。AIOps通过替换以筒仓为中心的IT监视工具，并监视价值流中所有层的应用程序的运行状况和性能，来帮助优化IT并降低IT成本。|(% style="width:77px" %)H
	931	+|(% style="width:99px" %)变更控制|(% style="width:724px" %)AIOP支持在每个设备级别可视化依赖项详细信息。|(% style="width:77px" %)M
	932	+|(% style="width:99px" %)IT资产管理|(% style="width:724px" %)AIOps可以收集具有逻辑和物理属性的动态库存信息。|(% style="width:77px" %)M
	933	+|(% style="width:99px" %)度量与报告|(% style="width:724px" %)AIOps为度量提供数据，以评估性能和法规遵从性。它还有助于自动执行报告任务。|(% style="width:77px" %)M
	934	+|(% style="width:99px" %)问题管理|(% style="width:724px" %)来自AIOps工具的信息可以帮助识别和调查问题和错误，以及自动化和监视规避措施的应用。们还可以基于预处理和合并的数据来帮助主动检测问题。|(% style="width:77px" %)M
	935	+|(% style="width:99px" %)服务配置管理|(% style="width:724px" %)AIOps数据可用于检测配置项的变更，从而帮助识别未经授权的变更。|(% style="width:77px" %)M
	936	+|(% style="width:99px" %)服务台|(% style="width:724px" %)来自AIOps工具的信息可以支持与外部利益干系人的互动。AIOps可帮助组织在问题发生主动进行计划，发现问题及其业务影响。AIOps还可以根据合并的数据和已识别的趋势对用户查询进行明智的分类。|(% style="width:77px" %)M
	937	+|(% style="width:99px" %)劳动力和人才管理|(% style="width:724px" %)在整个IT团队中实施AIOps故障孤岛的组织可以使经验不足的员工提高生产力，发展技能和效率。|(% style="width:77px" %)M
	938	+|(% style="width:99px" %)知识管理|(% style="width:724px" %)IT流程，运营，性能结果和数据处理算法的知识的组合支持关键的业务功能。|(% style="width:77px" %)L
1147	1147
1148		-
1149	1149	**ITIL故事：AIOps**
1150	1150
1151	1151	Radhika：：成千上万的客户使用该应用程序并租用我们的车辆。这些转换会产生大量数据，这是有关客户需求的丰富信息来源。
...	...	@@ -1185,19 +1185,18 @@
1185	1185
1186	1186	表4.19 与ChatOps相关的实践
1187	1187
1188		-(% style="width:974px" %)
1189		-|**ITIL管理实践**|(% style="width:798px" %)**与ChatOps相关的活动/资源**|(% style="width:95px" %)**影响**
1190		-|服务台|(% style="width:798px" %)与用户进行沟通和协调，以更好地管理事件和请求。|(% style="width:95px" %)H
1191		-|变更控制|(% style="width:798px" %)在管理服务变更的所有团队之间进行沟通和协调和服务组件。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps提供了与用户和团队进行沟通的渠道成员了解新服务或变更的服务，从而人性化工作方式。|(% style="width:95px" %)M
1192		-|持续改进|(% style="width:798px" %)实现持续改进计划的目标，以改进沟通与协调团队之间。|(% style="width:95px" %)M
1193		-|部署管理|(% style="width:798px" %)在参与部署新的或变更的所有团队之间进行沟通和协调服务组件。一些ChatOps工具可以与部署工具集成。|(% style="width:95px" %)M
1194		-|事件管理|(% style="width:798px" %)在外部利益干系人与参与其中的各个团队之间进行沟通和协调事件管理活动。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps帮助IT团队进行支持活动，例如注册和诊断，从而减少响应时间并消除重复的任务。|(% style="width:95px" %)M
1195		-|知识管理|(% style="width:798px" %)在聊天日志中搜索非结构化知识。获取知识并确定按计划或预期提供服务的要求。收集反馈以支持持续改进。|(% style="width:95px" %)M
1196		-|问题管理|(% style="width:798px" %)运行根本原因分析和回顾。|(% style="width:95px" %)M
1197		-|发布管理|(% style="width:798px" %)在管理服务变更的所有团队之间进行沟通和协调。|(% style="width:95px" %)M
1198		-|风险管理|(% style="width:798px" %)以可搜索的格式存储数据和信息。|(% style="width:95px" %)L
	979	+(% style="width:923px" %)
	980	+|**ITIL管理实践**|(% style="width:743px" %)**与ChatOps相关的活动/资源**|(% style="width:95px" %)**影响**
	981	+|服务台|(% style="width:743px" %)与用户进行沟通和协调，以更好地管理事件和请求。|(% style="width:95px" %)H
	982	+|变更控制|(% style="width:743px" %)在管理服务变更的所有团队之间进行沟通和协调和服务组件。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps提供了与用户和团队进行沟通的渠道成员了解新服务或变更的服务，从而人性化工作方式。|(% style="width:95px" %)M
	983	+|持续改进|(% style="width:743px" %)实现持续改进计划的目标，以改进沟通与协调团队之间。|(% style="width:95px" %)M
	984	+|部署管理|(% style="width:743px" %)在参与部署新的或变更的所有团队之间进行沟通和协调服务组件。一些ChatOps工具可以与部署工具集成。|(% style="width:95px" %)M
	985	+|事件管理|(% style="width:743px" %)在外部利益干系人与参与其中的各个团队之间进行沟通和协调事件管理活动。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps帮助IT团队进行支持活动，例如注册和诊断，从而减少响应时间并消除重复的任务。|(% style="width:95px" %)M
	986	+|知识管理|(% style="width:743px" %)在聊天日志中搜索非结构化知识。获取知识并确定按计划或预期提供服务的要求。收集反馈以支持持续改进。|(% style="width:95px" %)M
	987	+|问题管理|(% style="width:743px" %)运行根本原因分析和回顾。|(% style="width:95px" %)M
	988	+|发布管理|(% style="width:743px" %)在管理服务变更的所有团队之间进行沟通和协调。|(% style="width:95px" %)M
	989	+|风险管理|(% style="width:743px" %)以可搜索的格式存储数据和信息。|(% style="width:95px" %)L
1199	1199
1200		-
1201	1201	=== 4.3.7 站点可靠性工程 ===
1202	1202
1203	1203	**定义：站点可靠性工程**
...	...	@@ -1263,7 +1263,6 @@
1263	1263	|服务配置管理|(% style="width:707px" %)借助SRE，可以将自动发现和版本控制应用于基础架构组件。|(% style="width:51px" %)M
1264	1264	|服务验证与测试|(% style="width:707px" %)对于SRE中的发布工程，建议连续的构建测试目标与确定项目发布的相同测试目标相对应。|(% style="width:51px" %)M
1265	1265
1266		-
1267	1267	**ITIL故事：站点可靠性工程**
1268	1268
1269	1269	// Su：我们添加到应用程序的功能越多，它变得越复杂，其中的代码失败的可能性就越大。失败是任何软件平台都不可避免的功能。应用失败的方式可以教会我们如何对其进行重新校准以使其更具弹性。//
...	...	@@ -1346,7 +1346,6 @@
1346	1346	|服务验证与测试|(% style="width:719px" %)开发和维护服务体验测试。|(% style="width:83px" %)M
1347	1347	|供应商管理|(% style="width:719px" %)基于主观和客观协议来参与和管理供应商。|(% style="width:83px" %)M
1348	1348
1349		-
1350	1350	**ITIL故事：服务体验**
1351	1351
1352	1352	//Su：在Axle汽车租赁公司，业务与IT之间没有鸿沟。开发团队协作以提供可响应客户需求的服务体验。我们使用应用程序和车辆中的数据来指导服务的优化和自动化。该应用程序是可定制的，因此用户可以根据自己的需求优化服务。//
...	...	@@ -1372,7 +1372,6 @@
1372	1372	* 开发安全
1373	1373	* 同行评审
1374	1374
1375		-
1376	1376	**ITIL故事：保证合规的技术**
1377	1377
1378	1378	//Henri：与所有道德企业一样，Axle完全遵守法律法规。我们利用保证合规的技术，因为有时IT进步如此之快，以致可以忽略或延迟遵从性要求。我们敬业的治理团队只是我们关注合规性要求变化的方式之一。//
...	...	@@ -1406,7 +1406,6 @@
1406	1406	|业务分析|(% style="width:650px" %)将审核结果和建议的补救措施纳入产品积压。|(% style="width:97px" %)L
1407	1407	|战略管理|(% style="width:650px" %)将定期的外部或内部审核合并到服务的路线图中，以提供对服务的独立管理。|(% style="width:97px" %)L
1408	1408
1409		-
1410	1410	=== 4.5.2 开发安全 ===
1411	1411
1412	1412	大多数组织都有专门的信息安全团队，该团队执行风险评估并定义策略，规程和控制。在高速环境中，信息安全已尽可能集成到开发和运营的日常工作中，并将对过程控制的依赖转移到验证前提条件（例如员工的专业知识和完整性）上。安全员的角色从“维持治安”转变为使其他人能够采取必要措施。
...	...	@@ -1460,19 +1460,19 @@
1460	1460
1461	1461	表4.23 与DevSecOps相关的实践
1462	1462
1463		-(% style="width:1056px" %)
1464		-|**ITIL管理实践**|(% style="width:832px" %)**与DevSecOps相关的活动/资源**|(% style="width:90px" %)**影响**
1465		-|持续改进|(% style="width:832px" %)安全控制和策略的改进可以成为开发和运营团队纳入的学习和反馈的一部分。|(% style="width:90px" %)H
1466		-|信息安全管理|(% style="width:832px" %)在开发生命周期中设计和实施控件，以提供广泛的可追溯性和联合责任制。将信息安全职责整合到从业者的日常工作中。|(% style="width:90px" %)H
1467		-|监控与事态管理|(% style="width:832px" %)配置监视工具以连续扫描威胁和漏洞，以便可以将其升级为适当的团队。|(% style="width:90px" %)H
1468		-|变更控制|(% style="width:832px" %)实施预防性控制会自动要求安全管理人员进行预授权，然后开发人员才能根据某些定义的标准进行某些类型的生产数据编辑，包括他们有权使用的功能。|(% style="width:90px" %)M
1469		-|部署管理|(% style="width:832px" %)(((
	1249	+(% style="width:909px" %)
	1250	+|**ITIL管理实践**|(% style="width:690px" %)**与DevSecOps相关的活动/资源**|(% style="width:75px" %)**影响**
	1251	+|持续改进|(% style="width:690px" %)安全控制和策略的改进可以成为开发和运营团队纳入的学习和反馈的一部分。|(% style="width:75px" %)H
	1252	+|信息安全管理|(% style="width:690px" %)在开发生命周期中设计和实施控件，以提供广泛的可追溯性和联合责任制。将信息安全职责整合到从业者的日常工作中。|(% style="width:75px" %)H
	1253	+|监控与事态管理|(% style="width:690px" %)配置监视工具以连续扫描威胁和漏洞，以便可以将其升级为适当的团队。|(% style="width:75px" %)H
	1254	+|变更控制|(% style="width:690px" %)实施预防性控制会自动要求安全管理人员进行预授权，然后开发人员才能根据某些定义的标准进行某些类型的生产数据编辑，包括他们有权使用的功能。|(% style="width:75px" %)M
	1255	+|部署管理|(% style="width:690px" %)(((
1470	1470	安全管理提供有关关键证书管理，CD管道安全检查，容器安全，自动渗透测试以及数据和性能监视的指南。
1471	1471
1472	1472	信息安全管理和风险管理应该是从业者日常工作的组成部分。
1473		-)))|(% style="width:90px" %)M
1474		-|知识管理|(% style="width:832px" %)使员工和其他主要利益干系人可以访问相关的政策文档。|(% style="width:90px" %)M
1475		-|风险管理|(% style="width:832px" %)(((
	1259	+)))|(% style="width:75px" %)M
	1260	+|知识管理|(% style="width:690px" %)使员工和其他主要利益干系人可以访问相关的政策文档。|(% style="width:75px" %)M
	1261	+|风险管理|(% style="width:690px" %)(((
1476	1476	在企业风险管理，技术风险管理和新的工作方式之间创建一种平衡，实用的方法。
1477	1477
1478	1478	在变更IT服务时，确定并消除对外部团队/团队的依赖，这可能涉及将批准权限委派给团队的产品/交付经理。
...	...	@@ -1482,27 +1482,26 @@
1482	1482	详细说明供应商合同中的要求和风险控制措施，以支持职责整合，并守组织的安全策略。
1483	1483
1484	1484	进行价值流映射，以识别和最小化流程移交和批准。
1485		-)))|(% style="width:90px" %)M
1486		-|服务验证与测试|(% style="width:832px" %)测试数据管理是帮助确保持续稳定性，可靠性，可用性和安全性的关键元素。|(% style="width:90px" %)M
1487		-|战略管理|(% style="width:832px" %)整合职责以平衡法规要求和执行速度。|(% style="width:90px" %)M
1488		-|劳动力和人才管理|(% style="width:832px" %)在如何将安全性纳入开发和运营工作方面，对员工和其他相关利益干系人进行培训和辅导。|(% style="width:90px" %)M
1489		-|业务分析|(% style="width:832px" %)(((
	1271	+)))|(% style="width:75px" %)M
	1272	+|服务验证与测试|(% style="width:690px" %)测试数据管理是帮助确保持续稳定性，可靠性，可用性和安全性的关键元素。|(% style="width:75px" %)M
	1273	+|战略管理|(% style="width:690px" %)整合职责以平衡法规要求和执行速度。|(% style="width:75px" %)M
	1274	+|劳动力和人才管理|(% style="width:690px" %)在如何将安全性纳入开发和运营工作方面，对员工和其他相关利益干系人进行培训和辅导。|(% style="width:75px" %)M
	1275	+|业务分析|(% style="width:690px" %)(((
1490	1490	了解内部和外部环境中的安全策略，标准，风险，潜在威胁和漏洞，并将其转化为开发和运营团队的要求。
1491	1491
1492	1492	将安全要求纳入产品积压中。
1493		-)))|(% style="width:90px" %)L
1494		-|基础架构管理|(% style="width:832px" %)(((
	1279	+)))|(% style="width:75px" %)L
	1280	+|基础架构管理|(% style="width:690px" %)(((
1495	1495	安全管理可以通过有关安全标准和培训，隐私审查，威胁建模，凭证管理和数据安全的指南来增强基础架构和平台管理（尤其是在将基础架构用作代码时）。
1496	1496
1497	1497	信息安全管理和风险管理应该是从业者日常工作的组成部分。
1498		-)))|(% style="width:90px" %)L
1499		-|软件开发管理|(% style="width:832px" %)(((
	1284	+)))|(% style="width:75px" %)L
	1285	+|软件开发管理|(% style="width:690px" %)(((
1500	1500	通过有关安全编码标准和培训，隐私审查，威胁建模，代码分析，源代码和凭证管理以及数据安全性的指南来增强软件开发。
1501	1501
1502	1502	信息安全管理和风险管理应该是从业者日常工作的组成部分。
1503		-)))|(% style="width:90px" %)L
	1289	+)))|(% style="width:75px" %)L
1504	1504
1505		-
1506	1506	//ITIL故事：DevSecOps//
1507	1507
1508	1508	//Henri：数据的完整性和安全性是Axle汽车租赁团队工作方式的基础。快速工作以高节奏提供新的应用程序功能时，存在引入安全漏洞的风险，这些漏洞可能会被利用。//
...	...	@@ -1556,7 +1556,6 @@
1556	1556	)))|无|是|可能|是|无
1557	1557	|临时审查|无|无|是|是|无
1558	1558
1559		-
1560	1560	(% style="text-align:center" %)
1561	1561	[[image:1639569697056-454.png]]
1562	1562
...	...	@@ -1605,7 +1605,6 @@
1605	1605	请从业者将此章视为一个多功能工具集，并根据上下文和所执行的工作任务来应用这些工具。实施此处描述的技术不应仅作为目标。应始终将它们视为实现组织目标的手段。这适用于本出版物的其他章节以及总体上的ITIL：应采用并改编这些工具以满足组织的需求。
1606	1606
1607	1607
1608		-
1609	1609
1610	1610	**结论**
1611	1611
...	...	@@ -1627,4 +1627,6 @@
1627	1627
1628	1628	//ITIL4：创建、交付和支持：//提供有关产品和服务管理的文化和团队管理方面的指南，并概述了支持服务管理的各种工具和技术。它演示了如何将管理实践集成到端到端的价值流中。
1629	1629
1630		-
	1413	+
	1414	+
	1415	+[[返回上一章>>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/]]

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