Close

适用于高速团队的 ITSM

什么是 IT 服务连续性管理?

IT 服务连续性管理 (ITSCM) 是 ITIL 服务交付的关键组件。它侧重于事件预防、预测和管理的规划,目标是在灾难级事件发生之前、发生期间和之后,将服务可用性和性能保持在尽可能高的水平。

ITSCM 的目标是在事件不可避免地发生时制定有效的标准化流程,从而减少停机期间、成本和业务影响。

因为如果没有规划,有许多因素会减慢或阻止事件恢复。毕竟,您的待命专家可能会在凌晨 3 点睡眼惺忪地做出回应。在为其他事情工作了数周或数月之后,他们可能已经不再了解代码。他们可能会对灾难级事件的规模感到恐慌。或者他们可能是灾难恢复团队的最新成员,没有那么多解决问题的经验。

制定有据可查、明确的服务连续性管理计划将有助于最大限度地减少因学习曲线、远离代码的时间、灾难紧急情况或午夜警报而造成的任何延迟。

ITSCM 和 ITIL 4

在 ITIL 4 中,服务连续性管理是一个旨在支持业务连续性管理 (BCM) 的流程。该流程的目标是确保服务在发生重大服务中断后在约定的业务时间线内恢复正常运行。

ITSCM 与事件管理的对比

ITIL 4 区分了事件管理(处理各种影响级别的事件)和 ITSCM(用于针对大规模灾难的规划)。

那么,究竟什么构成灾难呢?每个业务的答案可能不同,但业务连续性研究所将其定义为:“对组织造成重大损害或严重损失的突发计划外事件。这会导致组织无法在预先确定的最短时间内提供关键业务功能。”

我们称为灾难的规模、预先确定的最短时间以及关键业务职能的定义是每个企业需要自己定义和记录的三件事。

ITSCM 和业务连续性管理 (BCM)

业务连续性管理是在 IT 外部管理的流程,用于识别业务风险并努力降低这些风险。有些风险可能与 IT 相关,包括灾难级别的事件,有些风险可能不在 IT 控制范围内,例如自然灾害或设施火灾。

由于 BCM 包括 ITSCM 以及其他风险缓解流程,因此 IT 团队与 BCM 团队密切合作以创建:

  • 业务连续性计划 (BCP),包括灾难级 IT 事件的预防和恢复计划
  • 业务影响分析 (BIA),用于确定 IT 灾难的潜在业务影响

ITSCM 目标

从业务角度来看,ITSCM 的目标是减少停机期间、成本和灾难级事件对业务的影响。在更具战术性的层面上,目标包括:

  • 与 BCM 紧密合作,以保护整体业务连续性
  • 制定并管理 IT 服务连续性和灾难恢复计划
  • 与供应商合作,最大限度地减少其产品和服务中停机期间的影响,因为这与业务有关
  • 分析风险和影响,并随着时间的推移相应地修改计划

ITSCM 流程

在 Atlassian,我们自己的连续性计划建立在这样的假设基础上:灾难规划过程是持续的、由领导层驱动,并且经过了全面测试。我们决定不要叨扰我们的客户。我们的流程包括规划、沟通、明确责任、测试和持续改进。

规划

规划流程从提出高级问题开始,然后根据您的答案制定计划。起始问题应包括:

  • 我们的事件响应是什么?
  • 我们要遵循的价值观是什么?
  • 我们需要针对什么样的灾难进行规划?我们的业务固有的风险和威胁是什么?
  • 我们需要支持哪些系统?哪些是至关重要的?
  • 万一发生灾难,我们将如何应对?
  • 支持和恢复关键系统所需的信息在哪里?
  • 我们怎样才能集中这些信息并简化恢复流程?
  • 负责管理的团队是否可以协作和审查信息和流程文档?

一旦有了这些问题的答案,下一步就是使用这些答案来定义:

  • 灾难恢复策略
  • IT 职责范围
  • 每种风险的业务影响范围
  • 每种风险情景的计划和流程
  • 人员和文件要求

ITSCM 规划阶段若要取得成功,关键是记录和模板化最终的计划,以使其一目了然并可重复。在高风险场景中,掌握事件响应小技巧或拥有其他手册一类的资产,便可成为响应者的信息和组织来源。

本着 ITSCM 精神,可访问内置知识库的解决方案(如由 Confluence 提供支持的 Jira Service Management)提供了不间断的文档记录,并允许对其进行修订、优化和协作。这样,响应者就可以访问以往的解决方案文档和最新的资源。

明确职责

发生灾难时,谁应担起责任?计划、流程和文档由谁负责维护和更新?ITSCM 应始终清楚相关的角色和责任,不仅对于灾难本身,也是为了持续监控与改进。通过使用 Jira Service Management,响应者可以标记事务的当事方或相关人员,确保正确委派职责,并促进跨职能协作。

在 Atlassian,我们方法的一部分是定期与我们的站点可靠性工程师和风险与合规团队举行灾难恢复会议。他们讨论了灾难恢复中的差距,并确定了需要制定其他计划、改进、评估或变更的地方。

沟通

开放性是 Atlassian 的核心价值观,我们相信您的组织越了解您的 ITSCM 计划,这些计划就会越有效。

在整个事件响应过程中提供灵活的沟通渠道,以便团队通过首选途径保持联系。Jira Service Management 集成了多个通信渠道,例如嵌入式状态小工具、专用状态页、电子邮件、聊天工具、社交媒体和短信,从而最大限度地减少停机。

沟通不仅可以让利益相关者参与进来,帮助高管在发生灾难级事件期间避免惊慌失措,而且还能使团队在必要时向其他团队寻求帮助,并降低因组织混乱而造成的摩擦风险。

测试

不测试怎么知道您的计划是否有效?这是 ITSCM 的基本问题,也是测试和事件管理演练对实践的成功至关重要的原因。

测试可以帮助您确定流程中的薄弱环节、不可预见的问题以及团队可能需要重新培训或改进文档的地方。

评估和改进

ITSCM 不是一个一劳永逸的流程。这需要事先进行周密的规划,并持续进行培训、评估和改进。这就是我们定期举行灾难恢复会议的原因。这就是为什么我们要测试系统备份,并对数据中心中断或 AWS 区域故障时会发生什么情况进行演练的原因。这也是为什么任何名副其实的 ITSCM 计划都是持续监控、不断变化的原因。

大多数公司将 ITSCM 流程描述为一系列步骤,但我们认为它更像是一个圈子。规划应明确定义角色和职责。从那时起,团队应该在整个组织内进行沟通、测试和再测试、评估、监控和改进,并在这些改进中继续更新计划,进一步定义角色并继续沟通。

同样,这也是内置协作知识库的用武之地。在评估和记录方面,知识库文章是一种宝贵的资源。事件的事后分析报告对于事件发生后的修订和修复至关重要,但也可以作为应对将来潜在问题的长期资源。由 Confluence 提供支持的 Jira Service Management 提供了一个强大的协作平台来执行评估和改进解决方案。

ITSCM 角色和职责

为了在整个组织内有效地规划和实施 ITSCM 实践,许多企业任命了服务连续性管理者和服务连续性恢复团队。

服务连续性管理者 (SCM)

顾名思义,服务连续性管理者负责监督服务连续性。此人通常负责整个流程,领导计划制定,管理持续的监控和评估活动,并监督灾难发生时的行动计划。

此人通常是一位经验丰富的高级技术支持专业人员,但可能担任管理职务,不直接参与日常技术工作。

服务连续性恢复团队

在 SCM 的领导下,该团队负责进行测试和事件演练,并不断改进 ITSCM。该团队通常包括技术人员、质量保证专业人员或测试用户,以及负责保持 ITSCM 与其团队之间沟通渠道畅通的组织各部门的代表。

为什么 ITSCM 很重要?

制定了明确的灾难恢复计划的组织在发生灾难时将更快、更全面地恢复。

ITSCM 不是为日常中断做好规划。而是解决最坏的情况,并确保在出现最坏情况时,对客户和员工生活造成的干扰最小。

以下是良好的 ITSCM 实践的三个明显好处:

  • 如果灾难来袭,良好的 ITSCM 计划意味着基本服务将迅速恢复运行。
  • 该组织始终为重大灾难做好准备,能够快速而适当地做出反应。
  • 企业中的每个人都知道灾难时会发生什么,以及他们预计系统停机多长时间。

了解 ITSCM 如何利用 Jira Service Management 提高客户服务质量,并最大限度地减少组织停机。