Changes for page 4.高速IT技术

Last modified by superadmin on 2024/04/03, 17:15
From version < 56.1 >
edited by superadmin
on 2022/01/09, 12:14
To version < 71.3 >
edited by superadmin
on 2024/03/07, 19:39
< >
Change comment: Update document after refactoring.

Summary

Details

Icon Page properties
Content
... ... @@ -92,18 +92,9 @@
92 92  
93 93  表4.1 与优先级相关的实践
94 94  
95 -(% style="width:781px" %)
96 -|**ITIL管理实践**|(% style="width:536px" %)**与优先次序相关的活动/资源**|(% style="width:95px" %)**影响**
97 -|组合管理|(% style="width:536px" %)持续根据价值优先考虑服务产品，并考虑延迟成本。|(% style="width:95px" %)H
98 -|问题管理|(% style="width:536px" %)计算未解决问题和错误的财务成本，以便确定优先级并指导问题管理工作。将规避措施的成本与长期解决方案的成本进行比较。|(% style="width:95px" %)H
99 -|项目管理|(% style="width:536px" %)计算执行或延迟项目工作的财务影响。|(% style="width:95px" %)H
100 -|软件开发与管理|(% style="width:536px" %)计算延迟工作对新软件功能或较大的基于软件的服务组件的财务影响。决定是获取还是构建软件组件。|(% style="width:95px" %)H
101 -|变更控制|(% style="width:536px" %)计算对服务或服务组件的变更进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
102 -|事件管理|(% style="width:536px" %)计算事故和重大事故的成本，以便优先安排对经济影响最大的工作。|(% style="width:95px" %)M
103 -|发布管理|(% style="width:536px" %)计算对新服务或变更的服务进行优先级安排和调度的成本和收益。|(% style="width:95px" %)M
104 -|服务财务管理|(% style="width:536px" %)计算时间值概要文件数据，以提供用于确定服务产品优先级的信息。|(% style="width:95px" %)M
105 -|服务请求管理|(% style="width:536px" %)计算和比较执行或延迟执行请求的财务影响，以便优先安排具有最高收益的工作。|(% style="width:95px" %)L
95 +[[image:1641700591514-812.png]]
106 106  
97 +
107 107  **ITIL故事：优先排序技术**
108 108  
109 109  //Su：部署应用程序更新后，我们的优先事项变得分散了。我们想从紧要待办项开发新功能，但是需要管理一些支持请求，以确保我们的客户对服务感到满意。//
... ... @@ -141,46 +141,11 @@
141 141  
142 142  表4.2 与最小可用方法相关的实践
143 143  
144 -(% style="width:863px" %)
145 -|**ITIL管理实践**|(% style="width:575px" %)**与最小可用方法相关的活动/资源**|(% style="width:87px" %)**影响**
146 -|架构管理|(% style="width:575px" %)(((
147 -使用最小可用的方法来描述服务、技术、信息或环境体系结构，这将为其他类型
135 +[[image:1641700659017-287.png]]
148 148  
149 -的服务或产品工作创建必要的约束、边界或促成因素。
150 -)))|(% style="width:87px" %)H
151 -|业务分析|(% style="width:575px" %)使用最低可行的方法作为从产品或服务中提取核心业务价值的工具。|(% style="width:87px" %)H
152 -|容量与性能管理|(% style="width:575px" %)(((
153 -使用容量和性能管理作为计算最低可行产品或服务所需的最小资源（服务器数量，服务
137 +[[image:1641700701040-265.png]]
154 154  
155 -台代理数量等）的基础。
156 -)))|(% style="width:87px" %)H
157 -|监控与事态管理|(% style="width:575px" %)(((
158 -使用监控和事态管理作为设计和配置监视和遥测工具的基础，这些工具用于操作和从最低
159 159  
160 -限度可行的产品或服务中学习。
161 -)))|(% style="width:87px" %)H
162 -|组合管理|(% style="width:575px" %)(((
163 -使用最小可用产品的概念作为动态决策工具，以支持对产品或服务中的功能组合进行良好
164 -
165 -的投资。
166 -)))|(% style="width:87px" %)H
167 -|项目管理|(% style="width:575px" %)阐明满足业务案例所需的最小输出。|(% style="width:87px" %)H
168 -|服务设计|(% style="width:575px" %)使用最小可用的方法来设计产品或服务的必要客户体验和用户体验元素。|(% style="width:87px" %)H
169 -|服务验证与测试|(% style="width:575px" %)开发测试用例以检查所有服务组件是否支持最低限度的可行产品或服务。|(% style="width:87px" %)H
170 -|软件开发管理|(% style="width:575px" %)使用最小可用方法作为决策工具来优先处理软件功能。|(% style="width:87px" %)H
171 -|架构管理|(% style="width:575px" %)(((
172 -使用最小可用方法作为决策工具来设计，实施基础架构组件上正在进行的工作并确定其优
173 -
174 -先级。
175 -)))|(% style="width:87px" %)M
176 -|服务目录管理|(% style="width:575px" %)(((
177 -使用最小可用方法作为描述所有产品、服务和服务产品的基础，并确保相关受众能够获取
178 -
179 -信息。
180 -)))|(% style="width:87px" %)M
181 -|服务连续性管理|(% style="width:575px" %)设计和建立连续性计划以支持最低限度的可行产品或服务。|(% style="width:87px" %)M
182 -|供应商管理|(% style="width:575px" %)合作伙伴和供应商提供产品和服务时，使用最小可用方法阐明所需的输出。|(% style="width:87px" %)M
183 -
184 184  **ITIL的故事：最小可用产品和服务**
185 185  
186 186  //Su：在开发新的应用程序功能时，我们将其作为最低限度的可行产品推出，以便我们评估客户的兴趣。这有助于确保我们没有投入过多的资源进行开发，并使我们能够了解需求市场。对最小可用产品的反馈决定了未来的优先级。//
... ... @@ -211,29 +211,9 @@
211 211  
212 212  表4.3 与产品或服务所有权相关的实践
213 213  
214 -(% style="width:788px" %)
215 -|**ITIL管理实践**|(% style="width:566px" %)**与产品或服务所有权相关的活动/资源**|(% style="width:63px" %)**影响**
216 -|架构管理|(% style="width:566px" %)(((
217 -产品和服务所有者参与阐明，完善基础架构和平台开发积压工作并确定其优先级，并
170 +[[image:1641700764097-167.png]]
218 218  
219 -决定是否购买市售的基础架构组件和服务。
220 -)))|(% style="width:63px" %)H
221 -|组合管理|(% style="width:566px" %)（软件）产品所有者和产品或服务经理参与评估和确定产品或服务投资建议的优先级。|(% style="width:63px" %)H
222 -|关系管理|(% style="width:566px" %)(((
223 -与利益干系人的互动。
224 224  
225 -参与确定客户对新产品或已变更产品和服务的优先级。
226 -
227 -协调客户的需求和反馈。
228 -
229 -参与解决投诉和调解相互矛盾的要求。
230 -)))|(% style="width:63px" %)H
231 -|服务目录管理|(% style="width:566px" %)产品或服务所有者和经理参与发布有关所有产品、服务和服务产品的信息。|(% style="width:63px" %)H
232 -|软件开发管理|(% style="width:566px" %)产品和服务所有者参与阐明，完善和确定软件开发积压的优先次序，并决定是否购买或升级商用软件。|(% style="width:63px" %)H
233 -|项目管理|(% style="width:566px" %)产品和服务所有者及经理参与交付项目工作和管理风险。|(% style="width:63px" %)M
234 -|风险管理|(% style="width:566px" %)产品和服务所有者参与阐明和减轻企业风险。|(% style="width:63px" %)M
235 -|供应商管理|(% style="width:566px" %)产品和服务所有者及管理人员参与阐明需求，组织互动以及与合作伙伴和供应商进行谈判。|(% style="width:63px" %)M
236 -
237 237  **ITIL故事：产品或服务所有权**
238 238  
239 239  //Su：我是预订应用程序专用的产品负责人。我在开发、市场营销、管理机队、预订等方面与团队联系并进行谈判。我对需求进行优先排序，并定期将优先级传达给利益干系人。//
... ... @@ -272,18 +272,9 @@
272 272  
273 273  表4.4 与A/B测试相关的实践
274 274  
275 -(% style="width:1031px" %)
276 -|**ITIL管理实践**|(% style="width:747px" %)**与A / B测试相关的活动/资源**|(% style="width:103px" %)**影响**
277 -|组合管理|(% style="width:747px" %)确定并优先考虑使用A / B测试数据进行投资的服务、产品和功能。|(% style="width:103px" %)H
278 -|风险管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定风险缓解方案的有效性。|(% style="width:103px" %)H
279 -|服务设计|(% style="width:747px" %)在进行进一步的投资和设计决策之前，使用A / B测试方法确定客户体验和用户体验原型的有效性。|(% style="width:103px" %)H
280 -|架构管理|(% style="width:747px" %)使用A / B测试方法设计和完善技术，信息，产品和服务体系结构。|(% style="width:103px" %)M
281 -|持续改进|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定各种改进方案和计划的有效性。|(% style="width:103px" %)M
282 -|知识管理|(% style="width:747px" %)在进行进一步的投资之前，使用A / B测试方法确定不同知识管理，表示以及通讯技术和工的有效性。|(% style="width:103px" %)M
283 -|组织变革管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定组织变革的有效性。|(% style="width:103px" %)M
284 -|问题管理|(% style="width:747px" %)在进行进一步投资之前，使用A / B测试方法确定规避措施和错误控制方法的有效性。|(% style="width:103px" %)M
285 -|服务验证与测试|(% style="width:747px" %)使用A / B测试方法定义和执行服务、验证和产品测试活动。|(% style="width:103px" %)M
211 +[[image:1641700825218-144.png]]
286 286  
213 +
287 287  **ITIL的故事：A / B测试**
288 288  
289 289  //Su：我们为该应用程序开发了一项新功能：通过该应用程序进行的每四笔预订，我们都会为客户免费升级到更好的汽车。//
... ... @@ -354,29 +354,10 @@
354 354  
355 355  图4.7 基础设施作为代码对服务价值链的贡献的热图
356 356  
357 -‘
358 358  
359 359  表4.5 与基础设施作为代码相关的实践
360 360  
361 -(% style="width:825px" %)
362 -|**ITIL管理实践**|(% style="width:560px" %)**与基础设施作为代码相关的活动/资源**|(% style="width:90px" %)**影响**
363 -|架构管理|(% style="width:560px" %)验证架构决策并比较基础架构解决方案。|(% style="width:90px" %)H
364 -|变更控制|(% style="width:560px" %)启用虚拟基础架构组件的快速配置或停用，以平衡交付速度与治理，风险和合规性需求。|(% style="width:90px" %)H
365 -|部署管理|(% style="width:560px" %)自动化基础架构的部署，确保基础架构和应用程序的部署更快，更重复，更可靠。|(% style="width:90px" %)H
366 -|信息安全管理|(% style="width:560px" %)在虚拟基础架构组件中设计和实施安全策略。|(% style="width:90px" %)H
367 -|IT资产管理|(% style="width:560px" %)跟踪分配给通常快速配置或停用的虚拟基础结构组件的商业软件许可证的使用。|(% style="width:90px" %)H
368 -|知识管理|(% style="width:560px" %)存储虚拟服务器配置文件，并使它们可用于IaC自动化。|(% style="width:90px" %)H
369 -|服务配置管理|(% style="width:560px" %)以适当的粒度级别设计和维护配置管理数据库和关系，以跟踪经常快速调配或退役的虚拟基础架构组件。|(% style="width:90px" %)H
370 -|服务财务管理|(% style="width:560px" %)由于对基础设施的投资减少，资金从资本支出转向运营支出。|(% style="width:90px" %)H
371 -|服务请求管理|(% style="width:560px" %)自动配置或停用虚拟基础架构组件。|(% style="width:90px" %)H
372 -|服务验证与测试|(% style="width:560px" %)设计和维护测试用例，以确保虚拟IaC满足组织要求和策略。|(% style="width:90px" %)H
373 -|软件开发管理|(% style="width:560px" %)开发软件体系结构和代码，以利用虚拟硬件基础结构的快速交付/配置。|(% style="width:90px" %)H
374 -|事件管理|(% style="width:560px" %)利用IaC功能自动化（在适当情况下）事件恢复任务。|(% style="width:90px" %)M
375 -|基础架构管理|(% style="width:560px" %)快速交付/配置虚拟硬件基础架构。|(% style="width:90px" %)M
376 -|问题管理|(% style="width:560px" %)利用IaC功能进行问题检测和错误控制。|(% style="width:90px" %)M
377 -|服务连续性管理|(% style="width:560px" %)设计适当的连续性计划以反映组织对IaC功能的使用。|(% style="width:90px" %)M
378 -|供应商管理|(% style="width:560px" %)选择可以提供IaC功能或利用组织对IaC的投资的供应商。|(% style="width:90px" %)M
379 -|风险管理|(% style="width:560px" %)认识到通过使用IaC引入或减轻的风险。|(% style="width:90px" %)L
287 +[[image:1641700916381-114.png]]
380 380  
381 381  表4.5 列出了与基础设施作为代码相关的实践。
382 382  
... ... @@ -422,23 +422,11 @@
422 422  
423 423  表4.6 与松散耦合信息系统架构相关的实践
424 424  
425 -(% style="width:718px" %)
426 -|(% style="width:108px" %)**ITIL管理实践**|(% style="width:520px" %)**与松散耦合信息系统架构相关的活动/资源**|(% style="width:87px" %)**影响**
427 -|(% style="width:108px" %)架构管理|(% style="width:520px" %)设计松耦合的服务，技术和信息体系结构。|(% style="width:87px" %)H
428 -|(% style="width:108px" %)业务分析|(% style="width:520px" %)了解消费者需求并将其转化为每个需求的详细需求松耦合服务体系结构的组件。|(% style="width:87px" %)H
429 -|(% style="width:108px" %)部署管理|(% style="width:520px" %)部署的范围和部署模式因以下因素的解耦而减小：系统架构；这使部署更易于管理和复制，并且功能强大自动化的候选人。|(% style="width:87px" %)H
430 -|(% style="width:108px" %)信息安全管理|(% style="width:520px" %)为松散耦合的服务设计和管理信息安全策略、服务组件。|(% style="width:87px" %)H
431 -|(% style="width:108px" %)基础设施及平台管理|(% style="width:520px" %)松耦合基础架构的详细设计，构建，运行和管理和平台组件。|(% style="width:87px" %)H
432 -|(% style="width:108px" %)问题管理|(% style="width:520px" %)研究问题并设计跨越多个松耦合系统的错误控制。|(% style="width:87px" %)H
433 -|(% style="width:108px" %)服务配置管理|(% style="width:520px" %)设计和维护有关各种服务和服务组件的信息，以及他们的相互关系。|(% style="width:87px" %)H
434 -|(% style="width:108px" %)服务级别管理|(% style="width:520px" %)通过与消费者的松耦合架构设计和调整服务级别服务消费方面的期望。|(% style="width:87px" %)H
435 -|(% style="width:108px" %)软件开发管理|(% style="width:520px" %)松耦合软件的详细设计、构建、运行和管理组件。|(% style="width:87px" %)H
436 -|(% style="width:108px" %)变更控制|(% style="width:520px" %)松散耦合的体系结构降低了与应用程序、基础架构变更相关的风险，如果这些变更失败。 较低的风险状况会导致变化在团队级别（而不是部门或组织级别）批准，从而减少了官僚。|(% style="width:87px" %)M
437 -|(% style="width:108px" %)事件管理|(% style="width:520px" %)事件后可以计划调查和解决方案， 以更少的压力和更有效的方式进行演练。服务中断的影响松散耦合的体系结构通常限于无法使用的配置项（CI），而不是其他CI。这是由于系统组件的设计原理应该具有弹性，并且不依赖于其他配置项提供的服务。结果是，事件对客户的影响较小。|(% style="width:87px" %)M
438 -|(% style="width:108px" %)服务财务管理|(% style="width:520px" %)松散耦合的系统体系结构使第三方服务的耦合和解耦更加容易，从而使服务提供商能够利用降价和提供新产品的优势。 这种灵活性还要求服务提供商采用敏捷成本核算模型来有效地切换提供商。|(% style="width:87px" %)M
439 -|(% style="width:108px" %)供应商管理|(% style="width:520px" %)当某些组件松散时，建立合同并管理绩效。耦合体系结构由供应商或外部服务提供商提供。|(% style="width:87px" %)M
440 -|(% style="width:108px" %)战略管理|(% style="width:520px" %)由于投资的原因，将紧密耦合的体系结构去耦是一项战略级决策必要条件以及利用它的潜在运营模式含义（例如引入自治团队）。 这种架构的一个例子是面向服务的可以将第三方服务作为端到端服务的一部分的体系结构。|(% style="width:87px" %)L
333 +[[image:1641701019297-720.png]]
441 441  
335 +[[image:1641701038534-675.png]]
336 +
337 +
442 442  === 4.2.3 复查 ===
443 443  
444 444  通过反馈使迭代不断进步意味着定期复查取得的成就，确定要吸取的经验教训并在必要时纠正的行动过程。但是，这些复查不应减慢进度或引入过多的控制。
... ... @@ -457,20 +457,7 @@
457 457  
458 458  表4.7 与回顾相关的实践
459 459  
460 -(% style="width:965px" %)
461 -|**ITIL管理实践**|(% style="width:722px" %)**与回顾相关的活动/资源**|(% style="width:77px" %)**影响**
462 -|持续改进|(% style="width:722px" %)定期或在完成时审查持续改进计划的活动和技术，以了解是否正在实现预期的成果。|(% style="width:77px" %)H
463 -|项目管理|(% style="width:722px" %)审查项目工作并汲取经验教训的活动和技术，可以使未来的类似项目受益。|(% style="width:77px" %)H
464 -|服务级别管理|(% style="width:722px" %)定期检查和修改服务水平（以了解如何改进）的活动和技术。|(% style="width:77px" %)H
465 -|软件开发管理|(% style="width:722px" %)定期审查工作以了解如何改进的活动和技术。|(% style="width:77px" %)H
466 -|变更控制|(% style="width:722px" %)定期审查进行变更的有效性和效率以了解如何改进的活动和技术（包括有关创建或暂停标准变更模型的决定）。|(% style="width:77px" %)M
467 -|事件管理|(% style="width:722px" %)定期或在重大事件后回顾事件管理工作的活动和技术，以了解如何改进。|(% style="width:77px" %)M
468 -|问题管理|(% style="width:722px" %)定期检查问题和错误控制以了解如何改进的活动和技术。|(% style="width:77px" %)M
469 -|关系管理|(% style="width:722px" %)定期审查与各种利益干系人之间现有关系的状态和方向的活动和技术。|(% style="width:77px" %)M
470 -|风险管理|(% style="width:722px" %)定期或在触发缓解措施后审查缓解风险的活动和技术，以了解如何提高风险。|(% style="width:77px" %)M
471 -|服务连续性管理|(% style="width:722px" %)从灾难恢复后，审查连续性计划的效率和有效性的活动和技术。|(% style="width:77px" %)M
472 -|服务台|(% style="width:722px" %)定期检查服务台交互的活动和技术，以了解如何改进。|(% style="width:77px" %)M
473 -|供应商管理|(% style="width:722px" %)定期审查与各种合作伙伴和供应商之间现有关系的状态和方向的活动和技巧。|(% style="width:77px" %)M
356 +[[image:1641701094058-713.png]]
474 474  
475 475  表4.7概述了与回顾相关的实践。
476 476  
... ... @@ -510,29 +510,9 @@
510 510  
511 511  表4.8 免责的时候反思的实践
512 512  
513 -(% style="width:920px" %)
514 -|**ITIL管理实践**|(% style="width:701px" %)**与无指责相关的活动/资源**|(% style="width:80px" %)**影响**
515 -|变更控制|(% style="width:701px" %)调查成功和失败的变更，以发现机会，以提高未来变更的成功率。|(% style="width:80px" %)H
516 -|部署管理|(% style="width:701px" %)调查服务组件的成功和失败部署，以发现机会，以提高未来部署的成功率。|(% style="width:80px" %)H
517 -|事件管理|(% style="width:701px" %)调查事件管理（和重大事件管理）活动，以发现改进的机会。|(% style="width:80px" %)H
518 -|问题管理|(% style="width:701px" %)调整领导方式以检查系统而不是人员。事后回顾可以帮助组织获得有关事件情况的更多信息。这为问题识别和调查提供了更好的信息。|(% style="width:80px" %)H
519 -|项目管理|(% style="width:701px" %)调查项目活动，以吸取经验教训和改进未来项目的机会。|(% style="width:80px" %)H
520 -|发布管理|(% style="width:701px" %)调查服务的成功和失败版本，以发现提高未来版本成功率的机会。|(% style="width:80px" %)H
521 -|持续改进|(% style="width:701px" %)(((
522 -调查持续改进活动，以识别经验教训，了解系统中的变更以及确定增加或保持未来改进成
396 +[[image:1641701145033-568.png]]
523 523  
524 -功的机会。
525 -)))|(% style="width:80px" %)M
526 -|信息安全管理|(% style="width:701px" %)获取有关与安全漏洞和安全事件有关的情况的更多信息。|(% style="width:80px" %)M
527 -|风险管理|(% style="width:701px" %)触发风险缓解措施后，评估其风险，以了解如何改进缓解措施以及对当前和未来风险的应对措施。修改风险记录并探索可能的风险的新领域。|(% style="width:80px" %)M
528 -|服务台|(% style="width:701px" %)调查与外部利益干系人的互动，以发现改进互动和持续沟通的机会。|(% style="width:80px" %)M
529 -|服务验证与测试|(% style="width:701px" %)调查成功和失败的验证和测试活动，以发现提高未来成功率的机会。|(% style="width:80px" %)M
530 -|软件开发管理|(% style="width:701px" %)(((
531 -从回顾中获取经验教训和改进思路。
532 532  
533 -让合作伙伴和供应商收集反馈以进行学习注册。
534 -)))|(% style="width:80px" %)M
535 -
536 536  === 4.2.4 持续业务分析 ===
537 537  
538 538  瞬息万变的HVIT环境需要不断调整，以适应不断变化的市场需求。这对业务分析具有影响。
... ... @@ -568,22 +568,11 @@
568 568  
569 569  表4.9 与持续业务分析相关的实践
570 570  
571 -(% style="width:900px" %)
572 -|**ITIL管理实践**|(% style="width:682px" %)**与持续业务分析相关的活动/资源**|(% style="width:96px" %)**影响**
573 -|业务分析|(% style="width:682px" %)持续了解分析客户、市场状况和更广泛的生态系统，以了解他们对组织产品和服务的影响。|(% style="width:96px" %)M
574 -|基础架构管理|(% style="width:682px" %)持续了解分析客户、状况和更广泛的生态系统，以了解他们对组织的基础架构和平台产品的影响。|(% style="width:96px" %)M
575 -|组合管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织投资各种产品和服务的方式的影响。监控正在进行的组合投资，以识别价值或验证价值共创。|(% style="width:96px" %)M
576 -|项目管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统了解它们对组织项目和相关业务案例的影响。|(% style="width:96px" %)M
577 -|关系管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织与外部利益干系人关系的影响。|(% style="width:96px" %)M
578 -|风险管理|(% style="width:682px" %)持续分析内部和外部公司风险，以评估和了解其对组织产品和服务的影响，并设计适当的缓解措施和对策。|(% style="width:96px" %)M
579 -|服务设计|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解其对客户和用户体验组织产品和服务的影响。|(% style="width:96px" %)M
580 -|软件开发管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以了解他们对组织软件产品的影响以及正在进行的软件开发工作的优先级。|(% style="width:96px" %)M
581 -|战略管理|(% style="width:682px" %)持续监视和评估客户，市场状况以及更广泛的生态系统，以了解其对组织产品和服务的影响，并相应地调整策略。|(% style="width:96px" %)M
582 -|架构管理|(% style="width:682px" %)持续分析组织内部和外部利益干系人对技术的使用，以了解其对组织的技术，服务和信息体系结构的影响。|(% style="width:96px" %)M
583 -|知识管理|(% style="width:682px" %)不断了解分析客户，市场状况和更广泛的生态系统，以在相关利益干系人之间建立共识。|(% style="width:96px" %)M
584 -|服务连续性管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，它们对组织的连续性和灾难恢复措施的影响。|(% style="width:96px" %)M
585 -|供应商管理|(% style="width:682px" %)持续了解分析客户，市场状况和更广泛的生态系统，以它们对组织与合作伙伴和供应商关系的影响。|(% style="width:96px" %)M
434 +[[image:1641701202590-318.png]]
586 586  
436 +[[image:1641701238590-838.png]]
437 +
438 +
587 587  === 4.2.5 持续集成、持续交付和持续部署 ===
588 588  
589 589  持续集成、持续交付和持续部署（CI / CD）是主要与软件工程相关的实践的描述性术语，它们是精益的理念和敏捷软件开发的核心。这些实践的采用迅速增长，在实施由软件开发支持的服务时，重要的是要了解CI / CD的定义特征以及不断发展的系统开发做法的更广泛的背景。
... ... @@ -620,21 +620,9 @@
620 620  
621 621  表4.10 与CI/CD最相关的实践
622 622  
623 -(% style="width:852px" %)
624 -|**ITIL管理实践**|(% style="width:651px" %)**与CI/CD最相关相关的活动/资源**|(% style="width:84px" %)**影响**
625 -|变更控制|(% style="width:651px" %)可以根据业务需求和期望，使用CI / CD管道来调整组织产品和服务的变化率。|(% style="width:84px" %)H
626 -|部署管理|(% style="width:651px" %)系统地/自动地将特定版本的软件或软件包安装到预定的环境（集成，用户验收测试，生产）。|(% style="width:84px" %)H
627 -|基础机构管理|(% style="width:651px" %)将CI / CD技术用于数字基础架构。|(% style="width:84px" %)H
628 -|发布管理|(% style="width:651px" %)认识到软件的部署和功能的发布通常是有助于计划和管理发布的不同活动。|(% style="width:84px" %)H
629 -|服务配置管理|(% style="width:651px" %)管理代码存储库和构成CI / CD工具链一部分的相关工具，并不断更新CMDB以反映进行了重大（CI级别）变更的时间。|(% style="width:84px" %)H
630 -|服务验证与测试|(% style="width:651px" %)开发自动化测试用例以支持持续的集成活动。|(% style="width:84px" %)H
631 -|软件开发管理|(% style="width:651px" %)使用用于应用程序软件的CI / CD技术。|(% style="width:84px" %)H
632 -|架构管理|(% style="width:651px" %)设计和改进服务，技术和信息体系结构以利用CI / CD功能。容器化是支持CI / CD的体系结构选择。|(% style="width:84px" %)M
633 -|信息安全管理|(% style="width:651px" %)通过减少手工工作来确保遵守信息安全合规。通过利用CI / CD工具来增加自动化的规模和范围，可以通过减少手工工作并改进变更的可追溯性来帮助确保遵守信息安全合规。|(% style="width:84px" %)M
634 -|知识管理|(% style="width:651px" %)不断更新知识库，以确保组织保持对通过CI / CD管道构建和部署的软件的最新了解。|(% style="width:84px" %)M
635 -|服务连续性管理|(% style="width:651px" %)应该建立CI / CD管道以将软件组件推向连续性和灾难恢复系统。|(% style="width:84px" %)M
636 -|风险管理|(% style="width:651px" %)通过使用CI / CD自动化减少某些类型的企业风险的影响。|(% style="width:84px" %)L
475 +[[image:1641701293452-859.png]]
637 637  
477 +
638 638  **ITIL故事：持续集成、持续交付和持续部署**
639 639  
640 640  //Marco：我们已经为该应用程序创建了相同的构建、测试和实时环境，这使我们能够不断集成和交付与现有代码库兼容的新代码。因此，我们可以使用已经有效的代码来高度开发该应用程序。我们还减少了由可能导致难以解决的路径的错误引起的事件。//
... ... @@ -647,34 +647,11 @@
647 647  
648 648  表4.11 软件测试的类型
649 649  
650 -(% style="width:813px" %)
651 -|(% style="width:165px" %)测试思路|(% style="width:646px" %)所有软件都源于一个想法，通常是试图解决问题的尝试。 测试该想法有助于从客户角度（基于需求和需求）和业务角度（基于指标，包括增长，收入，转化和用户基础）确定其质量。
652 -|(% style="width:165px" %)测试原型|(% style="width:646px" %)原型，例如史诗，用户故事，验收标准，数据流程图和过程流程图，应进行测试。 检查原型内的信息可以帮助识别与风险和变量有关的歧义，假设和信息。 该信息可用作反馈，以帮助审查和改进伪像。
653 -|(% style="width:165px" %)测试用户体验和用户界面设计|(% style="width:646px" %)原型用于设计活动，编程活动和测试活动。 设计活动产生的设计原型超出了可以测试的范围。 使用相关的原型对界面和体验进行了测试，并且测试结果可能会影响其他原型。
654 -|(% style="width:165px" %)测试架构和代码设计|(% style="width:646px" %)在设计软件体系结构并讨论如何构建它和新功能时，探索性测试可以增强设计和思想。
655 -|(% style="width:165px" %)代码测试|(% style="width:646px" %)代码审查是构建高质量产品的重要组成部分。任何人都应该能够阅读该代码并从不同的角度对其进行测试。单元测试可验证软件的每个单元是否都能正常运行。单元测试通常是自动化的。重要的是要注意，这是软件开发生命周期中的第一点，应该有针对性地加以衡量。
656 -|(% style="width:165px" %)测试操作软件|(% style="width:646px" %)测试操作软件是与测试相关的最常见的活动。开发后，许多敏捷团队都将“测试”作为其工作流中的一种状态。但是，测试不应该成为工作流程中的一种状态。它应该是在软件开发生命周期中进行的一系列结构化活动。
657 -|(% style="width:165px" %)在不同环境测试|(% style="width:646px" %)当涉及测试环境时，基于风险的方法可能是合适的。有很多风险可以测试。其中一些无法在开发环境中进行测试。对于其他人，则需要严格集成的环境来进行测试。某些风险只能在实际生产环境中进行测试。
658 -|(% style="width:165px" %)测试发布管道|(% style="width:646px" %)可以测试管道流程，团队通常会隐式地进行测试，以使其管道尽可能高效和快速地进行增强。这需要对管道测试背后的结构有充分的了解。
659 -|(% style="width:165px" %)生产环境下测试|(% style="width:646px" %)(((
660 -必须在生产环境中对某些风险进行测试，例如性能风险（尤其是用户负载和用户压力风险），用户接受度测试（用户将其与实际软件一样使用系统）和可观察性风险（以测试有效性、可观察性解决方案和实现）。
490 +[[image:1641701417790-550.png]]
661 661  
662 -在生产中进行测试时，目标应该是最大程度地降低影响客户的测试风险。实现这一目标的策略包括：
492 +[[image:1641701444463-764.png]]
663 663  
664 -● **金丝雀发布 **这项新功能最初是针对少数目标用户发布的，后来逐渐增加到所有用户。
665 665  
666 -●** 功能开关** 可以将功能隐藏在功能标志的后面，通过打开或关闭该标志可以轻松启用或禁用
667 -
668 -该功能。
669 -
670 -● **蓝/绿部署 **两个相同的生产环境同时运行（一个“蓝色”和一个“绿色”），只有一个环
671 -
672 -境处于活动状态，为所有生产流量提供服务，而另一个用于部署新版本。
673 -
674 -● **自动化的回滚策略 **发生事件时，自动化工具可以快速将发行版恢复为先前版本。
675 -)))
676 -|(% style="width:165px" %)测试生产环境中的服务|(% style="width:646px" %)为已发布的生产软件实现了许多服务，活动和技术，所有这些都可以进行测试。从服务交付的角度来看，测试流程很重要。 例如，在测试用户是否可以访问支持时，重要的是要问用户获得支持有多容易，用户在软件中在什么情况下做到这一点。
677 -
678 678  为了实现持续测试，应制定一些原则，包括：
679 679  
680 680  * 测试应该以最低级别进行。
... ... @@ -699,16 +699,9 @@
699 699  
700 700  表4.12 与持续测试最相关的实践
701 701  
702 -(% style="width:834px" %)
703 -|**ITIL管理实践**|(% style="width:641px" %)**与持续测试相关的活动/资源**|(% style="width:79px" %)**影响**
704 -|架构管理|(% style="width:641px" %)设计和改进服务，技术和信息架构，以利用CI / CD功能|(% style="width:79px" %)H
705 -|服务验证与测试|(% style="width:641px" %)在整个开发生命周期中，将持续进行单元，集成和回归测试。这包括应用程序单元测试，基础结构服务测试，功能/非功能测试，canary版本，蓝/绿测试以及基础结构安全性测试。|(% style="width:79px" %)H
706 -|部署管理|(% style="width:641px" %)导致连续测试失败的变更或部署会触发团队的告警线。然后，团队成员蜂拥而至以解决问题。|(% style="width:79px" %)M
707 -|信息安全管理|(% style="width:641px" %)通过减少手工工作来确保遵守信息安全合规。利用自动化测试工具，可以减少手工工作并提高变更的可追溯性，从而有助于确保遵守信息安全合规。|(% style="width:79px" %)M
708 -|问题管理|(% style="width:641px" %)自动化测试有助于验证问题的解决方案，已知错误的存在或规避措施的有效性。|(% style="width:79px" %)M
709 -|服务连续性管理|(% style="width:641px" %)自动化测试可以加速提供从灾难中恢复所需的技术资源。|(% style="width:79px" %)M
710 -|风险管理|(% style="width:641px" %)使用测试自动化减少某些类型的企业风险的影响。|(% style="width:79px" %)L
519 +[[image:1641701509520-551.png]]
711 711  
521 +
712 712  **ITIL的故事：持续测试**
713 713  
714 714  //Su：我们投放市场的每个产品都经过全面测试，以确保它是符合目 的并适合使用。应用程序的改进没有什么不同。我们测试了//：
... ... @@ -780,18 +780,9 @@
780 780  
781 781  表4.13 与看板相关的实践
782 782  
783 -(% style="width:804px" %)
784 -|**ITIL管理实践**|(% style="width:524px" %)**与看板相关的活动/资源**|(% style="width:70px" %)**影响**
785 -|变更控制|(% style="width:524px" %)通过限制进行中的工作，可视化并改进对服务和服务组件的变更流程。|(% style="width:70px" %)H
786 -|持续改进|(% style="width:524px" %)可视化并改进SVS中的改进流程。|(% style="width:70px" %)H
787 -|项目管理|(% style="width:524px" %)可视化并改进跨项目和团队的工作流程。|(% style="width:70px" %)H
788 -|发布管理|(% style="width:524px" %)可视化并提高发布给消费者的质量。|(% style="width:70px" %)H
789 -|软件开发管理|(% style="width:524px" %)可视化和改进新的或变更的软件组件进入实时环境的流程。|(% style="width:70px" %)H
790 -|事件管理|(% style="width:524px" %)通过限制进行中的工作来可视化并提高事件解决的速度和质量。|(% style="width:70px" %)M
791 -|组合管理|(% style="width:524px" %)可视化并改进整个投资组合管道中的投资流程。|(% style="width:70px" %)M
792 -|问题管理|(% style="width:524px" %)通过限制进行中的工作来可视化并改进问题和错误控制。|(% style="width:70px" %)M
793 -|供应商管理|(% style="width:524px" %)可视化供应商的入职/离职进度。|(% style="width:70px" %)M
593 +[[image:1641701559766-478.png]]
794 794  
595 +
795 795  == 4.3 弹性运营的技术 ==
796 796  
797 797  弹性运营目标涉及确保在需要时可以使用数字化产品。
... ... @@ -823,6 +823,7 @@
823 823  * 聊天运营
824 824  * 站点可靠性工程。
825 825  
627 +
826 826  **ITIL故事：弹性运营的技术**
827 827  
828 828  //亨利：我们的应用程序必须可靠且一致，否则我们的客户将其视为有缺陷的。如果他们的工作方式需要变更，我们还需要确保我们的团队有应变能力并且可以适应不同的条件。//
... ... @@ -846,39 +846,27 @@
846 846  
847 847  图4.17显示了技术债对服务价值链的贡献。
848 848  
849 -表4.14概述了与技术债相关的实践。
651 +(% style="text-align:center" %)
652 +[[image:1639568670048-316.png]]
850 850  
851 851  
852 -**ITIL故事：技术债**
655 +图4.17 技术债对服务价值链贡献的热图
853 853  
854 -//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
855 855  
856 -//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
658 +表4.14概述了与技术债相关的实践。
857 857  
660 +[[image:1641701689758-164.png]]
858 858  
859 -(% style="text-align:center" %)
860 -[[image:1639568670048-316.png]]
662 +表4.14 与技术债相关的实践
861 861  
862 -图4.17 技术债对服务价值链贡献的热图
863 863  
665 +**ITIL故事：技术债**
864 864  
865 -表4.14 与技术债相关的实践
667 +//Henri：应用程序开发工作将重用许多现有代码；因此我们会产生一些技术债。随着我们的应用程序的增长，我们可能需要实施规避措施以加快启动速度，但是这些变法会使代码日后容易受到不兼容的影响。//
866 866  
867 -(% style="width:702px" %)
868 -|**ITIL管理实践**|(% style="width:545px" %)**与技术债相关的活动/资源**|(% style="width:70px" %)**影响**
869 -|事件管理|(% style="width:545px" %)解决事件和管理事件需要了解现有的技术债及其解决方案。|(% style="width:70px" %)H
870 -|基础架构管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
871 -|知识管理|(% style="width:545px" %)确保所有相关的利益干系人都可以访问最新信息。|(% style="width:70px" %)H
872 -|组合管理|(% style="width:545px" %)决定是否投资资源来解决实时产品和服务中存在的技术债，并了解对投资对未来产品和服务的影响。评估技术债，以便可以将新的投资组合项目引入现有资产池。评估当前投资组合项目的技术债，以防止价值流失。|(% style="width:70px" %)H
873 -|问题管理|(% style="width:545px" %)应用问题控制和错误控制方法来管理技术债。|(% style="width:70px" %)H
874 -|软件开发管理|(% style="width:545px" %)通过创建或修改基础架构和平台服务组件来识别和减少技术债。|(% style="width:70px" %)H
875 -|业务分析|(% style="width:545px" %)了解技术债对需求和解决方案表达的影响。|(% style="width:70px" %)M
876 -|持续改进|(% style="width:545px" %)确定优先顺序和管理减少技术债的工作。|(% style="width:70px" %)M
877 -|信息安全管理|(% style="width:545px" %)信息安全控制的设计，实施和改进受现有技术债的影响。信息安全控制还可能导致技术债的产生，这需要得到承认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
878 -|项目管理|(% style="width:545px" %)计划和执行项目受现有技术债的影响。 项目还可能导致技术债的产生，需要承认这一债务并将其传达给所有相关的利益干系人。|(% style="width:70px" %)M
879 -|风险管理|(% style="width:545px" %)认识到技术债对新的或现有的企业风险的影响；减轻风险可能会产生技术债，需要予以确认并传达给所有相关的利益干系人。|(% style="width:70px" %)M
880 -|服务台|(% style="width:545px" %)与需要事件和请求协助的外部用户进行交流，需要了解现有的技术债以及为解决该问题而计划的工作。|(% style="width:70px" %)M
669 +//Marco：我们对改进原始代码所做的工作越多，它的弹性就越强，我们产生的技术债越少。//
881 881  
671 +
882 882  === 4.3.2 混沌工程 ===
883 883  
884 884  **定义：混沌工程**
... ... @@ -932,30 +932,11 @@
932 932  
933 933  表4.15 与混沌工程相关的实践
934 934  
935 -(% style="width:912px" %)
936 -|**ITIL管理实践**|(% style="width:677px" %)**与混沌工程相关的活动/资源**|(% style="width:97px" %)**影响**
937 -|持续改进|(% style="width:677px" %)使用混沌工程作为提高服务质量的最有效工具之一。|(% style="width:97px" %)H
938 -|基础架构管理|(% style="width:677px" %)设计基础架构和平台，以提供足够的弹性和冗余来处理混乱的工程工具导致的意外中断。为混乱的工程提供有关服务组件和备份活动的信息。|(% style="width:97px" %)H
939 -|服务连续性管理|(% style="width:677px" %)设计具有足够弹性和冗余性的服务连续性措施，以应对混乱的工程工具导致的意外中断。 持续监控弹性的连续性计划，措施和机制。|(% style="width:97px" %)H
940 -|服务级别管理|(% style="width:677px" %)在设计和运行测试时，必须考虑业务连续性策略，服务水平协议以及为服务降级建立的明确标准，以防人为破坏超过可接受的水平。|(% style="width:97px" %)H
941 -|软件开发管理|(% style="width:677px" %)混沌工程工具本身就是需要开发（或配置）和管理的软件应用程序。软件的设计和架构应具有足够的弹性和冗余性。|(% style="width:97px" %)H
942 -|架构管理|(% style="width:677px" %)(((
943 -通过混乱的工程促进弹性基础设施的建设。
725 +[[image:1641702469032-780.png]]
944 944  
945 -考虑服务和组件之间的交互以支持需求。
946 -)))|(% style="width:97px" %)M
947 -|容量与性能管理|(% style="width:677px" %)运行此类测试时，应捕获性能信息。因此，应确定改进措施，以确保为最佳性能，可伸缩性和容量设计服务。|(% style="width:97px" %)M
948 -|事件管理|(% style="width:677px" %)团队可以使用混乱的工程工具练习响应故障并从中断中恢复。他们必须准备好在不影响用户的情况下管理事件。冗余和自动化应内置于流程中。|(% style="width:97px" %)M
949 -|度量与报告|(% style="width:677px" %)混沌工程测试涉及实验和假设，将有助于收集和分析数据以进行计划和预测。结果支持连续性业务战略。|(% style="width:97px" %)M
950 -|监控与事态管理|(% style="width:677px" %)可以设置监视和事态管理工具来标记由混乱的工程工具策划的中断，或者监视服务质量而不是技术组件。|(% style="width:97px" %)M
951 -|组织变革管理|(% style="width:677px" %)混沌工程将有助于确保在现场环境中的契动与合作。|(% style="width:97px" %)M
952 -|问题管理|(% style="width:677px" %)通过引入随机失效并寻找服务/组件中的潜在缺陷来主动检测问题。从混乱的工程工具中收集的数据可以帮助识别需要调查和修复的潜在问题。|(% style="width:97px" %)M
953 -|服务配置管理|(% style="width:677px" %)CMDB和代码存储库应具有高可用性和准确的信息（与服务连续性管理定义的恢复点目保持一致），以帮助组织从中断中快速恢复。|(% style="width:97px" %)M
954 -|服务设计|(% style="width:677px" %)混沌工程测试原理可以帮助架构师设计更具弹性的系统并改进用户体验。|(% style="width:97px" %)M
955 -|服务台|(% style="width:677px" %)必须将有关测试的情况通知服务台团队，并准备好在不影响用户的情况下管理事件。|(% style="width:97px" %)M
956 -|服务验证与测试|(% style="width:677px" %)混沌工程测试原理可以帮助评估服务的可靠性。架构师应专注于服务中断。|(% style="width:97px" %)M
957 -|风险管理|(% style="width:677px" %)通过使用混乱的工程工具和方法来提高组织的弹性和健壮性，可以减轻某些类型的组织风险。|(% style="width:97px" %)L
727 +[[image:1641702487237-876.png]]
958 958  
729 +
959 959  ITIL故事：混沌工程
960 960  
961 961  //Radhika：我们需要测试该应用程序的弹性。例如，如果成员资格功能停止工作会怎样？客户仍然可以预定汽车？预订是否仍可以追溯分配到他们的账户？//
... ... @@ -1008,26 +1008,11 @@
1008 1008  
1009 1009  表4.16 与“完成”定义相关的实践
1010 1010  
1011 -(% style="width:777px" %)
1012 -|**ITIL管理实践**|(% style="width:601px" %)**与“完成”定义相关的活动/资源**|(% style="width:70px" %)**影响**
1013 -|可用性管理|(% style="width:601px" %)新服务或变更服务的详细功效要求应与利益干系人协商并达成协议。|(% style="width:70px" %)H
1014 -|容量与性能管理|(% style="width:601px" %)完成清单的定义必须考虑容量需求，需求预测以及管理业务和客户期望的性能。|(% style="width:70px" %)H
1015 -|变更控制|(% style="width:601px" %)变更支持活动可以围绕完成的定义来组织；例如，使用发布管理或部署管理创建边界。|(% style="width:70px" %)H
1016 -|持续改进|(% style="width:601px" %)完成的定义可用于范围和结构持续改进活动，并检查是否已实现结果。|(% style="width:70px" %)H
1017 -|部署管理|(% style="width:601px" %)部署管理活动可以围绕完成的定义来组织；例如，使用发布管理创建边界。将发行版移至实际环境时，团队应验证支持的交付成果是否完整：应接受所有要求，用户案例和测试。|(% style="width:70px" %)H
1018 -|事件管理|(% style="width:601px" %)事件管理活动可以围绕完成的定义来组织；例如，建立问题管理的界限。|(% style="width:70px" %)H
1019 -|信息安全管理|(% style="width:601px" %)应该考虑安全测试，例如漏洞，渗透或策略合规性在针对弹性产品和服务的完成定义中。|(% style="width:70px" %)H
1020 -|项目管理|(% style="width:601px" %)项目任务或输出可以使用以下定义定义成功或完成标准：完成的方法。|(% style="width:70px" %)H
1021 -|发布管理|(% style="width:601px" %)发布管理活动可以围绕完成的定义进行组织；例如，创建具有变更支持或部署管理的边界。发行必须设计为符合业务，客户和用户的期望。这很重要，评估每个版本以验证它满足用户需求和要求。|(% style="width:70px" %)H
1022 -|服务级别管理|(% style="width:601px" %)完成的定义可以阐明提供者和消费者的服务行为，并且可以用作根据预期性能监视实际性能的基础。|(% style="width:70px" %)H
1023 -|服务请求管理|(% style="width:601px" %)服务请求管理活动，例如记录或满足请求，可以是使用完成方法的定义进行结构化。|(% style="width:70px" %)H
1024 -|服务验证与测试|(% style="width:601px" %)可以围绕完成的定义来组织测试活动，以确保多种类型测试进行。|(% style="width:70px" %)H
1025 -|软件开发管理|(% style="width:601px" %)可以开发（或配置）软件以满足部署之前完成的定义进入实时环境，确保代码易于理解，可维护并且随时可以支持未来的变化。|(% style="width:70px" %)H
1026 -|业务分析|(% style="width:601px" %)保修和实用程序的功效和功用要求必须记录在为了满足客户的需求和期望。|(% style="width:70px" %)M
1027 -|服务设计|(% style="width:601px" %)完成的定义应以客户为中心，以简化设计方法采用并确保服务将可维护且具有成本效益。|(% style="width:70px" %)M
1028 -|服务目录管理|(% style="width:601px" %)发行新功能，产品或服务时，服务目录必须被更新。|(% style="width:70px" %)L
1029 -|服务台|(% style="width:601px" %)在完成的定义中指定质量属性，以便开发和支持团队可以在早期阶段考虑他们。|(% style="width:70px" %)L
782 +[[image:1641702547499-544.png]]
1030 1030  
784 +[[image:1641702577206-162.png]]
785 +
786 +
1031 1031  **ITIL故事：完成定义**
1032 1032  
1033 1033  //Su：该应用程序的交付团队包括来自Alxe汽车租赁部门许多部门人员，当开发人员移交工作代码时，对完成传统定义并不是最有效或最准确的。我们要保证该应用程序的弹性、功效、可维护性、功用和可用性。对我们来说，“完成“是指：//
... ... @@ -1082,19 +1082,9 @@
1082 1082  
1083 1083  表4.17 与版本控制相关的实践
1084 1084  
1085 -(% style="width:890px" %)
1086 -|**ITIL管理实践**|(% style="width:689px" %)**与版本控制相关的活动/资源**|(% style="width:91px" %)**影响**
1087 -|部署管理|(% style="width:689px" %)使用版本控制的存储库来部署新的或变更的服务组件，或者返回以前的版本。|(% style="width:91px" %)H
1088 -|信息安全管理|(% style="width:689px" %)通过标记易受攻击的版本来解决或消除信息安全风险服务组件。|(% style="width:91px" %)H
1089 -|基础设施管理|(% style="width:689px" %)基础架构组件，配置设置以及虚拟和物理基础架构可以使用版本控制的存储库正式存储和管理组件。|(% style="width:91px" %)H
1090 -|服务配置管理|(% style="width:689px" %)CMDB可以联合在一起，利用版本控制的代码存储库，基础架构即代码配置文件，甚至是物理设备和其他硬件的存储。办理登机手续应该每天发生多次，并且应该管理环境规范和版本化。|(% style="width:91px" %)H
1091 -|软件开发管理|(% style="width:689px" %)代码，甚至其他软件组件的配置设置都可以正式使用版本控制的存储库来管理软件输出开发和管理工作。|(% style="width:91px" %)H
1092 -|持续改进|(% style="width:689px" %)创建当前环境的基线，并在改进完成后更新基线。|(% style="width:91px" %)M
1093 -|事件管理|(% style="width:689px" %)使用版本控制的软件或硬件组件存储库来解决一个事件。|(% style="width:91px" %)M
1094 -|知识管理|(% style="width:689px" %)服务版本时更新知识库并传达信息组件发生变化。|(% style="width:91px" %)M
1095 -|服务连续性管理|(% style="width:689px" %)了解服务组件新版本的影响；并且如果可行，将它们传播到服务连续性和灾难恢复计划中。|(% style="width:91px" %)M
1096 -|服务请求管理|(% style="width:689px" %)使用版本控制的软件或硬件组件存储库来快速满足要求。|(% style="width:91px" %)M
841 +[[image:1641702628320-774.png]]
1097 1097  
843 +
1098 1098  **ITIL故事：版本控制**
1099 1099  
1100 1100  //Marco：我们实行持续集成和持续交付，我们利用版本控制系统地记录我们发布的应用程序的每次迭代，如果发布不稳定，我们可以通过将服务返回到先前的稳定版本来快速还原该服务。//
... ... @@ -1132,21 +1132,9 @@
1132 1132  
1133 1133  表4.18 与AIOps相关的实践
1134 1134  
1135 -(% style="width:904px" %)
1136 -|(% style="width:99px" %)**ITIL管理实践**|(% style="width:724px" %)**与AIOps相关的活动/资源**|(% style="width:77px" %)**影响**
1137 -|(% style="width:99px" %)容量与性能管理|(% style="width:724px" %)AIOps提供了识别模式和异常，确定资产的容量和利用率以及规划未来产品或服务的容量能。|(% style="width:77px" %)H
1138 -|(% style="width:99px" %)事件管理|(% style="width:724px" %)事件管理数据可受益于AIOps工具提供的高度自动化的功能，这些功能可增强手动工作。使用从不同系统合并的上下文预先分析的数据解决关联事件。|(% style="width:77px" %)H
1139 -|(% style="width:99px" %)基础架构管理|(% style="width:724px" %)AIOps工具可以自动执行基础结构和平台资源的大部分日常管理。|(% style="width:77px" %)H
1140 -|(% style="width:99px" %)监控与事态管理|(% style="width:724px" %)AIOps工具可以帮助关联来自多个监视工具的大量数据集。他们可以更好地理解IT环境。 AIOps通过一组集成的业务和运营指标来实现价值共创，从而降低了运营事态或事件的发生频率，因为它们是可以预测和预防的。AIOps通过替换以筒仓为中心的IT监视工具，并监视价值流中所有层的应用程序的运行状况和性能，来帮助优化IT并降低IT成本。|(% style="width:77px" %)H
1141 -|(% style="width:99px" %)变更控制|(% style="width:724px" %)AIOP支持在每个设备级别可视化依赖项详细信息。|(% style="width:77px" %)M
1142 -|(% style="width:99px" %)IT资产管理|(% style="width:724px" %)AIOps可以收集具有逻辑和物理属性的动态库存信息。|(% style="width:77px" %)M
1143 -|(% style="width:99px" %)度量与报告|(% style="width:724px" %)AIOps为度量提供数据，以评估性能和法规遵从性。它还有助于自动执行报告任务。|(% style="width:77px" %)M
1144 -|(% style="width:99px" %)问题管理|(% style="width:724px" %)来自AIOps工具的信息可以帮助识别和调查问题和错误，以及自动化和监视规避措施的应用。们还可以基于预处理和合并的数据来帮助主动检测问题。|(% style="width:77px" %)M
1145 -|(% style="width:99px" %)服务配置管理|(% style="width:724px" %)AIOps数据可用于检测配置项的变更，从而帮助识别未经授权的变更。|(% style="width:77px" %)M
1146 -|(% style="width:99px" %)服务台|(% style="width:724px" %)来自AIOps工具的信息可以支持与外部利益干系人的互动。AIOps可帮助组织在问题发生主动进行计划，发现问题及其业务影响。AIOps还可以根据合并的数据和已识别的趋势对用户查询进行明智的分类。|(% style="width:77px" %)M
1147 -|(% style="width:99px" %)劳动力和人才管理|(% style="width:724px" %)在整个IT团队中实施AIOps故障孤岛的组织可以使经验不足的员工提高生产力，发展技能和效率。|(% style="width:77px" %)M
1148 -|(% style="width:99px" %)知识管理|(% style="width:724px" %)IT流程，运营，性能结果和数据处理算法的知识的组合支持关键的业务功能。|(% style="width:77px" %)L
881 +[[image:1641702718413-352.png]]
1149 1149  
883 +
1150 1150  **ITIL故事：AIOps**
1151 1151  
1152 1152  Radhika：：成千上万的客户使用该应用程序并租用我们的车辆。这些转换会产生大量数据，这是有关客户需求的丰富信息来源。
... ... @@ -1186,18 +1186,9 @@
1186 1186  
1187 1187  表4.19 与ChatOps相关的实践
1188 1188  
1189 -(% style="width:923px" %)
1190 -|**ITIL管理实践**|(% style="width:743px" %)**与ChatOps相关的活动/资源**|(% style="width:95px" %)**影响**
1191 -|服务台|(% style="width:743px" %)与用户进行沟通和协调，以更好地管理事件和请求。|(% style="width:95px" %)H
1192 -|变更控制|(% style="width:743px" %)在管理服务变更的所有团队之间进行沟通和协调和服务组件。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps提供了与用户和团队进行沟通的渠道成员了解新服务或变更的服务，从而人性化工作方式。|(% style="width:95px" %)M
1193 -|持续改进|(% style="width:743px" %)实现持续改进计划的目标，以改进沟通与协调团队之间。|(% style="width:95px" %)M
1194 -|部署管理|(% style="width:743px" %)在参与部署新的或变更的所有团队之间进行沟通和协调服务组件。一些ChatOps工具可以与部署工具集成。|(% style="width:95px" %)M
1195 -|事件管理|(% style="width:743px" %)在外部利益干系人与参与其中的各个团队之间进行沟通和协调事件管理活动。一些ChatOps工具可以与其他IT和服务集成管理工具。ChatOps帮助IT团队进行支持活动，例如注册和诊断，从而减少响应时间并消除重复的任务。|(% style="width:95px" %)M
1196 -|知识管理|(% style="width:743px" %)在聊天日志中搜索非结构化知识。获取知识并确定按计划或预期提供服务的要求。收集反馈以支持持续改进。|(% style="width:95px" %)M
1197 -|问题管理|(% style="width:743px" %)运行根本原因分析和回顾。|(% style="width:95px" %)M
1198 -|发布管理|(% style="width:743px" %)在管理服务变更的所有团队之间进行沟通和协调。|(% style="width:95px" %)M
1199 -|风险管理|(% style="width:743px" %)以可搜索的格式存储数据和信息。|(% style="width:95px" %)L
923 +[[image:1641702752724-340.png]]
1200 1200  
925 +
1201 1201  === 4.3.7 站点可靠性工程 ===
1202 1202  
1203 1203  **定义：站点可靠性工程**
... ... @@ -1240,29 +1240,9 @@
1240 1240  
1241 1241  表4.20 与SRE相关的实践
1242 1242  
1243 -(% style="width:840px" %)
1244 -|**ITIL管理实践**|(% style="width:707px" %)**与SRE相关的活动/资源**|(% style="width:51px" %)**影响**
1245 -|可用性管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。跟踪“技术性” MTBF和（更重要的是）MTRS指标，例如用户中断时间，丢失的转换数量，丢失的业务价值和用户满意度。使用错误预算来平衡服务的可靠性和创新。|(% style="width:51px" %)H
1246 -|容量与性能管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。监控系统和已定义的SLO必须加以考虑和衡量。改进监视功能，以便在出现问题时更好地了解系统。|(% style="width:51px" %)H
1247 -|变更控制|(% style="width:707px" %)使用SRE技术和工具来启用对服务组件的变更以及失败变更的回滚。|(% style="width:51px" %)H
1248 -|事件管理|(% style="width:707px" %)使用SRE技术和工具来管理基础架构或平台层中的事件。|(% style="width:51px" %)H
1249 -|基础架构管理|(% style="width:707px" %)使用SRE技术和工具来帮助架构师和设计基础架构和平台功能以满足组织的需求。|(% style="width:51px" %)H
1250 -|监控和事态管理|(% style="width:707px" %)使用SRE技术和工具来改进系统的可见性，以便判断服务运行状况和诊断问题。|(% style="width:51px" %)H
1251 -|问题管理|(% style="width:707px" %)(((
1252 -来自SRE工具的数据可帮助识别问题，确保通过使用自动化快速应用规避措施。
968 +[[image:1641702861765-733.png]]
1253 1253  
1254 -自动化IT流程可提高弹性并减少工作量。
1255 1255  
1256 -回顾。
1257 -)))|(% style="width:51px" %)H
1258 -|服务设计|(% style="width:707px" %)在设计阶段进行SRE协作可以防止在生产后期出现各种问题或事件。尽管可以在开发生命周期的后期撤消或纠正设计决策，但这种变更付出了高昂的努力成本和复杂性。|(% style="width:51px" %)H
1259 -|软件开发管理|(% style="width:707px" %)向SRE团队提供要求并根据反馈采取行动。|(% style="width:51px" %)H
1260 -|部署管理|(% style="width:707px" %)部署过程应与服务设计中描述的风险过程保持一致。|(% style="width:51px" %)M
1261 -|组织变革管理|(% style="width:707px" %)SRE团队的核心职责是为团队快速创新做好准备。|(% style="width:51px" %)M
1262 -|发布管理|(% style="width:707px" %)借助SRE，用于发布软件的技术已应用于数字化基础架构。|(% style="width:51px" %)M
1263 -|服务配置管理|(% style="width:707px" %)借助SRE，可以将自动发现和版本控制应用于基础架构组件。|(% style="width:51px" %)M
1264 -|服务验证与测试|(% style="width:707px" %)对于SRE中的发布工程，建议连续的构建测试目标与确定项目发布的相同测试目标相对应。|(% style="width:51px" %)M
1265 -
1266 1266  **ITIL故事：站点可靠性工程**
1267 1267  
1268 1268  // Su：我们添加到应用程序的功能越多，它变得越复杂，其中的代码失败的可能性就越大。失败是任何软件平台都不可避免的功能。应用失败的方式可以教会我们如何对其进行重新校准以使其更具弹性。//
... ... @@ -1320,31 +1320,9 @@
1320 1320  
1321 1321  表4.21 与服务体验相关的实践
1322 1322  
1323 -(% style="width:977px" %)
1324 -|**ITIL管理实践**|(% style="width:719px" %)**与服务体验相关的活动/资源**|(% style="width:83px" %)**影响**
1325 -|业务分析|(% style="width:719px" %)除了关于功用和功效的传统要求之外，了解用户需求并将其转化为客户体验或用户体验要求。|(% style="width:83px" %)H
1326 -|服务目录管理|(% style="width:719px" %)从技术和体验方面描述服务和产品。|(% style="width:83px" %)H
1327 -|服务设计|(% style="width:719px" %)表达客户体验和用户体验的需求超出了基本体验。|(% style="width:83px" %)H
1328 -|服务台|(% style="width:719px" %)(((
1329 -善解人意并拥有情绪智力，以了解用户的体验需求。
1028 +[[image:1641702908935-105.png]]
1330 1330  
1331 -让用户选择沟通渠道。
1332 1332  
1333 -服务经验需要技术和信息支持者，例如自助服务工具，在线门户，移动应用程序，呼叫中心工具和聊天。
1334 -
1335 -使用用户满意度作为KPI。
1336 -
1337 -评估用户体验，同时选择与用户进行双向通信的工具。
1338 -
1339 -收集服务体验数据（用户对服务满意/不满意的粗略估计）。
1340 -)))|(% style="width:83px" %)H
1341 -|服务水平管理|(% style="width:719px" %)促进对服务消费者的心理和服务交互对消费者的（情感）影响的良好理解。|(% style="width:83px" %)H
1342 -|软件开发管理|(% style="width:719px" %)所需的服务体验会通知用户界面的设计。|(% style="width:83px" %)H
1343 -|监控与事态管理|(% style="width:719px" %)除技术监视和事态管理之外，还开发和配置工具和技术以监视服务体验和相关事态。|(% style="width:83px" %)M
1344 -|关系管理|(% style="width:719px" %)善解人意，在情感上能够理解消费者的体验需求。|(% style="width:83px" %)M
1345 -|服务验证与测试|(% style="width:719px" %)开发和维护服务体验测试。|(% style="width:83px" %)M
1346 -|供应商管理|(% style="width:719px" %)基于主观和客观协议来参与和管理供应商。|(% style="width:83px" %)M
1347 -
1348 1348  **ITIL故事：服务体验**
1349 1349  
1350 1350  //Su：在Axle汽车租赁公司，业务与IT之间没有鸿沟。开发团队协作以提供可响应客户需求的服务体验。我们使用应用程序和车辆中的数据来指导服务的优化和自动化。该应用程序是可定制的，因此用户可以根据自己的需求优化服务。//
... ... @@ -1391,18 +1391,9 @@
1391 1391  
1392 1392  表4.22 DevOps审计防御工具包与之相关的实践
1393 1393  
1394 -(% style="width:968px" %)
1395 -|**ITIL管理实践**|(% style="width:650px" %)**与DevOps审计防御工具包相关的活动/资源**|(% style="width:97px" %)**影响**
1396 -|持续改进|(% style="width:650px" %)审核提供了正式注册，确定优先级和进行管理的新信息或改进机会。|(% style="width:97px" %)H
1397 -|信息安全管理|(% style="width:650px" %)在产品生命周期中设计和实施控制措施，以提供广泛的可追溯性和联合责任制。|(% style="width:97px" %)H
1398 -|监控与事态管理|(% style="width:650px" %)合并性能和事态数据的运营数据仓库提供了丰富的信息库，以审核控制的实施和性能。|(% style="width:97px" %)H
1399 -|服务配置管理|(% style="width:650px" %)标准化配置可支持安全性和审核要求。|(% style="width:97px" %)H
1400 -|知识管理|(% style="width:650px" %)使员工和其他主要利益干系人可以访问相关政策文档和以前的审核报告。|(% style="width:97px" %)M
1401 -|风险管理|(% style="width:650px" %)在企业风险管理，技术风险管理和新的工作方式之间创建一种平衡，实用的方法。|(% style="width:97px" %)M
1402 -|劳动力和人才管理|(% style="width:650px" %)培训员工的义务和义务，以确保他们遵守所有相关政策和法规。|(% style="width:97px" %)M
1403 -|业务分析|(% style="width:650px" %)将审核结果和建议的补救措施纳入产品积压。|(% style="width:97px" %)L
1404 -|战略管理|(% style="width:650px" %)将定期的外部或内部审核合并到服务的路线图中，以提供对服务的独立管理。|(% style="width:97px" %)L
1077 +[[image:1641702956598-898.png]]
1405 1405  
1079 +
1406 1406  === 4.5.2 开发安全 ===
1407 1407  
1408 1408  大多数组织都有专门的信息安全团队，该团队执行风险评估并定义策略，规程和控制。在高速环境中，信息安全已尽可能集成到开发和运营的日常工作中，并将对过程控制的依赖转移到验证前提条件（例如员工的专业知识和完整性）上。安全员的角色从“维持治安”转变为使其他人能够采取必要措施。
... ... @@ -1456,48 +1456,11 @@
1456 1456  
1457 1457  表4.23 与DevSecOps相关的实践
1458 1458  
1459 -(% style="width:909px" %)
1460 -|**ITIL管理实践**|(% style="width:690px" %)**与DevSecOps相关的活动/资源**|(% style="width:75px" %)**影响**
1461 -|持续改进|(% style="width:690px" %)安全控制和策略的改进可以成为开发和运营团队纳入的学习和反馈的一部分。|(% style="width:75px" %)H
1462 -|信息安全管理|(% style="width:690px" %)在开发生命周期中设计和实施控件，以提供广泛的可追溯性和联合责任制。将信息安全职责整合到从业者的日常工作中。|(% style="width:75px" %)H
1463 -|监控与事态管理|(% style="width:690px" %)配置监视工具以连续扫描威胁和漏洞，以便可以将其升级为适当的团队。|(% style="width:75px" %)H
1464 -|变更控制|(% style="width:690px" %)实施预防性控制会自动要求安全管理人员进行预授权，然后开发人员才能根据某些定义的标准进行某些类型的生产数据编辑，包括他们有权使用的功能。|(% style="width:75px" %)M
1465 -|部署管理|(% style="width:690px" %)(((
1466 -安全管理提供有关关键证书管理，CD管道安全检查，容器安全，自动渗透测试以及数据和性能监视的指南。
1133 +[[image:1641703051758-407.png]]
1467 1467  
1468 -信息安全管理和风险管理应该是从业者日常工作的组成部分。
1469 -)))|(% style="width:75px" %)M
1470 -|知识管理|(% style="width:690px" %)使员工和其他主要利益干系人可以访问相关的政策文档。|(% style="width:75px" %)M
1471 -|风险管理|(% style="width:690px" %)(((
1472 -在企业风险管理，技术风险管理和新的工作方式之间创建一种平衡，实用的方法。
1135 +[[image:1641703070463-409.png]]
1473 1473  
1474 -在变更IT服务时，确定并消除对外部团队/团队的依赖，这可能涉及将批准权限委派给团队的产品/交付经理。
1475 1475  
1476 -投资具有定义和集成控制的过程自动化（例如CI / CD），以执行职责分离的要求。除此之外，采用独立的第三方合规软件可以中止部署的生产，直到获得批准为止。
1477 -
1478 -详细说明供应商合同中的要求和风险控制措施，以支持职责整合，并守组织的安全策略。
1479 -
1480 -进行价值流映射，以识别和最小化流程移交和批准。
1481 -)))|(% style="width:75px" %)M
1482 -|服务验证与测试|(% style="width:690px" %)测试数据管理是帮助确保持续稳定性，可靠性，可用性和安全性的关键元素。|(% style="width:75px" %)M
1483 -|战略管理|(% style="width:690px" %)整合职责以平衡法规要求和执行速度。|(% style="width:75px" %)M
1484 -|劳动力和人才管理|(% style="width:690px" %)在如何将安全性纳入开发和运营工作方面，对员工和其他相关利益干系人进行培训和辅导。|(% style="width:75px" %)M
1485 -|业务分析|(% style="width:690px" %)(((
1486 -了解内部和外部环境中的安全策略，标准，风险，潜在威胁和漏洞，并将其转化为开发和运营团队的要求。
1487 -
1488 -将安全要求纳入产品积压中。
1489 -)))|(% style="width:75px" %)L
1490 -|基础架构管理|(% style="width:690px" %)(((
1491 -安全管理可以通过有关安全标准和培训，隐私审查，威胁建模，凭证管理和数据安全的指南来增强基础架构和平台管理（尤其是在将基础架构用作代码时）。
1492 -
1493 -信息安全管理和风险管理应该是从业者日常工作的组成部分。
1494 -)))|(% style="width:75px" %)L
1495 -|软件开发管理|(% style="width:690px" %)(((
1496 -通过有关安全编码标准和培训，隐私审查，威胁建模，代码分析，源代码和凭证管理以及数据安全性的指南来增强软件开发。
1497 -
1498 -信息安全管理和风险管理应该是从业者日常工作的组成部分。
1499 -)))|(% style="width:75px" %)L
1500 -
1501 1501  //ITIL故事：DevSecOps//
1502 1502  
1503 1503  //Henri：数据的完整性和安全性是Axle汽车租赁团队工作方式的基础。快速工作以高节奏提供新的应用程序功能时，存在引入安全漏洞的风险，这些漏洞可能会被利用。//
... ... @@ -1538,19 +1538,11 @@
1538 1538  
1539 1539  表4.24 在不同的同行评审方法中的活动
1540 1540  
1541 -|(% rowspan="2" %)**评审方法**| | |**活动**| |
1542 -|**规划**|**准备**|**讨论**|**改进**|**验证**
1543 -|检查|是|是|是|是|是
1544 -|团队审查|是|是|是|是|无
1545 -|演练|是|无|是|是|无
1546 -|结对编程|是|无|连续|是|是
1547 -|(((
1548 -同行检查
1178 +[[image:1641703105916-225.png]]
1549 1549  
1550 -传送
1551 -)))|无|是|可能|是|无
1552 -|临时审查|无|无|是|是|无
1553 1553  
1181 +图4.28显示了同行评审对服务价值链的贡献。
1182 +
1554 1554  (% style="text-align:center" %)
1555 1555  [[image:1639569697056-454.png]]
1556 1556  
... ... @@ -1559,27 +1559,9 @@
1559 1559  
1560 1560  表4.25 与同行评审相关的实践
1561 1561  
1562 -(% style="width:919px" %)
1563 -|**ITIL管理实践**|(% style="width:622px" %)**与同行评审相关的活动/资源**|(% style="width:104px" %)**影响**
1564 -|风险管理|(% style="width:622px" %)(((
1565 -减少未经授权的变更被开发并发布到生产中的风险。
1191 +[[image:1641703160673-370.png]]
1566 1566  
1567 -在识别和评估风险之间进行交叉检查。
1568 -)))|(% style="width:104px" %)H
1569 -|软件开发管理|(% style="width:622px" %)检查同级之间的开发工作以提高代码质量，以确保其有效满足需求和性能期望。|(% style="width:104px" %)H
1570 -|变更控制|(% style="width:622px" %)(((
1571 -同事通过对标准或低风险变更进行同行评审来充当变更权限。
1572 1572  
1573 -通过同行评审或对变更请求的初步评估来授权进行某些变更。
1574 -)))|(% style="width:104px" %)M
1575 -|持续改进|(% style="width:622px" %)审查作为持续改进计划一部分而完成的工作，以帮助提高所取得成果的质量。|(% style="width:104px" %)M
1576 -|基础架构管理|(% style="width:622px" %)检查基础架构和平台组件以提高其质量。|(% style="width:104px" %)M
1577 -|知识管理|(% style="width:622px" %)查看知识文章和类似文档可帮助消除偏见并提高整个组织的沟通质量。|(% style="width:104px" %)M
1578 -|问题管理|(% style="width:622px" %)审查规避措施并提出对错误的修正，以提高其质量。|(% style="width:104px" %)M
1579 -|架构管理|(% style="width:622px" %)对技术架构的拟议变更进行演练，以确保变更与商定的蓝图和路线图保持一致。|(% style="width:104px" %)L
1580 -
1581 -图4.28显示了同行评审对服务价值链的贡献。
1582 -
1583 1583  表4.25概述了同行评审相关的实践。
1584 1584  
1585 1585  
Icon 1641702469032-780.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +83.0 KB
Content Icon
Icon 1641702487237-876.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +45.7 KB
Content Icon
Icon 1641702547499-544.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +102.0 KB
Content Icon
Icon 1641702577206-162.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +59.5 KB
Content Icon
Icon 1641702628320-774.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +90.2 KB
Content Icon
Icon 1641702718413-352.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +108.8 KB
Content Icon
Icon 1641702752724-340.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +73.6 KB
Content Icon
Icon 1641702861765-733.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +122.8 KB
Content Icon
Icon 1641702908935-105.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +93.1 KB
Content Icon
Icon 1641702956598-898.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +74.3 KB
Content Icon
Icon 1641703051758-407.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +117.4 KB
Content Icon
Icon 1641703070463-409.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +64.7 KB
Content Icon
Icon 1641703105916-225.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +34.0 KB
Content Icon
Icon 1641703160673-370.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +82.9 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司