Changes for page 服务管理实践 - 14 服务连续性

Last modified by superadmin on 2024/12/25, 15:40

From version < 1.11 >

edited by superadmin
on 2020/09/21, 17:10

To version < 34.1 >

edited by superadmin
on 2022/01/16, 00:06

< >

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (3 modified, 0 added, 0 removed)
Attachments (0 modified, 21 added, 0 removed)

Details

Page properties

Title

@@ -1,1
          +1,1 @@
--14 服务连续性管理
++14 服务连续性管理实践

Parent

@@ -1,1
          +1,1 @@
--C 实践指南.WebHome
++Main.WebHome

Content

@@ -1,19
          +1,1010 @@
++{{box cssClass="floatinginfobox" title="**Contents**"}}
++{{toc/}}
++{{/box}}
--
--(% class="jumbotron" %)
  (((
--(% class="container" %)
--(((
--=   =
++
++)))
++需要下载 **ITIL 4 服务连续性管理实践【中文】**pdf版全文，请关注微信公众号itilxf ，并回复“服务连续性”即可。
++ [[image:微信截图_20210206234644.png]]
++**申明：**
++本系列ITIL 4实践中文版本由ITIL先锋论坛专家委员会组织翻译，国内众多从事ITIL理论推广及落地实践的专家们参与，需要下载最新翻译版本请关注微信公众号：ITILXF，也可访问ITIL4中文知识库网站：itil4hub.cn。
--
++
++请注意，ITIL先锋论坛专家团队仅仅只是进行了这些著作的语种转换工作，我们并不拥有包括原著以及中文发行文件的任何版权，所有版权均为Axoles持有，读者在使用这些文件（含本中文翻译版本）时需完全遵守Axoles 和 TSO所申明的所有版权要求。
++
++
++翻译：李天池    审校：张宏伟    审核：谢帅
++
++
++
++----
++
++= **1 关于本文档** =
++
++本文档提供服务连续性实践实用指南，分为五个主要部分，涵盖：
++
++* 本实践的一般信息
++* 本实践相关的流程和活动及其在服务价值链中的作用
++* 参与本实践的组织和人员
++* 支持本实践的信息和技术
++* 对本实践的合作伙伴和供应商的考虑
++
++== **1.1 ITIL 4资格认证计划** ==
++
++本文档中的部分内容可作为以下教学大纲的一部分以供检查：
++
++* ITIL专家创建、交付和支持
++* ITIL专家交付利益干系人价值
++
++详情请参考各部分教学大纲。
++
++
++
++----
++
++= **2 一般信息** =
++
++
++== **2.1 目的和描述** ==
++
++* **关键信息**
++
++服务连续性管理实践的目的是确保灾难发生时，服务的可用性和性能能够保持在足够的水平。本实践提供了一个框架机制，利用产生有效响应的能力来构建组织的弹性，以保障关键利益相关者的利益，还有组织的声誉、品牌和创造价值的活动。
++
++* **定义：灾难**
++
++一个突发的意外事态，会对组织造成巨大损坏或严重损失。要被归类为灾难，这一事态必须与组织预定义的特定业务影响准则相匹配。服务连续性管理实践有助于确保服务提供者做好应对高影响事件的准备，这些事件会破坏组织的核心活动和/或信誉。在数字化转型的背景下，服务连续性管理实践变得越来越重要，因为在各个行业，数字化服务的作用越来越大。对于在过去专注于非技术灾难的组织而言，重大服务中断可能产生灾难性的影响。
++
++云解决方案的广泛使用，以及与合作伙伴和服务消费者的数字化服务的广泛整合，正在产生更加难以控制的新的关键依赖关系。合作伙伴和服务消费者通常会投资于高可用性和高连续性解决方案上，但是组织之间缺乏整合和一致性会产生新的脆弱性，这一点需要被了解并解决。
++
++服务连续性管理实践与其他实践（包括可用性管理、容量和性能管理、信息安全管理、风险管理、服务设计、关系管理、架构管理和供应商管理实践）相结合，可以确保组织的服务具有弹性并为灾难性事件做好准备。
++
++风险的概念是服务连续性管理实践的核心。该实践通常可以减轻无法被完全避免的高影响、低概率风险（因为某些风险因素不在组织的控制之下，例如自然灾害）。
++
++简单来说，此实践与事件管理实践非常相似，不同之处在于其潜在的损害要大得多，并且它可能威胁到服务提供者创造价值的能力。
++
++服务连续性管理实践与服务价值系统（SVS）中的可用性管理实践密切相关，并且在某些情况下可以合二为一。它也与公司背景下的业务连续性管理实践紧密相关，并可以纳入其中。
++
++服务经济时代，每个组织的业务都是由服务驱动和数字化的。由于这样的紧密联系，业务连续性管理实践可能会与数字化服务连续性与服务管理进行全面整合。如果数字化转型导致消除了“ IT 管理”和“业务管理”之间的界限，则这种整合可能是可行且有用的（有关该主题的更多信息，请参见ITIL4：高速IT）。
++
++
++== **2.2  术语和概念** ==
++
++* **定义：服务连续性**
++
++在灾难事态或破坏性事件发生后，服务提供者以可接受的预定义级别继续服务运营的能力。
++
++对于内部服务提供商，服务连续性管理实践的主要目的是通过管理可能影响IT服务的风险来确保服务提供者能够始终提供相关的议定服务级别，从而支持整个业务连续性管理实践。
++
++对于外部服务提供商，服务连续性管理等同于业务连续性管理。
++
++业务连续性专业人员也有兴趣处理业务危机，如负面媒体关注或破坏性市场事件。但是，在本实践指南中，服务连续性管理实践的范围仅限于运营风险。
++
++
++=== **2.2.1  灾难（或破坏性事件或危机）** ===
++
++ISO将灾难定义为“一种具有高度不确定性的情况，这种情况会破坏核心业务和/或组织的信誉，并需要紧急行动”
++
++明确定义被认为是灾难的事态列表通常是一个好主意。这样做有助于制定一套适当的服务连续性计划，从而确保组织做好应对破坏性事件的准备。灾难清单通常包括：
++
++* 网络攻击
++* 停电
++* 战略合作伙伴的失败
++* 火灾
++* 洪水
++* 关键人员不可用
++* 大规模IT基础设施故障（例如数据中心故障）
++* 自然灾害
++* 界定那些不是灾难的事态同样重要。通常，服务连续性管理实践不涵盖：
++* 轻度故障 故障被视为轻度或重度取决于其对业务的影响程度。重要的是要考虑诸如受影响的服务行动，故障的规模，故障的时间等因素。
++* 战略，政治，市场或行业事件
++
++为了从灾难中成功恢复，服务提供者应该定义服务的连续性要求。服务的连续性要求包括：
++
++* 恢复时间目标(RTO)
++* 恢复点目标(RPO)
++
++最低服务连续性级别（请参阅图2.1）
++
++(% style="text-align:center" %)
++[[image:1613802480933-588.png]]
++
++图2.1 服务的连续性要求：RTO，RPO，最低目标服务级别
++
++
++=== **2.2.2   恢复时间目标** ===
++
++|(((
++**定义：恢复时间目标**
++
++由于业务功能缺失导致对组织产生严重影响之前，服务中断持续的最长时间。这就意味着在这个最大约定时间内必须重新开始生产或业务活动，或者必须恢复资源。
  )))
++
++估算RTO时应考虑的主要因素是：
++
++* 服务提供者提供服务的能力下降以及与此下降相关的成本
++* 服务级别协议罚款和监管判决
++* 与竞争优势和声誉减弱相关的损失
++
++业务连续性专业人员还使用术语“最大容忍中断时间/最大可接受中断（MAO）”，并将其与RTO区分开。
++
++ISO 22301：2012提供以下定义：
++
++* MAO因没有提供生产/服务或执行活动而产生的，为不良影响所花费的变得不可接受的时长
++* RTO 事件之后的时间段，在此期间生产或业务活动必须重新开始，或者资源必须恢复
++
++按照此逻辑，RTO应当比MAO在数量上少一些，这足以说明组织的风险偏好.MAO应该在业务影响分析中确定。RTO应该在服务连续性计划的开发中定义。
++
++
++=== **2.2.3  恢复点目标** ===
++
++|(((
++**定义：恢复点目标**
++
++活动所使用的必须恢复的信息所指向的点，以使活动在重新开始后能够有效运行。
  )))
++RPO定义了可容许的数据损失的时间段。如果RPO为30分钟，则在破坏性事态之前30分钟应至少有一个备份，在服务恢复后的服务交付重新开始时，距离破坏性事态之前30分钟或更短时间内的数据是可用的。
++
++估算RPO时应考虑的主要因素是：
++
++* 使用数据的服务的重要性
++* 数据的重要性
++* 数据的生产率。
++
++例如，一家网上商店每小时接收100个订单。高管们说，丢失200个订单将是不可接受的。因此，RPO为2小时。
++
++RPO定义了备份频率的要求。在灾难发生时，备份管理必须确保最近的备份副本的可用性。
++
++
++=== **2.2.4  最低目标服务级别** ===
++
++|**定义：最低目标服务级别**服务提供者可接受的服务级别，可以在中断期间实现其目标。
++
++灾难恢复期间，服务提供者通常应以最低目标服务级别提供服务。即使客户没有特殊要求，但达到最低服务级别也有助于尽量减小损失。
++
++最低目标服务级别通常根据以下方面进行定义：
++
++* 中断期间用户可以使用的特定服务操作和功能点的列表
++* 中断期间应能够访问服务的有限的用户数量或特定用户组
++* 中断期间用户应能够处理的单位时间段内有限的交易数量。
++
++=== **2.2.5  业务影响分析** ===
++
++|(((
++**定义：业务影响分析**
++
++服务连续性管理实践中的关键活动，用于标识重要的业务功能（VBF）及其依赖关系。这些依赖关系可能包括供应商，人员，其他业务流程和IT服务。业务影响分析定义了IT服务的恢复要求。这些要求包括RTO，RPO和每个IT服务的最低目标服务级别。
++)))
++
++业务影响分析（BIA）是一个流程，用于分析活动以及中断可能对其产生的影响
++
++根据ISO 22301，业务影响分析应包括：
++
++* 识别支持产品和服务提供的活动
++* 评估不执行这些活动，随着时间流逝而造成的影响
++* 设置优先级时间范围以在明确规定的最低可接受水平上恢复这些活动，考虑到在这时间内不恢复它们，带来的影响将变得不可接受
++* 确定这些活动的依赖关系和支持资源，包括供应商，外包合作伙伴，以及其他相关利益方。
++
++=== **2.2.6  服务连续性/ 灾难恢复计划** ===
++
++|(((
++**定义：服务连续性**
++
++一套明确定义的考虑到服务管理四维模型的计划，有关组织如何从灾难恢复并返回到灾难之前的状态。
++)))
++
++服务连续性计划用于指导服务提供者在中断后响应，恢复服务并将其还原到正常水平。
++
++服务连续性计划通常包括：
++
++* 响应计划 明确了服务提供者最初如何对破坏性的事态做出反应，以防止损坏，例如火灾或网络攻击。
++* 恢复计划 明确了服务提供者如何恢复服务以实现RTO和RPO。
++* 计划恢复正常操作明确了服务提供者在恢复之后如何重新开始正常。例如，如果已使用备用数据中心，则此阶段将使主数据中心重新投入运行，并修复再次调用IT服务连续性计划的能力。
++
++在许多情况下也会有制定业务连续性计划的需求。业务连续性计划可能包括：
++
++* 紧急响应 对接所有紧急服务和活动
++* 疏散计划以确保人员安全
++* 危机管理和公众关系计划为不同危机的指挥和控制，以及媒体和公众关系的管理做出计划
++* 安全计划展示了所有主站点和恢复站点上的安全的各个方面是如何被管理的
++* 沟通计划展示了在重大事件期间，与所有相关领域和当事人沟通的各个方面是如何处理和管理的。
++
++这些计划通常在制定时被当做业务连续性管理实践的一部分。
++
++
++== **2.3 范围** ==
++
++服务连续性管理实践包括以下领域：
++
++* 执行BIA来量化服务不可用带给服务提供者和服务消费者的影响
++* 开发服务连续性策略（并将它们整合到相关的业务连续性管理策略中）。这应该包括的要素有风险缓解措施，以及适当的、全面的恢复选项的选择
++* 制定和管理服务连续性计划（并为相关的业务连续性计划提供清晰的接口）
++* 进行练习，并测试如果发生灾难情况下，服务连续性计划的启用
++* 有一些活动和责任领域尽管仍与服务连续性管理密切相关，但不包含在服务连续性管理实践中。表2.1中列出了这些内容，以及涉及到的包含这些内容的实践。重要的是要记住，ITIL实践只是在价值流的背景中使用的工具的集合；它们应当根据情况在必要时组合在一起。
++
++(% style="width:469px" %)
++|(% style="width:335px" %)活动|(% style="width:132px" %)实践指南
++|(% style="width:335px" %)与客户沟通以使客户的业务连续性策略和计划与服务提供者的服务连续性策略和计划保持一致|(% style="width:132px" %)关系管理
++|(% style="width:335px" %)协商并与客户服务连续性要求达成一致|(% style="width:132px" %)服务级别管理
++|(% style="width:335px" %)将服务连续性解决方案设计为服务模型的一部分|(% style="width:132px" %)服务设计
++|(% style="width:335px" %)使服务连续性解决方案与业务架构保持一致|(% style="width:132px" %)架构管理
++|(% style="width:335px" %)识别与服务连续性相关的风险|(% style="width:132px" %)风险管理
++|(% style="width:335px" %)与供应商和合作伙伴建立和管理合同|(% style="width:132px" %)供应商管理
++|(% style="width:335px" %)监控服务的可用性|(% style="width:132px" %)监控和事态管理
++|(% style="width:335px" %)证明新的服务连续性解决方案|(% style="width:132px" %)组合管理
++|(% style="width:335px" %)实施风险缓解措施并更改IT基础设施，以确保弹性|(% style="width:132px" %)项目管理, 变更控制
++|(% style="width:335px" %)管理并实施持续改进|(% style="width:132px" %)持续改进
++
++
++
++=== **2.3.1  可用性与连续性之间的界线** ===
++
++服务的连续性和可用性管理的实践之间的界限是不明显的。两种做法都涉及风险的概念，并致力于识别和准备应对可能威胁并导致服务不能运转的事件。对于这两种实践，都需要了解VBF和风险评估或服务故障的BIA。最终，两种做法都确保了组织的抗故障能力。
++
++一些组织不希望将可用性的管理和连续性分开。但是，表2.2中概述了这两种做法之间的一些差异，在设计服务管理系统时应考虑这些差异。
++
++(% style="width:454px" %)
++|(% style="width:174px" %)可用性管理|(% style="width:278px" %)服务连续性管理
++|(% style="width:174px" %)专注于高概率的风险|(% style="width:278px" %)专注于高影响风险（紧急情况，灾难）
++|(% style="width:174px" %)更主动|(% style="width:278px" %)更被动
++|(% style="width:174px" %)减少意外的可能性|(% style="width:278px" %)减少意外的影响
++|(% style="width:174px" %)关注技术解决方案|(% style="width:278px" %)关注组织措施
++|(% style="width:174px" %)优化|(% style="width:278px" %)创建冗余
++|(% style="width:174px" %)不属于公司职能|(% style="width:278px" %)通常是公司职能的一部分
++|(% style="width:174px" %)日常业务|(% style="width:278px" %)特殊情况下
++|(% style="width:174px" %)MTRS, MTBF, MTBSI|(% style="width:278px" %)RTO, RPO
++
++表2.2 可用性管理和服务连续性管理之间的区别
++
++
++服务连续性管理实践不包含那些不会严重影响组织的轻度或短期故障。它关注与重大损害相关的风险，无论它们发生的可能性或不可能性有多大。通常，这些是紧急情况：火灾，洪水，断电，数据中心故障等。虽然可用性管理实践并未忽略故障对服务提供者和消费者造成的负面影响，但是单个组件的轻度中断也在流程中有所考虑。
++
++这些实践的目标之间存在对立。可用性管理实践处理统计数据并分析趋势；连续性管理关心如何应对破坏性事件。
++
++可用性规划致力于满足当前和将来的商定要求，并避免出现偏差。可用性管理实践发现并消除单点失效；所采取的对策通常是积极主动的，以减少意外事态发生的可能性。服务连续性管理实践专注于规划，以管理破坏性事件的严重后果。备份站点，服务提供的替代方案的过渡，还有恢复程序，都可以减少损坏，但是通常不影响事件发生的可能性。
++
++
++=== **2.3.2 事件管理** ===
++
++事件管理实践的活动与服务连续性管理实践的非常相似。但是，事件管理实践专注于不会威胁组织的弹性的故障，而服务连续性管理实践专注于可能会阻碍组织恢复服务交付的高影响故障。
++
++同样，这两个实践之间的界线是不明显的，应根据对务提供者和服务使用者的影响来明确定义。同时，在某些情况下（通常在小的，单站点服务提供者中），服务连续性活动可作为重大事件管理的一部分来执行。
++
++当服务连续性计划到位并与事件管理活动分开管理时，应该有一个清晰的标准来触发服务连续性程序。在评估事件的业务影响时，支持专家应确定重大事件是否可能导致灾难，并通知危机管理组，以便他们能够做出有关启用的决定。
++
++|(((
++**定义：启用**
++
++服务提供者必须承诺服务连续性计划，以便继续服务的交付。
++)))
++
++
++
++=== **2.3.3 服务连续性实践在管理风险时的角色** ===
++
++风险的概念是服务连续性管理实践的核心。该实践通常关注于减轻无法完全防止的高影响，低概率风险。
++
++为了降低风险，此实践致力于使预期损失减小到最低程度，以便在灾难发生时不会造成重大损失。
++
++为确保准备好应对破坏性事件，服务连续性管理实践需要有关风险的信息，这些信息可以通过风险管理实践获得。
++
++有效的服务连续性管理实践可以为组织的风险管理做出显著贡献。大量风险缓解措施在某种程度上与服务连续性选项相关。
++
++
++== **2.4 实践成功因素** ==
++
++|(((
++**定义：实践成功因素**
++
++实践的一个复杂的功能性的组件，是实践实现其目的所必需的。
++)))
++
++实践的成功因素（PSF）不仅仅是一项任务或活动，因为它包括全部服务管理四维模型的组件。活动的性质和实践中PSF的资源可能有所不同，但它们共同确保实践有效。
++
++服务连续性管理实践包括以下PSF：
++
++* 制定和管理服务连续性计划
++* 降低服务的连续性风险
++* 确保认知和准备就绪
++* 制定和管理服务连续性计划
++
++为了有效地应对灾难并从中恢复，服务提供者需要服务连续性计划，该计划应反映所选的服务连续性策略。应该根据在BIA期间确定的服务连续性要求选择服务连续性策略。
++
++因此，为了制定和管理服务连续性计划，服务提供者应该首先完成BIA，然后选择适当的一组服务连续性要求，进而定义服务连续性策略。
++
++业务连续性研究所（BCI）定义了以下连续性策略:
++
++* 多样化
++* 复制
++* 备用
++* 事件之后的采集
++* 什么都不作
++* 分包
++
++只要服务的连续性要求和服务提供者的背景有所变化，它们就不是一次性的活动。例如，当服务提供者开始将其服务交付给新的消费者时。该事态是重新执行BIA和更新服务连续性策略的触发器。如果长期没有明显变化，则通常每年进行一次或两次BIA，并与风险评估周期同步。有关BIA的更多详细信息，请参见[[3.2.2>>path:#_bookmark10]].
++
++
++=== **2.4.1 连续性计划** ===
++
++BCI在响应和恢复规划结构中引入了三个层次：战略层、战术层和操作层，如表2.3所示。
++
++表2.3响应和恢复规划结构中的层次
++
++(% style="width:683px" %)
++|(% style="width:66px" %)层次|(% style="width:614px" %)描述
++|(% style="width:66px" %)战略层|(% style="width:614px" %)高管如何做出有关恢复流程的决策，如何与外部各方（包括相关媒体）进行沟通以及处理服务连续性计划中未涉及的任何情况
++|(% style="width:66px" %)战术层|(% style="width:614px" %)管理层如何协调恢复流程，以确保根据优先级（当前业务优先级，季节性变化等）适当分配资源并管理规划团队和恢复团队之间的冲突
++|(% style="width:66px" %)操作层|(% style="width:614px" %)团队如何执行恢复活动，包括响应破坏性事件，恢复到服务的预定义级别，和/或提供替代设施以继续运行
++
++根据组织的规模以及服务提供者是内部的还是外部的，可能会有不同的解决方案来构建计划。责任主体也可能有所不同。
++
++服务连续性计划根据服务提供者的类型和组织的规模，其结构的复杂度可能会或多或少。表2.4 概述了一些常见的结构。
++
++[[image:1642262167262-433.png]]
++
++表2.4 连续性计划的结构选项
++
++
++服务连续性计划应涵盖表2.5中概述的灾难发生之后的各个阶段。
++
++[[image:1642262190748-510.png]]
++
++表2.5 响应阶段和恢复阶段
++
++
++计划应清晰，简洁且以行动为导向。通常，计划中应排除掉那些对于使用计划的恢复团队不直接应用的信息。程序应基于时间，并应包含可能的延迟以及计划与团队之间的交互信息。
++
++有关响应和恢复的组织结构的详细信息，请参见[[4.2>>path:#_bookmark14]].
++
++
++=== **2.4.2 减轻服务连续性风险** ===
++
++服务连续性管理实践包括管理各种风险的控制项的定义和管理。为此，它与风险管理实践和其他以风险为中心的实践（例如容量和性能管理，可用性管理和信息安全管理实践）结合使用。商定的可用性控件应通过服务设计，软件开发和管理，以及基础设施和平台管理实践来实施。
++
++表2.6 中概述的服务连续性选项可以作为总体风险缓解计划的一部分来设计和实现。
++
++(% style="width:475px" %)
++|(% style="width:129px" %)服务管理维度|(% style="width:343px" %)服务连续性措施
++|(% style="width:129px" %)组织和人员|(% style="width:343px" %)(((
++* 在灾难期间的人员管理
++* 使用替代站点和设施
++)))
++|(% style="width:129px" %)信息和技术|(% style="width:343px" %)(((
++* 物理安全
++* 弹性电信网络
++* 运维中的数据保护：使用RAID阵列，SAN等来确保数据的可用性
++* 数据备份
++* 容错应用程序
++* 监控以提供及时告警
++)))
++|(% style="width:129px" %)合作伙伴和供应商|(% style="width:343px" %)(((
++* 互惠协议
++* 将服务外包给多个提供商
++* 作为服务的火灾探测系统或灭火系统
++)))
++|(% style="width:129px" %)流程和价值流|(% style="width:343px" %)(((
++* 服务交付的手动操作和替代方法
++* 响应和恢复的计划与程序（服务连续性计划）
++)))
++
++表2.6 服务连续性管理实践的四个维度
++
++
++如果服务的BIA表明了有更早和更高的影响发生，则需要采取更多的预防措施。如果初始影响较低且发展缓慢，则投资于连续性和恢复对策是更经济有效的方法。
++
++选择服务连续性措施时，每个选项的效果和效率应得到评估。同样重要的是持续控制并验证其持续效果和效率。
++
++* 效果根据风险管理原则，应评估服务连续性措施的效果，并将其与破坏性事态的预期损失进行比较。
++* 效率服务连续性度量的成本应该进行评估，并与收益进行比较。通过估算实施该措施后破坏性事态发生概率的降低，并乘以发生事态会对服务提供者和客户造成的预期的影响，可以计算出收益。就成本而言，应将此价值与该措施实施的成本进行比较。这里可以使用成本效益分析。
++
++
++=== **2.4.3 确保认知和就绪状态** ===
++
++未经测试的恢复计划通常根本无法按预期工作。因此，测试是服务连续性管理的关键组成部分，并且是确保所选策略，已实施措施和计划切实可行的唯一方法。
++
++测试服务连续性计划是检查和提高准备状态的一种手段。通过定期修改计划和程序，恢复团队发现缺陷和低效率，然后更新服务连续性计划以反映他们的发现。
++
++BCI定义以下演练类型:
++
++* 走查
++* 桌上演练
++* 指挥所演练
++* 现场
++* 测试。
++
++根据BCI良好实践指南，每种类型的关键特征和目的。
++
++表2.7 概述了2013年。
++
++[[image:1642262249963-601.png]]
++
++[[image:1642262271197-361.png]]
++
++表2.7 锻炼类型
++
++
++演练应该按计划的时间间隔，以及发生可能影响恢复的显著变更时实施。服务中断的可能造成的影响程度越高，演练的频率就应该越高。
++
++演练不仅是确保准备就绪的一种方法，而且是一个改进机会。因此，通常的好主意是，分析测试期间的发现以及整个恢复团队表现，然后生成包括发现和正式建议的演练报告。
++
++
++== **2.5 关键指标** ==
++
++每个实践所做的贡献应该在价值流的背景下评估ITIL实践的效果和绩效。与任何工具的性能/绩效一样，只能在应用程序的背景下评估实践的绩效。然而，工具在设计和质量方面会有很大差异，这些差异被定义为一种工具在根据其用途使用时的有效潜力或能力。更多的有关指标，关键绩效指标（KPIs），和有助于此目的的其他工具的进一步指导，能够在度量和报告实践指南中找到。
++
++服务连续性管理实践的关键指标已映射到其PSF。它们可以用作价值流的背景中的KPI，以评估实践对这些价值流的效果和效率的贡献。表2.8给出了一些关键指标的示例。
++
++(% style="width:565px" %)
++|(% style="width:172px" %)实践成功因素|(% style="width:391px" %)指标示例
++|(% style="width:172px" %)制定和管理服务连续性计划|(% style="width:391px" %)(((
++* 具有清晰地文件化连续性要求的产品和服务的百分比
++* 文件化的服务连续性计划中（关键）产品和服务的百分比
++* 及时更新服务连续性计划
++)))
++|(% style="width:172px" %)降低服务的连续性风险|(% style="width:391px" %)(((
++* RTO达成情况（实际灾难和演练）
++* RPO达成情况（实际灾难和演练）
++* 有效连续性措施的百分比
++* 实际损失与预期损失之比
++)))
++|(% style="width:172px" %)确保认知和就绪状态|(% style="width:391px" %)(((
++* 按计划进行的演练和认知活动的百分比
++* 在给定时间段内（通常为过去6个月）对其连续性计划进行测试的服务所占的百分比
++)))
++
++表2.8 实践成功因素的指标示例
++
++将指标正确汇总到复杂指标中，将使数据更易于用于价值流的日常管理，以及用于服务连续性管理实践的定期评估和持续改进。没有单一的最佳解决方案。指标将基于总体的服务战略和组织的优先级，以及实践有助于的价值流目标。
++
++
++
++----
++
++
++= **3  价值流和流程** =
++
++
++== **3.1  价值流贡献** ==
++
++像任何其他ITIL 管理实践一样，服务连续性管理也有助于多个价值流。重要的是要记住，价值流永远不会由单个实践形成。服务连续性管理实践与其他实践相结合，可以为消费者提供高质量服务。实践贡献的主要价值链活动是：
++
++* 交付和支持
++* 设计和转换
++* 改进
++* 获取或构建
++* 计划
++
++服务连续性管理实践对服务价值链的贡献如图3.1 所示。
++
++(% style="text-align:center" %)
++[[image:1613802652783-527.png]]
++
++图3.1 服务连续性管理实践对价值链活动贡献的热力图
++
++
++== **3.2  流程** ==
++
++每个实践可能包含一个或多个流程和活动，它们对于实现该实践的目的可能是必需的。
++
++|(((
++**定义：流程**
++
++一组相互关联或交互的活动，可将输入转换为输出。流程接受一个或多个定义的输入，并将其转换为定义的输出。流程定义活动的顺序及它们的依赖关系。
++)))
++
++服务连续性管理活动形成五个流程：
++
++* 服务连续性管理的治理
++* 业务影响分析
++* 制定和维护服务连续性计划
++* 测试服务连续性计划
++* 响应和恢复
++
++=== **3.2.1  服务连续性管理的治理** ===
++
++该流程包括表3.1中列出的活动，并将输入转换为输出。
++
++(% style="width:515px" %)
++|(% style="width:176px" %)关键输入|(% style="width:145px" %)活动|(% style="width:191px" %)关键输出
++|(% style="width:176px" %)(((
++* 业务影响分析报告
++* 风险登记册
++* 客户要求
++* 法规要求
++* 风险偏好
++* 标准
++)))|(% style="width:145px" %)(((
++* 范围的定义
++* 策略设置
++* 认知和演练方案制定
++)))|(% style="width:191px" %)(((
++* 服务连续性策略
++* 文件化的角色和职责
++* 认知和演练方案
++)))
++
++表3.1 服务连续性管理的治理的输入，活动和输出
++
++
++图3.2显示了流程的工作流程图。
++
++(% style="text-align:center" %)
++[[image:1613802681329-660.png]]
++
++图3.2 服务连续性管理的治理的工作流程
++
++
++这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.2进一步描述了这些活动。
++
++(% style="width:687px" %)
++|(% style="width:98px" %)活动|(% style="width:587px" %)描述
++|(% style="width:98px" %)范围的定义|(% style="width:587px" %)(((
++定义服务连续性管理实践的范围，确保它所涵盖的组织的环境和地域清晰。
++
++组织范围可能受到产品和服务，站点和位置，客户等的限制。那些已停产的或即将终止的产品和服务通常被排除在范围之外，非关键和低利润的产品和服务也一样。
++
++实施服务连续性管理实践的成本可能很高。因此，如果服务提供者启动服务连续性管理方案，则某些服务，产品或站点最初可能会作为分阶段实施的一部分而被排除在外。
++
++许多不同的技术被用来定义实践的范围，包括成本效益分析，SWOT分析，PESTLE分析等。
++
++定义范围时，组织应考虑：
++
++* 以前的业务影响分析报告
++* 现有风险登记册
++* 客户要求
++* 监管要求
++
++根据灾难定义实践的范围也很重要。
++)))
++|(% style="width:98px" %)策略设置|(% style="width:587px" %)(((
++策略的设置包括：
++
++* 记录范围。
++* 分配角色和职责。如果服务提供者仅启动服务连续性方案，则将没有组织结构来支持任何服务连续性计划。在其他情况下，响应和恢复团队的组织结构通常是服务连续性策略的一部分。
++* 定义服务连续性管理的一般方法。服务连续性策略应阐明在BIA期间应考虑的可用资源和限制。
++* 应尽快建立并传达政策，以便所有参与服务连续性管理实践或受其影响的利益相关者都知道范围，限制及其职责。
++* 范围和政策应定期修订（通常每年一次）。修订被触发，可能是由于破坏性事态（尤其是计划未涵盖的），一个新的服务，一个新的客户或者是与合作伙伴的一个新关系。
++)))
++|(% style="width:98px" %)认知和演练方案制定|(% style="width:587px" %)(((
++测试是整个服务连续性管理实践的关键部分：这是确保所选策略，措施和计划有效的唯一方法。
++
++应该制定教育，认知培训和演练计划，以确保实践的所有部分（站点，团队成员，服务或CI）每年至少进行一次测试。
++
++演练方案应确保测试整个的服务管理四维模型：
++
++* 组织和人员
++
++* 具有适当技能的适当人员
++* 恢复团队成员的知识和经验
++* 工作人员了解服务连续性计划
++
++* 信息和技术:
++
++* 所需的设备正常工作
++* 所需的数据可用
++
++* 合作伙伴和供应商:
++* 参与响应和恢复的第三方准备就绪，以满足服务连续性要求
++
++* 流程和价值流：
++
++* 程序是正确的，一致的，可管理的
++)))
++
++表3.2 服务连续性管理的活动
++
++
++=== **3.2.2 业务影响分析** ===
++
++该流程包括表3.3中列出的活动，并将输入转换为输出。
++
++(% style="width:475px" %)
++|(% style="width:153px" %)关键输入|(% style="width:150px" %)活动|(% style="width:170px" %)关键输出
++|(% style="width:153px" %)(((
++* 服务文档
++* 风险评估报告
++* VBF损失的财务数据
++* 重大事件报告
++* 服务模型
++* 风险管理策略
++* 风险偏好
++* 监管要求
++)))|(% style="width:150px" %)(((
++* VBF识别
++* 中断后果分析
++* VBF相互依赖关系识别
++* 服务连续性要求的确定
++)))|(% style="width:170px" %)(((
++* VBF的优先级列表
++* 文件化的VBF损失产生的影响
++* 文件化的VBF相互依赖关系
++* 业务影响分析报告
++)))
++
++表3.3 业务影响分析流程的输入、活动和输出
++
++
++图3.3 业务影响分析流程的工作流程
++
++(% style="text-align:center" %)
++[[image:1613802733108-253.png]]
++
++图3.3 显示了流程的工作流程图
++
++
++这些活动可以由组织中的许多人以不同程度的正式方式来执行。表3.4进一步概述了这些活动。
++
++(% style="width:704px" %)
++|(% style="width:78px" %)活动|(% style="width:624px" %)描述
++|(% style="width:78px" %)VBF识别|(% style="width:624px" %)(((
++VBF涉及到服务中对于服务提供者和/或客户的成功至关重要的一部分。识别和文件化这些VBF，以提供适当的焦点和资源分配非常重要。
++
++可以使用许多不同的技术来识别风险，包括头脑风暴，与利益相关者（包括客户和用户）的访谈，对服务文档的分析等等。
++
++如果服务提供者具有已建立的风险管理实践，则有关风险评估的信息可能有助于理解最关键的区域。
++)))
++|(% style="width:78px" %)中断后果分析|(% style="width:624px" %)(((
++当确定了VBF时，应确定中断的影响。该影响可能是可以准确识别的“硬” 影响，例如财务损失，也可以是“软” 影响，例如声誉受损或失去竞争优势。
++
++可以考虑FAIR提出的以下形式的损失：
++
++* 生产效率：服务提供者提供服务的能力下降
++* 响应：与管理损失事态有关的费用
++* 替换：资产的固有价值，与替换丢失或损坏的资产相关的费用（例如，购买替换服务器）
++* SLA罚款和监管判决：针对服务提供者的法律或监管行动
++* 竞争优势：与竞争优势减弱相关的损失。
++* 声誉：与外部对服务提供者的看法的相关损耗
++
++影响可能会随时间推移产生变化。服务提供者和客户也许可以在短时间内不使用特定的服务或VBF而正常工作，但是随着时间的流逝，影响可能会增加，直到服务提供者或客户不能再操作。
++
++BIA演练的主要输出之一是一项IT服务或特定VBF随时间推移的预期损失图。使用此图以驱动服务连续性策略和计划。
++
++服务中断造成的损失通常会随着时间呈指数增长。除了与组织产生其主要价值主张的能力下降的有关损失之外，还存在罚款，判决和声誉受损的威胁。
++)))
++|(% style="width:78px" %)(((
++VBF
++
++相互依赖关系识别
++)))|(% style="width:624px" %)(((
++VBF和服务组件以及关键的内部和外部资源之间的相互依赖关系应予以识别和文件化。
++
++为此，如果已安装配置管理数据库，则服务提供者可以使用服务和配置模型。组件故障影响分析（CFIA）也可能是有用的技术。CFIA可用于识别失效的单个点，现有的冗余等。
++)))
++|(% style="width:78px" %)服务连续性要求的确定|(% style="width:624px" %)(((
++基于对中断后果和识别的相互依赖关系的分析，服务提供者应为服务连续性管理范围中的每个服务或VBF确定服务连续性要求，包括：
++
++* 恢复时间目标
++* 恢复点目标
++* 最低目标服务级别
++)))
++
++表3.4 业务影响分析流程的活动
++
++
++=== **3.2.3   制定和维护服务连续性计划** ===
++
++该流程包括表3.5 中列出的活动，并将输入转换为输出。
++
++(% style="width:554px" %)
++|(% style="width:186px" %)关键输入|(% style="width:188px" %)活动|(% style="width:178px" %)关键输出
++|(% style="width:186px" %)(((
++* 业务影响分析报告
++* 现有控件
++* 有关可用资源的信息
++* 消费者的连续性计划
++* 服务连续性策略
++)))|(% style="width:188px" %)(((
++* 服务连续性策略制定
++* 服务连续性计划制定
++* 服务连续性计划的初始测试
++)))|(% style="width:178px" %)(((
++* 新的和更新的控件
++* 服务连续性策略
++* 服务连续性计划
++)))
++
++表3.5 制定和维护服务连续性计划流程的输入，活动和输出
++
++
++图3.4 显示了该流程的工作流程图。
++
++(% style="text-align:center" %)
++[[image:1613803200091-580.png]]
++
++图3.4 制定和维护服务连续性计划流程的工作流程
++
++
++这些活动可以由组织中的许多人以不同程度的正式方式来执行。
++
++表3.6 进一步概述了这些活动。
++
++(% style="width:657px" %)
++|(% style="width:147px" %)活动|(% style="width:508px" %)描述
++|(% style="width:147px" %)服务连续性策略制定|(% style="width:508px" %)(((
++基于BIA 报告，服务提供者应该确定一套适当的且具有成本效益的服务连续性策略集。
++
++对于影响更早，影响更大的流程和服务，应采取更多的预防措施。对于影响较低且需要较长时间开发的流程和服务，应更加重视恢复措施。
++)))
++|(% style="width:147px" %)服务连续性计划制定|(% style="width:508px" %)(((
++基于服务连续性政策和策略，服务提供者应该制定和维护服务连续性计划。
++
++如果服务或恢复团队成员发生变化，则必须更新计划。计划也可以在演练或实际恢复之后更新。
++)))
++|(% style="width:147px" %)服务连续性计划的初始测试|(% style="width:508px" %)发布之前，应测试服务连续性计划。初始测试的方法类似于正在进行的演练。
++
++表3.6 制定和维护服务连续性计划流程的活动
++
++
++=== **3.2.4  测试服务连续性计划** ===
++
++该流程包括表3.7 中列出的活动，并将输入转换为输出。
++
++(% style="width:536px" %)
++|(% style="width:156px" %)关键输入|(% style="width:164px" %)活动|(% style="width:214px" %)关键输出
++|(% style="width:156px" %)(((
++* 认知和演练方案
++* 服务连续性计划
++)))|(% style="width:164px" %)(((
++* 进行演练
++* 服务连续性审计
++)))|(% style="width:214px" %)(((
++* 演练报告
++* 新的和更新的控件的要求
++* 策略或计划的变更请求
++* 审计报告
++)))
++
++表3.7 测试服务连续性计划流程的输入、活动和输出
++
++
++图3.5 显示了该流程的工作流程图。
++
++(% style="text-align:center" %)
++[[image:1613803224419-995.png]]
++
++图3.5 测试服务连续性计划流程的工作流程
++
++
++这些活动可能由组织中的许多人以不同程度的正式方式来执行。表3.8进一步概述了这些活动。
++
++(% style="width:613px" %)
++|(% style="width:121px" %)活动|(% style="width:490px" %)描述
++|(% style="width:121px" %)进行演练|(% style="width:490px" %)(((
++演练应按计划的时间间隔，和当出现可能影响恢复的显著变化时进行。服务中断的可能影响越高，演练的频率就应该越高。
++
++演练和测试不仅是确保准备就绪的方法；它们也是改进机会。这通常是一个好主意，用来分析测试结果以及整个恢复团队绩效，然后生成包括结果和建议的演练报告。
++
++练习报告可能包括对新的或更新的现存的要求，或对服务连续性计划变更的请求。
++
++如果演练失败，则会更新后续演练时间表以便尽快重新执行失败的演练。
++)))
++|(% style="width:121px" %)服务连续性审计|(% style="width:490px" %)(((
++服务连续性审计可确保在环境更改时，BIA，服务连续性策略和计划保持适当和相关。审计通常是按计划进行的，但是可能由于演练失败或恢复失败而触发。
++
++审核可以在内部进行，也可以由第三方进行。审计的输出可能会确定一个实施新的或更新的控件的需求，也可以是调整服务连续性策略或计划的需求。
++)))
++
++表3.8测试服务连续性计划流程的活动
++
++
++=== **3.2.5  响应和恢复** ===
++
++该流程包括表3.9 中所述的活动，并将输入转换为输出。
++
++(% style="width:496px" %)
++|(% style="width:170px" %)关键输入|(% style="width:155px" %)活动|(% style="width:169px" %)关键输出
++|(% style="width:170px" %)(((
++* 服务连续性计划
++* 事件记录
++)))|(% style="width:155px" %)(((
++* 调用
++* 执行服务连续性计划
++)))|(% style="width:169px" %)(((
++* 恢复报告
++* 新的和更新的控件的要求
++* 变更计划的请求
++)))
++
++表3.9 响应和恢复流程的输入、活动和输出
++
++
++图3.6 显示了该流程的工作流程图。
++
++(% style="text-align:center" %)
++[[image:1613803263520-830.png]]
++
++图3.6 响应的工作流程和恢复流程
++
++
++这些活动可以由组织中的许多人以不同程度的正式方式来执行。
++
++表3.10 进一步概述了这些活动。
++
++(% style="width:715px" %)
++|(% style="width:92px" %)实现价值|(% style="width:621px" %)描述
++|(% style="width:92px" %)启动|(% style="width:621px" %)(((
++启动是一项声明行为，组织的连续性安排需要实施，以便继续提供关键产品和服务[[12>>path:#_bookmark12]].
++
++启动的决定通常是由“ 危机管理”团队（在组织结构的战略层面上）做出的。[[13>>path:#_bookmark13]]），用于核算：
++
++* 服务中断的潜在影响
++* 服务中断的可能持续时间
++* 每天/每月/每年的时间
++)))
++|(% colspan="2" style="width:712px" %)(((
++|(% style="width:81px" %)启动|(% style="width:614px" %)(((
++如果风险较低，则危机管理团队可以决定不调用服务连续性计划。
++
++如果启动，危机管理团队还应该：
++
++* 确定服务提供者要使用的哪些恢复选项（如果有几个选项可用）
++* 定义启动的范围（服务，产品，站点，位置等）
++
++启动是服务连续性计划的最终测试。如果准备工作已经完成并且计划已经制定和经过测试，那么启动应该很简单。如果计划未经测试，则可能会失败。
++)))
++|(% style="width:81px" %)执行服务连续性计划|(% style="width:614px" %)(((
++一旦发生启动，所有参与的恢复团队都应执行服务连续性程序。恢复可能是一段时间的高级活动，需要许多人花费长时间。在战术层面上，恢复团队调度员必须对此进行识别和管理。
++
++任何时候都可能发生中断，因此对于办公室内外的关键人员而言，容易获得启动流程的指南是非常必要的。
++
++恢复流程通常包括以下阶段：
++
++* 响应：为防止损坏对破坏性的事态做出响应，例如在火灾或网络攻击情况下。
++* 恢复：根据RTO，RPO和最低要求目标服务级别，恢复服务的交付。
++* 返回正常操作。
++)))
++)))
++
++表3.10 活动的响应和恢复流程
++
++
++
++----
++
++= **4  组织和人员** =
++
++
++== **4.1  角色，能力和责任** ==
++
++ITIL 实践指南没有描述实践管理的角色，例如实践所有者，实践负责人或实践教练。相反，他们专注于每个实践特有的专门角色。每个角色的结构和命名都可能因组织而异，因此ITIL中定义的任何角色都不应被视为强制性的，只是推荐性的。
++
++请记住，角色不是职位。一个人可以担任多个角色，一个角色可以分配给多个人。
++
++角色是在流程和活动的背景中描述的。每个角色都具有基于表4.1中所示模型的一个能力简介的特征。
++
++
++表4.1 能力代码和简介
++
++(% style="width:477px" %)
++|(% style="width:75px" %)能力代码|(% style="width:400px" %)能力类型（活动和技能）
++|(% style="width:75px" %)L|(% style="width:400px" %)**领导者 **决策，委派，监督其他活动，提供激励和动机以及评估结果
++|(% style="width:75px" %)A|(% style="width:400px" %)**管理员 **分配任务并确定优先级，保留记录，进行中的报告并启动基本改进
++|(% style="width:75px" %)C|(% style="width:400px" %)**协调员/沟通者 **协调多方，维护利益相关者之间的沟通，并开展宣传活动
++|(% style="width:75px" %)M|(% style="width:400px" %)**方法和技术专家 **设计和实施工作技术，记录程序，咨询流程，工作分析和持续改进
++|(% style="width:75px" %)T|(% style="width:400px" %)**技术专家 **提供技术（IT）专业知识并实施基于专业知识的任务
++
++
++
++表4.2 中列出了服务连续性管理实践涉及的角色示例，以及相关的能力简介和特定技能。
++
++[[image:1642262555280-925.png]]
++
++[[image:1642262576270-128.png]]
++
++[[image:1642262601759-766.png]]
++
++[[image:1642262627236-955.png]]
++
++
++表4.2 负责服务连续性管理活动的角色示例
++
++
++== **4.2  组织结构和团队** ==
++
++灾难是影响重大的事件，因此响应必须非常快。协调响应和恢复活动需要灵活性。因此，常规业务的组织结构与灾难无关。
++
++在恢复过程中，组织结构通常基于连续性计划的级别。表4.3概述了用于响应和恢复的组织结构级别。
++
++(% style="width:467px" %)
++|(% style="width:91px" %)连续性计划的层次|(% style="width:81px" %)组织层次|(% style="width:293px" %)描述
++|(% style="width:91px" %)战略|(% style="width:81px" %)行政级别|(% style="width:293px" %)这包括高级管理/主管人员，他们具有组织内的总体权限和控制，并负责危机管理，联络其他部门，事业部，组织，媒体，监管机构，紧急服务等。
++|(% style="width:91px" %)战术|(% style="width:81px" %)协调级别|(% style="width:293px" %)通常，该级别比主管组低一级，该组负责协调组织内的整体恢复工作。
++|(% style="width:91px" %)运行|(% style="width:81px" %)专家级|(% style="width:293px" %)一系列服务恢复团队，负责在各自区域内执行计划并与员工，客户和第三方保持联系。在IT内部，恢复团队应按服务和产品分组。
++
++表4.3 用于响应和恢复的组织结构
++
++
++
++----
++
++= **5  信息和技术** =
++
++
++== **5.1  信息交换，输入/输出** ==
++
++服务连续性管理实践的效果基于所使用信息的质量。该信息可以包括：
++
++* 消费者的业务流程
++* 服务及其架构和设计
++* 合作伙伴和供应商及其提供的服务信息
++* 有关服务连续性的法规要求
++* 与服务连续性安排有关的市场上可用的技术和服务
++
++实践的关键输入和输出在第3节中列出。
++
++服务连续性计划是该实践的核心。它们应该是最新的，并可供所有相关方使用。
++
++
++== **5.2 自动化和工具** ==
++
++尤其是在大型组织中，服务连续性实践应该是自动化的。在可行且有效的地方，可能涉及表5.1中概述的解决方案。
++
++[[image:1642262695902-600.png]]
++
++[[image:1642262721398-460.png]]
++
++[[image:1642262745322-477.png]]
++
++[[image:1642262768023-787.png]]
++
++[[image:1642262782136-227.png]]
++
++表5.1 服务连续性管理活动的自动化解决方案
++
++
++
++----
++
++= **6  合作伙伴和供应商** =
++
++很少有服务仅使用组织自己的资源来交付的。大多数（如果不是全部）依赖于其他服务，这些服务通常由组织之外的第三方提供（请参阅ITIL Foundation的2.4节：ITIL 4 Edition 服务关系模型）。在服务设计，架构管理和供应商管理的实践指南中描述了由支持服务引入的关系和依赖。
++
++合作伙伴和供应商可以提供关键产品和服务组件。服务提供者需要与合作伙伴和供应商协商，并就服务的连续性要求达成一致，以便满足服务的连续性要求。
++
++合作伙伴和供应商也可以提供连续性服务和解决方案，例如备份站点，按需计算，灾难恢复的服务等。在这些情况下，它们也应参与服务连续性计划的开发，测试和执行。
++
++
++
++----
++
++= **7  重要提醒** =
++
++该实践指南的大部分内容都应作为组织在建立和培养自己的实践时可能考虑的领域的建议。实践指南是组织可能考虑的主题目录，而不是答案列表。使用实践指南的内容时，组织应始终遵循ITIL 指导原则：
++
++* 聚焦价值
++* 此时此刻
++* 基于反馈迭代推进
++* 协作和提升可视化程度
++* 通盘思考和工作
++* 保持简单实用
++* 优化和自动化
++
++有关指导原则及其应用的更多信息，请参见ITIL ® Foundation: ITIL 4 Edition的第4.3节。
++
++
++
++----
++
++= **8  致谢** =
++
++AXELOS有限公司非常感谢为本指南的开发做出贡献的每一个人。这些实践指南融合了ITIL社区前所未有的热情和反馈。AXELOS特别要感谢以下人员。
++
++
++== **8.1  作者** ==
++
++Pavel Demin
++
++
++== **8.2 审稿人** ==
++
++
++
  (% class="row" %)
  (((
  (% class="col-xs-12 col-sm-4" %)

1613802480933-588.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+63.1 KB

Content

1613802652783-527.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+148.6 KB

Content

1613802681329-660.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+228.6 KB

Content

1613802733108-253.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+187.3 KB

Content

1613803200091-580.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+178.9 KB

Content

1613803224419-995.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+214.8 KB

Content

1613803263520-830.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+114.3 KB

Content

1642262167262-433.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+69.5 KB

Content

1642262190748-510.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+59.5 KB

Content

1642262249963-601.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+42.6 KB

Content

1642262271197-361.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+45.7 KB

Content

1642262555280-925.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+64.4 KB

Content

1642262576270-128.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+64.8 KB

Content

1642262601759-766.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+61.5 KB

Content

1642262627236-955.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+51.6 KB

Content

1642262695902-600.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+54.7 KB

Content

1642262721398-460.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+54.6 KB

Content

1642262745322-477.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+68.5 KB

Content

1642262768023-787.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+49.0 KB

Content

1642262782136-227.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+40.5 KB

Content

微信截图_20210206234644.png

Author

...	...	@@ -1,0 +1,1 @@
	1	+XWiki.superadmin

Size

...	...	@@ -1,0 +1,1 @@
	1	+36.4 KB

Content

粤ICP备17056641号

深圳市艾拓先锋企业管理咨询有限公司