From version < 16.1 >
edited by superadmin
on 2021/02/20, 15:00
To version < 34.1 >
edited by superadmin
on 2022/01/16, 00:06
< >
Change comment: There is no comment for this version

Summary

Details

Icon Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -14 服务连续性管理
1 +14 服务连续性管理实践
Content
... ... @@ -3,7 +3,7 @@
3 3  {{/box}}
4 4  
5 5  (((
6 -
6 +
7 7  )))
8 8  
9 9  需要下载 **ITIL 4 服务连续性管理实践【中文】**pdf版全文,请关注微信公众号itilxf ,并回复“服务连续性”即可。
... ... @@ -34,7 +34,6 @@
34 34  * 支持本实践的信息和技术
35 35  * 对本实践的合作伙伴和供应商的考虑
36 36  
37 -
38 38  == **1.1 ITIL 4资格认证计划** ==
39 39  
40 40  本文档中的部分内容可作为以下教学大纲的一部分以供检查:
... ... @@ -175,8 +175,6 @@
175 175  * 中断期间应能够访问服务的有限的用户数量或特定用户组
176 176  * 中断期间用户应能够处理的单位时间段内有限的交易数量。
177 177  
178 -
179 -
180 180  === **2.2.5  业务影响分析** ===
181 181  
182 182  |(((
... ... @@ -194,8 +194,6 @@
194 194  * 设置优先级时间范围以在明确规定的最低可接受水平上恢复这些活动,考虑到在这时间内不恢复它们,带来的影响将变得不可接受
195 195  * 确定这些活动的依赖关系和支持资源,包括供应商,外包合作伙伴,以及其他相关利益方。
196 196  
197 -
198 -
199 199  === **2.2.6  服务连续性/ 灾难恢复计划** ===
200 200  
201 201  |(((
... ... @@ -233,21 +233,21 @@
233 233  * 进行练习,并测试如果发生灾难情况下,服务连续性计划的启用
234 234  * 有一些活动和责任领域尽管仍与服务连续性管理密切相关,但不包含在服务连续性管理实践中。表2.1中列出了这些内容,以及涉及到的包含这些内容的实践。重要的是要记住,ITIL实践只是在价值流的背景中使用的工具的集合;它们应当根据情况在必要时组合在一起。
235 235  
231 +(% style="width:469px" %)
232 +|(% style="width:335px" %)活动|(% style="width:132px" %)实践指南
233 +|(% style="width:335px" %)与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|(% style="width:132px" %)关系管理
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" %)实施风险缓解措施并更改IT基础设施,以确保弹性|(% style="width:132px" %)项目管理, 变更控制
242 +|(% style="width:335px" %)管理并实施持续改进|(% style="width:132px" %)持续改进
236 236  
237 -|活动|实践指南
238 -|与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|关系管理
239 -|协商并与客户服务连续性要求达成一致|服务级别管理
240 -|将服务连续性解决方案设计为服务模型的一部分|服务设计
241 -|使服务连续性解决方案与业务架构保持一致|架构管理
242 -|识别与服务连续性相关的风险|风险管理
243 -|与供应商和合作伙伴建立和管理合同|供应商管理
244 -|监控服务的可用性|监控和事态管理
245 -|证明新的服务连续性解决方案|组合管理
246 -|实施风险缓解措施并更改IT基础设施,以确保弹性|项目管理, 变更控制
247 -|管理并实施持续改进|持续改进
248 248  
249 249  
250 -
251 251  === **2.3.1  可用性与连续性之间的界线** ===
252 252  
253 253  服务的连续性和可用性管理的实践之间的界限是不明显的。两种做法都涉及风险的概念,并致力于识别和准备应对可能威胁并导致服务不能运转的事件。对于这两种实践,都需要了解VBF和风险评估或服务故障的BIA。最终,两种做法都确保了组织的抗故障能力。
... ... @@ -254,15 +254,16 @@
254 254  
255 255  一些组织不希望将可用性的管理和连续性分开。但是,表2.2中概述了这两种做法之间的一些差异,在设计服务管理系统时应考虑这些差异。
256 256  
257 -|可用性管理|服务连续性管理
258 -|专注于高概率的风险|专注于高影响风险(紧急情况,灾难)
259 -|更主动|更被动
260 -|减少意外的可能性|减少意外的影响
261 -|关注技术解决方案|关注组织措施
262 -|优化|创建冗余
263 -|不属于公司职能|通常是公司职能的一部分
264 -|日常业务|特殊情况下
265 -|MTRS, MTBF, MTBSI|RTO, RPO
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
266 266  
267 267  表2.2 可用性管理和服务连续性管理之间的区别
268 268  
... ... @@ -340,66 +340,25 @@
340 340  
341 341  表2.3响应和恢复规划结构中的层次
342 342  
343 -|层次|描述
344 -|战略层|高管如何做出有关恢复流程的决策,如何与外部各方(包括相关媒体)进行沟通以及处理服务连续性计划中未涉及的任何情况
345 -|战术层|管理层如何协调恢复流程,以确保根据优先级(当前业务优先级,季节性变化等)适当分配资源并管理规划团队和恢复团队之间的冲突
346 -|操作层|团队如何执行恢复活动,包括响应破坏性事件,恢复到服务的预定义级别,和/或提供替代设施以继续运行
339 +(% style="width:683px" %)
340 +|(% style="width:66px" %)层次|(% style="width:614px" %)描述
341 +|(% style="width:66px" %)战略层|(% style="width:614px" %)高管如何做出有关恢复流程的决策,如何与外部各方(包括相关媒体)进行沟通以及处理服务连续性计划中未涉及的任何情况
342 +|(% style="width:66px" %)战术层|(% style="width:614px" %)管理层如何协调恢复流程,以确保根据优先级(当前业务优先级,季节性变化等)适当分配资源并管理规划团队和恢复团队之间的冲突
343 +|(% style="width:66px" %)操作层|(% style="width:614px" %)团队如何执行恢复活动,包括响应破坏性事件,恢复到服务的预定义级别,和/或提供替代设施以继续运行
347 347  
348 348  根据组织的规模以及服务提供者是内部的还是外部的,可能会有不同的解决方案来构建计划。责任主体也可能有所不同。
349 349  
350 350  服务连续性计划根据服务提供者的类型和组织的规模,其结构的复杂度可能会或多或少。表2.4 概述了一些常见的结构。
351 351  
352 -| |小型组织|大型组织
353 -|内部服务提供商|(((
354 -在小型组织的IT部门中,可能没有任何服务连续性计划。所有连续性安排都可以作为业务连续性管理的一部分进行管理。
349 +[[image:1642262167262-433.png]]
355 355  
356 -特定的IT服务连续性活动可以作为事件管理实践的一部分执行。
357 -)))|(((
358 -战略层:由高管执行的危机管理计划。它通常是业务连续性计划的一部分。
359 -
360 -战术层:大量计划,每个计划都涵盖一个产品,服务,业务单元,站点或位置,每个计划都拥有自己的恢复团队。战术的IT部门活动可以包含在业务连续性计划中,但通常将它们设计为单独的相关计划。
361 -
362 -操作层:大量的用于特定恢复活动的详细步骤(例如,从备份中恢复应用程序数据)。其他部门可能会有自己的特定操作说明,作为连续性计划的一部分。
363 -)))
364 -|外部服务提供商|所有层次(战略,战术,运行的)都可以作为一个计划实施,而一个团队则负责响应和恢复的各个方面。|连续性计划级别的描述与上面类似,但是服务提供者对所有级别负责。
365 -
366 366  表2.4 连续性计划的结构选项
367 367  
368 368  
369 369  服务连续性计划应涵盖表2.5中概述的灾难发生之后的各个阶段。
370 370  
371 -|阶段|响应|恢复|复原
372 -|计划|响应计划|恢复计划|恢复正常运行计划
373 -|内容|(((
374 -应触发服务连续性计划的事件和场景
356 +[[image:1642262190748-510.png]]
375 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 -
400 -复原恢复站点的说明(如果有)
401 -)))
402 -
403 403  表2.5 响应阶段和恢复阶段
404 404  
405 405  
... ... @@ -414,27 +414,28 @@
414 414  
415 415  表2.6 中概述的服务连续性选项可以作为总体风险缓解计划的一部分来设计和实现。
416 416  
417 -|服务管理维度|服务连续性措施
418 -|组织和人员|(((
419 -1. 在灾难期间的人员管理
420 -1. 使用替代站点和设施
372 +(% style="width:475px" %)
373 +|(% style="width:129px" %)服务管理维度|(% style="width:343px" %)服务连续性措施
374 +|(% style="width:129px" %)组织和人员|(% style="width:343px" %)(((
375 +* 在灾难期间的人员管理
376 +* 使用替代站点和设施
421 421  )))
422 -|信息和技术|(((
423 -1. 物理安全
424 -1. 弹性电信网络
425 -1. 运维中的数据保护:使用RAID阵列,SAN等来确保数据的可用性
426 -1. 数据备份
427 -1. 容错应用程序
428 -1. 监控以提供及时告警
378 +|(% style="width:129px" %)信息和技术|(% style="width:343px" %)(((
379 +* 物理安全
380 +* 弹性电信网络
381 +* 运维中的数据保护:使用RAID阵列,SAN等来确保数据的可用性
382 +* 数据备份
383 +* 容错应用程序
384 +* 监控以提供及时告警
429 429  )))
430 -|合作伙伴和供应商|(((
431 -1. 互惠协议
432 -1. 将服务外包给多个提供商
433 -1. 作为服务的火灾探测系统或灭火系统
386 +|(% style="width:129px" %)合作伙伴和供应商|(% style="width:343px" %)(((
387 +* 互惠协议
388 +* 将服务外包给多个提供商
389 +* 作为服务的火灾探测系统或灭火系统
434 434  )))
435 -|流程和价值流|(((
436 -1. 服务交付的手动操作和替代方法
437 -1. 响应和恢复的计划与程序(服务连续性计划)
391 +|(% style="width:129px" %)流程和价值流|(% style="width:343px" %)(((
392 +* 服务交付的手动操作和替代方法
393 +* 响应和恢复的计划与程序(服务连续性计划)
438 438  )))
439 439  
440 440  表2.6 服务连续性管理实践的四个维度
... ... @@ -448,7 +448,6 @@
448 448  * 效率服务连续性度量的成本应该进行评估,并与收益进行比较。通过估算实施该措施后破坏性事态发生概率的降低,并乘以发生事态会对服务提供者和客户造成的预期的影响,可以计算出收益。就成本而言,应将此价值与该措施实施的成本进行比较。这里可以使用成本效益分析。
449 449  
450 450  
451 -
452 452  === **2.4.3 确保认知和就绪状态** ===
453 453  
454 454  未经测试的恢复计划通常根本无法按预期工作。因此,测试是服务连续性管理的关键组成部分,并且是确保所选策略,已实施措施和计划切实可行的唯一方法。
... ... @@ -467,32 +467,9 @@
467 467  
468 468  表2.7 概述了2013年。
469 469  
470 -|(% style="width:92px" %)演练类型|(% style="width:426px" %)关键特征|目的
471 -|(% style="width:92px" %)走查|(% style="width:426px" %)(((
472 -* 基于讨论的演练
473 -* 未加压的环境
474 -* 通常专注于某一特定区域进行改进
475 -)))|(((
476 -用于恢复团队成员首次见面
425 +[[image:1642262249963-601.png]]
477 477  
478 -利用改进机会
479 -)))
480 -|(% style="width:92px" %)桌上演练|(% style="width:426px" %)(((
481 -* 基于一个给定场景的讨论
482 -* 通常实时运行,但可以包含“时间跳跃”以使得场景的不同阶段都受到演练
483 -)))|提高对计划的了解
484 -|(% style="width:92px" %)指挥所演练|(% style="width:426px" %)(((
485 -* 以模拟真实事件的方式为恢复团队成员提供信息,并邀请他们做出回应
486 -)))|测试沟通,决策和协调
487 -|(% style="width:92px" %)现场|(% style="width:426px" %)(((
488 -* 测试计划的最逼真的方法
489 -* 范围可以从一个组件的恢复的小型排练,到整个服务或组织的恢复的全面排练
490 -* 通常包括参与的利益相关方
491 -)))|测试在发生破坏性事态时,达到RTO,RPO和最低目标服务水平的能力
492 -|(% style="width:92px" %)测试|(% style="width:426px" %)(((
493 -* 它通常应用于特定的硬件或软件,例如从备份恢复应用程序数据。
494 -* 依照ISO 22301,测试是一种独特类型的演练,它包含了一个期望,就是:演练的(一个或多个)目标的成功或失败要素正在计划中
495 -)))|当故障的风险较高时,测试服务组件的恢复
427 +[[image:1642262271197-361.png]]
496 496  
497 497  表2.7 锻炼类型
498 498  
... ... @@ -508,19 +508,20 @@
508 508  
509 509  服务连续性管理实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI,以评估实践对这些价值流的效果和效率的贡献。表2.8给出了一些关键指标的示例。
510 510  
511 -|实践成功因素|指标示例
512 -|制定和管理服务连续性计划|(((
443 +(% style="width:565px" %)
444 +|(% style="width:172px" %)实践成功因素|(% style="width:391px" %)指标示例
445 +|(% style="width:172px" %)制定和管理服务连续性计划|(% style="width:391px" %)(((
513 513  * 具有清晰地文件化连续性要求的产品和服务的百分比
514 514  * 文件化的服务连续性计划中(关键)产品和服务的百分比
515 515  * 及时更新服务连续性计划
516 516  )))
517 -|降低服务的连续性风险|(((
450 +|(% style="width:172px" %)降低服务的连续性风险|(% style="width:391px" %)(((
518 518  * RTO达成情况(实际灾难和演练)
519 519  * RPO达成情况(实际灾难和演练)
520 520  * 有效连续性措施的百分比
521 521  * 实际损失与预期损失之比
522 522  )))
523 -|确保认知和就绪状态|(((
456 +|(% style="width:172px" %)确保认知和就绪状态|(% style="width:391px" %)(((
524 524  * 按计划进行的演练和认知活动的百分比
525 525  * 在给定时间段内(通常为过去6个月)对其连续性计划进行测试的服务所占的百分比
526 526  )))
... ... @@ -573,28 +573,27 @@
573 573  * 测试服务连续性计划
574 574  * 响应和恢复
575 575  
576 -
577 -
578 578  === **3.2.1  服务连续性管理的治理** ===
579 579  
580 580  该流程包括表3.1中列出的活动,并将输入转换为输出。
581 581  
582 -|关键输入|活动|关键输出
583 -|(((
584 -1. 业务影响分析报告
585 -1. 风险登记册
586 -1. 客户要求
587 -1. 法规要求
588 -1. 风险偏好
589 -1. 标准
590 -)))|(((
591 -1. 范围的定义
592 -1. 策略设置
593 -1. 认知和演练方案制定
594 -)))|(((
595 -1. 服务连续性策略
596 -1. 文件化的角色和职责
597 -1. 认知和演练方案
513 +(% style="width:515px" %)
514 +|(% style="width:176px" %)关键输入|(% style="width:145px" %)活动|(% style="width:191px" %)关键输出
515 +|(% style="width:176px" %)(((
516 +* 业务影响分析报告
517 +* 风险登记册
518 +* 客户要求
519 +* 法规要求
520 +* 风险偏好
521 +* 标准
522 +)))|(% style="width:145px" %)(((
523 +* 范围的定义
524 +* 策略设置
525 +* 认知和演练方案制定
526 +)))|(% style="width:191px" %)(((
527 +* 服务连续性策略
528 +* 文件化的角色和职责
529 +* 认知和演练方案
598 598  )))
599 599  
600 600  表3.1 服务连续性管理的治理的输入,活动和输出
... ... @@ -610,8 +610,9 @@
610 610  
611 611  这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.2进一步描述了这些活动。
612 612  
613 -|(% style="width:106px" %)活动|(% style="width:662px" %)描述
614 -|(% style="width:106px" %)范围的定义|(% style="width:662px" %)(((
545 +(% style="width:687px" %)
546 +|(% style="width:98px" %)活动|(% style="width:587px" %)描述
547 +|(% style="width:98px" %)范围的定义|(% style="width:587px" %)(((
615 615  定义服务连续性管理实践的范围,确保它所涵盖的组织的环境和地域清晰。
616 616  
617 617  组织范围可能受到产品和服务,站点和位置,客户等的限制。那些已停产的或即将终止的产品和服务通常被排除在范围之外,非关键和低利润的产品和服务也一样。
... ... @@ -629,7 +629,7 @@
629 629  
630 630  根据灾难定义实践的范围也很重要。
631 631  )))
632 -|(% style="width:106px" %)策略设置|(% style="width:662px" %)(((
565 +|(% style="width:98px" %)策略设置|(% style="width:587px" %)(((
633 633  策略的设置包括:
634 634  
635 635  * 记录范围。
... ... @@ -638,7 +638,7 @@
638 638  * 应尽快建立并传达政策,以便所有参与服务连续性管理实践或受其影响的利益相关者都知道范围,限制及其职责。
639 639  * 范围和政策应定期修订(通常每年一次)。修订被触发,可能是由于破坏性事态(尤其是计划未涵盖的),一个新的服务,一个新的客户或者是与合作伙伴的一个新关系。
640 640  )))
641 -|(% style="width:106px" %)认知和演练方案制定|(% style="width:662px" %)(((
574 +|(% style="width:98px" %)认知和演练方案制定|(% style="width:587px" %)(((
642 642  测试是整个服务连续性管理实践的关键部分:这是确保所选策略,措施和计划有效的唯一方法。
643 643  
644 644  应该制定教育,认知培训和演练计划,以确保实践的所有部分(站点,团队成员,服务或CI)每年至少进行一次测试。
... ... @@ -671,8 +671,9 @@
671 671  
672 672  该流程包括表3.3中列出的活动,并将输入转换为输出。
673 673  
674 -|关键输入|活动|关键输出
675 -|(((
607 +(% style="width:475px" %)
608 +|(% style="width:153px" %)关键输入|(% style="width:150px" %)活动|(% style="width:170px" %)关键输出
609 +|(% style="width:153px" %)(((
676 676  * 服务文档
677 677  * 风险评估报告
678 678  * VBF损失的财务数据
... ... @@ -681,12 +681,12 @@
681 681  * 风险管理策略
682 682  * 风险偏好
683 683  * 监管要求
684 -)))|(((
618 +)))|(% style="width:150px" %)(((
685 685  * VBF识别
686 686  * 中断后果分析
687 687  * VBF相互依赖关系识别
688 688  * 服务连续性要求的确定
689 -)))|(((
623 +)))|(% style="width:170px" %)(((
690 690  * VBF的优先级列表
691 691  * 文件化的VBF损失产生的影响
692 692  * 文件化的VBF相互依赖关系
... ... @@ -706,8 +706,9 @@
706 706  
707 707  这些活动可以由组织中的许多人以不同程度的正式方式来执行。表3.4进一步概述了这些活动。
708 708  
709 -|(% style="width:110px" %)活动|(% style="width:657px" %)描述
710 -|(% style="width:110px" %)VBF识别|(% style="width:657px" %)(((
643 +(% style="width:704px" %)
644 +|(% style="width:78px" %)活动|(% style="width:624px" %)描述
645 +|(% style="width:78px" %)VBF识别|(% style="width:624px" %)(((
711 711  VBF涉及到服务中对于服务提供者和/或客户的成功至关重要的一部分。识别和文件化这些VBF,以提供适当的焦点和资源分配非常重要。
712 712  
713 713  可以使用许多不同的技术来识别风险,包括头脑风暴,与利益相关者(包括客户和用户)的访谈,对服务文档的分析等等。
... ... @@ -714,7 +714,7 @@
714 714  
715 715  如果服务提供者具有已建立的风险管理实践,则有关风险评估的信息可能有助于理解最关键的区域。
716 716  )))
717 -|(% style="width:110px" %)中断后果分析|(% style="width:657px" %)(((
652 +|(% style="width:78px" %)中断后果分析|(% style="width:624px" %)(((
718 718  当确定了VBF时,应确定中断的影响。该影响可能是可以准确识别的“硬” 影响,例如财务损失,也可以是“软” 影响,例如声誉受损或失去竞争优势。
719 719  
720 720  可以考虑FAIR提出的以下形式的损失:
... ... @@ -732,16 +732,16 @@
732 732  
733 733  服务中断造成的损失通常会随着时间呈指数增长。除了与组织产生其主要价值主张的能力下降的有关损失之外,还存在罚款,判决和声誉受损的威胁。
734 734  )))
735 -|(% style="width:110px" %)(((
670 +|(% style="width:78px" %)(((
736 736  VBF
737 737  
738 738  相互依赖关系识别
739 -)))|(% style="width:657px" %)(((
674 +)))|(% style="width:624px" %)(((
740 740  VBF和服务组件以及关键的内部和外部资源之间的相互依赖关系应予以识别和文件化。
741 741  
742 742  为此,如果已安装配置管理数据库,则服务提供者可以使用服务和配置模型。组件故障影响分析(CFIA)也可能是有用的技术。CFIA可用于识别失效的单个点,现有的冗余等。
743 743  )))
744 -|(% style="width:110px" %)服务连续性要求的确定|(% style="width:657px" %)(((
679 +|(% style="width:78px" %)服务连续性要求的确定|(% style="width:624px" %)(((
745 745  基于对中断后果和识别的相互依赖关系的分析,服务提供者应为服务连续性管理范围中的每个服务或VBF确定服务连续性要求,包括:
746 746  
747 747  * 恢复时间目标
... ... @@ -752,22 +752,23 @@
752 752  表3.4 业务影响分析流程的活动
753 753  
754 754  
755 -=== **3.3.2  制定和维护服务连续性计划** ===
690 +=== **3.2.3  制定和维护服务连续性计划** ===
756 756  
757 757  该流程包括表3.5 中列出的活动,并将输入转换为输出。
758 758  
759 -|关键输入|活动|关键输出
760 -|(((
694 +(% style="width:554px" %)
695 +|(% style="width:186px" %)关键输入|(% style="width:188px" %)活动|(% style="width:178px" %)关键输出
696 +|(% style="width:186px" %)(((
761 761  * 业务影响分析报告
762 762  * 现有控件
763 763  * 有关可用资源的信息
764 764  * 消费者的连续性计划
765 765  * 服务连续性策略
766 -)))|(((
702 +)))|(% style="width:188px" %)(((
767 767  * 服务连续性策略制定
768 768  * 服务连续性计划制定
769 769  * 服务连续性计划的初始测试
770 -)))|(((
706 +)))|(% style="width:178px" %)(((
771 771  * 新的和更新的控件
772 772  * 服务连续性策略
773 773  * 服务连续性计划
... ... @@ -788,34 +788,36 @@
788 788  
789 789  表3.6 进一步概述了这些活动。
790 790  
791 -|(% style="width:147px" %)活动|(% style="width:621px" %)描述
792 -|(% style="width:147px" %)服务连续性策略制定|(% style="width:621px" %)(((
727 +(% style="width:657px" %)
728 +|(% style="width:147px" %)活动|(% style="width:508px" %)描述
729 +|(% style="width:147px" %)服务连续性策略制定|(% style="width:508px" %)(((
793 793  基于BIA 报告,服务提供者应该确定一套适当的且具有成本效益的服务连续性策略集。
794 794  
795 795  对于影响更早,影响更大的流程和服务,应采取更多的预防措施。对于影响较低且需要较长时间开发的流程和服务,应更加重视恢复措施。
796 796  )))
797 -|(% style="width:147px" %)服务连续性计划制定|(% style="width:621px" %)(((
734 +|(% style="width:147px" %)服务连续性计划制定|(% style="width:508px" %)(((
798 798  基于服务连续性政策和策略,服务提供者应该制定和维护服务连续性计划。
799 799  
800 800  如果服务或恢复团队成员发生变化,则必须更新计划。计划也可以在演练或实际恢复之后更新。
801 801  )))
802 -|(% style="width:147px" %)服务连续性计划的初始测试|(% style="width:621px" %)发布之前,应测试服务连续性计划。初始测试的方法类似于正在进行的演练。
739 +|(% style="width:147px" %)服务连续性计划的初始测试|(% style="width:508px" %)发布之前,应测试服务连续性计划。初始测试的方法类似于正在进行的演练。
803 803  
804 804  表3.6 制定和维护服务连续性计划流程的活动
805 805  
806 806  
807 -=== **3.3.3  测试服务连续性计划** ===
744 +=== **3.2.4  测试服务连续性计划** ===
808 808  
809 809  该流程包括表3.7 中列出的活动,并将输入转换为输出。
810 810  
811 -|关键输入|活动|关键输出
812 -|(((
748 +(% style="width:536px" %)
749 +|(% style="width:156px" %)关键输入|(% style="width:164px" %)活动|(% style="width:214px" %)关键输出
750 +|(% style="width:156px" %)(((
813 813  * 认知和演练方案
814 814  * 服务连续性计划
815 -)))|(((
753 +)))|(% style="width:164px" %)(((
816 816  * 进行演练
817 817  * 服务连续性审计
818 -)))|(((
756 +)))|(% style="width:214px" %)(((
819 819  * 演练报告
820 820  * 新的和更新的控件的要求
821 821  * 策略或计划的变更请求
... ... @@ -835,8 +835,9 @@
835 835  
836 836  这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.8进一步概述了这些活动。
837 837  
838 -|(% style="width:131px" %)活动|(% style="width:636px" %)描述
839 -|(% style="width:131px" %)进行演练|(% style="width:636px" %)(((
776 +(% style="width:613px" %)
777 +|(% style="width:121px" %)活动|(% style="width:490px" %)描述
778 +|(% style="width:121px" %)进行演练|(% style="width:490px" %)(((
840 840  演练应按计划的时间间隔,和当出现可能影响恢复的显著变化时进行。服务中断的可能影响越高,演练的频率就应该越高。
841 841  
842 842  演练和测试不仅是确保准备就绪的方法;它们也是改进机会。这通常是一个好主意,用来分析测试结果以及整个恢复团队绩效,然后生成包括结果和建议的演练报告。
... ... @@ -845,7 +845,7 @@
845 845  
846 846  如果演练失败,则会更新后续演练时间表以便尽快重新执行失败的演练。
847 847  )))
848 -|(% style="width:131px" %)服务连续性审计|(% style="width:636px" %)(((
787 +|(% style="width:121px" %)服务连续性审计|(% style="width:490px" %)(((
849 849  服务连续性审计可确保在环境更改时,BIA,服务连续性策略和计划保持适当和相关。审计通常是按计划进行的,但是可能由于演练失败或恢复失败而触发。
850 850  
851 851  审核可以在内部进行,也可以由第三方进行。审计的输出可能会确定一个实施新的或更新的控件的需求,也可以是调整服务连续性策略或计划的需求。
... ... @@ -854,18 +854,19 @@
854 854  表3.8测试服务连续性计划流程的活动
855 855  
856 856  
857 -=== **3.3.4  响应和恢复** ===
796 +=== **3.2.5  响应和恢复** ===
858 858  
859 859  该流程包括表3.9 中所述的活动,并将输入转换为输出。
860 860  
861 -|关键输入|活动|关键输出
862 -|(((
800 +(% style="width:496px" %)
801 +|(% style="width:170px" %)关键输入|(% style="width:155px" %)活动|(% style="width:169px" %)关键输出
802 +|(% style="width:170px" %)(((
863 863  * 服务连续性计划
864 864  * 事件记录
865 -)))|(((
805 +)))|(% style="width:155px" %)(((
866 866  * 调用
867 867  * 执行服务连续性计划
868 -)))|(((
808 +)))|(% style="width:169px" %)(((
869 869  * 恢复报告
870 870  * 新的和更新的控件的要求
871 871  * 变更计划的请求
... ... @@ -886,8 +886,9 @@
886 886  
887 887  表3.10 进一步概述了这些活动。
888 888  
889 -|(% style="width:152px" %)实现价值|(% style="width:615px" %)描述
890 -|(% style="width:152px" %)启动|(% style="width:615px" %)(((
829 +(% style="width:715px" %)
830 +|(% style="width:92px" %)实现价值|(% style="width:621px" %)描述
831 +|(% style="width:92px" %)启动|(% style="width:621px" %)(((
891 891  启动是一项声明行为,组织的连续性安排需要实施,以便继续提供关键产品和服务[[12>>path:#_bookmark12]].
892 892  
893 893  启动的决定通常是由“ 危机管理”团队(在组织结构的战略层面上)做出的。[[13>>path:#_bookmark13]]),用于核算:
... ... @@ -896,8 +896,8 @@
896 896  * 服务中断的可能持续时间
897 897  * 每天/每月/每年的时间
898 898  )))
899 -|(% colspan="2" %)(((
900 -|(% style="width:143px" %)启动|(% style="width:607px" %)(((
840 +|(% colspan="2" style="width:712px" %)(((
841 +|(% style="width:81px" %)启动|(% style="width:614px" %)(((
901 901  如果风险较低,则危机管理团队可以决定不调用服务连续性计划。
902 902  
903 903  如果启动,危机管理团队还应该:
... ... @@ -907,7 +907,7 @@
907 907  
908 908  启动是服务连续性计划的最终测试。如果准备工作已经完成并且计划已经制定和经过测试,那么启动应该很简单。如果计划未经测试,则可能会失败。
909 909  )))
910 -|(% style="width:143px" %)执行服务连续性计划|(% style="width:607px" %)(((
851 +|(% style="width:81px" %)执行服务连续性计划|(% style="width:614px" %)(((
911 911  一旦发生启动,所有参与的恢复团队都应执行服务连续性程序。恢复可能是一段时间的高级活动,需要许多人花费长时间。在战术层面上,恢复团队调度员必须对此进行识别和管理。
912 912  
913 913  任何时候都可能发生中断,因此对于办公室内外的关键人员而言,容易获得启动流程的指南是非常必要的。
... ... @@ -940,158 +940,30 @@
940 940  
941 941  表4.1 能力代码和简介
942 942  
943 -|能力代码|能力类型(活动和技能)
944 -|L|**领导者 **决策,委派,监督其他活动,提供激励和动机以及评估结果
945 -|A|**管理员 **分配任务并确定优先级,保留记录,进行中的报告并启动基本改进
946 -|C|**协调员/沟通者 **协调多方,维护利益相关者之间的沟通,并开展宣传活动
947 -|M|**方法和技术专家 **设计和实施工作技术,记录程序,咨询流程,工作分析和持续改进
948 -|T|**技术专家 **提供技术(IT)专业知识并实施基于专业知识的任务
884 +(% style="width:477px" %)
885 +|(% style="width:75px" %)能力代码|(% style="width:400px" %)能力类型(活动和技能)
886 +|(% style="width:75px" %)L|(% style="width:400px" %)**领导者 **决策,委派,监督其他活动,提供激励和动机以及评估结果
887 +|(% style="width:75px" %)A|(% style="width:400px" %)**管理员 **分配任务并确定优先级,保留记录,进行中的报告并启动基本改进
888 +|(% style="width:75px" %)C|(% style="width:400px" %)**协调员/沟通者 **协调多方,维护利益相关者之间的沟通,并开展宣传活动
889 +|(% style="width:75px" %)M|(% style="width:400px" %)**方法和技术专家 **设计和实施工作技术,记录程序,咨询流程,工作分析和持续改进
890 +|(% style="width:75px" %)T|(% style="width:400px" %)**技术专家 **提供技术(IT)专业知识并实施基于专业知识的任务
949 949  
950 950  
951 951  
952 952  表4.2 中列出了服务连续性管理实践涉及的角色示例,以及相关的能力简介和特定技能。
953 953  
954 -|流程活动|(% colspan="2" %)负责角色|(% colspan="2" %)能力类型|具体技能
955 -|(% colspan="6" %)服务连续性管理流程的治理
956 -|范围的定义|(% colspan="2" %)指导委员会|(% colspan="2" %)MC|对各种影响组织的PESTLE因素的能见度
957 -|策略设置|(% colspan="2" %)指导委员会|(% colspan="2" %)MCL|(((
958 -意识到组织特定的文档要求
896 +[[image:1642262555280-925.png]]
959 959  
960 -确保管理人员的持续参与,以确保服务连续性策略的清晰性和持续实现
961 -)))
962 -|认知和演练方案开发|(% colspan="2" %)连续性管理员|(% colspan="2" %)ACM|(((
963 -演练类型和恢复团队结构的知识
898 +[[image:1642262576270-128.png]]
964 964  
965 -启用沟通渠道
966 -)))
967 -|(% colspan="6" %)业务影响分析流程
968 -|VBF识别|(% colspan="2" %)(((
969 -服务或产品所有者
900 +[[image:1642262601759-766.png]]
970 970  
971 -关系经理
902 +[[image:1642262627236-955.png]]
972 972  
973 -服务设计者
974 974  
975 -客户
976 -)))|(% colspan="2" %)CM|(((
977 -业务分析
978 -
979 -很好的了解服务消费者的业务
980 -
981 -熟悉产品,包括其架构和配置
982 -)))
983 -|中断后果分析|(% colspan="2" %)(((
984 -服务或产品所有者
985 -
986 -关系经理
987 -
988 -客户
989 -)))|(% colspan="2" %)MC|(((
990 -能够系统地应用定性和定量风险分析工具
991 -
992 -专业能力和对影响服务的PESTLE因素的能见度
993 -)))
994 -|VBF相互依赖关系识别|(% colspan="2" %)(((
995 -服务或产品所有者
996 -
997 -服务设计者
998 -
999 -技术专家
1000 -
1001 -架构管理专家
1002 -)))|(% colspan="2" %)MT|熟悉产品,包括其架构和配置
1003 -|服务连续性要求的确定|(% colspan="2" %)(((
1004 -服务或产品所有者
1005 -
1006 -连续性管理员
1007 -)))|(% colspan="2" %)MTC|(((
1008 -对恢复流程的深入了解
1009 -
1010 -了解服务的连续性策略
1011 -)))
1012 -|(% colspan="6" %)制定和维护服务连续性计划流程
1013 -|服务连续性策略开发|(% colspan="2" %)(((
1014 -连续性管理员
1015 -
1016 -服务设计者
1017 -
1018 -技术专家
1019 -)))|(% colspan="2" %)TM|(((
1020 -对服务连续性选项有很好的了解
1021 -
1022 -认知现有控件
1023 -
1024 -认知市场上可用的技术
1025 -)))
1026 -|服务连续性计划开发|(% colspan="2" %)(((
1027 -连续性管理员
1028 -
1029 -技术专家
1030 -)))|(% colspan="2" %)MTA|(((
1031 -优秀的文档编制能力
1032 -
1033 -优秀的逻辑能力
1034 -
1035 -很好地了解服务组件的相互依赖关系
1036 -
1037 -对技术有很好的了解
1038 -)))
1039 -|服务连续性计划的初始测试|(% colspan="2" %)(((
1040 -连续性管理员
1041 -
1042 -响应和恢复协调员及团队成员
1043 -)))|(% colspan="2" %)CATL|(((
1044 -协调与沟通
1045 -
1046 -对服务连续性计划有深入的了解
1047 -
1048 -了解作为服务连续性策略组成部分的技术
1049 -)))
1050 -|(% colspan="6" %)测试服务连续性计划流程
1051 -|(% colspan="2" %)进行演练|(((
1052 -连续性管理员
1053 -
1054 -响应和恢复协调员及团队成员
1055 -)))|CATL|(% colspan="2" %)(((
1056 -协调与沟通
1057 -
1058 -对服务连续性计划有深入的了解
1059 -
1060 -了解作为服务连续性策略组成部分的技术
1061 -)))
1062 -|(% colspan="2" %)服务连续性审计|内部或外部审计师(根据授权并代表董事会)|CAMT|(% colspan="2" %)(((
1063 -审计管理技术
1064 -
1065 -常见的审计实践命令
1066 -
1067 -确保审核员公正性,客观性和独立性
1068 -)))
1069 -|(% colspan="6" %)响应和恢复流程
1070 -|(% colspan="2" %)调用|危机管理组|LC|(% colspan="2" %)(((
1071 -对服务提供者和消费者风险有深入的了解
1072 -
1073 -了解对消费者的背景
1074 -
1075 -协调与沟通
1076 -)))
1077 -|(% colspan="2" %)执行服务连续性计划|(((
1078 -危机管理组
1079 -
1080 -连续性管理员
1081 -
1082 -响应和恢复协调员及团队成员
1083 -)))|CATL|(% colspan="2" %)(((
1084 -协调与沟通
1085 -
1086 -对服务连续性计划有深入的了解
1087 -
1088 -了解作为服务连续性策略组成部分的技术
1089 -)))
1090 -
1091 1091  表4.2 负责服务连续性管理活动的角色示例
1092 1092  
1093 1093  
1094 -
1095 1095  == **4.2  组织结构和团队** ==
1096 1096  
1097 1097  灾难是影响重大的事件,因此响应必须非常快。协调响应和恢复活动需要灵活性。因此,常规业务的组织结构与灾难无关。
... ... @@ -1098,10 +1098,11 @@
1098 1098  
1099 1099  在恢复过程中,组织结构通常基于连续性计划的级别。表4.3概述了用于响应和恢复的组织结构级别。
1100 1100  
1101 -|连续性计划的层次|(% style="width:77px" %)组织层次|(% style="width:602px" %)描述
1102 -|战略|(% style="width:77px" %)行政级别|(% style="width:602px" %)这包括高级管理/主管人员,他们具有组织内的总体权限和控制,并负责危机管理,联络其他部门,事业部,组织,媒体,监管机构,紧急服务等。
1103 -|战术|(% style="width:77px" %)协调级别|(% style="width:602px" %)通常,该级别比主管组低一级,该组负责协调组织内的整体恢复工作。
1104 -|运行|(% style="width:77px" %)专家级|(% style="width:602px" %)一系列服务恢复团队,负责在各自区域内执行计划并与员工,客户和第三方保持联系。在IT内部,恢复团队应按服务和产品分组。
914 +(% style="width:467px" %)
915 +|(% style="width:91px" %)连续性计划的层次|(% style="width:81px" %)组织层次|(% style="width:293px" %)描述
916 +|(% style="width:91px" %)战略|(% style="width:81px" %)行政级别|(% style="width:293px" %)这包括高级管理/主管人员,他们具有组织内的总体权限和控制,并负责危机管理,联络其他部门,事业部,组织,媒体,监管机构,紧急服务等。
917 +|(% style="width:91px" %)战术|(% style="width:81px" %)协调级别|(% style="width:293px" %)通常,该级别比主管组低一级,该组负责协调组织内的整体恢复工作。
918 +|(% style="width:91px" %)运行|(% style="width:81px" %)专家级|(% style="width:293px" %)一系列服务恢复团队,负责在各自区域内执行计划并与员工,客户和第三方保持联系。在IT内部,恢复团队应按服务和产品分组。
1105 1105  
1106 1106  表4.3 用于响应和恢复的组织结构
1107 1107  
... ... @@ -1131,44 +1131,16 @@
1131 1131  
1132 1132  尤其是在大型组织中,服务连续性实践应该是自动化的。在可行且有效的地方,可能涉及表5.1中概述的解决方案。
1133 1133  
1134 -|(% style="width:89px" %)流程活动|(% colspan="4" style="width:293px" %)自动化手段|(% colspan="3" style="width:442px" %)关键功能|(% colspan="3" style="width:132px" %)对实践有效性的影响
1135 -|(% colspan="11" %)服务连续性管理流程的治理
1136 -|(% style="width:89px" %)(((
1137 -范围的定义
948 +[[image:1642262695902-600.png]]
1138 1138  
1139 -策略设置
1140 -)))|(% colspan="4" style="width:293px" %)知识管理工具和文档存储库|(% colspan="3" style="width:442px" %)服务提供者的员工,监管机构和外部利益相关者(例如客户代表)必须容易访问服务的连续性策略,包括方案的范围,指南,角色和职责。|(% colspan="3" style="width:132px" %)低
1141 -|(% style="width:89px" %)认知和演练方案开发|(% colspan="4" style="width:293px" %)业务连续性计划工具|(% colspan="3" style="width:442px" %)服务连续性管理员,服务所有者和恢复团队成员们应有权访问演练时间表,以及他们参与的演练范围的信息。|(% colspan="3" style="width:132px" %)中
1142 -|(% colspan="11" %)业务影响分析流程
1143 -|(% colspan="3" style="width:105px" %)VBF识别|(% colspan="3" style="width:164px" %)服务目录,CMDB,BPM工具|(% colspan="3" style="width:470px" %)为了识别VBF,服务分析人员应有权访问有关服务组件和操作的信息。BPM工具可以提供消费者的流程以及服务支持的操作的有关信息|(% colspan="2" %)高
1144 -|(% colspan="3" style="width:105px" %)中断后果分析|(% colspan="3" style="width:164px" %)(((
1145 -业务连续性计划工具
950 +[[image:1642262721398-460.png]]
1146 1146  
1147 -分析工具,
952 +[[image:1642262745322-477.png]]
1148 1148  
1149 -风险评估工具,事件管理工具
1150 -)))|(% colspan="3" style="width:470px" %)各种管理系统数据都可以支持分析,例如事件报告和有关已经意识到的风险的信息。在服务或特定的VBF中断的情况下,分析师还可以使用建模工具预测预期的损失。|(% colspan="2" %)高
1151 -|(% colspan="3" style="width:105px" %)(((
1152 -VBF
954 +[[image:1642262768023-787.png]]
1153 1153  
1154 -相互依赖关系识别
1155 -)))|(% colspan="3" style="width:164px" %)业务连续性计划工具,CMDB,分析工具|(% colspan="3" style="width:470px" %)分析师可以使用服务和配置模型来识别关键的服务和VBF相互依赖关系。|(% colspan="2" %)高
1156 -|(% colspan="3" style="width:105px" %)服务连续性要求的确定|(% colspan="3" style="width:164px" %)业务连续性计划工具,服务目录|(% colspan="3" style="width:470px" %)连续性管理员,服务所有者和恢复团队成员应有权访问服务的连续性要求。|(% colspan="2" %)低
1157 -|(% colspan="11" %)开发和维护服务连续性计划流程
1158 -|(% colspan="3" style="width:105px" %)服务连续性策略开发|(% colspan="3" style="width:164px" %)业务连续性计划工具,CMDB,变更初始化和控制工具|(% colspan="3" style="width:470px" %)(((
1159 -确定现有控件和弹性措施
956 +[[image:1642262782136-227.png]]
1160 1160  
1161 -发起应作为服务连续性策略实现的一部分实施的变更
1162 -)))|(% colspan="2" %)中
1163 -|(% colspan="3" style="width:105px" %)服务连续性计划开发|(% colspan="3" style="width:164px" %)业务连续性计划工具,文档控制工具|(% colspan="3" style="width:470px" %)失效日期控制,版本控制和文档的归档|(% colspan="2" %)从低到高,取决于要管理的文档量
1164 -|(% colspan="2" style="width:138px" %)服务连续性计划的初始测试|(% colspan="9" style="width:877px" %)参见“进行演练”
1165 -|(% colspan="11" %)测试服务连续性计划流程
1166 -|(% colspan="4" %)进行演练|(% colspan="3" %)会议工具,监控工具,技术管理和系统管理工具|(% colspan="3" %)所有相关方应该能够进行沟通和协作,持续了解当前状况并管理服务组件,以执行服务连续性计划。|高
1167 -|(% colspan="4" %)服务连续性审计|(% colspan="3" %)知识管理工具和文档存储库|(% colspan="3" %)审核员应该可以访问服务连续性文档资料,包括计划,练习程序,练习报告和恢复报告。|中
1168 -|(% colspan="11" %)响应和恢复流程
1169 -|(% colspan="4" %)启用|(% colspan="3" %)监控工具,紧急通知,会议工具,事件管理工具|(% colspan="3" %)危机管理组必须能够获得有关事态的信息,并立即直接响应和恢复流程。|高
1170 -|(% colspan="4" %)执行服务连续性计划|(% colspan="3" %)会议工具,紧急管理工具,监控工具,技术管理和系统管理工具,事件管理工具|(% colspan="3" %)所有相关方应能够进行沟通和协作,对当前情况有持续的了解,并管理服务组件,以执行服务连续性计划|高
1171 -
1172 1172  表5.1 服务连续性管理活动的自动化解决方案
1173 1173  
1174 1174  
Icon 1642262167262-433.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +69.5 KB
Content Icon
Icon 1642262190748-510.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +59.5 KB
Content Icon
Icon 1642262249963-601.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +42.6 KB
Content Icon
Icon 1642262271197-361.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +45.7 KB
Content Icon
Icon 1642262555280-925.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +64.4 KB
Content Icon
Icon 1642262576270-128.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +64.8 KB
Content Icon
Icon 1642262601759-766.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +61.5 KB
Content Icon
Icon 1642262627236-955.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +51.6 KB
Content Icon
Icon 1642262695902-600.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +54.7 KB
Content Icon
Icon 1642262721398-460.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +54.6 KB
Content Icon
Icon 1642262745322-477.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +68.5 KB
Content Icon
Icon 1642262768023-787.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +49.0 KB
Content Icon
Icon 1642262782136-227.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.superadmin
Size
... ... @@ -1,0 +1,1 @@
1 +40.5 KB
Content Icon
深圳市艾拓先锋企业管理咨询有限公司