由 superadmin 于 2024/12/25, 15:40 最后修改
从版本< 40.1 >
由superadmin编辑
在2024/09/27, 17:16上
到版本
由superadmin编辑
在2021/02/20, 15:03上
< >
修改评论 该版本没有评论

Summary

Details

Icon Page properties
标题
... ... @@ -1,1 +1,1 @@
1 -服务管理实践 - 14 服务连续性
1 +14 服务连续性管理
Content
... ... @@ -1,20 +1,18 @@
1 -{{box cssClass="floatinginfobox" title="{{info~}~}
2 -**学习长河老师 ¥799元  [[ITIL 4 基础级认证核心考点讲解和习题辅导网课>>https://www.itil4hub.cn/bin/view/ITIL4%E8%AE%A4%E8%AF%81%E5%9F%B9%E8%AE%AD%E8%80%83%E8%AF%95%E8%B5%84%E6%96%99/ITIL4%E5%9F%BA%E7%A1%80%E8%AE%A4%E8%AF%81%E5%BF%85%E8%80%83%E7%9F%A5%E8%AF%86%E9%80%9F%E5%AD%A6%E7%BD%91%E8%AF%BE/]]，轻松获取 ITIL 4 Foundation国际证书**
3 -{{/info~}~}
4 -
5 -**Contents**"}}
1 +{{box cssClass="floatinginfobox" title="**Contents**"}}
6 6  {{toc/}}
7 7  {{/box}}
8 8  
9 9  (((
10 10  
11 -
12 -
13 13  )))
14 14  
9 +需要下载 **ITIL 4 服务连续性管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“服务连续性”即可。
10 +
11 + ​[[image:微信截图_20210206234644.png]]
12 +
15 15  **申明：**
16 16  
17 -本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注**微信公众号**：**ITILXF**，并回复“**服务连续性**”即可。
15 +本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
18 18  
19 19  
20 20  请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
... ... @@ -36,6 +36,9 @@
36 36  * 支持本实践的信息和技术
37 37  * 对本实践的合作伙伴和供应商的考虑
38 38  
37 +
38 +
39 +
39 39  == **1.1 ITIL 4资格认证计划** ==
40 40  
41 41  本文档中的部分内容可作为以下教学大纲的一部分以供检查：
... ... @@ -176,6 +176,7 @@
176 176  * 中断期间应能够访问服务的有限的用户数量或特定用户组
177 177  * 中断期间用户应能够处理的单位时间段内有限的交易数量。
178 178  
180 +
179 179  === **2.2.5  业务影响分析** ===
180 180  
181 181  |(((
... ... @@ -193,6 +193,7 @@
193 193  * 设置优先级时间范围以在明确规定的最低可接受水平上恢复这些活动，考虑到在这时间内不恢复它们，带来的影响将变得不可接受
194 194  * 确定这些活动的依赖关系和支持资源，包括供应商，外包合作伙伴，以及其他相关利益方。
195 195  
198 +
196 196  === **2.2.6  服务连续性/ 灾难恢复计划** ===
197 197  
198 198  |(((
... ... @@ -230,19 +230,19 @@
230 230  * 进行练习，并测试如果发生灾难情况下，服务连续性计划的启用
231 231  * 有一些活动和责任领域尽管仍与服务连续性管理密切相关，但不包含在服务连续性管理实践中。表2.1中列出了这些内容，以及涉及到的包含这些内容的实践。重要的是要记住，ITIL实践只是在价值流的背景中使用的工具的集合；它们应当根据情况在必要时组合在一起。
232 232  
233 -(% style="width:469px" %)
234 -|(% style="width:335px" %)活动|(% style="width:132px" %)实践指南
235 -|(% style="width:335px" %)与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|(% style="width:132px" %)关系管理
236 -|(% style="width:335px" %)协商并与客户服务连续性要求达成一致|(% style="width:132px" %)服务级别管理
237 -|(% style="width:335px" %)将服务连续性解决方案设计为服务模型的一部分|(% style="width:132px" %)服务设计
238 -|(% style="width:335px" %)使服务连续性解决方案与业务架构保持一致|(% style="width:132px" %)架构管理
239 -|(% style="width:335px" %)识别与服务连续性相关的风险|(% style="width:132px" %)风险管理
240 -|(% style="width:335px" %)与供应商和合作伙伴建立和管理合同|(% style="width:132px" %)供应商管理
241 -|(% style="width:335px" %)监控服务的可用性|(% style="width:132px" %)监控和事态管理
242 -|(% style="width:335px" %)证明新的服务连续性解决方案|(% style="width:132px" %)组合管理
243 -|(% style="width:335px" %)实施风险缓解措施并更改IT基础设施，以确保弹性|(% style="width:132px" %)项目管理, 变更控制
244 -|(% style="width:335px" %)管理并实施持续改进|(% style="width:132px" %)持续改进
236 +|活动|实践指南
237 +|与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|关系管理
238 +|协商并与客户服务连续性要求达成一致|服务级别管理
239 +|将服务连续性解决方案设计为服务模型的一部分|服务设计
240 +|使服务连续性解决方案与业务架构保持一致|架构管理
241 +|识别与服务连续性相关的风险|风险管理
242 +|与供应商和合作伙伴建立和管理合同|供应商管理
243 +|监控服务的可用性|监控和事态管理
244 +|证明新的服务连续性解决方案|组合管理
245 +|实施风险缓解措施并更改IT基础设施，以确保弹性|项目管理, 变更控制
246 +|管理并实施持续改进|持续改进
245 245  
248 +
246 246  === **2.3.1  可用性与连续性之间的界线** ===
247 247  
248 248  服务的连续性和可用性管理的实践之间的界限是不明显的。两种做法都涉及风险的概念，并致力于识别和准备应对可能威胁并导致服务不能运转的事件。对于这两种实践，都需要了解VBF和风险评估或服务故障的BIA。最终，两种做法都确保了组织的抗故障能力。
... ... @@ -249,16 +249,15 @@
249 249  
250 250  一些组织不希望将可用性的管理和连续性分开。但是，表2.2中概述了这两种做法之间的一些差异，在设计服务管理系统时应考虑这些差异。
251 251  
252 -(% style="width:454px" %)
253 -|(% style="width:174px" %)可用性管理|(% style="width:278px" %)服务连续性管理
254 -|(% style="width:174px" %)专注于高概率的风险|(% style="width:278px" %)专注于高影响风险（紧急情况，灾难）
255 -|(% style="width:174px" %)更主动|(% style="width:278px" %)更被动
256 -|(% style="width:174px" %)减少意外的可能性|(% style="width:278px" %)减少意外的影响
257 -|(% style="width:174px" %)关注技术解决方案|(% style="width:278px" %)关注组织措施
258 -|(% style="width:174px" %)优化|(% style="width:278px" %)创建冗余
259 -|(% style="width:174px" %)不属于公司职能|(% style="width:278px" %)通常是公司职能的一部分
260 -|(% style="width:174px" %)日常业务|(% style="width:278px" %)特殊情况下
261 -|(% style="width:174px" %)MTRS, MTBF, MTBSI|(% style="width:278px" %)RTO, RPO
255 +|可用性管理|服务连续性管理
256 +|专注于高概率的风险|专注于高影响风险（紧急情况，灾难）
257 +|更主动|更被动
258 +|减少意外的可能性|减少意外的影响
259 +|关注技术解决方案|关注组织措施
260 +|优化|创建冗余
261 +|不属于公司职能|通常是公司职能的一部分
262 +|日常业务|特殊情况下
263 +|MTRS, MTBF, MTBSI|RTO, RPO
262 262  
263 263  表2.2 可用性管理和服务连续性管理之间的区别
264 264  
... ... @@ -284,6 +284,7 @@
284 284  服务提供者必须承诺服务连续性计划，以便继续服务的交付。
285 285  )))
286 286  
289 +
287 287  === **2.3.3 服务连续性实践在管理风险时的角色** ===
288 288  
289 289  风险的概念是服务连续性管理实践的核心。该实践通常关注于减轻无法完全防止的高影响，低概率风险。
... ... @@ -334,25 +334,66 @@
334 334  
335 335  表2.3响应和恢复规划结构中的层次
336 336  
337 -(% style="width:683px" %)
338 -|(% style="width:66px" %)层次|(% style="width:614px" %)描述
339 -|(% style="width:66px" %)战略层|(% style="width:614px" %)高管如何做出有关恢复流程的决策，如何与外部各方（包括相关媒体）进行沟通以及处理服务连续性计划中未涉及的任何情况
340 -|(% style="width:66px" %)战术层|(% style="width:614px" %)管理层如何协调恢复流程，以确保根据优先级（当前业务优先级，季节性变化等）适当分配资源并管理规划团队和恢复团队之间的冲突
341 -|(% style="width:66px" %)操作层|(% style="width:614px" %)团队如何执行恢复活动，包括响应破坏性事件，恢复到服务的预定义级别，和/或提供替代设施以继续运行
340 +|层次|描述
341 +|战略层|高管如何做出有关恢复流程的决策，如何与外部各方（包括相关媒体）进行沟通以及处理服务连续性计划中未涉及的任何情况
342 +|战术层|管理层如何协调恢复流程，以确保根据优先级（当前业务优先级，季节性变化等）适当分配资源并管理规划团队和恢复团队之间的冲突
343 +|操作层|团队如何执行恢复活动，包括响应破坏性事件，恢复到服务的预定义级别，和/或提供替代设施以继续运行
342 342  
343 343  根据组织的规模以及服务提供者是内部的还是外部的，可能会有不同的解决方案来构建计划。责任主体也可能有所不同。
344 344  
345 345  服务连续性计划根据服务提供者的类型和组织的规模，其结构的复杂度可能会或多或少。表2.4 概述了一些常见的结构。
346 346  
347 -[[image:1642262167262-433.png]]
349 +|(% style="width:122px" %) |(% style="width:290px" %)小型组织|大型组织
350 +|(% style="width:122px" %)内部服务提供商|(% style="width:290px" %)(((
351 +在小型组织的IT部门中，可能没有任何服务连续性计划。所有连续性安排都可以作为业务连续性管理的一部分进行管理。
348 348  
353 +特定的IT服务连续性活动可以作为事件管理实践的一部分执行。
354 +)))|(((
355 +战略层：由高管执行的危机管理计划。它通常是业务连续性计划的一部分。
356 +
357 +战术层：大量计划，每个计划都涵盖一个产品，服务，业务单元，站点或位置，每个计划都拥有自己的恢复团队。战术的IT部门活动可以包含在业务连续性计划中，但通常将它们设计为单独的相关计划。
358 +
359 +操作层：大量的用于特定恢复活动的详细步骤（例如，从备份中恢复应用程序数据）。其他部门可能会有自己的特定操作说明，作为连续性计划的一部分。
360 +)))
361 +|(% style="width:122px" %)外部服务提供商|(% style="width:290px" %)所有层次（战略，战术，运行的）都可以作为一个计划实施，而一个团队则负责响应和恢复的各个方面。|连续性计划级别的描述与上面类似，但是服务提供者对所有级别负责。
362 +
349 349  表2.4 连续性计划的结构选项
350 350  
351 351  
352 352  服务连续性计划应涵盖表2.5中概述的灾难发生之后的各个阶段。
353 353  
354 -[[image:1642262190748-510.png]]
368 +|(% style="width:79px" %)阶段|(% style="width:503px" %)响应|恢复|复原
369 +|(% style="width:79px" %)计划|(% style="width:503px" %)响应计划|恢复计划|恢复正常运行计划
370 +|(% style="width:79px" %)内容|(% style="width:503px" %)(((
371 +应触发服务连续性计划的事件和场景
355 355  
373 +危机管理组联系人
374 +
375 +初始响应并最小化潜在损失的规程。通常会有针对特定场景的程序（例如火灾或停电）
376 +
377 +用于挑选恢复选项的文档化准则（如果有）
378 +
379 +沟通程序，包括与客户，合作伙伴和员工的沟通
380 +
381 +用于启用的文件化的触发器
382 +)))|(((
383 +恢复团队成员联系方式
384 +
385 +恢复团队的协调指南
386 +
387 +恢复程序的详细说明
388 +
389 +整个组织的监控和共享信息的指南
390 +
391 +升级程序
392 +)))|(((
393 +恢复正常运行的文件化准则
394 +
395 +恢复正常运行程序的详细说明
396 +
397 +复原恢复站点的说明（如果有）
398 +)))
399 +
356 356  表2.5 响应阶段和恢复阶段
357 357  
358 358  
... ... @@ -367,13 +367,12 @@
367 367  
368 368  表2.6 中概述的服务连续性选项可以作为总体风险缓解计划的一部分来设计和实现。
369 369  
370 -(% style="width:475px" %)
371 -|(% style="width:129px" %)服务管理维度|(% style="width:343px" %)服务连续性措施
372 -|(% style="width:129px" %)组织和人员|(% style="width:343px" %)(((
414 +|(% style="width:174px" %)服务管理维度|(% style="width:842px" %)服务连续性措施
415 +|(% style="width:174px" %)组织和人员|(% style="width:842px" %)(((
373 373  * 在灾难期间的人员管理
374 374  * 使用替代站点和设施
375 375  )))
376 -|(% style="width:129px" %)信息和技术|(% style="width:343px" %)(((
419 +|(% style="width:174px" %)信息和技术|(% style="width:842px" %)(((
377 377  * 物理安全
378 378  * 弹性电信网络
379 379  * 运维中的数据保护：使用RAID阵列，SAN等来确保数据的可用性
... ... @@ -381,12 +381,12 @@
381 381  * 容错应用程序
382 382  * 监控以提供及时告警
383 383  )))
384 -|(% style="width:129px" %)合作伙伴和供应商|(% style="width:343px" %)(((
427 +|(% style="width:174px" %)合作伙伴和供应商|(% style="width:842px" %)(((
385 385  * 互惠协议
386 386  * 将服务外包给多个提供商
387 387  * 作为服务的火灾探测系统或灭火系统
388 388  )))
389 -|(% style="width:129px" %)流程和价值流|(% style="width:343px" %)(((
432 +|(% style="width:174px" %)流程和价值流|(% style="width:842px" %)(((
390 390  * 服务交付的手动操作和替代方法
391 391  * 响应和恢复的计划与程序（服务连续性计划）
392 392  )))
... ... @@ -401,6 +401,7 @@
401 401  * 效果根据风险管理原则，应评估服务连续性措施的效果，并将其与破坏性事态的预期损失进行比较。
402 402  * 效率服务连续性度量的成本应该进行评估，并与收益进行比较。通过估算实施该措施后破坏性事态发生概率的降低，并乘以发生事态会对服务提供者和客户造成的预期的影响，可以计算出收益。就成本而言，应将此价值与该措施实施的成本进行比较。这里可以使用成本效益分析。
403 403  
447 +
404 404  === **2.4.3 确保认知和就绪状态** ===
405 405  
406 406  未经测试的恢复计划通常根本无法按预期工作。因此，测试是服务连续性管理的关键组成部分，并且是确保所选策略，已实施措施和计划切实可行的唯一方法。
... ... @@ -419,9 +419,32 @@
419 419  
420 420  表2.7 概述了2013年。
421 421  
422 -[[image:1642262249963-601.png]]
466 +|(% style="width:92px" %)演练类型|(% style="width:426px" %)关键特征|目的
467 +|(% style="width:92px" %)走查|(% style="width:426px" %)(((
468 +* 基于讨论的演练
469 +* 未加压的环境
470 +* 通常专注于某一特定区域进行改进
471 +)))|(((
472 +用于恢复团队成员首次见面
423 423  
424 -[[image:1642262271197-361.png]]
474 +利用改进机会
475 +)))
476 +|(% style="width:92px" %)桌上演练|(% style="width:426px" %)(((
477 +* 基于一个给定场景的讨论
478 +* 通常实时运行，但可以包含“时间跳跃”以使得场景的不同阶段都受到演练
479 +)))|提高对计划的了解
480 +|(% style="width:92px" %)指挥所演练|(% style="width:426px" %)(((
481 +* 以模拟真实事件的方式为恢复团队成员提供信息，并邀请他们做出回应
482 +)))|测试沟通，决策和协调
483 +|(% style="width:92px" %)现场|(% style="width:426px" %)(((
484 +* 测试计划的最逼真的方法
485 +* 范围可以从一个组件的恢复的小型排练，到整个服务或组织的恢复的全面排练
486 +* 通常包括参与的利益相关方
487 +)))|测试在发生破坏性事态时，达到RTO，RPO和最低目标服务水平的能力
488 +|(% style="width:92px" %)测试|(% style="width:426px" %)(((
489 +* 它通常应用于特定的硬件或软件，例如从备份恢复应用程序数据。
490 +* 依照ISO 22301，测试是一种独特类型的演练，它包含了一个期望，就是：演练的（一个或多个）目标的成功或失败要素正在计划中
491 +)))|当故障的风险较高时，测试服务组件的恢复
425 425  
426 426  表2.7 锻炼类型
427 427  
... ... @@ -437,20 +437,19 @@
437 437  
438 438  服务连续性管理实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.8给出了一些关键指标的示例。
439 439  
440 -(% style="width:565px" %)
441 -|(% style="width:172px" %)实践成功因素|(% style="width:391px" %)指标示例
442 -|(% style="width:172px" %)制定和管理服务连续性计划|(% style="width:391px" %)(((
507 +|实践成功因素|指标示例
508 +|制定和管理服务连续性计划|(((
443 443  * 具有清晰地文件化连续性要求的产品和服务的百分比
444 444  * 文件化的服务连续性计划中（关键）产品和服务的百分比
445 445  * 及时更新服务连续性计划
446 446  )))
447 -|(% style="width:172px" %)降低服务的连续性风险|(% style="width:391px" %)(((
513 +|降低服务的连续性风险|(((
448 448  * RTO达成情况（实际灾难和演练）
449 449  * RPO达成情况（实际灾难和演练）
450 450  * 有效连续性措施的百分比
451 451  * 实际损失与预期损失之比
452 452  )))
453 -|(% style="width:172px" %)确保认知和就绪状态|(% style="width:391px" %)(((
519 +|确保认知和就绪状态|(((
454 454  * 按计划进行的演练和认知活动的百分比
455 455  * 在给定时间段内（通常为过去6个月）对其连续性计划进行测试的服务所占的百分比
456 456  )))
... ... @@ -503,27 +503,27 @@
503 503  * 测试服务连续性计划
504 504  * 响应和恢复
505 505  
572 +
506 506  === **3.2.1  服务连续性管理的治理** ===
507 507  
508 508  该流程包括表3.1中列出的活动，并将输入转换为输出。
509 509  
510 -(% style="width:515px" %)
511 -|(% style="width:176px" %)关键输入|(% style="width:145px" %)活动|(% style="width:191px" %)关键输出
512 -|(% style="width:176px" %)(((
513 -* 业务影响分析报告
514 -* 风险登记册
515 -* 客户要求
516 -* 法规要求
517 -* 风险偏好
518 -* 标准
519 -)))|(% style="width:145px" %)(((
520 -* 范围的定义
521 -* 策略设置
522 -* 认知和演练方案制定
523 -)))|(% style="width:191px" %)(((
524 -* 服务连续性策略
525 -* 文件化的角色和职责
526 -* 认知和演练方案
577 +|关键输入|活动|关键输出
578 +|(((
579 +1. 业务影响分析报告
580 +1. 风险登记册
581 +1. 客户要求
582 +1. 法规要求
583 +1. 风险偏好
584 +1. 标准
585 +)))|(((
586 +1. 范围的定义
587 +1. 策略设置
588 +1. 认知和演练方案制定
589 +)))|(((
590 +1. 服务连续性策略
591 +1. 文件化的角色和职责
592 +1. 认知和演练方案
527 527  )))
528 528  
529 529  表3.1 服务连续性管理的治理的输入，活动和输出
... ... @@ -539,9 +539,8 @@
539 539  
540 540  这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.2进一步描述了这些活动。
541 541  
542 -(% style="width:687px" %)
543 -|(% style="width:98px" %)活动|(% style="width:587px" %)描述
544 -|(% style="width:98px" %)范围的定义|(% style="width:587px" %)(((
608 +|(% style="width:106px" %)活动|(% style="width:662px" %)描述
609 +|(% style="width:106px" %)范围的定义|(% style="width:662px" %)(((
545 545  定义服务连续性管理实践的范围，确保它所涵盖的组织的环境和地域清晰。
546 546  
547 547  组织范围可能受到产品和服务，站点和位置，客户等的限制。那些已停产的或即将终止的产品和服务通常被排除在范围之外，非关键和低利润的产品和服务也一样。
... ... @@ -559,7 +559,7 @@
559 559  
560 560  根据灾难定义实践的范围也很重要。
561 561  )))
562 -|(% style="width:98px" %)策略设置|(% style="width:587px" %)(((
627 +|(% style="width:106px" %)策略设置|(% style="width:662px" %)(((
563 563  策略的设置包括：
564 564  
565 565  * 记录范围。
... ... @@ -568,7 +568,7 @@
568 568  * 应尽快建立并传达政策，以便所有参与服务连续性管理实践或受其影响的利益相关者都知道范围，限制及其职责。
569 569  * 范围和政策应定期修订（通常每年一次）。修订被触发，可能是由于破坏性事态（尤其是计划未涵盖的），一个新的服务，一个新的客户或者是与合作伙伴的一个新关系。
570 570  )))
571 -|(% style="width:98px" %)认知和演练方案制定|(% style="width:587px" %)(((
636 +|(% style="width:106px" %)认知和演练方案制定|(% style="width:662px" %)(((
572 572  测试是整个服务连续性管理实践的关键部分：这是确保所选策略，措施和计划有效的唯一方法。
573 573  
574 574  应该制定教育，认知培训和演练计划，以确保实践的所有部分（站点，团队成员，服务或CI）每年至少进行一次测试。
... ... @@ -601,9 +601,8 @@
601 601  
602 602  该流程包括表3.3中列出的活动，并将输入转换为输出。
603 603  
604 -(% style="width:475px" %)
605 -|(% style="width:153px" %)关键输入|(% style="width:150px" %)活动|(% style="width:170px" %)关键输出
606 -|(% style="width:153px" %)(((
669 +|关键输入|活动|关键输出
670 +|(((
607 607  * 服务文档
608 608  * 风险评估报告
609 609  * VBF损失的财务数据
... ... @@ -612,12 +612,12 @@
612 612  * 风险管理策略
613 613  * 风险偏好
614 614  * 监管要求
615 -)))|(% style="width:150px" %)(((
679 +)))|(((
616 616  * VBF识别
617 617  * 中断后果分析
618 618  * VBF相互依赖关系识别
619 619  * 服务连续性要求的确定
620 -)))|(% style="width:170px" %)(((
684 +)))|(((
621 621  * VBF的优先级列表
622 622  * 文件化的VBF损失产生的影响
623 623  * 文件化的VBF相互依赖关系
... ... @@ -637,9 +637,8 @@
637 637  
638 638  这些活动可以由组织中的许多人以不同程度的正式方式来执行。表3.4进一步概述了这些活动。
639 639  
640 -(% style="width:704px" %)
641 -|(% style="width:78px" %)活动|(% style="width:624px" %)描述
642 -|(% style="width:78px" %)VBF识别|(% style="width:624px" %)(((
704 +|(% style="width:110px" %)活动|(% style="width:657px" %)描述
705 +|(% style="width:110px" %)VBF识别|(% style="width:657px" %)(((
643 643  VBF涉及到服务中对于服务提供者和/或客户的成功至关重要的一部分。识别和文件化这些VBF，以提供适当的焦点和资源分配非常重要。
644 644  
645 645  可以使用许多不同的技术来识别风险，包括头脑风暴，与利益相关者（包括客户和用户）的访谈，对服务文档的分析等等。
... ... @@ -646,7 +646,7 @@
646 646  
647 647  如果服务提供者具有已建立的风险管理实践，则有关风险评估的信息可能有助于理解最关键的区域。
648 648  )))
649 -|(% style="width:78px" %)中断后果分析|(% style="width:624px" %)(((
712 +|(% style="width:110px" %)中断后果分析|(% style="width:657px" %)(((
650 650  当确定了VBF时，应确定中断的影响。该影响可能是可以准确识别的“硬” 影响，例如财务损失，也可以是“软” 影响，例如声誉受损或失去竞争优势。
651 651  
652 652  可以考虑FAIR提出的以下形式的损失：
... ... @@ -664,16 +664,16 @@
664 664  
665 665  服务中断造成的损失通常会随着时间呈指数增长。除了与组织产生其主要价值主张的能力下降的有关损失之外，还存在罚款，判决和声誉受损的威胁。
666 666  )))
667 -|(% style="width:78px" %)(((
730 +|(% style="width:110px" %)(((
668 668  VBF
669 669  
670 670  相互依赖关系识别
671 -)))|(% style="width:624px" %)(((
734 +)))|(% style="width:657px" %)(((
672 672  VBF和服务组件以及关键的内部和外部资源之间的相互依赖关系应予以识别和文件化。
673 673  
674 674  为此，如果已安装配置管理数据库，则服务提供者可以使用服务和配置模型。组件故障影响分析（CFIA）也可能是有用的技术。CFIA可用于识别失效的单个点，现有的冗余等。
675 675  )))
676 -|(% style="width:78px" %)服务连续性要求的确定|(% style="width:624px" %)(((
739 +|(% style="width:110px" %)服务连续性要求的确定|(% style="width:657px" %)(((
677 677  基于对中断后果和识别的相互依赖关系的分析，服务提供者应为服务连续性管理范围中的每个服务或VBF确定服务连续性要求，包括：
678 678  
679 679  * 恢复时间目标
... ... @@ -684,23 +684,22 @@
684 684  表3.4 业务影响分析流程的活动
685 685  
686 686  
687 -=== **3.2.3  制定和维护服务连续性计划** ===
750 +=== **3.3.2  制定和维护服务连续性计划** ===
688 688  
689 689  该流程包括表3.5 中列出的活动，并将输入转换为输出。
690 690  
691 -(% style="width:554px" %)
692 -|(% style="width:186px" %)关键输入|(% style="width:188px" %)活动|(% style="width:178px" %)关键输出
693 -|(% style="width:186px" %)(((
754 +|关键输入|活动|关键输出
755 +|(((
694 694  * 业务影响分析报告
695 695  * 现有控件
696 696  * 有关可用资源的信息
697 697  * 消费者的连续性计划
698 698  * 服务连续性策略
699 -)))|(% style="width:188px" %)(((
761 +)))|(((
700 700  * 服务连续性策略制定
701 701  * 服务连续性计划制定
702 702  * 服务连续性计划的初始测试
703 -)))|(% style="width:178px" %)(((
765 +)))|(((
704 704  * 新的和更新的控件
705 705  * 服务连续性策略
706 706  * 服务连续性计划
... ... @@ -721,36 +721,34 @@
721 721  
722 722  表3.6 进一步概述了这些活动。
723 723  
724 -(% style="width:657px" %)
725 -|(% style="width:147px" %)活动|(% style="width:508px" %)描述
726 -|(% style="width:147px" %)服务连续性策略制定|(% style="width:508px" %)(((
786 +|(% style="width:147px" %)活动|(% style="width:621px" %)描述
787 +|(% style="width:147px" %)服务连续性策略制定|(% style="width:621px" %)(((
727 727  基于BIA 报告，服务提供者应该确定一套适当的且具有成本效益的服务连续性策略集。
728 728  
729 729  对于影响更早，影响更大的流程和服务，应采取更多的预防措施。对于影响较低且需要较长时间开发的流程和服务，应更加重视恢复措施。
730 730  )))
731 -|(% style="width:147px" %)服务连续性计划制定|(% style="width:508px" %)(((
792 +|(% style="width:147px" %)服务连续性计划制定|(% style="width:621px" %)(((
732 732  基于服务连续性政策和策略，服务提供者应该制定和维护服务连续性计划。
733 733  
734 734  如果服务或恢复团队成员发生变化，则必须更新计划。计划也可以在演练或实际恢复之后更新。
735 735  )))
736 -|(% style="width:147px" %)服务连续性计划的初始测试|(% style="width:508px" %)发布之前，应测试服务连续性计划。初始测试的方法类似于正在进行的演练。
797 +|(% style="width:147px" %)服务连续性计划的初始测试|(% style="width:621px" %)发布之前，应测试服务连续性计划。初始测试的方法类似于正在进行的演练。
737 737  
738 738  表3.6 制定和维护服务连续性计划流程的活动
739 739  
740 740  
741 -=== **3.2.4  测试服务连续性计划** ===
802 +=== **3.3.3  测试服务连续性计划** ===
742 742  
743 743  该流程包括表3.7 中列出的活动，并将输入转换为输出。
744 744  
745 -(% style="width:536px" %)
746 -|(% style="width:156px" %)关键输入|(% style="width:164px" %)活动|(% style="width:214px" %)关键输出
747 -|(% style="width:156px" %)(((
806 +|关键输入|活动|关键输出
807 +|(((
748 748  * 认知和演练方案
749 749  * 服务连续性计划
750 -)))|(% style="width:164px" %)(((
810 +)))|(((
751 751  * 进行演练
752 752  * 服务连续性审计
753 -)))|(% style="width:214px" %)(((
813 +)))|(((
754 754  * 演练报告
755 755  * 新的和更新的控件的要求
756 756  * 策略或计划的变更请求
... ... @@ -770,9 +770,8 @@
770 770  
771 771  这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.8进一步概述了这些活动。
772 772  
773 -(% style="width:613px" %)
774 -|(% style="width:121px" %)活动|(% style="width:490px" %)描述
775 -|(% style="width:121px" %)进行演练|(% style="width:490px" %)(((
833 +|(% style="width:131px" %)活动|(% style="width:636px" %)描述
834 +|(% style="width:131px" %)进行演练|(% style="width:636px" %)(((
776 776  演练应按计划的时间间隔，和当出现可能影响恢复的显著变化时进行。服务中断的可能影响越高，演练的频率就应该越高。
777 777  
778 778  演练和测试不仅是确保准备就绪的方法；它们也是改进机会。这通常是一个好主意，用来分析测试结果以及整个恢复团队绩效，然后生成包括结果和建议的演练报告。
... ... @@ -781,7 +781,7 @@
781 781  
782 782  如果演练失败，则会更新后续演练时间表以便尽快重新执行失败的演练。
783 783  )))
784 -|(% style="width:121px" %)服务连续性审计|(% style="width:490px" %)(((
843 +|(% style="width:131px" %)服务连续性审计|(% style="width:636px" %)(((
785 785  服务连续性审计可确保在环境更改时，BIA，服务连续性策略和计划保持适当和相关。审计通常是按计划进行的，但是可能由于演练失败或恢复失败而触发。
786 786  
787 787  审核可以在内部进行，也可以由第三方进行。审计的输出可能会确定一个实施新的或更新的控件的需求，也可以是调整服务连续性策略或计划的需求。
... ... @@ -790,19 +790,18 @@
790 790  表3.8测试服务连续性计划流程的活动
791 791  
792 792  
793 -=== **3.2.5  响应和恢复** ===
852 +=== **3.3.4  响应和恢复** ===
794 794  
795 795  该流程包括表3.9 中所述的活动，并将输入转换为输出。
796 796  
797 -(% style="width:496px" %)
798 -|(% style="width:170px" %)关键输入|(% style="width:155px" %)活动|(% style="width:169px" %)关键输出
799 -|(% style="width:170px" %)(((
856 +|关键输入|活动|关键输出
857 +|(((
800 800  * 服务连续性计划
801 801  * 事件记录
802 -)))|(% style="width:155px" %)(((
860 +)))|(((
803 803  * 调用
804 804  * 执行服务连续性计划
805 -)))|(% style="width:169px" %)(((
863 +)))|(((
806 806  * 恢复报告
807 807  * 新的和更新的控件的要求
808 808  * 变更计划的请求
... ... @@ -823,9 +823,8 @@
823 823  
824 824  表3.10 进一步概述了这些活动。
825 825  
826 -(% style="width:715px" %)
827 -|(% style="width:92px" %)实现价值|(% style="width:621px" %)描述
828 -|(% style="width:92px" %)启动|(% style="width:621px" %)(((
884 +|(% style="width:152px" %)实现价值|(% style="width:615px" %)描述
885 +|(% style="width:152px" %)启动|(% style="width:615px" %)(((
829 829  启动是一项声明行为，组织的连续性安排需要实施，以便继续提供关键产品和服务[[12>>path:#_bookmark12]].
830 830  
831 831  启动的决定通常是由“ 危机管理”团队（在组织结构的战略层面上）做出的。[[13>>path:#_bookmark13]]），用于核算：
... ... @@ -834,8 +834,8 @@
834 834  * 服务中断的可能持续时间
835 835  * 每天/每月/每年的时间
836 836  )))
837 -|(% colspan="2" style="width:712px" %)(((
838 -|(% style="width:81px" %)启动|(% style="width:614px" %)(((
894 +|(% colspan="2" %)(((
895 +|(% style="width:143px" %)启动|(% style="width:607px" %)(((
839 839  如果风险较低，则危机管理团队可以决定不调用服务连续性计划。
840 840  
841 841  如果启动，危机管理团队还应该：
... ... @@ -845,7 +845,7 @@
845 845  
846 846  启动是服务连续性计划的最终测试。如果准备工作已经完成并且计划已经制定和经过测试，那么启动应该很简单。如果计划未经测试，则可能会失败。
847 847  )))
848 -|(% style="width:81px" %)执行服务连续性计划|(% style="width:614px" %)(((
905 +|(% style="width:143px" %)执行服务连续性计划|(% style="width:607px" %)(((
849 849  一旦发生启动，所有参与的恢复团队都应执行服务连续性程序。恢复可能是一段时间的高级活动，需要许多人花费长时间。在战术层面上，恢复团队调度员必须对此进行识别和管理。
850 850  
851 851  任何时候都可能发生中断，因此对于办公室内外的关键人员而言，容易获得启动流程的指南是非常必要的。
... ... @@ -878,28 +878,157 @@
878 878  
879 879  表4.1 能力代码和简介
880 880  
881 -(% style="width:477px" %)
882 -|(% style="width:75px" %)能力代码|(% style="width:400px" %)能力类型（活动和技能）
883 -|(% style="width:75px" %)L|(% style="width:400px" %)**领导者 **决策，委派，监督其他活动，提供激励和动机以及评估结果
884 -|(% style="width:75px" %)A|(% style="width:400px" %)**管理员 **分配任务并确定优先级，保留记录，进行中的报告并启动基本改进
885 -|(% style="width:75px" %)C|(% style="width:400px" %)**协调员/沟通者 **协调多方，维护利益相关者之间的沟通，并开展宣传活动
886 -|(% style="width:75px" %)M|(% style="width:400px" %)**方法和技术专家 **设计和实施工作技术，记录程序，咨询流程，工作分析和持续改进
887 -|(% style="width:75px" %)T|(% style="width:400px" %)**技术专家 **提供技术（IT）专业知识并实施基于专业知识的任务
938 +|能力代码|能力类型（活动和技能）
939 +|L|**领导者 **决策，委派，监督其他活动，提供激励和动机以及评估结果
940 +|A|**管理员 **分配任务并确定优先级，保留记录，进行中的报告并启动基本改进
941 +|C|**协调员/沟通者 **协调多方，维护利益相关者之间的沟通，并开展宣传活动
942 +|M|**方法和技术专家 **设计和实施工作技术，记录程序，咨询流程，工作分析和持续改进
943 +|T|**技术专家 **提供技术（IT）专业知识并实施基于专业知识的任务
888 888  
945 +
889 889  表4.2 中列出了服务连续性管理实践涉及的角色示例，以及相关的能力简介和特定技能。
890 890  
891 -[[image:1642262555280-925.png]]
948 +|流程活动|(% colspan="2" %)负责角色|(% colspan="2" %)能力类型|具体技能
949 +|(% colspan="6" %)服务连续性管理流程的治理
950 +|范围的定义|(% colspan="2" %)指导委员会|(% colspan="2" %)MC|对各种影响组织的PESTLE因素的能见度
951 +|策略设置|(% colspan="2" %)指导委员会|(% colspan="2" %)MCL|(((
952 +意识到组织特定的文档要求
892 892  
893 -[[image:1642262576270-128.png]]
954 +确保管理人员的持续参与，以确保服务连续性策略的清晰性和持续实现
955 +)))
956 +|认知和演练方案开发|(% colspan="2" %)连续性管理员|(% colspan="2" %)ACM|(((
957 +演练类型和恢复团队结构的知识
894 894  
895 -[[image:1642262601759-766.png]]
959 +启用沟通渠道
960 +)))
961 +|(% colspan="6" %)业务影响分析流程
962 +|VBF识别|(% colspan="2" %)(((
963 +服务或产品所有者
896 896  
897 -[[image:1642262627236-955.png]]
965 +关系经理
898 898  
967 +服务设计者
899 899  
969 +客户
970 +)))|(% colspan="2" %)CM|(((
971 +业务分析
972 +
973 +很好的了解服务消费者的业务
974 +
975 +熟悉产品，包括其架构和配置
976 +)))
977 +|中断后果分析|(% colspan="2" %)(((
978 +服务或产品所有者
979 +
980 +关系经理
981 +
982 +客户
983 +)))|(% colspan="2" %)MC|(((
984 +能够系统地应用定性和定量风险分析工具
985 +
986 +专业能力和对影响服务的PESTLE因素的能见度
987 +)))
988 +|VBF相互依赖关系识别|(% colspan="2" %)(((
989 +服务或产品所有者
990 +
991 +服务设计者
992 +
993 +技术专家
994 +
995 +架构管理专家
996 +)))|(% colspan="2" %)MT|熟悉产品，包括其架构和配置
997 +|服务连续性要求的确定|(% colspan="2" %)(((
998 +服务或产品所有者
999 +
1000 +连续性管理员
1001 +)))|(% colspan="2" %)MTC|(((
1002 +对恢复流程的深入了解
1003 +
1004 +了解服务的连续性策略
1005 +)))
1006 +|(% colspan="6" %)制定和维护服务连续性计划流程
1007 +|服务连续性策略开发|(% colspan="2" %)(((
1008 +连续性管理员
1009 +
1010 +服务设计者
1011 +
1012 +技术专家
1013 +)))|(% colspan="2" %)TM|(((
1014 +对服务连续性选项有很好的了解
1015 +
1016 +认知现有控件
1017 +
1018 +认知市场上可用的技术
1019 +)))
1020 +|服务连续性计划开发|(% colspan="2" %)(((
1021 +连续性管理员
1022 +
1023 +技术专家
1024 +)))|(% colspan="2" %)MTA|(((
1025 +优秀的文档编制能力
1026 +
1027 +优秀的逻辑能力
1028 +
1029 +很好地了解服务组件的相互依赖关系
1030 +
1031 +对技术有很好的了解
1032 +)))
1033 +|服务连续性计划的初始测试|(% colspan="2" %)(((
1034 +连续性管理员
1035 +
1036 +响应和恢复协调员及团队成员
1037 +)))|(% colspan="2" %)CATL|(((
1038 +协调与沟通
1039 +
1040 +对服务连续性计划有深入的了解
1041 +
1042 +了解作为服务连续性策略组成部分的技术
1043 +)))
1044 +|(% colspan="6" %)测试服务连续性计划流程
1045 +|(% colspan="2" %)进行演练|(((
1046 +连续性管理员
1047 +
1048 +响应和恢复协调员及团队成员
1049 +)))|CATL|(% colspan="2" %)(((
1050 +协调与沟通
1051 +
1052 +对服务连续性计划有深入的了解
1053 +
1054 +了解作为服务连续性策略组成部分的技术
1055 +)))
1056 +|(% colspan="2" %)服务连续性审计|内部或外部审计师（根据授权并代表董事会）|CAMT|(% colspan="2" %)(((
1057 +审计管理技术
1058 +
1059 +常见的审计实践命令
1060 +
1061 +确保审核员公正性，客观性和独立性
1062 +)))
1063 +|(% colspan="6" %)响应和恢复流程
1064 +|(% colspan="2" %)调用|危机管理组|LC|(% colspan="2" %)(((
1065 +对服务提供者和消费者风险有深入的了解
1066 +
1067 +了解对消费者的背景
1068 +
1069 +协调与沟通
1070 +)))
1071 +|(% colspan="2" %)执行服务连续性计划|(((
1072 +危机管理组
1073 +
1074 +连续性管理员
1075 +
1076 +响应和恢复协调员及团队成员
1077 +)))|CATL|(% colspan="2" %)(((
1078 +协调与沟通
1079 +
1080 +对服务连续性计划有深入的了解
1081 +
1082 +了解作为服务连续性策略组成部分的技术
1083 +)))
1084 +
900 900  表4.2 负责服务连续性管理活动的角色示例
901 901  
902 902  
1088 +
903 903  == **4.2  组织结构和团队** ==
904 904  
905 905  灾难是影响重大的事件，因此响应必须非常快。协调响应和恢复活动需要灵活性。因此，常规业务的组织结构与灾难无关。
... ... @@ -906,11 +906,10 @@
906 906  
907 907  在恢复过程中，组织结构通常基于连续性计划的级别。表4.3概述了用于响应和恢复的组织结构级别。
908 908  
909 -(% style="width:467px" %)
910 -|(% style="width:91px" %)连续性计划的层次|(% style="width:81px" %)组织层次|(% style="width:293px" %)描述
911 -|(% style="width:91px" %)战略|(% style="width:81px" %)行政级别|(% style="width:293px" %)这包括高级管理/主管人员，他们具有组织内的总体权限和控制，并负责危机管理，联络其他部门，事业部，组织，媒体，监管机构，紧急服务等。
912 -|(% style="width:91px" %)战术|(% style="width:81px" %)协调级别|(% style="width:293px" %)通常，该级别比主管组低一级，该组负责协调组织内的整体恢复工作。
913 -|(% style="width:91px" %)运行|(% style="width:81px" %)专家级|(% style="width:293px" %)一系列服务恢复团队，负责在各自区域内执行计划并与员工，客户和第三方保持联系。在IT内部，恢复团队应按服务和产品分组。
1095 +|连续性计划的层次|(% style="width:77px" %)组织层次|(% style="width:602px" %)描述
1096 +|战略|(% style="width:77px" %)行政级别|(% style="width:602px" %)这包括高级管理/主管人员，他们具有组织内的总体权限和控制，并负责危机管理，联络其他部门，事业部，组织，媒体，监管机构，紧急服务等。
1097 +|战术|(% style="width:77px" %)协调级别|(% style="width:602px" %)通常，该级别比主管组低一级，该组负责协调组织内的整体恢复工作。
1098 +|运行|(% style="width:77px" %)专家级|(% style="width:602px" %)一系列服务恢复团队，负责在各自区域内执行计划并与员工，客户和第三方保持联系。在IT内部，恢复团队应按服务和产品分组。
914 914  
915 915  表4.3 用于响应和恢复的组织结构
916 916  
... ... @@ -940,16 +940,44 @@
940 940  
941 941  尤其是在大型组织中，服务连续性实践应该是自动化的。在可行且有效的地方，可能涉及表5.1中概述的解决方案。
942 942  
943 -[[image:1642262695902-600.png]]
1128 +|(% style="width:89px" %)流程活动|(% colspan="4" style="width:293px" %)自动化手段|(% colspan="3" style="width:442px" %)关键功能|(% colspan="3" style="width:132px" %)对实践有效性的影响
1129 +|(% colspan="11" %)服务连续性管理流程的治理
1130 +|(% style="width:89px" %)(((
1131 +范围的定义
944 944  
945 -[[image:1642262721398-460.png]]
1133 +策略设置
1134 +)))|(% colspan="4" style="width:293px" %)知识管理工具和文档存储库|(% colspan="3" style="width:442px" %)服务提供者的员工，监管机构和外部利益相关者（例如客户代表）必须容易访问服务的连续性策略，包括方案的范围，指南，角色和职责。|(% colspan="3" style="width:132px" %)低
1135 +|(% style="width:89px" %)认知和演练方案开发|(% colspan="4" style="width:293px" %)业务连续性计划工具|(% colspan="3" style="width:442px" %)服务连续性管理员，服务所有者和恢复团队成员们应有权访问演练时间表，以及他们参与的演练范围的信息。|(% colspan="3" style="width:132px" %)中
1136 +|(% colspan="11" %)业务影响分析流程
1137 +|(% colspan="3" style="width:105px" %)VBF识别|(% colspan="3" style="width:164px" %)服务目录，CMDB，BPM工具|(% colspan="3" style="width:470px" %)为了识别VBF，服务分析人员应有权访问有关服务组件和操作的信息。BPM工具可以提供消费者的流程以及服务支持的操作的有关信息|(% colspan="2" %)高
1138 +|(% colspan="3" style="width:105px" %)中断后果分析|(% colspan="3" style="width:164px" %)(((
1139 +业务连续性计划工具
946 946  
947 -[[image:1642262745322-477.png]]
1141 +分析工具，
948 948  
949 -[[image:1642262768023-787.png]]
1143 +风险评估工具，事件管理工具
1144 +)))|(% colspan="3" style="width:470px" %)各种管理系统数据都可以支持分析，例如事件报告和有关已经意识到的风险的信息。在服务或特定的VBF中断的情况下，分析师还可以使用建模工具预测预期的损失。|(% colspan="2" %)高
1145 +|(% colspan="3" style="width:105px" %)(((
1146 +VBF
950 950  
951 -[[image:1642262782136-227.png]]
1148 +相互依赖关系识别
1149 +)))|(% colspan="3" style="width:164px" %)业务连续性计划工具，CMDB，分析工具|(% colspan="3" style="width:470px" %)分析师可以使用服务和配置模型来识别关键的服务和VBF相互依赖关系。|(% colspan="2" %)高
1150 +|(% colspan="3" style="width:105px" %)服务连续性要求的确定|(% colspan="3" style="width:164px" %)业务连续性计划工具，服务目录|(% colspan="3" style="width:470px" %)连续性管理员，服务所有者和恢复团队成员应有权访问服务的连续性要求。|(% colspan="2" %)低
1151 +|(% colspan="11" %)开发和维护服务连续性计划流程
1152 +|(% colspan="3" style="width:105px" %)服务连续性策略开发|(% colspan="3" style="width:164px" %)业务连续性计划工具，CMDB，变更初始化和控制工具|(% colspan="3" style="width:470px" %)(((
1153 +确定现有控件和弹性措施
952 952  
1155 +发起应作为服务连续性策略实现的一部分实施的变更
1156 +)))|(% colspan="2" %)中
1157 +|(% colspan="3" style="width:105px" %)服务连续性计划开发|(% colspan="3" style="width:164px" %)业务连续性计划工具，文档控制工具|(% colspan="3" style="width:470px" %)失效日期控制，版本控制和文档的归档|(% colspan="2" %)从低到高，取决于要管理的文档量
1158 +|(% colspan="2" style="width:138px" %)服务连续性计划的初始测试|(% colspan="9" style="width:877px" %)参见“进行演练”
1159 +|(% colspan="11" %)测试服务连续性计划流程
1160 +|(% colspan="4" %)进行演练|(% colspan="3" %)会议工具，监控工具，技术管理和系统管理工具|(% colspan="3" %)所有相关方应该能够进行沟通和协作，持续了解当前状况并管理服务组件，以执行服务连续性计划。|高
1161 +|(% colspan="4" %)服务连续性审计|(% colspan="3" %)知识管理工具和文档存储库|(% colspan="3" %)审核员应该可以访问服务连续性文档资料，包括计划，练习程序，练习报告和恢复报告。|中
1162 +|(% colspan="11" %)响应和恢复流程
1163 +|(% colspan="4" %)启用|(% colspan="3" %)监控工具，紧急通知，会议工具，事件管理工具|(% colspan="3" %)危机管理组必须能够获得有关事态的信息，并立即直接响应和恢复流程。|高
1164 +|(% colspan="4" %)执行服务连续性计划|(% colspan="3" %)会议工具，紧急管理工具，监控工具，技术管理和系统管理工具，事件管理工具|(% colspan="3" %)所有相关方应能够进行沟通和协作，对当前情况有持续的了解，并管理服务组件，以执行服务连续性计划|高
1165 +
953 953  表5.1 服务连续性管理活动的自动化解决方案
954 954  
955 955  
Icon 1642262167262-433.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -69.5 KB
Content Icon
Icon 1642262190748-510.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -59.5 KB
Content Icon
Icon 1642262249963-601.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -42.6 KB
Content Icon
Icon 1642262271197-361.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -45.7 KB
Content Icon
Icon 1642262555280-925.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -64.4 KB
Content Icon
Icon 1642262576270-128.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -64.8 KB
Content Icon
Icon 1642262601759-766.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -61.5 KB
Content Icon
Icon 1642262627236-955.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -51.6 KB
Content Icon
Icon 1642262695902-600.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -54.7 KB
Content Icon
Icon 1642262721398-460.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -54.6 KB
Content Icon
Icon 1642262745322-477.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -68.5 KB
Content Icon
Icon 1642262768023-787.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -49.0 KB
Content Icon
Icon 1642262782136-227.png
Author
... ... @@ -1,1 +1,0 @@
1 -XWiki.superadmin
Size
... ... @@ -1,1 +1,0 @@
1 -40.5 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司