Changes for page 4.高速IT技术

Last modified by superadmin on 2024/04/03, 17:15
From version < 70.1 >
edited by superadmin
on 2022/01/09, 12:39
To version < 30.1 >
edited by superadmin
on 2021/12/15, 20:00
< >
Change comment: 上传新附件1639569657674-856.png

Summary

Details

Icon Page properties
Content
... ... @@ -1,12 +10,3 @@
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 -
10 10  = 4. 高速IT技术 =
11 11  
12 12  本章介绍了表征HVIT环境特征的一些技术选择。有些通常只在这些环境中发现，而另一些是对HVIT工作至关重要的更通用的技术。选择并不详尽；这些技术是帮助高度数字化的组织实现其苛刻目标的工作方式的示例。
... ... @@ -92,9 +92,18 @@
92 92  
93 93  表4.1 与优先级相关的实践
94 94  
95 -[[image:1641700591514-812.png]]
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
96 96  
97 -
98 98  **ITIL故事：优先排序技术**
99 99  
100 100  //Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
... ... @@ -132,11 +132,46 @@
132 132  
133 133  表4.2 与最小可用方法相关的实践
134 134  
135 -[[image:1641700659017-287.png]]
135 +(% style="width:863px" %)
136 +|**ITIL管理实践**|(% style="width:575px" %)**与最小可用方法相关的活动/资源**|(% style="width:87px" %)**影响**
137 +|架构管理|(% style="width:575px" %)(((
138 +使用最小可用的方法来描述服务、技术、信息或环境体系结构，这将为其他类型
136 136  
137 -[[image:1641700701040-265.png]]
140 +的服务或产品工作创建必要的约束、边界或促成因素。
141 +)))|(% style="width:87px" %)H
142 +|业务分析|(% style="width:575px" %)使用最低可行的方法作为从产品或服务中提取核心业务价值的工具。|(% style="width:87px" %)H
143 +|容量与性能管理|(% style="width:575px" %)(((
144 +使用容量和性能管理作为计算最低可行产品或服务所需的最小资源（服务器数量，服务
138 138  
146 +台代理数量等）的基础。
147 +)))|(% style="width:87px" %)H
148 +|监控与事态管理|(% style="width:575px" %)(((
149 +使用监控和事态管理作为设计和配置监视和遥测工具的基础，这些工具用于操作和从最低
139 139  
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 +
140 140  **ITIL的故事：最小可用产品和服务**
141 141  
142 142  //Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
... ... @@ -167,9 +167,29 @@
167 167  
168 168  表4.3 与产品或服务所有权相关的实践
169 169  
170 -[[image:1641700764097-167.png]]
205 +(% style="width:788px" %)
206 +|**ITIL管理实践**|(% style="width:566px" %)**与产品或服务所有权相关的活动/资源**|(% style="width:63px" %)**影响**
207 +|架构管理|(% style="width:566px" %)(((
208 +产品和服务所有者参与阐明，完善基础架构和平台开发积压工作并确定其优先级，并
171 171  
210 +决定是否购买市售的基础架构组件和服务。
211 +)))|(% style="width:63px" %)H
212 +|组合管理|(% style="width:566px" %)（软件）产品所有者和产品或服务经理参与评估和确定产品或服务投资建议的优先级。|(% style="width:63px" %)H
213 +|关系管理|(% style="width:566px" %)(((
214 +与利益干系人的互动。
172 172  
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 +
173 173  **ITIL故事：产品或服务所有权**
174 174  
175 175  //Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
... ... @@ -208,9 +208,17 @@
208 208  
209 209  表4.4 与A/B测试相关的实践
210 210  
211 -[[image:1641700825218-144.png]]
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
212 212  
213 -
214 214  **ITIL的故事：A / B测试**
215 215  
216 216  //Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
... ... @@ -281,10 +281,29 @@
281 281  
282 282  图4.7 基础设施作为代码对服务价值链的贡献的热图
283 283  
347 +‘
284 284  
285 285  表4.5 与基础设施作为代码相关的实践
286 286  
287 -[[image:1641700916381-114.png]]
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
288 288  
289 289  表4.5 列出了与基础设施作为代码相关的实践。
290 290  
... ... @@ -330,11 +330,23 @@
330 330  
331 331  表4.6 与松散耦合信息系统架构相关的实践
332 332  
333 -[[image:1641701019297-720.png]]
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
334 334  
335 -[[image:1641701038534-675.png]]
336 -
337 -
338 338  === 4.2.3 复查 ===
339 339  
340 340  通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
... ... @@ -353,7 +353,20 @@
353 353  
354 354  表4.7 与回顾相关的实践
355 355  
356 -[[image:1641701094058-713.png]]
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
357 357  
358 358  表4.7概述了与回顾相关的实践。
359 359  
... ... @@ -393,9 +393,29 @@
393 393  
394 394  表4.8 免责的时候反思的实践
395 395  
396 -[[image:1641701145033-568.png]]
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 +调查持续改进活动，以识别经验教训，了解系统中的变更以及确定增加或保持未来改进成
397 397  
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 +从回顾中获取经验教训和改进思路。
398 398  
523 +让合作伙伴和供应商收集反馈以进行学习注册。
524 +)))|(% style="width:80px" %)M
525 +
399 399  === 4.2.4 持续业务分析 ===
400 400  
401 401  瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
... ... @@ -431,11 +431,22 @@
431 431  
432 432  表4.9 与持续业务分析相关的实践
433 433  
434 -[[image:1641701202590-318.png]]
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
435 435  
436 -[[image:1641701238590-838.png]]
437 -
438 -
439 439  === 4.2.5 持续集成、持续交付和持续部署 ===
440 440  
441 441  持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
... ... @@ -472,7 +472,20 @@
472 472  
473 473  表4.10 与CI/CD最相关的实践
474 474  
475 -[[image:1641701293452-859.png]]
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
476 476  
477 477  
478 478  **ITIL故事：持续集成、持续交付和持续部署**
... ... @@ -487,11 +487,34 @@
487 487  
488 488  表4.11 软件测试的类型
489 489  
490 -[[image:1641701417790-550.png]]
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 +必须在生产环境中对某些风险进行测试，例如性能风险（尤其是用户负载和用户压力风险），用户接受度测试（用户将其与实际软件一样使用系统）和可观察性风险（以测试有效性、可观察性解决方案和实现）。
491 491  
492 -[[image:1641701444463-764.png]]
653 +在生产中进行测试时，目标应该是最大程度地降低影响客户的测试风险。实现这一目标的策略包括：
493 493  
655 +● **金丝雀发布 **这项新功能最初是针对少数目标用户发布的，后来逐渐增加到所有用户。
494 494  
657 +●** 功能开关** 可以将功能隐藏在功能标志的后面，通过打开或关闭该标志可以轻松启用或禁用
658 +
659 +该功能。
660 +
661 +● **蓝/绿部署 **两个相同的生产环境同时运行（一个“蓝色”和一个“绿色”），只有一个环
662 +
663 +境处于活动状态，为所有生产流量提供服务，而另一个用于部署新版本。
664 +
665 +● **自动化的回滚策略 **发生事件时，自动化工具可以快速将发行版恢复为先前版本。
666 +)))
667 +|(% style="width:165px" %)测试生产环境中的服务|(% style="width:646px" %)为已发布的生产软件实现了许多服务，活动和技术，所有这些都可以进行测试。从服务交付的角度来看，测试流程很重要。 例如，在测试用户是否可以访问支持时，重要的是要问用户获得支持有多容易，用户在软件中在什么情况下做到这一点。
668 +
495 495  为了实现持续测试，应制定一些原则，包括：
496 496  
497 497  * 测试应该以最低级别进行。
... ... @@ -510,906 +510,4 @@
510 510  (% style="text-align:center" %)
511 511  [[image:1639234708265-714.png]]
512 512  
513 -
514 -图4.14 持续测试对服务价值链贡献的热图
515 -
516 -
517 -表4.12 与持续测试最相关的实践
518 -
519 -[[image:1641701509520-551.png]]
520 -
521 -
522 -**ITIL的故事：持续测试**
523 -
524 -//Su：我们投放市场的每个产品都经过全面测试，以确保它是符合目 的并适合使用。应用程序的改进没有什么不同。我们测试了//：
525 -
526 -●     新功能的初步构想，以确保它们有潜力实现我们的目标
527 -
528 -●     史诗、用户故事和接受标准
529 -
530 -●     设计界面的改进，以确保它直观且易用
531 -
532 -●     代码设计和软件架构，以确保其健壮性
533 -
534 -●     修复开发期间引入的错误和故障的代码
535 -
536 -●     生产中的系统和软件
537 -
538 -//在每个阶段，如果测试表明我们引入了明显的低效或缺陷，我们就会重新考虑以前的决定。//
539 -
540 -
541 -=== 4.2.7 看板 ===
542 -
543 -看板是一套原则、实践和常规活动，旨在开发和管理可预测的，有节奏的，持续的工作流程。如果正确应用，它可以极大地加速高质量产品和服务的开发。拉动式触发机制使客户能够通过价值流进行工作。拉动式的工作具有不会被强加于人的优点，从而不必要地增加了工作负担。这在精益团队中很有价值，因为过载是浪费的一种形式。
544 -
545 -
546 -**定义：看板**
547 -
548 -一种基于高度可视化基于拉动的工作流程的精益方法，该工作流程通过平衡需求与可用的容量并改进对系统级别瓶颈的处理，来管理和改进整个人系统的工作。
549 -
550 -看板的主要做法是：
551 -
552 -* 可视化工作
553 -* 限制进行中的工作
554 -* 管理流程
555 -* 明确制定流程政策
556 -* 实施反馈循环
557 -* 改进协作
558 -* 实验性地发展。
559 -
560 -有时组织仅使用看板来可视化进行中的工作。尽管使用看板很重要，但这是看板的有限应用。看板的功能取决于整体实施和对工作流程的持续关注。看板示例如图4.15所示。
561 -
562 -(% style="text-align:center" %)
563 -[[image:1639568393888-457.png]]
564 -
565 -图4.15 看板的一个例子
566 -
567 -
568 -看板建议定期召开会议，以确保有效的沟通。该系统通常被称为“ 看板节奏”。节奏的频率特定于组织，应根据情况进行定义和调整。会议是：
569 -
570 -* 战略评审
571 -* 运营评审
572 -* 风险评审
573 -* 服务交付评审
574 -* 补充会议
575 -* 交付规划会议。
576 -
577 -图4.16显示了看板对服务价值链的贡献。表4.13概述了与看板相关的实践。
578 -
579 -
580 -**ITIL故事：看板**
581 -
582 -//Radhika：我们使用看板来可视化我们应用程序的工作流程，以便我们可以跟踪瓶颈。通常可以通过额外的资源或重新设计工作流来消除这些问题。看板的视觉特性使核心开发团队之外的同事和利益干系人能够了解工作的进展情况，从而使他们能够更好地计划并创建更多价值。//
583 -
584 -
585 -(% style="text-align:center" %)
586 -[[image:1639568494739-564.png]]
587 -
588 -图4.16 看板对服务价值链贡献的热图
589 -
590 -
591 -表4.13 与看板相关的实践
592 -
593 -[[image:1641701559766-478.png]]
594 -
595 -
596 -== 4.3 弹性运营的技术 ==
597 -
598 -弹性运营目标涉及确保在需要时可以使用数字化产品。
599 -
600 -数字投资的潜在价值仅当投入使用的数字化产品和服务可用时才能实现。满足非功能性要求提供了功效，并降低了问题将严重影响产品和服务的功用的风险。
601 -
602 -信息系统越来越依赖于如此众多的组件，以至于行为通常无法被预测或保证。故障安全系统是一种幻想。组织必须为不可避免的和意外的失效做准备。重点不再是在失效之间保持较长的间隔；当不可避免的问题确实发生时，它可以快速恢复服务。这样可以减少对业务运营的干扰。
603 -
604 -弹性适用于系统堆栈的所有部分，也适用于管理这些组件部分的组织。只有每个组件都具有弹性时，面向消费者的部件才具有弹性。弹性运营不会增加潜在的价值投资；相反，他们确保可以实现其潜在的价值。由于信息系统很复杂，因此本质上容易出错，因此弹性涉及损害限制。根据系统的性质，损害可以用收入损失、价格降低，产生的成本和声誉损害来表示。例如，当电子商务网站的可用性或性能较差时：
605 -
606 -* 如果客户转向其他提供商，收入将会损失
607 -* 客户满意度降低而产生价格降低的压力
608 -* 恢复服务，实施规避措施以及与消费者进行沟通会产生成本
609 -* 当提供者不能很好地处理事件时，会造成声誉损害；例如，不采取适当的行动，不关心，隐瞒信息或不从事件中汲取教训。
610 -
611 -IT的消费化导致人们期望随时随地可以使用公司的IT系统。云服务能力可以极大地改进弹性，而云功能的成本仅为本地系统的一小部分。弹性系统和服务不再是一种选择，由于云和IT的消费化，它们已成为现实的期望。
612 -
613 -根据可用性、性能和安全性来衡量弹性操作。可用性是两次失效之间的平均时间和恢复服务的平均时间以百分比规范。众所周知，可用性不可靠，不能说明可用性对服务使用者的影响。这也很难衡量；例如，当系统部分可用时。
614 -
615 -绩效的测量方法多种多样。例如，网页加载时间、数据查询执行时间或批处理流程完成时间。可以根据安全漏洞来衡量安全，但这仅衡量已检测到的漏洞。更好的指标是控制监控的成熟度，以及分析日志信息以识别风险和漏洞的能力。
616 -
617 -可用于实现弹性运营的技术包括：
618 -
619 -* 技术债
620 -* 混沌工程
621 -* 完成的定义
622 -* 版本控制
623 -* 人工智能运营
624 -* 聊天运营
625 -* 站点可靠性工程。
626 -
627 -
628 -**ITIL故事：弹性运营的技术**
629 -
630 -//亨利：我们的应用程序必须可靠且一致，否则我们的客户将其视为有缺陷的。如果他们的工作方式需要变更，我们还需要确保我们的团队有应变能力并且可以适应不同的条件。//
631 -
632 -
633 -=== 4.3.1 技术债 ===
634 -
635 -**定义：技术债**
636 -
637 -通过选择规避措施而不是需要更长时间的系统解决方案来累积待办项的返工。
638 -
639 -在软件开发和管理中，技术债是修复不合格（变更）软件所需的返工待办项。通常，当使用软件时，将进行增强和修复。应用这些变更后，除非努力限制损坏，否则软件的质量将会下降。这被称为“软件熵”，它与HVIT密切相关，因为在软件上的大量投资，变更的频率以及需要变更迅速跟上市场需求的需求。
640 -
641 -技术债是待办的工作，用于解决在增强或修复软件时引起的损坏。这种损坏通常是由于时间、金钱、知识和技能有限所造成的。例如，在软件出现故障时承受恢复正常服务压力的组织可以应用简单的规避措施来快速解决问题。通常有意在以后对其进行正确修复，但是在许多情况下，这不会发生。预期的“正确修复”可能未正式记录，随后将被遗忘。
642 -
643 -技术债也可以在应用程序的初始开发期间发生，在此之前，期限或预算限制导致出现捷径。几乎每个项目都有其遗产，这有时使其捐助者感到惊讶。
644 -
645 -技术利益是指由于质量下降而使变更难以进行的软件应用变更所涉及的成本之和，以及由这些缺陷引起的事件成本。只要利息不高，技术债就是可以接受的。但是，它倾向于积累，并且债务越高，涉及的风险就越大。此风险必须加以管理。
646 -
647 -减少技术债可以减少事件的发生，因此有助于弹性运营。它还有助于有价值的投资和快速研发。这些收益之间应保持平衡。因此，应谨慎考虑技术债的存在，尽可能对其进行鉴定和量化，评估相关的短期和长期风险，并作为（软件）产品管理的一部分做出适当的决定，包括将预算分配给“偿还技术债“（另请参阅第4.3.7节中的错误预算的概念）。
648 -
649 -图4.17显示了技术债对服务价值链的贡献。
650 -
651 -(% style="text-align:center" %)
652 -[[image:1639568670048-316.png]]
653 -
654 -
655 -图4.17 技术债对服务价值链贡献的热图
656 -
657 -
658 -表4.14概述了与技术债相关的实践。
659 -
660 -[[image:1641701689758-164.png]]
661 -
662 -表4.14 与技术债相关的实践
663 -
664 -
665 -**ITIL故事：技术债**
666 -
667 -//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
668 -
669 -//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
670 -
671 -
672 -=== 4.3.2 混沌工程 ===
673 -
674 -**定义：混沌工程**
675 -
676 -为了建立对系统承受生产中动荡环境能力的信心而在系统上进行实验的学科。
677 -
678 -为了解决分布式系统的不确定性，混沌工程依靠四个基本步骤：
679 -
680 -* 定义稳态；这将是普通行为的输出。
681 -* 假设这种稳定状态将持续下去。
682 -* 引入反映真实事态的变量。
683 -* 尝试反驳这个假设。
684 -
685 -混沌工程理想应用的原则是：
686 -
687 -* **围绕稳态行为进行构建和假设 **关注于可测量的系统输出，而不是系统的属性。
688 -* **变化的真实世界事态 **混沌变量反映真实世界的事态。必须通过考虑事态的影响或估计频率来定义优先级。
689 -* **在生产中进行实验 **混沌倾向于直接对生产流量进行实验。
690 -* **使实验自动化以连续运行 **将自动化构建到系统中以推动业务流程和分析。
691 -* **最小化爆炸半径 **应该最小化并控制实验的后果。
692 -
693 -混沌工程的一些优点是：
694 -
695 -* 为团队为随机实例失效做好准备
696 -* 鼓励冗余
697 -* 使系统更强大，从而增强了在复杂系统中快速移动的信心
698 -* 将现实条件引入受控运行中，在弱点引起问题之前就将其发现
699 -* 在影响生产中的客户之前，主动解决最重要的弱点。
700 -
701 -混沌猴子是所谓的猿猴军团中最著名的混沌工程工具集之一。猿猴军团是由Netflix®创建的开源云测试工具的集合。混沌猴子通过禁用某些组件来测试对系统失效的响应，以查看其余系统将如何响应。尽管混沌猴子可能会中断运营，但也有助于它们的长期恢复能力。
702 -
703 -
704 -**定义：混沌猴子**
705 -
706 -通过有意地禁用生产中的组件来测试其余系统如何响应中断的方式来测试IT系统的弹性的工具。
707 -
708 -混沌猴子的部署导致在已识别的系统组中随机选择的系统终止。这会产生接近自然事件的情况，并测试系统承受失效的能力。猿猴军团的另一个成员，合规性猴子，检查每项服务，以实现架构定义的最佳实践。
709 -
710 -猿猴军团的其他成员包括：
711 -
712 -* **延迟猴子 **导致人为延迟，以模拟服务降级并检查相关服务是否充分响应。
713 -* **猴子医生 **进行健康检查以确定不健康的实例，如果所有者不修复根因，则主动将其关闭。
714 -* **安全猴子 **查找并终止安全违规或漏洞的实例。
715 -* **看门猴子 **确保云环境没有混乱和浪费。图4.18显示了混沌工程对服务价值链的贡献。表4.15概述了与混沌工程相关的实践。
716 -
717 -(% style="text-align:center" %)
718 -[[image:1639568794032-283.png]]
719 -
720 -图4.18 混沌工程对服务价值链贡献的热图
721 -
722 -
723 -表4.15 与混沌工程相关的实践
724 -
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" %)(((
733 -通过混乱的工程促进弹性基础设施的建设。
734 -
735 -考虑服务和组件之间的交互以支持需求。
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
748 -
749 -ITIL故事：混沌工程
750 -
751 -//Radhika：我们需要测试该应用程序的弹性。例如，如果成员资格功能停止工作会怎样？客户仍然可以预定汽车？预订是否仍可以追溯分配到他们的账户？//
752 -
753 -//Solmaz：我们使用了混沌猴子工具来了解该应用在胁迫下的工作方式。它使我们能够看到系统可能在哪里崩溃，这意味着我们可以修改代码和软件体系结构以减少或消除薄弱环节。//
754 -
755 -
756 -=== 4.3.3 完成的定义 ===
757 -
758 -**完成的定义**
759 -
760 -拟议产品或服务的商定标准清单。
761 -
762 -应用程序开发人员通常使用敏捷方法“ 完成的定义”。敏捷社区将“完成”定义为“已经产生了可能发布的软件增量”。在DevOps圈子中，此功能已扩展为“已发布到生产环境”。从端到端的角度来看，这种急需的扩展仍然不足。如果用户使用不当，错误地解释数据，做出次优决策或无法做出好的决定，则释放所需的功能将无用。专注于IT部门的职能可能不是阻止它的责任，而是组织的责任。
763 -
764 -因此，对完成的更完整的定义包括操作和使用标准。该技术广泛适用，并且在HVIT环境中经常遇到。
765 -
766 -完成的定义描述了有助于产品或服务实用程序的功用标准，以及有助于其修复的非功效标准。应定义这些非功能性标准并与负责操作的人达成一致。因此，包含非功能性标准的完成定义有助于弹性运营，并通过提高可用性共创价值共创，也有助于加快研发速度，因为需要的返工较少。
767 -
768 -非功能性标准指定了将要操作，维护和增强系统的人员以及将确保安全和法规合规性的人员所需的质量。这些标准解决了执行和演进所需的质量。功能性标准描述“是什么”，而非功能性标准描述“如何”。完成的定义中指定了质量属性，以便开发和支持团队可以在早期阶段考虑它们。对于开发来说，它们是软件设计约束。
769 -
770 -在敏捷软件开发中，“完成”通常意味着具有潜在可部署的软件增量。DevOps将此定义扩展为三类：已部署、已发布和可使用。从共同构服务的角度来看，将工作定义为“完成”的更好方法是用户从其投资中获得期望的成果。不管选择哪种方法，完成的定义都应该是整体的，并着重于价值。
771 -
772 -创建完成的定义时应考虑以下方面：
773 -
774 -* **应准备好使用环境 **应当验证连续集成框架并使其正常工作。
775 -* **支持的交付内容应完整 **且接受所有标准、用户故事和测试。
776 -* **应该有可用的度量标准 **每个发布以验证其满足用户故事和标准（在敏捷世界中被称为“故事点”）非常重要。
777 -* **代码必须易于理解，可维护并且可以支持将来的变更。**
778 -
779 -考虑就绪定义也很有用，它描述了何时可以处理待办项。首字母缩略词“ INVEST”代表有用的标准。项目应为：
780 -
781 -* **独立 **自包含，不依赖于其他待办项。
782 -* **可协商 **进行讨论和微调。
783 -* **有价值 **关于利益干系人将如何受益的问题应该有明确的说明。
784 -* **可估计 **范围足以接受可接受的近似值。
785 -* **足够小 **足以估计并计划到一个时间表中。
786 -* **可测试 **具有明确的验收标准。
787 -
788 - 弹性测试可验证系统在不同领域是否满足约定的非功能性标准，例如可用性、容量、效率、可维护性、性能、隐私、可靠性、可恢复性和安全性。
789 -
790 - 图4.19显示了完成定义对服务价值链的贡献。表4.16概述了完成定义相关的实践。
791 -
792 -
793 -(% style="text-align:center" %)
794 -[[image:1639568893041-234.png]]
795 -
796 -图4.19 完成定义对服务价值链贡献的热图
797 -
798 -
799 -表4.16 与“完成”定义相关的实践
800 -
801 -(% style="width:777px" %)
802 -|**ITIL管理实践**|(% style="width:601px" %)**与“完成”定义相关的活动/资源**|(% style="width:70px" %)**影响**
803 -|可用性管理|(% style="width:601px" %)新服务或变更服务的详细功效要求应与利益干系人协商并达成协议。|(% style="width:70px" %)H
804 -|容量与性能管理|(% style="width:601px" %)完成清单的定义必须考虑容量需求，需求预测以及管理业务和客户期望的性能。|(% style="width:70px" %)H
805 -|变更控制|(% style="width:601px" %)变更支持活动可以围绕完成的定义来组织；例如，使用发布管理或部署管理创建边界。|(% style="width:70px" %)H
806 -|持续改进|(% style="width:601px" %)完成的定义可用于范围和结构持续改进活动，并检查是否已实现结果。|(% style="width:70px" %)H
807 -|部署管理|(% style="width:601px" %)部署管理活动可以围绕完成的定义来组织；例如，使用发布管理创建边界。将发行版移至实际环境时，团队应验证支持的交付成果是否完整：应接受所有要求，用户案例和测试。|(% style="width:70px" %)H
808 -|事件管理|(% style="width:601px" %)事件管理活动可以围绕完成的定义来组织；例如，建立问题管理的界限。|(% style="width:70px" %)H
809 -|信息安全管理|(% style="width:601px" %)应该考虑安全测试，例如漏洞，渗透或策略合规性在针对弹性产品和服务的完成定义中。|(% style="width:70px" %)H
810 -|项目管理|(% style="width:601px" %)项目任务或输出可以使用以下定义定义成功或完成标准：完成的方法。|(% style="width:70px" %)H
811 -|发布管理|(% style="width:601px" %)发布管理活动可以围绕完成的定义进行组织；例如，创建具有变更支持或部署管理的边界。发行必须设计为符合业务，客户和用户的期望。这很重要，评估每个版本以验证它满足用户需求和要求。|(% style="width:70px" %)H
812 -|服务级别管理|(% style="width:601px" %)完成的定义可以阐明提供者和消费者的服务行为，并且可以用作根据预期性能监视实际性能的基础。|(% style="width:70px" %)H
813 -|服务请求管理|(% style="width:601px" %)服务请求管理活动，例如记录或满足请求，可以是使用完成方法的定义进行结构化。|(% style="width:70px" %)H
814 -|服务验证与测试|(% style="width:601px" %)可以围绕完成的定义来组织测试活动，以确保多种类型测试进行。|(% style="width:70px" %)H
815 -|软件开发管理|(% style="width:601px" %)可以开发（或配置）软件以满足部署之前完成的定义进入实时环境，确保代码易于理解，可维护并且随时可以支持未来的变化。|(% style="width:70px" %)H
816 -|业务分析|(% style="width:601px" %)保修和实用程序的功效和功用要求必须记录在为了满足客户的需求和期望。|(% style="width:70px" %)M
817 -|服务设计|(% style="width:601px" %)完成的定义应以客户为中心，以简化设计方法采用并确保服务将可维护且具有成本效益。|(% style="width:70px" %)M
818 -|服务目录管理|(% style="width:601px" %)发行新功能，产品或服务时，服务目录必须被更新。|(% style="width:70px" %)L
819 -|服务台|(% style="width:601px" %)在完成的定义中指定质量属性，以便开发和支持团队可以在早期阶段考虑他们。|(% style="width:70px" %)L
820 -
821 -**ITIL故事：完成定义**
822 -
823 -//Su：该应用程序的交付团队包括来自Alxe汽车租赁部门许多部门人员，当开发人员移交工作代码时，对完成传统定义并不是最有效或最准确的。我们要保证该应用程序的弹性、功效、可维护性、功用和可用性。对我们来说，“完成“是指：//
824 -
825 -//●     生产和测试环境已准备就绪//
826 -
827 -//●     准备了持续集成框架//
828 -
829 -//●     用户故事和测试已得到认可//
830 -
831 -//●     度量和指标已被接受并且可以进行测试//
832 -
833 -//●     该软件具有可读性、可用性和适应性//
834 -
835 -
836 -=== 4.3.4 版本控制 ===
837 -
838 -**定义：版本控制**
839 -
840 -信息系统、产品和服务的来源和人工制品的管理。
841 -
842 -版本控制与HVIT特别相关，因为已经在好的版本控制和高IT性能之间建立了强大的关联：它提供了更早的变更前置时间、更频繁的部署以及更快地平均恢复服务时间。
843 -
844 -版本控制跟踪在哪些环境中存在哪些版本的源和人工制品。在版本控制系统中存储软件源代码的通用实践扩展为包括IT系统、产品或服务的几乎所有其他重要组件，例如：
845 -
846 -* 为每个环境创建和配置基础的脚本，包括开发、测试和生产环境
847 -* 验收标准、测试用例和测试本身
848 -* 外部和内部库、模块和组件
849 -* 有关相互依赖性的信息
850 -* 部署管道的脚本和配置文件
851 -* 运行任务的脚本，例如重复操作
852 -* 文档，包括架构决策
853 -* 构建和运行系统所需的制品
854 -* 合同，协议等。
855 -
856 -因此，版本控制不仅适用于服务组件（在获取或构建价值链活动中开发/设计和管理），而且还适用于服务级别。适当的版本控制可以收集有关产品或服务所需的每个组件的当前和以前状态的有价值的信息。该信息包括变更的初始状态、变更、变更时间和日期、操作变更的人员以及任何其他澄清和支持信息。版本控制的优点包括：
857 -
858 -* 版本控制支持基础架构即代码技术（请参阅第4.2.1节）。
859 -* 版本控制应用于源代码和产品，可以缩短变更的前置时间、更频繁的部署以及更快的平均恢复服务时间。
860 -* 版本控制支持的自动化测试与更快的变更前置时间相关。
861 -* 版本控制是持续交付的前提条件，而持续交付与更频繁的部署相关。
862 -
863 -因此，版本控制有助于弹性运营和快速研发。也可以将其视为用于架构的促进因素：一种实践，其中的架构决策不受限制，而是使产品和服务能够持续发展和实现改进点，而无需重新设计和重新开发先前的解决方案。
864 -
865 -图4.20显示了版本控制对服务价值链的贡献。表4.17概述了与版本控制相关的实践。
866 -
867 -(% style="text-align:center" %)
868 -[[image:1639568991350-151.png]]
869 -
870 -图4.20 版本控制对服务价值链贡献的热图
871 -
872 -
873 -表4.17 与版本控制相关的实践
874 -
875 -(% style="width:890px" %)
876 -|**ITIL管理实践**|(% style="width:689px" %)**与版本控制相关的活动/资源**|(% style="width:91px" %)**影响**
877 -|部署管理|(% style="width:689px" %)使用版本控制的存储库来部署新的或变更的服务组件，或者返回以前的版本。|(% style="width:91px" %)H
878 -|信息安全管理|(% style="width:689px" %)通过标记易受攻击的版本来解决或消除信息安全风险服务组件。|(% style="width:91px" %)H
879 -|基础设施管理|(% style="width:689px" %)基础架构组件，配置设置以及虚拟和物理基础架构可以使用版本控制的存储库正式存储和管理组件。|(% style="width:91px" %)H
880 -|服务配置管理|(% style="width:689px" %)CMDB可以联合在一起，利用版本控制的代码存储库，基础架构即代码配置文件，甚至是物理设备和其他硬件的存储。办理登机手续应该每天发生多次，并且应该管理环境规范和版本化。|(% style="width:91px" %)H
881 -|软件开发管理|(% style="width:689px" %)代码，甚至其他软件组件的配置设置都可以正式使用版本控制的存储库来管理软件输出开发和管理工作。|(% style="width:91px" %)H
882 -|持续改进|(% style="width:689px" %)创建当前环境的基线，并在改进完成后更新基线。|(% style="width:91px" %)M
883 -|事件管理|(% style="width:689px" %)使用版本控制的软件或硬件组件存储库来解决一个事件。|(% style="width:91px" %)M
884 -|知识管理|(% style="width:689px" %)服务版本时更新知识库并传达信息组件发生变化。|(% style="width:91px" %)M
885 -|服务连续性管理|(% style="width:689px" %)了解服务组件新版本的影响；并且如果可行，将它们传播到服务连续性和灾难恢复计划中。|(% style="width:91px" %)M
886 -|服务请求管理|(% style="width:689px" %)使用版本控制的软件或硬件组件存储库来快速满足要求。|(% style="width:91px" %)M
887 -
888 -**ITIL故事：版本控制**
889 -
890 -//Marco：我们实行持续集成和持续交付，我们利用版本控制系统地记录我们发布的应用程序的每次迭代，如果发布不稳定，我们可以通过将服务返回到先前的稳定版本来快速还原该服务。//
891 -
892 -
893 -=== 4.3.5 人工智能运营 ===
894 -
895 -**定义：AIOps**
896 -
897 -将机器学习和大数据应用于IT运营以获取持续的见解，并通过自动化提供持续的修复和改进。也称为“IT运营的人工智能“或”算法IT运营“。
898 -
899 -AIOps旨在将人工智能引入IT运营，以应对基础架构持续发展中的现代趋势所带来的挑战，例如软件定义系统的增长。这些新技术的影响（例如，基础设施的重新配置和重塑速率的增加）需要更自动化和动态的管理技术，这些技术可能在组织的数字化服务上具有重要的影响。
900 -
901 -AIOps平台用于增强和部分替代许多主要的IT运营功能，例如可用性和性能监控、失效识别、预测分析以及事态相关性和分析。
902 -
903 -AIOps利用数据平台和机器学习，收集观察数据（例如事态、日志文件、运营指标）和参与数据（例如客户请求和服务台票证），并通过对该数据应用认知或算法处理得出见解。
904 -
905 -这些见解可用于驱动一些或全部范围的通用输出，例如：
906 -
907 -* **问题检测和预测 **帮助服务组织更快地对事件做出响应。
908 -* **主动的系统维护和调整 **减少了人工和潜在错误。
909 -* **阈值分析 **可以更准确地了解系统的正常运行范围。
910 -
911 -AIOps的应用在很大程度上取决于要分析的数据的可用性，以及数据是否适合进行分析，如果其性质极其复杂，原因和影响之间的相关性较弱，则可能不会。
912 -
913 -一些组织还开始在IT运营以外使用AIOps，以使业务管理人员实时了解IT对业务的影响。这样可以使他们随时了解情况，并使他们能够基于实时的相关数据做出决策。
914 -
915 -图4.21显示了AIOps对服务价值链的贡献。表4.18概述了与AIOps相关的实践。
916 -
917 -(% style="text-align:center" %)
918 -[[image:1639569057821-522.png]]
919 -
920 -图4.21 AIOps对服务价值链贡献的热图
921 -
922 -
923 -表4.18 与AIOps相关的实践
924 -
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
939 -
940 -**ITIL故事：AIOps**
941 -
942 -Radhika：：成千上万的客户使用该应用程序并租用我们的车辆。这些转换会产生大量数据，这是有关客户需求的丰富信息来源。
943 -
944 -Su：我们创建了脚本来分析数据，查找使用模式并优化服务的基础架构。例如，如果数据表明电动汽车的用户正在达到电池充电的终点，则脚本会自动突出显示提示，说明如何为电池充电，以及最近的充电设施的地图。
945 -
946 -
947 -=== 4.3.6 聊天运营 ===
948 -
949 -ChatOps是一个模型，其中人员、工具、流程和自动化都连接在透明的流程中。该模型有助于控制管道和协作。它是即时通信与运营执行的紧密结合：这是一个新兴的运动，促进了多个团队、工具和DevOps平台的集成。通过将工具和平台进行对话来驱动开发。当机器人是团队成员时，可以向他们发送请求并获得即时响应。
950 -
951 -ChatOps支持人与工具之间的协作通信，通过消除对重复信息的请求并自动执行一些常规的IT运维操作来减少事件响应时间。
952 -
953 -ChatOps的元素包括：
954 -
955 -* **聊天平台 **连接利益干系人，团队及其工作系统的服务。
956 -* **Bots ** ChatOps模型的核心。Bot存在并且可以在协作工具和DevOps工具之间工作。他们接收团队成员的请求，然后通过执行脚本从集成系统中检索信息。
957 -* **集成和自动化服务 **ChatOps中的第三方元素。例如，用于问题跟踪：版本控制系统、基础架构即代码、持续集成服务器或监控工具。
958 -
959 -这款模型变得越来越受欢迎。组织将其聊天平台连接到其构建系统，以便在其持续集成服务器上接收通知并执行和查询过程。相同的模型可以应用于质量保证团队。ChatOps工作流程考虑：
960 -
961 -* 工作需要
962 -* 工作进行中
963 -* 工作完成。
964 -
965 -模型可以促进反馈，改进沟通和交叉培训并增强团队协作。在“聊天”中，人们进行协作和创新，从而推动进步。通过收集知识并确定按计划或预期提供服务的要求，ChatOps使工作人性化。
966 -
967 - 这类工具强调了在工具、运营团队和消息传递工具之间需要即时协作。ChatOps是传统聊天的发展，因为它使系统能够加入对话。例如，DevOps或IT和服务管理工具可以将事件或事态通知支持小组。
968 -
969 - 图4.22显示了ChatOps对服务价值链的贡献。表4.19概述了与ChatOps相关的实践。
970 -
971 -(% style="text-align:center" %)
972 -[[image:1639569157526-866.png]]
973 -
974 -图4.22 ChatOps对服务价值链贡献的热图
975 -
976 -
977 -表4.19 与ChatOps相关的实践
978 -
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
990 -
991 -=== 4.3.7 站点可靠性工程 ===
992 -
993 -**定义：站点可靠性工程**
994 -
995 -该学科结合了软件工程的各个方面，并将其应用于基础结构和操作问题，旨在创建超可扩展且高度可靠的软件系统。
996 -
997 -由于高度数字化的组织要求高度弹性的运营，因此站点可靠性工程（SRE）与HVIT特别相关。
998 -
999 -SRE将软件开发思维方式应用于IT运营，并有助于使开发和运营保持一致。SRE团队将时间分散在执行IT运营、指导IT运营团队以及开发可提高IT系统弹性和性能的软件之间。他们倾向于花费少于一半的时间在琐事工作上（否则，这表明系统存在问题）。
1000 -
1001 -琐事被定义为工作，即：
1002 -
1003 -* **手动 **需要人工的时间。
1004 -* **重复性 **一遍又一遍。
1005 -* **可自动化的 **因为不需要特殊的人工判断，所以可以通过机器来实现。
1006 -* **战术型 **由中断驱动和被动式驱动，而不是由策略驱动和主动驱动。
1007 -* **缺乏持久性价值 **并非永久性地改进和服务。
1008 -* **线性缩放 **与服务的大小、流量或用户的数量成比例地缩放。
1009 -
1010 -SRE基于经验表明，系统很复杂，因此会发生故障。因此，在预防故障和减少无法预防的失效的影响之间可以进行权衡，例如通过将系统设计为逐渐降级而不是突然失效。认识到人是复杂系统的适应性要素，并且他们的专业知识与系统的其他部分一样在发生变化，因此失效被认为是学习的机会。
1011 -
1012 -从失效中学习并不是专注于根本原因的识别，因为在复杂系统中这是无效的，甚至是不可能的（请参阅第3.2.3.1节）。相反，失效是用来提高团队的集体知识的。它们帮助人们不断地校准其心理模型，以便他们可以更轻松地识别危害，并采取行动将系统保持在可接受的性能范围内。从业人员评估何时应用标准修复程序以及何时需要即兴创作。他们永远无法确定其行动的后果，他们会从反馈中学习有关系统性能如何根据其行动而变化的信息。因为团队应该承担风险，所以不要将责任归咎于责备文化至关重要。虽然算法在机器学习中占有一席之地，例如，启发式算法在处理复杂系统方面更为有效，因此人工判断至关重要。这需要智力，经验和采取行动的动力；和鼓励期望行为的工作场所。
1013 -
1014 -在可用性管理中，平衡停机预防和事件解决很重要。相应的关键可用性指标是MTBF和MTRS。系统越复杂，不可避免的失效就越多，这意味着重点应该从预防失效转移到快速恢复服务。正确的平衡因服务而异，具体取决于服务的功效要求和基础系统的特性。在HVIT环境中，系统通常会更复杂，因此，专注于减少MTRS比增加MTBF更有效。
1015 -
1016 -平衡对新功能和服务可靠性的投资可能是一项挑战。错误预算是一个功能强大的SRE工具，可在此方面提供帮助。变更往往会导致系统事件。功能的开发工作和稳定性的开发工作需要平衡。错误预算是一种控制机制，可为开发工作分配适当的能力以保持稳定，并确保适当的平衡。当服务接近其错误预算时，产品团队应专注于改进而不是新功能。
1017 -
1018 -错误预算表示为100％减去服务的服务水平目标（SLO）。99.9％的SLO服务的错误预算为0.1％。这笔预算应用于改进稳定性。错误预算允许团队根据策略进行自我调整，如果超出错误预算，后果将不堪设想。重要的是，应以影响服务消费者体验的术语表示SLO，而不是内部系统的KPI。
1019 -
1020 -SRE对可用性，延迟和性能的改进都有助于恢复操作。图4.23显示了SRE对服务价值链的贡献。
1021 -
1022 -表4.20概述了与SRE相关的实践。
1023 -
1024 -
1025 -(% style="text-align:center" %)
1026 -[[image:1639569226390-186.png]]
1027 -
1028 -图4.23 SRE对服务价值链贡献的热图
1029 -
1030 -
1031 -表4.20 与SRE相关的实践
1032 -
1033 -(% style="width:840px" %)
1034 -|**ITIL管理实践**|(% style="width:707px" %)**与SRE相关的活动/资源**|(% style="width:51px" %)**影响**
1035 -|可用性管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。跟踪“技术性” MTBF和（更重要的是）MTRS指标，例如用户中断时间，丢失的转换数量，丢失的业务价值和用户满意度。使用错误预算来平衡服务的可靠性和创新。|(% style="width:51px" %)H
1036 -|容量与性能管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。监控系统和已定义的SLO必须加以考虑和衡量。改进监视功能，以便在出现问题时更好地了解系统。|(% style="width:51px" %)H
1037 -|变更控制|(% style="width:707px" %)使用SRE技术和工具来启用对服务组件的变更以及失败变更的回滚。|(% style="width:51px" %)H
1038 -|事件管理|(% style="width:707px" %)使用SRE技术和工具来管理基础架构或平台层中的事件。|(% style="width:51px" %)H
1039 -|基础架构管理|(% style="width:707px" %)使用SRE技术和工具来帮助架构师和设计基础架构和平台功能以满足组织的需求。|(% style="width:51px" %)H
1040 -|监控和事态管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。|(% style="width:51px" %)H
1041 -|问题管理|(% style="width:707px" %)(((
1042 -来自SRE工具的数据可帮助识别问题，确保通过使用自动化快速应用规避措施。
1043 -
1044 -自动化IT流程可提高弹性并减少工作量。
1045 -
1046 -回顾。
1047 -)))|(% style="width:51px" %)H
1048 -|服务设计|(% style="width:707px" %)在设计阶段进行SRE协作可以防止在生产后期出现各种问题或事件。尽管可以在开发生命周期的后期撤消或纠正设计决策，但这种变更付出了高昂的努力成本和复杂性。|(% style="width:51px" %)H
1049 -|软件开发管理|(% style="width:707px" %)向SRE团队提供要求并根据反馈采取行动。|(% style="width:51px" %)H
1050 -|部署管理|(% style="width:707px" %)部署过程应与服务设计中描述的风险过程保持一致。|(% style="width:51px" %)M
1051 -|组织变革管理|(% style="width:707px" %)SRE团队的核心职责是为团队快速创新做好准备。|(% style="width:51px" %)M
1052 -|发布管理|(% style="width:707px" %)借助SRE，用于发布软件的技术已应用于数字化基础架构。|(% style="width:51px" %)M
1053 -|服务配置管理|(% style="width:707px" %)借助SRE，可以将自动发现和版本控制应用于基础架构组件。|(% style="width:51px" %)M
1054 -|服务验证与测试|(% style="width:707px" %)对于SRE中的发布工程，建议连续的构建测试目标与确定项目发布的相同测试目标相对应。|(% style="width:51px" %)M
1055 -
1056 -**ITIL故事：站点可靠性工程**
1057 -
1058 -// Su：我们添加到应用程序的功能越多，它变得越复杂，其中的代码失败的可能性就越大。失败是任何软件平台都不可避免的功能。应用失败的方式可以教会我们如何对其进行重新校准以使其更具弹性。//
1059 -
1060 -//Radhika：站点可靠性工程在减少服务故障的需求与减少服务故障之间进行平衡的需求之间取得了平衡。我们越能自动化工作并减少重复的手动操作，代码就越强大。价值共创的技术//
1061 -
1062 -
1063 -== 4.4 价值共创的技术 ==
1064 -
1065 -价值共创目标涉及通过服务提供商和服务消费者的紧密合作，从数字化产品价值共创。
1066 -
1067 -价值共创是服务消费者有效地使用服务提供商的产品和服务，并从其功用和功效中受益。只有通过从自动化信息系统获得的信息来改进决策（无论是由人，自动化还是AI来完成），才能实现数字投资的回报。因此，用户必须了解数字化产品和信息及其在上下文中的用途。他们应该充分理解该功能以适当地使用它，并能够正确地解释信息以改进决策。最后，人或事必须根据这些决定采取行动；只有这样，价值才能实现。
1068 -
1069 -例
1070 -
1071 -有人使用叫车应用程序前往机场。他们错误地将指示的到达时间解释为保证而非估计。他们做出错误的决定等待。然后他们会紧张地飞往机场，因为他们可能会错过航班。正确地解释后，这些信息将使他们决定搭乘一辆普通的出租车，因此将具有价值。
1072 -
1073 -许多用户没有有效地使用信息系统的功能。他们还会误解系统提供的数据的含义，随后做出次优的决策，因此无法获得所需的IT投资回报。不仅无法实现潜在价值，而且在出现问题时生产率通常会下降。造成的某些损失是由于与弹性操作相关的问题所致，而某些损失是由于服务使用者的滥用所致。这意味着应该优先考虑主动的功能用户支持。在业务环境中，这种形式的支持更适合于位于同一地点的角色，例如充当“价值实现教练”的主动超级用户，而不是远程服务台。
1074 -
1075 -“价值共创”是指服务消费者、服务提供商和其他利益干系人的价值。对于服务使用者而言，价值是服务输出促进的成果。对于服务提供商而言，取决于投资的性质，价值可以用不同的术语表示，例如数字化产品和服务的收入、网站流量以及降低的成本和风险。
1076 -
1077 -在HVIT环境中，服务使用者经常使用数字化产品和服务，因此期望值更高。消费者需要更直观，响应更快的用户体验和客户体验。服务提供商更好地了解服务消费者如何使用IT服务或数字化产品，他们为他们提供更好的支持。同样，服务消费者对服务提供商如何提供IT服务或数字化产品的了解越多，他们与他们进行有效交互的能力就越强。这些概念说明了服务的共生、共创性的本质。
1078 -
1079 -尽管按照定义，数字体验将是基于算法的，但是经验丰富的数字服务消费者希望它也应该是复杂的，并且要尽可能地适应他们的情况。如果这对于数字服务来说太困难了，那么服务消费者将期望与服务提供商的员工有丰富的身体/模拟/人类体验。在数字体验依赖于高级算法的情况下，人类体验则依赖于应对不可预测的情况所需的高级启发式方法。这样的服务交互是社会交互，并且服务可能会因人类交互中的小细节而被破坏。经验丰富的服务提供商和消费者认识到环境和对方的人性。这产生了一种相互经验，在彼此尊重彼此立场的情况下，已经实现了可能的成就。
1080 -
1081 -共创不仅与服务交互有关，而且在其中实现价值。这也与消费者参与服务设计和进一步开发有关。敏捷产品所有者与开发团队之间的协作是IT从业人员、业务人员以及某些情况下客户与消费者之间紧密协作的一个很好的例子。这样自成体系的面向产品或服务的团队非常有效。在许多情况下，只有在设计信息系统时考虑到这种工作方式，才能实现这种构造，从而使各个小型团队可以在较大系统的相对隔离的部分上工作而无需太多交互。这需要一个松散耦合的信息系统体系结构（请参阅第4.2.2节）。
1082 -
1083 -支持价值共创的一项重要技术是服务体验。
1084 -
1085 -
1086 -**ITIL故事：价值共创的技术**
1087 -
1088 -//Henri：我们的目标是为所有利益干系人价值共创，因此，无论表面上发生什么变化，我们都需要确保为预订汽车提供的界面是一致且直观的。该应用程序应无缝响应客户要求，以确保用户获得提供最佳价值的优化服务。//
1089 -
1090 -
1091 -=== 4.4.1 服务体验 ===
1092 -
1093 -“服务体验”是指服务消费者对服务的评价是基于服务的“技术”输出以及从人的角度看待它的方式这一事实。这意味着服务提供商应该越来越意识到消费者的需求以及他们可用来价值共创的资源。不会被动地获得服务：价值共创需要消费者的努力。服务提供者和使用者必须动态地响应彼此的行为，并尽可能地容纳异常。
1094 -
1095 -当在一些具有数字功能的组织中，业务和IT融合为一个组织实体时，就不再需要业务和IT实体。因此，也不再需要管理业务与IT的关系。“业务人员”和“ IT人员”向同一管理人员报告，具有相同的目标，并且通常在物理上位于同一地点。当采用敏捷或Scrum的工作方式时，有一个相对独立的团队致力于一个产品，则业务人员和IT人员在同一团队中，产品所有者代表业务利益。产品负责人经常管理与外部客户和其他利益干系人的关系。这些其他利益干系人包括寻求协同作用的其他产品所有者；例如知识和资源共享。
1096 -
1097 -数据分析和机器学习可以极大地促进关系管理。信息安全和道德也同样重要。客户体验管理和客户旅程是值得考虑的其他主题。
1098 -
1099 -有关服务关系和服务体验的更多详细信息，请参见ITIL4：推动利益干系人价值。图4.24显示了服务经验对服务价值链的贡献。
1100 -
1101 -表4.21概述了与服务经验相关的实践。
1102 -
1103 -
1104 -(% style="text-align:center" %)
1105 -[[image:1639569323167-699.png]]
1106 -
1107 -
1108 -图4.24 服务体验对服务价值链贡献的热图
1109 -
1110 -
1111 -表4.21 与服务体验相关的实践
1112 -
1113 -(% style="width:977px" %)
1114 -|**ITIL管理实践**|(% style="width:719px" %)**与服务体验相关的活动/资源**|(% style="width:83px" %)**影响**
1115 -|业务分析|(% style="width:719px" %)除了关于功用和功效的传统要求之外，了解用户需求并将其转化为客户体验或用户体验要求。|(% style="width:83px" %)H
1116 -|服务目录管理|(% style="width:719px" %)从技术和体验方面描述服务和产品。|(% style="width:83px" %)H
1117 -|服务设计|(% style="width:719px" %)表达客户体验和用户体验的需求超出了基本体验。|(% style="width:83px" %)H
1118 -|服务台|(% style="width:719px" %)(((
1119 -善解人意并拥有情绪智力，以了解用户的体验需求。
1120 -
1121 -让用户选择沟通渠道。
1122 -
1123 -服务经验需要技术和信息支持者，例如自助服务工具，在线门户，移动应用程序，呼叫中心工具和聊天。
1124 -
1125 -使用用户满意度作为KPI。
1126 -
1127 -评估用户体验，同时选择与用户进行双向通信的工具。
1128 -
1129 -收集服务体验数据（用户对服务满意/不满意的粗略估计）。
1130 -)))|(% style="width:83px" %)H
1131 -|服务水平管理|(% style="width:719px" %)促进对服务消费者的心理和服务交互对消费者的（情感）影响的良好理解。|(% style="width:83px" %)H
1132 -|软件开发管理|(% style="width:719px" %)所需的服务体验会通知用户界面的设计。|(% style="width:83px" %)H
1133 -|监控与事态管理|(% style="width:719px" %)除技术监视和事态管理之外，还开发和配置工具和技术以监视服务体验和相关事态。|(% style="width:83px" %)M
1134 -|关系管理|(% style="width:719px" %)善解人意，在情感上能够理解消费者的体验需求。|(% style="width:83px" %)M
1135 -|服务验证与测试|(% style="width:719px" %)开发和维护服务体验测试。|(% style="width:83px" %)M
1136 -|供应商管理|(% style="width:719px" %)基于主观和客观协议来参与和管理供应商。|(% style="width:83px" %)M
1137 -
1138 -**ITIL故事：服务体验**
1139 -
1140 -//Su：在Axle汽车租赁公司，业务与IT之间没有鸿沟。开发团队协作以提供可响应客户需求的服务体验。我们使用应用程序和车辆中的数据来指导服务的优化和自动化。该应用程序是可定制的，因此用户可以根据自己的需求优化服务。//
1141 -
1142 -
1143 -== 4.5 保证合规的技术 ==
1144 -
1145 -保证合规目标涉及确保服务提供和服务使用在治理，风险和合规性方面符合公司和法规指令。除了确保合规性之外，确保责任人员实现合规性也很重要。
1146 -
1147 -尽管外部需求可能保持不变，但是对于启用数字化技术的组织来说，可能会有其他更合适的方式来实现它们。
1148 -
1149 -高速往往与冒险息息相关，从商业角度看，这些风险可能是必要的。矛盾的是，组织可能承担的最大风险之一就是没有承担足够的风险。
1150 -
1151 -但是，必须证明风险是合理的，并且组织必须遵守内部规则和外部法规。必须确保理事机构遵守其指示。保证合规性可以确保对治理，风险和合规性问题负责并受其影响的人们放心，因为他们知道组织在这些约束条件下会更加自信。
1152 -
1153 -关于治理，从业者不治理而是被治理。他们在治理框架内运营，并且必须了解适用的限制以及如何在该框架内采取行动。从业者的见识和判断会影响他们的行为。他们越有洞察力，他们的判断能力越强，从业人员就越有能力判断何时有必要在合理的相关收益和风险下偏离规则。这就要求从业者理解约束背后的思想。
1154 -
1155 -保证合规可以通过（不存在）安全漏洞、监管机构罚款、宣传不佳、内部和外部审计师要求采取的措施以及确保与治理，风险和合规性问题相符的措施成本来衡量保证的符合性。
1156 -
1157 -可以用来保证合规的技术包括：
1158 -
1159 -* DevOps审核防御工具包
1160 -* 开发安全
1161 -* 同行评审
1162 -
1163 -**ITIL故事：保证合规的技术**
1164 -
1165 -//Henri：与所有道德企业一样，Axle完全遵守法律法规。我们利用保证合规的技术，因为有时IT进步如此之快，以致可以忽略或延迟遵从性要求。我们敬业的治理团队只是我们关注合规性要求变化的方式之一。//
1166 -
1167 -
1168 -=== 4.5.1 DevOps审核防御工具包 ===
1169 -
1170 -DevOps审核防御工具包17是指南，解决了DevOps社区中新的、更流畅的工作模式所引起的IT与审核之间的紧张关系。它有助于向审计师证明IT部门了解业务风险并正在适当地减轻风险。该工具包建议了一些技术，这些技术可以降低风险，并在IT部门和审计师之间建立共同的观点和共识。因此，它有助于保证合规。通过减少不必要的官僚主义，它也为快速发展做出了贡献。
1171 -
1172 -DevOps审核防御工具包与HVIT有关，因为HVIT的某些原理和技术似乎与常规合规性要求相抵触。但是，通常情况下，这是寻找获得所需结果的其他方法的情况。内部法规源自外部要求，通常可以找到替代的内部法规。但是，使审核员参与此过程非常重要。
1173 -
1174 -图4.25显示了DevOps Audit Defense Toolkit对服务价值链的贡献。表4.22概述了与DevOpsAudit Defense Toolkit相关的实践。
1175 -
1176 -(% style="text-align:center" %)
1177 -[[image:1639569448205-317.png]]
1178 -
1179 -图4.25 DevOps审计防御工具包对服务价值链贡献的热图
1180 -
1181 -
1182 -表4.22 DevOps审计防御工具包与之相关的实践
1183 -
1184 -(% style="width:968px" %)
1185 -|**ITIL管理实践**|(% style="width:650px" %)**与DevOps审计防御工具包相关的活动/资源**|(% style="width:97px" %)**影响**
1186 -|持续改进|(% style="width:650px" %)审核提供了正式注册，确定优先级和进行管理的新信息或改进机会。|(% style="width:97px" %)H
1187 -|信息安全管理|(% style="width:650px" %)在产品生命周期中设计和实施控制措施，以提供广泛的可追溯性和联合责任制。|(% style="width:97px" %)H
1188 -|监控与事态管理|(% style="width:650px" %)合并性能和事态数据的运营数据仓库提供了丰富的信息库，以审核控制的实施和性能。|(% style="width:97px" %)H
1189 -|服务配置管理|(% style="width:650px" %)标准化配置可支持安全性和审核要求。|(% style="width:97px" %)H
1190 -|知识管理|(% style="width:650px" %)使员工和其他主要利益干系人可以访问相关政策文档和以前的审核报告。|(% style="width:97px" %)M
1191 -|风险管理|(% style="width:650px" %)在企业风险管理，技术风险管理和新的工作方式之间创建一种平衡，实用的方法。|(% style="width:97px" %)M
1192 -|劳动力和人才管理|(% style="width:650px" %)培训员工的义务和义务，以确保他们遵守所有相关政策和法规。|(% style="width:97px" %)M
1193 -|业务分析|(% style="width:650px" %)将审核结果和建议的补救措施纳入产品积压。|(% style="width:97px" %)L
1194 -|战略管理|(% style="width:650px" %)将定期的外部或内部审核合并到服务的路线图中，以提供对服务的独立管理。|(% style="width:97px" %)L
1195 -
1196 -=== 4.5.2 开发安全 ===
1197 -
1198 -大多数组织都有专门的信息安全团队，该团队执行风险评估并定义策略，规程和控制。在高速环境中，信息安全已尽可能集成到开发和运营的日常工作中，并将对过程控制的依赖转移到验证前提条件（例如员工的专业知识和完整性）上。安全员的角色从“维持治安”转变为使其他人能够采取必要措施。
1199 -
1200 -“ DevSecOps”是指将与安全相关的活动集成到应用程序开发和IT运营的日常工作中。在整个DevOps流程中，跨文化，自动化，指标和共享（CAMS或CALMS加上精益）的四个支柱都内置了安全性。
1201 -
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 -图4.26显示了DevSecOps对服务价值链的贡献。
1237 -
1238 -表4.23列出了与DevSecOps相关的实践。
1239 -
1240 -
1241 -(% style="text-align:center" %)
1242 -[[image:1639569550207-851.png]]
1243 -
1244 -图4.26 DevSecOps对服务价值链贡献的热图
1245 -
1246 -
1247 -表4.23 与DevSecOps相关的实践
1248 -
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" %)(((
1256 -安全管理提供有关关键证书管理，CD管道安全检查，容器安全，自动渗透测试以及数据和性能监视的指南。
1257 -
1258 -信息安全管理和风险管理应该是从业者日常工作的组成部分。
1259 -)))|(% style="width:75px" %)M
1260 -|知识管理|(% style="width:690px" %)使员工和其他主要利益干系人可以访问相关的政策文档。|(% style="width:75px" %)M
1261 -|风险管理|(% style="width:690px" %)(((
1262 -在企业风险管理，技术风险管理和新的工作方式之间创建一种平衡，实用的方法。
1263 -
1264 -在变更IT服务时，确定并消除对外部团队/团队的依赖，这可能涉及将批准权限委派给团队的产品/交付经理。
1265 -
1266 -投资具有定义和集成控制的过程自动化（例如CI / CD），以执行职责分离的要求。除此之外，采用独立的第三方合规软件可以中止部署的生产，直到获得批准为止。
1267 -
1268 -详细说明供应商合同中的要求和风险控制措施，以支持职责整合，并守组织的安全策略。
1269 -
1270 -进行价值流映射，以识别和最小化流程移交和批准。
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" %)(((
1276 -了解内部和外部环境中的安全策略，标准，风险，潜在威胁和漏洞，并将其转化为开发和运营团队的要求。
1277 -
1278 -将安全要求纳入产品积压中。
1279 -)))|(% style="width:75px" %)L
1280 -|基础架构管理|(% style="width:690px" %)(((
1281 -安全管理可以通过有关安全标准和培训，隐私审查，威胁建模，凭证管理和数据安全的指南来增强基础架构和平台管理（尤其是在将基础架构用作代码时）。
1282 -
1283 -信息安全管理和风险管理应该是从业者日常工作的组成部分。
1284 -)))|(% style="width:75px" %)L
1285 -|软件开发管理|(% style="width:690px" %)(((
1286 -通过有关安全编码标准和培训，隐私审查，威胁建模，代码分析，源代码和凭证管理以及数据安全性的指南来增强软件开发。
1287 -
1288 -信息安全管理和风险管理应该是从业者日常工作的组成部分。
1289 -)))|(% style="width:75px" %)L
1290 -
1291 -//ITIL故事：DevSecOps//
1292 -
1293 -//Henri：数据的完整性和安全性是Axle汽车租赁团队工作方式的基础。快速工作以高节奏提供新的应用程序功能时，存在引入安全漏洞的风险，这些漏洞可能会被利用。//
1294 -
1295 -//Marco：我们所有的员工都接受过培训，以了解他们的行为如何危害我们的安全。他们遵循安全流程，可以检测，预防和纠正安全事件。//
1296 -
1297 -
1298 -=== 4.5.3 同行评审 ===
1299 -
1300 -**定义：同行评审**
1301 -
1302 -同一领域的其他人对一件科学或其他专业作品的判断。当应用于软件开发时，工作产品的开发人员和一个或多个同事将对其进行检查，以评估其技术含量和质量。这有助于保证合规。
1303 -
1304 -
1305 -(% style="text-align:center" %)
1306 -[[image:1639569657674-856.png]]
1307 -
1308 -图4.27 同行评审形式谱
1309 -
1310 -
1311 -基于在工程行业中的同行评审的价值，许多行业专家已将其视为非常理想的开发实践。经验表明，如果开发过程包含同行评审，则可以较早地消除问题（缺陷）。这些审核与测试一样有效，甚至比测试更有效。
1312 -
1313 -同行评审提供了一种纪律严明的工程实践，用于检测和纠正设计产品中的缺陷。在软件工程和其他工程学科（包括电气，土木，机械和消防工程）中，它也是提高设计过程质量和生产率的最有效方法之一。
1314 -
1315 -在同行评审过程中收集的数据用于纠正缺陷，以及评估和改进开发过程本身。
1316 -
1317 -同行评审方法可以包括以下一项或多项：
1318 -
1319 -* 检查
1320 -* 团队审查
1321 -* 演练
1322 -* 结对编程
1323 -* 同行检查
1324 -* 传送
1325 -* 临时审查。
1326 -
1327 -这些方法按形式顺序在图4.27中进行了说明。此外，表4.24概述了不同类型的同行评议中通常包括的活动（摘自Wiegers，2002年；经纽约皮尔森教育公司许可转载）。
1328 -
1329 -表4.24 在不同的同行评审方法中的活动
1330 -
1331 -|(% rowspan="2" %)**评审方法**| | |**活动**| |
1332 -|**规划**|**准备**|**讨论**|**改进**|**验证**
1333 -|检查|是|是|是|是|是
1334 -|团队审查|是|是|是|是|无
1335 -|演练|是|无|是|是|无
1336 -|结对编程|是|无|连续|是|是
1337 -|(((
1338 -同行检查
1339 -
1340 -传送
1341 -)))|无|是|可能|是|无
1342 -|临时审查|无|无|是|是|无
1343 -
1344 -(% style="text-align:center" %)
1345 -[[image:1639569697056-454.png]]
1346 -
1347 -图4.28 同行评审对服务价值链贡献的热图
1348 -
1349 -
1350 -表4.25 与同行评审相关的实践
1351 -
1352 -(% style="width:919px" %)
1353 -|**ITIL管理实践**|(% style="width:622px" %)**与同行评审相关的活动/资源**|(% style="width:104px" %)**影响**
1354 -|风险管理|(% style="width:622px" %)(((
1355 -减少未经授权的变更被开发并发布到生产中的风险。
1356 -
1357 -在识别和评估风险之间进行交叉检查。
1358 -)))|(% style="width:104px" %)H
1359 -|软件开发管理|(% style="width:622px" %)检查同级之间的开发工作以提高代码质量，以确保其有效满足需求和性能期望。|(% style="width:104px" %)H
1360 -|变更控制|(% style="width:622px" %)(((
1361 -同事通过对标准或低风险变更进行同行评审来充当变更权限。
1362 -
1363 -通过同行评审或对变更请求的初步评估来授权进行某些变更。
1364 -)))|(% style="width:104px" %)M
1365 -|持续改进|(% style="width:622px" %)审查作为持续改进计划一部分而完成的工作，以帮助提高所取得成果的质量。|(% style="width:104px" %)M
1366 -|基础架构管理|(% style="width:622px" %)检查基础架构和平台组件以提高其质量。|(% style="width:104px" %)M
1367 -|知识管理|(% style="width:622px" %)查看知识文章和类似文档可帮助消除偏见并提高整个组织的沟通质量。|(% style="width:104px" %)M
1368 -|问题管理|(% style="width:622px" %)审查规避措施并提出对错误的修正，以提高其质量。|(% style="width:104px" %)M
1369 -|架构管理|(% style="width:622px" %)对技术架构的拟议变更进行演练，以确保变更与商定的蓝图和路线图保持一致。|(% style="width:104px" %)L
1370 -
1371 -图4.28显示了同行评审对服务价值链的贡献。
1372 -
1373 -表4.25概述了同行评审相关的实践。
1374 -
1375 -
1376 -**ITIL故事：同行评审**
1377 -
1378 -//Su：我们的应用程序开发团队协同工作，并定期进行定期的同行评审。我们从同事的专业知识和经验中受益匪浅，他们会互相回顾彼此的工作，并在问题到达实际环境之前发现并纠正问题。//
1379 -
1380 -//索尔玛兹：我们倡导开放，无责的文化，这意味着个人在与同行分享工作时会感到自在。这有助于构建强大，有影响力的服务，为所有利益干系人创造价值。//
1381 -
1382 -
1383 -== 4.6 小结 ==
1384 -
1385 -在第2章中，描述了实现高速IT的五个重要组织目标。为了支持实现这些目标，组织可以采用多种技术和模型。其中一些是最近开发的，而其他一些则是根据以前采用的运营模型和管理方法改编的。第4章探讨了一些流行且重要的技术。
1386 -
1387 -在本章中，这些技术围绕高速目标进行了分组。但是，它们中的大多数在一定程度上有助于实现多个目标。HVIT技术在许多实践中普遍适用。为了帮助在实践中采用它们，提供了它们对服务价值链的相对贡献的热图。
1388 -
1389 -请从业者将此章视为一个多功能工具集，并根据上下文和所执行的工作任务来应用这些工具。实施此处描述的技术不应仅作为目标。应始终将它们视为实现组织目标的手段。这适用于本出版物的其他章节以及总体上的ITIL：应采用并改编这些工具以满足组织的需求。
1390 -
1391 -
1392 -
1393 -**结论**
1394 -
1395 -数字化技术已经打破了许多行业的业务，带来了新的机遇和新的挑战。商业产品、服务和运营都发生了重大变化，即所谓的数字化转型，而这种变化需要采用新的IT和业务管理方法。
1396 -
1397 -为了满足这些要求，已经开发了许多方法，技术和工具。这些的数量和种类以及决定如何最好地使用它们会带来挑战，并且选择合适的方法并不总是容易的。除了对产品、服务和运营的变更之外，数字化转型还涉及文化和组织上的变革，这些变革自身都有困难。
1398 -
1399 -业务和IT领域的领导者和从业者应该了解数字化转型的前景，并能够定义目标，采用有效的行为模式并采用适当的技术来取得成功。
1400 -
1401 -该出版物概述了数字化转型以及高速业务和IT管理的关键概念。它提出了一组目标和行为模式，这些目标和行为模式将帮助企业转型，使其从数字化技术中获得最大收益。最后，它描述了可以支持每个目标的有用技术和方法的集合。ITIL SVS提供了一个整体结构，将有助于高速IT的实际应用。
1402 -
1403 -为了充分利用ITIL 4：高速IT，应与ITIL管理实践指南一起进行研究，该指南可在线获得，并为所有34种实践提供详细的实用建议。它们包括可在所有ITIL 4出版物中应用的动手指南。
1404 -
1405 -所有ITIL出版物都是整体出版物，并且注重价值。它们解决了服务管理的四个方面，并以一种能够为组织，其客户和其他利益干系人创造价值的方式帮助管理资源。
1406 -
1407 -//ITIL4：指导、计划和改进：//为使产品和服务管理与当今的业务需求保持一致，推动成功的组织转型以及将持续改进融入组织的各个层次的文化提供了指导。
1408 -
1409 -//ITIL4：驱动利益干系人的价值：//包含有关建立、维护和发展有效服务关系的指南。它带领组织以服务提供者和服务使用者的身份进行服务之旅，帮助他们在每个步骤进行有效的交互和沟通。
1410 -
1411 -//ITIL4：创建、交付和支持：//提供有关产品和服务管理的文化和团队管理方面的指南，并概述了支持服务管理的各种工具和技术。它演示了如何将管理实践集成到端到端的价值流中。
1412 -
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/]]
687 +
Icon 1639569697056-454.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -60.6 KB
Content Icon
Icon 1641700591514-812.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -85.4 KB
Content Icon
Icon 1641700659017-287.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -77.7 KB
Content Icon
Icon 1641700683365-399.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -60.7 KB
Content Icon
Icon 1641700701040-265.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -55.3 KB
Content Icon
Icon 1641700764097-167.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -78.1 KB
Content Icon
Icon 1641700825218-144.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -81.9 KB
Content Icon
Icon 1641700916381-114.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -96.1 KB
Content Icon
Icon 1641701019297-720.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -81.3 KB
Content Icon
Icon 1641701038534-675.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -65.8 KB
Content Icon
Icon 1641701094058-713.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -99.1 KB
Content Icon
Icon 1641701145033-568.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -103.2 KB
Content Icon
Icon 1641701202590-318.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -81.6 KB
Content Icon
Icon 1641701238590-838.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -66.8 KB
Content Icon
Icon 1641701293452-859.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -93.1 KB
Content Icon
Icon 1641701355821-388.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -104.7 KB
Content Icon
Icon 1641701417790-550.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -120.9 KB
Content Icon
Icon 1641701444463-764.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -83.7 KB
Content Icon
Icon 1641701509520-551.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -93.9 KB
Content Icon
Icon 1641701559766-478.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -60.2 KB
Content Icon
Icon 1641701689758-164.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -110.4 KB
Content Icon
Icon 1641702469032-780.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -83.0 KB
Content Icon
Icon 1641702487237-876.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -45.7 KB
Content Icon
Icon 1641702547499-544.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -102.0 KB
Content Icon
Icon 1641702577206-162.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -59.5 KB
Content Icon
Icon 1641702628320-774.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -90.2 KB
Content Icon
Icon 1641702718413-352.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -108.8 KB
Content Icon
Icon 1641702752724-340.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -73.6 KB
Content Icon
Icon 1641702861765-733.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -122.8 KB
Content Icon
Icon 1641702908935-105.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -93.1 KB
Content Icon
Icon 1641702956598-898.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -74.3 KB
Content Icon
Icon 1641703051758-407.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -117.4 KB
Content Icon
Icon 1641703070463-409.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -64.7 KB
Content Icon
Icon 1641703105916-225.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -34.0 KB
Content Icon
Icon 1641703160673-370.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -82.9 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司