Changes for page 服务管理实践 - 14 服务连续性
Last modified by superadmin on 2024/12/25, 15:40
Summary
Details
- Page properties
-
- Content
-
... ... @@ -3,16 +3,14 @@ 3 3 {{/box}} 4 4 5 5 ((( 6 +如有[[ITIL认证>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]、[[ITIL培训>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]或[[ITIL考试>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]需求,可[[点击了解详情>>url:http://www.itilchina.cn/achotsao/vip_doc/13354653.html]]。 7 + 6 6 7 7 ))) 8 8 9 -需要下载 **ITIL 4 服务连续性管理实践【中文】**pdf版全文,请关注微信公众号itilxf ,并回复“服务连续性”即可。 10 - 11 - [[image:微信截图_20210206234644.png]] 12 - 13 13 **申明:** 14 14 15 -本系列ITIL 4 实践中文版本由ITIL先锋论坛专家委员会组织翻译,国内众多从事ITIL理论推广及落地实践的专家们参与,需要下载最新翻译版本请关注微信公众号:ITILXF,也可访问ITIL4中文知识库网站:itil4hub.cn。13 +本系列ITIL 4中文版本由长河领导的ITIL先锋论坛专家委员会组织翻译,国内众多从事ITIL理论推广及落地实践的专家们参与。需要下载最新翻译版本请关注**微信公众号**:**ITILXF**,并回复“**服务连续性**”即可。 16 16 17 17 18 18 请注意,ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作,我们并不拥有包括原著以及中文发行文件的任何版权,所有版权均为Axoles持有,读者在使用这些文件(含本中文翻译版本)时需完全遵守Axoles 和 TSO所申明的所有版权要求。 ... ... @@ -228,18 +228,20 @@ 228 228 * 进行练习,并测试如果发生灾难情况下,服务连续性计划的启用 229 229 * 有一些活动和责任领域尽管仍与服务连续性管理密切相关,但不包含在服务连续性管理实践中。表2.1中列出了这些内容,以及涉及到的包含这些内容的实践。重要的是要记住,ITIL实践只是在价值流的背景中使用的工具的集合;它们应当根据情况在必要时组合在一起。 230 230 231 -|活动|实践指南 232 -|与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|关系管理 233 -|协商并与客户服务连续性要求达成一致|服务级别管理 234 -|将服务连续性解决方案设计为服务模型的一部分|服务设计 235 -|使服务连续性解决方案与业务架构保持一致|架构管理 236 -|识别与服务连续性相关的风险|风险管理 237 -|与供应商和合作伙伴建立和管理合同|供应商管理 238 -|监控服务的可用性|监控和事态管理 239 -|证明新的服务连续性解决方案|组合管理 240 -|实施风险缓解措施并更改IT基础设施,以确保弹性|项目管理, 变更控制 241 -|管理并实施持续改进|持续改进 229 +(% style="width:469px" %) 230 +|(% style="width:335px" %)活动|(% style="width:132px" %)实践指南 231 +|(% style="width:335px" %)与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|(% style="width:132px" %)关系管理 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" %)实施风险缓解措施并更改IT基础设施,以确保弹性|(% style="width:132px" %)项目管理, 变更控制 240 +|(% style="width:335px" %)管理并实施持续改进|(% style="width:132px" %)持续改进 242 242 242 + 243 243 === **2.3.1 可用性与连续性之间的界线** === 244 244 245 245 服务的连续性和可用性管理的实践之间的界限是不明显的。两种做法都涉及风险的概念,并致力于识别和准备应对可能威胁并导致服务不能运转的事件。对于这两种实践,都需要了解VBF和风险评估或服务故障的BIA。最终,两种做法都确保了组织的抗故障能力。 ... ... @@ -246,15 +246,16 @@ 246 246 247 247 一些组织不希望将可用性的管理和连续性分开。但是,表2.2中概述了这两种做法之间的一些差异,在设计服务管理系统时应考虑这些差异。 248 248 249 -|可用性管理|服务连续性管理 250 -|专注于高概率的风险|专注于高影响风险(紧急情况,灾难) 251 -|更主动|更被动 252 -|减少意外的可能性|减少意外的影响 253 -|关注技术解决方案|关注组织措施 254 -|优化|创建冗余 255 -|不属于公司职能|通常是公司职能的一部分 256 -|日常业务|特殊情况下 257 -|MTRS, MTBF, MTBSI|RTO, RPO 249 +(% style="width:454px" %) 250 +|(% style="width:174px" %)可用性管理|(% style="width:278px" %)服务连续性管理 251 +|(% style="width:174px" %)专注于高概率的风险|(% style="width:278px" %)专注于高影响风险(紧急情况,灾难) 252 +|(% style="width:174px" %)更主动|(% style="width:278px" %)更被动 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" %)MTRS, MTBF, MTBSI|(% style="width:278px" %)RTO, RPO 258 258 259 259 表2.2 可用性管理和服务连续性管理之间的区别 260 260 ... ... @@ -280,6 +280,7 @@ 280 280 服务提供者必须承诺服务连续性计划,以便继续服务的交付。 281 281 ))) 282 282 284 + 283 283 === **2.3.3 服务连续性实践在管理风险时的角色** === 284 284 285 285 风险的概念是服务连续性管理实践的核心。该实践通常关注于减轻无法完全防止的高影响,低概率风险。 ... ... @@ -330,66 +330,25 @@ 330 330 331 331 表2.3响应和恢复规划结构中的层次 332 332 333 -|层次|描述 334 -|战略层|高管如何做出有关恢复流程的决策,如何与外部各方(包括相关媒体)进行沟通以及处理服务连续性计划中未涉及的任何情况 335 -|战术层|管理层如何协调恢复流程,以确保根据优先级(当前业务优先级,季节性变化等)适当分配资源并管理规划团队和恢复团队之间的冲突 336 -|操作层|团队如何执行恢复活动,包括响应破坏性事件,恢复到服务的预定义级别,和/或提供替代设施以继续运行 335 +(% style="width:683px" %) 336 +|(% style="width:66px" %)层次|(% style="width:614px" %)描述 337 +|(% style="width:66px" %)战略层|(% style="width:614px" %)高管如何做出有关恢复流程的决策,如何与外部各方(包括相关媒体)进行沟通以及处理服务连续性计划中未涉及的任何情况 338 +|(% style="width:66px" %)战术层|(% style="width:614px" %)管理层如何协调恢复流程,以确保根据优先级(当前业务优先级,季节性变化等)适当分配资源并管理规划团队和恢复团队之间的冲突 339 +|(% style="width:66px" %)操作层|(% style="width:614px" %)团队如何执行恢复活动,包括响应破坏性事件,恢复到服务的预定义级别,和/或提供替代设施以继续运行 337 337 338 338 根据组织的规模以及服务提供者是内部的还是外部的,可能会有不同的解决方案来构建计划。责任主体也可能有所不同。 339 339 340 340 服务连续性计划根据服务提供者的类型和组织的规模,其结构的复杂度可能会或多或少。表2.4 概述了一些常见的结构。 341 341 342 -|(% style="width:122px" %) |(% style="width:290px" %)小型组织|大型组织 343 -|(% style="width:122px" %)内部服务提供商|(% style="width:290px" %)((( 344 -在小型组织的IT部门中,可能没有任何服务连续性计划。所有连续性安排都可以作为业务连续性管理的一部分进行管理。 345 +[[image:1642262167262-433.png]] 345 345 346 -特定的IT服务连续性活动可以作为事件管理实践的一部分执行。 347 -)))|((( 348 -战略层:由高管执行的危机管理计划。它通常是业务连续性计划的一部分。 349 - 350 -战术层:大量计划,每个计划都涵盖一个产品,服务,业务单元,站点或位置,每个计划都拥有自己的恢复团队。战术的IT部门活动可以包含在业务连续性计划中,但通常将它们设计为单独的相关计划。 351 - 352 -操作层:大量的用于特定恢复活动的详细步骤(例如,从备份中恢复应用程序数据)。其他部门可能会有自己的特定操作说明,作为连续性计划的一部分。 353 -))) 354 -|(% style="width:122px" %)外部服务提供商|(% style="width:290px" %)所有层次(战略,战术,运行的)都可以作为一个计划实施,而一个团队则负责响应和恢复的各个方面。|连续性计划级别的描述与上面类似,但是服务提供者对所有级别负责。 355 - 356 356 表2.4 连续性计划的结构选项 357 357 358 358 359 359 服务连续性计划应涵盖表2.5中概述的灾难发生之后的各个阶段。 360 360 361 -|(% style="width:79px" %)阶段|(% style="width:503px" %)响应|恢复|复原 362 -|(% style="width:79px" %)计划|(% style="width:503px" %)响应计划|恢复计划|恢复正常运行计划 363 -|(% style="width:79px" %)内容|(% style="width:503px" %)((( 364 -应触发服务连续性计划的事件和场景 352 +[[image:1642262190748-510.png]] 365 365 366 -危机管理组联系人 367 - 368 -初始响应并最小化潜在损失的规程。通常会有针对特定场景的程序(例如火灾或停电) 369 - 370 -用于挑选恢复选项的文档化准则(如果有) 371 - 372 -沟通程序,包括与客户,合作伙伴和员工的沟通 373 - 374 -用于启用的文件化的触发器 375 -)))|((( 376 -恢复团队成员联系方式 377 - 378 -恢复团队的协调指南 379 - 380 -恢复程序的详细说明 381 - 382 -整个组织的监控和共享信息的指南 383 - 384 -升级程序 385 -)))|((( 386 -恢复正常运行的文件化准则 387 - 388 -恢复正常运行程序的详细说明 389 - 390 -复原恢复站点的说明(如果有) 391 -))) 392 - 393 393 表2.5 响应阶段和恢复阶段 394 394 395 395 ... ... @@ -404,12 +404,13 @@ 404 404 405 405 表2.6 中概述的服务连续性选项可以作为总体风险缓解计划的一部分来设计和实现。 406 406 407 -|(% style="width:174px" %)服务管理维度|(% style="width:842px" %)服务连续性措施 408 -|(% style="width:174px" %)组织和人员|(% style="width:842px" %)((( 368 +(% style="width:475px" %) 369 +|(% style="width:129px" %)服务管理维度|(% style="width:343px" %)服务连续性措施 370 +|(% style="width:129px" %)组织和人员|(% style="width:343px" %)((( 409 409 * 在灾难期间的人员管理 410 410 * 使用替代站点和设施 411 411 ))) 412 -|(% style="width:1 74px" %)信息和技术|(% style="width:842px" %)(((374 +|(% style="width:129px" %)信息和技术|(% style="width:343px" %)((( 413 413 * 物理安全 414 414 * 弹性电信网络 415 415 * 运维中的数据保护:使用RAID阵列,SAN等来确保数据的可用性 ... ... @@ -417,12 +417,12 @@ 417 417 * 容错应用程序 418 418 * 监控以提供及时告警 419 419 ))) 420 -|(% style="width:1 74px" %)合作伙伴和供应商|(% style="width:842px" %)(((382 +|(% style="width:129px" %)合作伙伴和供应商|(% style="width:343px" %)((( 421 421 * 互惠协议 422 422 * 将服务外包给多个提供商 423 423 * 作为服务的火灾探测系统或灭火系统 424 424 ))) 425 -|(% style="width:1 74px" %)流程和价值流|(% style="width:842px" %)(((387 +|(% style="width:129px" %)流程和价值流|(% style="width:343px" %)((( 426 426 * 服务交付的手动操作和替代方法 427 427 * 响应和恢复的计划与程序(服务连续性计划) 428 428 ))) ... ... @@ -437,7 +437,6 @@ 437 437 * 效果根据风险管理原则,应评估服务连续性措施的效果,并将其与破坏性事态的预期损失进行比较。 438 438 * 效率服务连续性度量的成本应该进行评估,并与收益进行比较。通过估算实施该措施后破坏性事态发生概率的降低,并乘以发生事态会对服务提供者和客户造成的预期的影响,可以计算出收益。就成本而言,应将此价值与该措施实施的成本进行比较。这里可以使用成本效益分析。 439 439 440 - 441 441 === **2.4.3 确保认知和就绪状态** === 442 442 443 443 未经测试的恢复计划通常根本无法按预期工作。因此,测试是服务连续性管理的关键组成部分,并且是确保所选策略,已实施措施和计划切实可行的唯一方法。 ... ... @@ -456,32 +456,9 @@ 456 456 457 457 表2.7 概述了2013年。 458 458 459 -|(% style="width:92px" %)演练类型|(% style="width:426px" %)关键特征|目的 460 -|(% style="width:92px" %)走查|(% style="width:426px" %)((( 461 -* 基于讨论的演练 462 -* 未加压的环境 463 -* 通常专注于某一特定区域进行改进 464 -)))|((( 465 -用于恢复团队成员首次见面 420 +[[image:1642262249963-601.png]] 466 466 467 -利用改进机会 468 -))) 469 -|(% style="width:92px" %)桌上演练|(% style="width:426px" %)((( 470 -* 基于一个给定场景的讨论 471 -* 通常实时运行,但可以包含“时间跳跃”以使得场景的不同阶段都受到演练 472 -)))|提高对计划的了解 473 -|(% style="width:92px" %)指挥所演练|(% style="width:426px" %)((( 474 -* 以模拟真实事件的方式为恢复团队成员提供信息,并邀请他们做出回应 475 -)))|测试沟通,决策和协调 476 -|(% style="width:92px" %)现场|(% style="width:426px" %)((( 477 -* 测试计划的最逼真的方法 478 -* 范围可以从一个组件的恢复的小型排练,到整个服务或组织的恢复的全面排练 479 -* 通常包括参与的利益相关方 480 -)))|测试在发生破坏性事态时,达到RTO,RPO和最低目标服务水平的能力 481 -|(% style="width:92px" %)测试|(% style="width:426px" %)((( 482 -* 它通常应用于特定的硬件或软件,例如从备份恢复应用程序数据。 483 -* 依照ISO 22301,测试是一种独特类型的演练,它包含了一个期望,就是:演练的(一个或多个)目标的成功或失败要素正在计划中 484 -)))|当故障的风险较高时,测试服务组件的恢复 422 +[[image:1642262271197-361.png]] 485 485 486 486 表2.7 锻炼类型 487 487 ... ... @@ -497,19 +497,20 @@ 497 497 498 498 服务连续性管理实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI,以评估实践对这些价值流的效果和效率的贡献。表2.8给出了一些关键指标的示例。 499 499 500 -|实践成功因素|指标示例 501 -|制定和管理服务连续性计划|((( 438 +(% style="width:565px" %) 439 +|(% style="width:172px" %)实践成功因素|(% style="width:391px" %)指标示例 440 +|(% style="width:172px" %)制定和管理服务连续性计划|(% style="width:391px" %)((( 502 502 * 具有清晰地文件化连续性要求的产品和服务的百分比 503 503 * 文件化的服务连续性计划中(关键)产品和服务的百分比 504 504 * 及时更新服务连续性计划 505 505 ))) 506 -|降低服务的连续性风险|((( 445 +|(% style="width:172px" %)降低服务的连续性风险|(% style="width:391px" %)((( 507 507 * RTO达成情况(实际灾难和演练) 508 508 * RPO达成情况(实际灾难和演练) 509 509 * 有效连续性措施的百分比 510 510 * 实际损失与预期损失之比 511 511 ))) 512 -|确保认知和就绪状态|((( 451 +|(% style="width:172px" %)确保认知和就绪状态|(% style="width:391px" %)((( 513 513 * 按计划进行的演练和认知活动的百分比 514 514 * 在给定时间段内(通常为过去6个月)对其连续性计划进行测试的服务所占的百分比 515 515 ))) ... ... @@ -562,27 +562,27 @@ 562 562 * 测试服务连续性计划 563 563 * 响应和恢复 564 564 565 - 566 566 === **3.2.1 服务连续性管理的治理** === 567 567 568 568 该流程包括表3.1中列出的活动,并将输入转换为输出。 569 569 570 -|关键输入|活动|关键输出 571 -|((( 572 -1. 业务影响分析报告 573 -1. 风险登记册 574 -1. 客户要求 575 -1. 法规要求 576 -1. 风险偏好 577 -1. 标准 578 -)))|((( 579 -1. 范围的定义 580 -1. 策略设置 581 -1. 认知和演练方案制定 582 -)))|((( 583 -1. 服务连续性策略 584 -1. 文件化的角色和职责 585 -1. 认知和演练方案 508 +(% style="width:515px" %) 509 +|(% style="width:176px" %)关键输入|(% style="width:145px" %)活动|(% style="width:191px" %)关键输出 510 +|(% style="width:176px" %)((( 511 +* 业务影响分析报告 512 +* 风险登记册 513 +* 客户要求 514 +* 法规要求 515 +* 风险偏好 516 +* 标准 517 +)))|(% style="width:145px" %)((( 518 +* 范围的定义 519 +* 策略设置 520 +* 认知和演练方案制定 521 +)))|(% style="width:191px" %)((( 522 +* 服务连续性策略 523 +* 文件化的角色和职责 524 +* 认知和演练方案 586 586 ))) 587 587 588 588 表3.1 服务连续性管理的治理的输入,活动和输出 ... ... @@ -598,8 +598,9 @@ 598 598 599 599 这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.2进一步描述了这些活动。 600 600 601 -|(% style="width:106px" %)活动|(% style="width:662px" %)描述 602 -|(% style="width:106px" %)范围的定义|(% style="width:662px" %)((( 540 +(% style="width:687px" %) 541 +|(% style="width:98px" %)活动|(% style="width:587px" %)描述 542 +|(% style="width:98px" %)范围的定义|(% style="width:587px" %)((( 603 603 定义服务连续性管理实践的范围,确保它所涵盖的组织的环境和地域清晰。 604 604 605 605 组织范围可能受到产品和服务,站点和位置,客户等的限制。那些已停产的或即将终止的产品和服务通常被排除在范围之外,非关键和低利润的产品和服务也一样。 ... ... @@ -617,7 +617,7 @@ 617 617 618 618 根据灾难定义实践的范围也很重要。 619 619 ))) 620 -|(% style="width: 106px" %)策略设置|(% style="width:662px" %)(((560 +|(% style="width:98px" %)策略设置|(% style="width:587px" %)((( 621 621 策略的设置包括: 622 622 623 623 * 记录范围。 ... ... @@ -626,7 +626,7 @@ 626 626 * 应尽快建立并传达政策,以便所有参与服务连续性管理实践或受其影响的利益相关者都知道范围,限制及其职责。 627 627 * 范围和政策应定期修订(通常每年一次)。修订被触发,可能是由于破坏性事态(尤其是计划未涵盖的),一个新的服务,一个新的客户或者是与合作伙伴的一个新关系。 628 628 ))) 629 -|(% style="width: 106px" %)认知和演练方案制定|(% style="width:662px" %)(((569 +|(% style="width:98px" %)认知和演练方案制定|(% style="width:587px" %)((( 630 630 测试是整个服务连续性管理实践的关键部分:这是确保所选策略,措施和计划有效的唯一方法。 631 631 632 632 应该制定教育,认知培训和演练计划,以确保实践的所有部分(站点,团队成员,服务或CI)每年至少进行一次测试。 ... ... @@ -659,8 +659,9 @@ 659 659 660 660 该流程包括表3.3中列出的活动,并将输入转换为输出。 661 661 662 -|关键输入|活动|关键输出 663 -|((( 602 +(% style="width:475px" %) 603 +|(% style="width:153px" %)关键输入|(% style="width:150px" %)活动|(% style="width:170px" %)关键输出 604 +|(% style="width:153px" %)((( 664 664 * 服务文档 665 665 * 风险评估报告 666 666 * VBF损失的财务数据 ... ... @@ -669,12 +669,12 @@ 669 669 * 风险管理策略 670 670 * 风险偏好 671 671 * 监管要求 672 -)))|((( 613 +)))|(% style="width:150px" %)((( 673 673 * VBF识别 674 674 * 中断后果分析 675 675 * VBF相互依赖关系识别 676 676 * 服务连续性要求的确定 677 -)))|((( 618 +)))|(% style="width:170px" %)((( 678 678 * VBF的优先级列表 679 679 * 文件化的VBF损失产生的影响 680 680 * 文件化的VBF相互依赖关系 ... ... @@ -694,8 +694,9 @@ 694 694 695 695 这些活动可以由组织中的许多人以不同程度的正式方式来执行。表3.4进一步概述了这些活动。 696 696 697 -|(% style="width:110px" %)活动|(% style="width:657px" %)描述 698 -|(% style="width:110px" %)VBF识别|(% style="width:657px" %)((( 638 +(% style="width:704px" %) 639 +|(% style="width:78px" %)活动|(% style="width:624px" %)描述 640 +|(% style="width:78px" %)VBF识别|(% style="width:624px" %)((( 699 699 VBF涉及到服务中对于服务提供者和/或客户的成功至关重要的一部分。识别和文件化这些VBF,以提供适当的焦点和资源分配非常重要。 700 700 701 701 可以使用许多不同的技术来识别风险,包括头脑风暴,与利益相关者(包括客户和用户)的访谈,对服务文档的分析等等。 ... ... @@ -702,7 +702,7 @@ 702 702 703 703 如果服务提供者具有已建立的风险管理实践,则有关风险评估的信息可能有助于理解最关键的区域。 704 704 ))) 705 -|(% style="width: 110px" %)中断后果分析|(% style="width:657px" %)(((647 +|(% style="width:78px" %)中断后果分析|(% style="width:624px" %)((( 706 706 当确定了VBF时,应确定中断的影响。该影响可能是可以准确识别的“硬” 影响,例如财务损失,也可以是“软” 影响,例如声誉受损或失去竞争优势。 707 707 708 708 可以考虑FAIR提出的以下形式的损失: ... ... @@ -720,16 +720,16 @@ 720 720 721 721 服务中断造成的损失通常会随着时间呈指数增长。除了与组织产生其主要价值主张的能力下降的有关损失之外,还存在罚款,判决和声誉受损的威胁。 722 722 ))) 723 -|(% style="width: 110px" %)(((665 +|(% style="width:78px" %)((( 724 724 VBF 725 725 726 726 相互依赖关系识别 727 -)))|(% style="width:6 57px" %)(((669 +)))|(% style="width:624px" %)((( 728 728 VBF和服务组件以及关键的内部和外部资源之间的相互依赖关系应予以识别和文件化。 729 729 730 730 为此,如果已安装配置管理数据库,则服务提供者可以使用服务和配置模型。组件故障影响分析(CFIA)也可能是有用的技术。CFIA可用于识别失效的单个点,现有的冗余等。 731 731 ))) 732 -|(% style="width: 110px" %)服务连续性要求的确定|(% style="width:657px" %)(((674 +|(% style="width:78px" %)服务连续性要求的确定|(% style="width:624px" %)((( 733 733 基于对中断后果和识别的相互依赖关系的分析,服务提供者应为服务连续性管理范围中的每个服务或VBF确定服务连续性要求,包括: 734 734 735 735 * 恢复时间目标 ... ... @@ -744,18 +744,19 @@ 744 744 745 745 该流程包括表3.5 中列出的活动,并将输入转换为输出。 746 746 747 -|关键输入|活动|关键输出 748 -|((( 689 +(% style="width:554px" %) 690 +|(% style="width:186px" %)关键输入|(% style="width:188px" %)活动|(% style="width:178px" %)关键输出 691 +|(% style="width:186px" %)((( 749 749 * 业务影响分析报告 750 750 * 现有控件 751 751 * 有关可用资源的信息 752 752 * 消费者的连续性计划 753 753 * 服务连续性策略 754 -)))|((( 697 +)))|(% style="width:188px" %)((( 755 755 * 服务连续性策略制定 756 756 * 服务连续性计划制定 757 757 * 服务连续性计划的初始测试 758 -)))|((( 701 +)))|(% style="width:178px" %)((( 759 759 * 新的和更新的控件 760 760 * 服务连续性策略 761 761 * 服务连续性计划 ... ... @@ -776,18 +776,19 @@ 776 776 777 777 表3.6 进一步概述了这些活动。 778 778 779 -|(% style="width:147px" %)活动|(% style="width:621px" %)描述 780 -|(% style="width:147px" %)服务连续性策略制定|(% style="width:621px" %)((( 722 +(% style="width:657px" %) 723 +|(% style="width:147px" %)活动|(% style="width:508px" %)描述 724 +|(% style="width:147px" %)服务连续性策略制定|(% style="width:508px" %)((( 781 781 基于BIA 报告,服务提供者应该确定一套适当的且具有成本效益的服务连续性策略集。 782 782 783 783 对于影响更早,影响更大的流程和服务,应采取更多的预防措施。对于影响较低且需要较长时间开发的流程和服务,应更加重视恢复措施。 784 784 ))) 785 -|(% style="width:147px" %)服务连续性计划制定|(% style="width: 621px" %)(((729 +|(% style="width:147px" %)服务连续性计划制定|(% style="width:508px" %)((( 786 786 基于服务连续性政策和策略,服务提供者应该制定和维护服务连续性计划。 787 787 788 788 如果服务或恢复团队成员发生变化,则必须更新计划。计划也可以在演练或实际恢复之后更新。 789 789 ))) 790 -|(% style="width:147px" %)服务连续性计划的初始测试|(% style="width: 621px" %)发布之前,应测试服务连续性计划。初始测试的方法类似于正在进行的演练。734 +|(% style="width:147px" %)服务连续性计划的初始测试|(% style="width:508px" %)发布之前,应测试服务连续性计划。初始测试的方法类似于正在进行的演练。 791 791 792 792 表3.6 制定和维护服务连续性计划流程的活动 793 793 ... ... @@ -796,14 +796,15 @@ 796 796 797 797 该流程包括表3.7 中列出的活动,并将输入转换为输出。 798 798 799 -|关键输入|活动|关键输出 800 -|((( 743 +(% style="width:536px" %) 744 +|(% style="width:156px" %)关键输入|(% style="width:164px" %)活动|(% style="width:214px" %)关键输出 745 +|(% style="width:156px" %)((( 801 801 * 认知和演练方案 802 802 * 服务连续性计划 803 -)))|((( 748 +)))|(% style="width:164px" %)((( 804 804 * 进行演练 805 805 * 服务连续性审计 806 -)))|((( 751 +)))|(% style="width:214px" %)((( 807 807 * 演练报告 808 808 * 新的和更新的控件的要求 809 809 * 策略或计划的变更请求 ... ... @@ -823,8 +823,9 @@ 823 823 824 824 这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.8进一步概述了这些活动。 825 825 826 -|(% style="width:131px" %)活动|(% style="width:636px" %)描述 827 -|(% style="width:131px" %)进行演练|(% style="width:636px" %)((( 771 +(% style="width:613px" %) 772 +|(% style="width:121px" %)活动|(% style="width:490px" %)描述 773 +|(% style="width:121px" %)进行演练|(% style="width:490px" %)((( 828 828 演练应按计划的时间间隔,和当出现可能影响恢复的显著变化时进行。服务中断的可能影响越高,演练的频率就应该越高。 829 829 830 830 演练和测试不仅是确保准备就绪的方法;它们也是改进机会。这通常是一个好主意,用来分析测试结果以及整个恢复团队绩效,然后生成包括结果和建议的演练报告。 ... ... @@ -833,7 +833,7 @@ 833 833 834 834 如果演练失败,则会更新后续演练时间表以便尽快重新执行失败的演练。 835 835 ))) 836 -|(% style="width:1 31px" %)服务连续性审计|(% style="width:636px" %)(((782 +|(% style="width:121px" %)服务连续性审计|(% style="width:490px" %)((( 837 837 服务连续性审计可确保在环境更改时,BIA,服务连续性策略和计划保持适当和相关。审计通常是按计划进行的,但是可能由于演练失败或恢复失败而触发。 838 838 839 839 审核可以在内部进行,也可以由第三方进行。审计的输出可能会确定一个实施新的或更新的控件的需求,也可以是调整服务连续性策略或计划的需求。 ... ... @@ -846,14 +846,15 @@ 846 846 847 847 该流程包括表3.9 中所述的活动,并将输入转换为输出。 848 848 849 -|关键输入|活动|关键输出 850 -|((( 795 +(% style="width:496px" %) 796 +|(% style="width:170px" %)关键输入|(% style="width:155px" %)活动|(% style="width:169px" %)关键输出 797 +|(% style="width:170px" %)((( 851 851 * 服务连续性计划 852 852 * 事件记录 853 -)))|((( 800 +)))|(% style="width:155px" %)((( 854 854 * 调用 855 855 * 执行服务连续性计划 856 -)))|((( 803 +)))|(% style="width:169px" %)((( 857 857 * 恢复报告 858 858 * 新的和更新的控件的要求 859 859 * 变更计划的请求 ... ... @@ -874,8 +874,9 @@ 874 874 875 875 表3.10 进一步概述了这些活动。 876 876 877 -|(% style="width:152px" %)实现价值|(% style="width:615px" %)描述 878 -|(% style="width:152px" %)启动|(% style="width:615px" %)((( 824 +(% style="width:715px" %) 825 +|(% style="width:92px" %)实现价值|(% style="width:621px" %)描述 826 +|(% style="width:92px" %)启动|(% style="width:621px" %)((( 879 879 启动是一项声明行为,组织的连续性安排需要实施,以便继续提供关键产品和服务[[12>>path:#_bookmark12]]. 880 880 881 881 启动的决定通常是由“ 危机管理”团队(在组织结构的战略层面上)做出的。[[13>>path:#_bookmark13]]),用于核算: ... ... @@ -884,8 +884,8 @@ 884 884 * 服务中断的可能持续时间 885 885 * 每天/每月/每年的时间 886 886 ))) 887 -|(% colspan="2" %)((( 888 -|(% style="width:1 43px" %)启动|(% style="width:607px" %)(((835 +|(% colspan="2" style="width:712px" %)((( 836 +|(% style="width:81px" %)启动|(% style="width:614px" %)((( 889 889 如果风险较低,则危机管理团队可以决定不调用服务连续性计划。 890 890 891 891 如果启动,危机管理团队还应该: ... ... @@ -895,7 +895,7 @@ 895 895 896 896 启动是服务连续性计划的最终测试。如果准备工作已经完成并且计划已经制定和经过测试,那么启动应该很简单。如果计划未经测试,则可能会失败。 897 897 ))) 898 -|(% style="width:1 43px" %)执行服务连续性计划|(% style="width:607px" %)(((846 +|(% style="width:81px" %)执行服务连续性计划|(% style="width:614px" %)((( 899 899 一旦发生启动,所有参与的恢复团队都应执行服务连续性程序。恢复可能是一段时间的高级活动,需要许多人花费长时间。在战术层面上,恢复团队调度员必须对此进行识别和管理。 900 900 901 901 任何时候都可能发生中断,因此对于办公室内外的关键人员而言,容易获得启动流程的指南是非常必要的。 ... ... @@ -928,156 +928,29 @@ 928 928 929 929 表4.1 能力代码和简介 930 930 931 -|能力代码|能力类型(活动和技能) 932 -|L|**领导者 **决策,委派,监督其他活动,提供激励和动机以及评估结果 933 -|A|**管理员 **分配任务并确定优先级,保留记录,进行中的报告并启动基本改进 934 -|C|**协调员/沟通者 **协调多方,维护利益相关者之间的沟通,并开展宣传活动 935 -|M|**方法和技术专家 **设计和实施工作技术,记录程序,咨询流程,工作分析和持续改进 936 -|T|**技术专家 **提供技术(IT)专业知识并实施基于专业知识的任务 879 +(% style="width:477px" %) 880 +|(% style="width:75px" %)能力代码|(% style="width:400px" %)能力类型(活动和技能) 881 +|(% style="width:75px" %)L|(% style="width:400px" %)**领导者 **决策,委派,监督其他活动,提供激励和动机以及评估结果 882 +|(% style="width:75px" %)A|(% style="width:400px" %)**管理员 **分配任务并确定优先级,保留记录,进行中的报告并启动基本改进 883 +|(% style="width:75px" %)C|(% style="width:400px" %)**协调员/沟通者 **协调多方,维护利益相关者之间的沟通,并开展宣传活动 884 +|(% style="width:75px" %)M|(% style="width:400px" %)**方法和技术专家 **设计和实施工作技术,记录程序,咨询流程,工作分析和持续改进 885 +|(% style="width:75px" %)T|(% style="width:400px" %)**技术专家 **提供技术(IT)专业知识并实施基于专业知识的任务 937 937 887 + 938 938 表4.2 中列出了服务连续性管理实践涉及的角色示例,以及相关的能力简介和特定技能。 939 939 940 -|流程活动|(% colspan="2" %)负责角色|(% colspan="2" %)能力类型|具体技能 941 -|(% colspan="6" %)服务连续性管理流程的治理 942 -|范围的定义|(% colspan="2" %)指导委员会|(% colspan="2" %)MC|对各种影响组织的PESTLE因素的能见度 943 -|策略设置|(% colspan="2" %)指导委员会|(% colspan="2" %)MCL|((( 944 -意识到组织特定的文档要求 890 +[[image:1642262555280-925.png]] 945 945 946 -确保管理人员的持续参与,以确保服务连续性策略的清晰性和持续实现 947 -))) 948 -|认知和演练方案开发|(% colspan="2" %)连续性管理员|(% colspan="2" %)ACM|((( 949 -演练类型和恢复团队结构的知识 892 +[[image:1642262576270-128.png]] 950 950 951 -启用沟通渠道 952 -))) 953 -|(% colspan="6" %)业务影响分析流程 954 -|VBF识别|(% colspan="2" %)((( 955 -服务或产品所有者 894 +[[image:1642262601759-766.png]] 956 956 957 - 关系经理896 +[[image:1642262627236-955.png]] 958 958 959 -服务设计者 960 960 961 -客户 962 -)))|(% colspan="2" %)CM|((( 963 -业务分析 964 - 965 -很好的了解服务消费者的业务 966 - 967 -熟悉产品,包括其架构和配置 968 -))) 969 -|中断后果分析|(% colspan="2" %)((( 970 -服务或产品所有者 971 - 972 -关系经理 973 - 974 -客户 975 -)))|(% colspan="2" %)MC|((( 976 -能够系统地应用定性和定量风险分析工具 977 - 978 -专业能力和对影响服务的PESTLE因素的能见度 979 -))) 980 -|VBF相互依赖关系识别|(% colspan="2" %)((( 981 -服务或产品所有者 982 - 983 -服务设计者 984 - 985 -技术专家 986 - 987 -架构管理专家 988 -)))|(% colspan="2" %)MT|熟悉产品,包括其架构和配置 989 -|服务连续性要求的确定|(% colspan="2" %)((( 990 -服务或产品所有者 991 - 992 -连续性管理员 993 -)))|(% colspan="2" %)MTC|((( 994 -对恢复流程的深入了解 995 - 996 -了解服务的连续性策略 997 -))) 998 -|(% colspan="6" %)制定和维护服务连续性计划流程 999 -|服务连续性策略开发|(% colspan="2" %)((( 1000 -连续性管理员 1001 - 1002 -服务设计者 1003 - 1004 -技术专家 1005 -)))|(% colspan="2" %)TM|((( 1006 -对服务连续性选项有很好的了解 1007 - 1008 -认知现有控件 1009 - 1010 -认知市场上可用的技术 1011 -))) 1012 -|服务连续性计划开发|(% colspan="2" %)((( 1013 -连续性管理员 1014 - 1015 -技术专家 1016 -)))|(% colspan="2" %)MTA|((( 1017 -优秀的文档编制能力 1018 - 1019 -优秀的逻辑能力 1020 - 1021 -很好地了解服务组件的相互依赖关系 1022 - 1023 -对技术有很好的了解 1024 -))) 1025 -|服务连续性计划的初始测试|(% colspan="2" %)((( 1026 -连续性管理员 1027 - 1028 -响应和恢复协调员及团队成员 1029 -)))|(% colspan="2" %)CATL|((( 1030 -协调与沟通 1031 - 1032 -对服务连续性计划有深入的了解 1033 - 1034 -了解作为服务连续性策略组成部分的技术 1035 -))) 1036 -|(% colspan="6" %)测试服务连续性计划流程 1037 -|(% colspan="2" %)进行演练|((( 1038 -连续性管理员 1039 - 1040 -响应和恢复协调员及团队成员 1041 -)))|CATL|(% colspan="2" %)((( 1042 -协调与沟通 1043 - 1044 -对服务连续性计划有深入的了解 1045 - 1046 -了解作为服务连续性策略组成部分的技术 1047 -))) 1048 -|(% colspan="2" %)服务连续性审计|内部或外部审计师(根据授权并代表董事会)|CAMT|(% colspan="2" %)((( 1049 -审计管理技术 1050 - 1051 -常见的审计实践命令 1052 - 1053 -确保审核员公正性,客观性和独立性 1054 -))) 1055 -|(% colspan="6" %)响应和恢复流程 1056 -|(% colspan="2" %)调用|危机管理组|LC|(% colspan="2" %)((( 1057 -对服务提供者和消费者风险有深入的了解 1058 - 1059 -了解对消费者的背景 1060 - 1061 -协调与沟通 1062 -))) 1063 -|(% colspan="2" %)执行服务连续性计划|((( 1064 -危机管理组 1065 - 1066 -连续性管理员 1067 - 1068 -响应和恢复协调员及团队成员 1069 -)))|CATL|(% colspan="2" %)((( 1070 -协调与沟通 1071 - 1072 -对服务连续性计划有深入的了解 1073 - 1074 -了解作为服务连续性策略组成部分的技术 1075 -))) 1076 - 1077 1077 表4.2 负责服务连续性管理活动的角色示例 1078 1078 1079 1079 1080 - 1081 1081 == **4.2 组织结构和团队** == 1082 1082 1083 1083 灾难是影响重大的事件,因此响应必须非常快。协调响应和恢复活动需要灵活性。因此,常规业务的组织结构与灾难无关。 ... ... @@ -1084,10 +1084,11 @@ 1084 1084 1085 1085 在恢复过程中,组织结构通常基于连续性计划的级别。表4.3概述了用于响应和恢复的组织结构级别。 1086 1086 1087 -|连续性计划的层次|(% style="width:77px" %)组织层次|(% style="width:602px" %)描述 1088 -|战略|(% style="width:77px" %)行政级别|(% style="width:602px" %)这包括高级管理/主管人员,他们具有组织内的总体权限和控制,并负责危机管理,联络其他部门,事业部,组织,媒体,监管机构,紧急服务等。 1089 -|战术|(% style="width:77px" %)协调级别|(% style="width:602px" %)通常,该级别比主管组低一级,该组负责协调组织内的整体恢复工作。 1090 -|运行|(% style="width:77px" %)专家级|(% style="width:602px" %)一系列服务恢复团队,负责在各自区域内执行计划并与员工,客户和第三方保持联系。在IT内部,恢复团队应按服务和产品分组。 908 +(% style="width:467px" %) 909 +|(% style="width:91px" %)连续性计划的层次|(% style="width:81px" %)组织层次|(% style="width:293px" %)描述 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" %)一系列服务恢复团队,负责在各自区域内执行计划并与员工,客户和第三方保持联系。在IT内部,恢复团队应按服务和产品分组。 1091 1091 1092 1092 表4.3 用于响应和恢复的组织结构 1093 1093 ... ... @@ -1117,44 +1117,16 @@ 1117 1117 1118 1118 尤其是在大型组织中,服务连续性实践应该是自动化的。在可行且有效的地方,可能涉及表5.1中概述的解决方案。 1119 1119 1120 -|(% style="width:89px" %)流程活动|(% colspan="4" style="width:293px" %)自动化手段|(% colspan="3" style="width:442px" %)关键功能|(% colspan="3" style="width:132px" %)对实践有效性的影响 1121 -|(% colspan="11" %)服务连续性管理流程的治理 1122 -|(% style="width:89px" %)((( 1123 -范围的定义 942 +[[image:1642262695902-600.png]] 1124 1124 1125 -策略设置 1126 -)))|(% colspan="4" style="width:293px" %)知识管理工具和文档存储库|(% colspan="3" style="width:442px" %)服务提供者的员工,监管机构和外部利益相关者(例如客户代表)必须容易访问服务的连续性策略,包括方案的范围,指南,角色和职责。|(% colspan="3" style="width:132px" %)低 1127 -|(% style="width:89px" %)认知和演练方案开发|(% colspan="4" style="width:293px" %)业务连续性计划工具|(% colspan="3" style="width:442px" %)服务连续性管理员,服务所有者和恢复团队成员们应有权访问演练时间表,以及他们参与的演练范围的信息。|(% colspan="3" style="width:132px" %)中 1128 -|(% colspan="11" %)业务影响分析流程 1129 -|(% colspan="3" style="width:105px" %)VBF识别|(% colspan="3" style="width:164px" %)服务目录,CMDB,BPM工具|(% colspan="3" style="width:470px" %)为了识别VBF,服务分析人员应有权访问有关服务组件和操作的信息。BPM工具可以提供消费者的流程以及服务支持的操作的有关信息|(% colspan="2" %)高 1130 -|(% colspan="3" style="width:105px" %)中断后果分析|(% colspan="3" style="width:164px" %)((( 1131 -业务连续性计划工具 944 +[[image:1642262721398-460.png]] 1132 1132 1133 - 分析工具,946 +[[image:1642262745322-477.png]] 1134 1134 1135 -风险评估工具,事件管理工具 1136 -)))|(% colspan="3" style="width:470px" %)各种管理系统数据都可以支持分析,例如事件报告和有关已经意识到的风险的信息。在服务或特定的VBF中断的情况下,分析师还可以使用建模工具预测预期的损失。|(% colspan="2" %)高 1137 -|(% colspan="3" style="width:105px" %)((( 1138 -VBF 948 +[[image:1642262768023-787.png]] 1139 1139 1140 -相互依赖关系识别 1141 -)))|(% colspan="3" style="width:164px" %)业务连续性计划工具,CMDB,分析工具|(% colspan="3" style="width:470px" %)分析师可以使用服务和配置模型来识别关键的服务和VBF相互依赖关系。|(% colspan="2" %)高 1142 -|(% colspan="3" style="width:105px" %)服务连续性要求的确定|(% colspan="3" style="width:164px" %)业务连续性计划工具,服务目录|(% colspan="3" style="width:470px" %)连续性管理员,服务所有者和恢复团队成员应有权访问服务的连续性要求。|(% colspan="2" %)低 1143 -|(% colspan="11" %)开发和维护服务连续性计划流程 1144 -|(% colspan="3" style="width:105px" %)服务连续性策略开发|(% colspan="3" style="width:164px" %)业务连续性计划工具,CMDB,变更初始化和控制工具|(% colspan="3" style="width:470px" %)((( 1145 -确定现有控件和弹性措施 950 +[[image:1642262782136-227.png]] 1146 1146 1147 -发起应作为服务连续性策略实现的一部分实施的变更 1148 -)))|(% colspan="2" %)中 1149 -|(% colspan="3" style="width:105px" %)服务连续性计划开发|(% colspan="3" style="width:164px" %)业务连续性计划工具,文档控制工具|(% colspan="3" style="width:470px" %)失效日期控制,版本控制和文档的归档|(% colspan="2" %)从低到高,取决于要管理的文档量 1150 -|(% colspan="2" style="width:138px" %)服务连续性计划的初始测试|(% colspan="9" style="width:877px" %)参见“进行演练” 1151 -|(% colspan="11" %)测试服务连续性计划流程 1152 -|(% colspan="4" %)进行演练|(% colspan="3" %)会议工具,监控工具,技术管理和系统管理工具|(% colspan="3" %)所有相关方应该能够进行沟通和协作,持续了解当前状况并管理服务组件,以执行服务连续性计划。|高 1153 -|(% colspan="4" %)服务连续性审计|(% colspan="3" %)知识管理工具和文档存储库|(% colspan="3" %)审核员应该可以访问服务连续性文档资料,包括计划,练习程序,练习报告和恢复报告。|中 1154 -|(% colspan="11" %)响应和恢复流程 1155 -|(% colspan="4" %)启用|(% colspan="3" %)监控工具,紧急通知,会议工具,事件管理工具|(% colspan="3" %)危机管理组必须能够获得有关事态的信息,并立即直接响应和恢复流程。|高 1156 -|(% colspan="4" %)执行服务连续性计划|(% colspan="3" %)会议工具,紧急管理工具,监控工具,技术管理和系统管理工具,事件管理工具|(% colspan="3" %)所有相关方应能够进行沟通和协作,对当前情况有持续的了解,并管理服务组件,以执行服务连续性计划|高 1157 - 1158 1158 表5.1 服务连续性管理活动的自动化解决方案 1159 1159 1160 1160