ITIL 4的可用性管理
最近在做可用性管理,客户提了一个问题,如果一个页面的响应很慢,比如10秒,我们是否可以算作系统不可以,列入可用性指标的计算。在回答这个问题之前,先聊聊什么是可用性。


什么是可用性

可用性早在ITIL V2的服务交付中,就被定义为一个独立的流程。ITIL V2对于可用性的定义是:可用性(Availability)是指IT服务或组件在某一特定时点或一段时间内能够正常发挥其应有功能的能力。可用性是衡量IT基础设施的关键性指标,它具体体现在以下几个方面:

  • 组件的可用性;
  • IT基础设施的弹性;
  • 维护和支持活动的有效性;
  • 运营流程和程序部署的质量、方式和程度;
  • 数据的安全性、完整性和可用性。

除了可用性,ITIL V2里还介绍了可靠性和可维护性。可靠性(Reliability)是指IT基础设施在服务运营过程中不出现运营故障的特性。它由以下两个因素决定:

  •  IT基础设施内每个组件的可靠性;
  •  IT基础设施的弹性

可维护性(Maintainability)是指IT基础设施组件在出现故障后可被修复并恢复正常运营的特性。

我们通常用以下指标来计算这三个特性。

  • 平均修复时间(Mean Time to Repair-MTTR):事故发生到服务恢复之间的平均间隔时间,又称为停机时间(Downtime)。它由检测时间和解决时间两部门组成。这项指标与服务的可维护性和适用性有关。

  • 平均无故障时间(Mean Time Between Failures-MTBF):从某次事故修复到下次事故发生之间的平均间隔时间,又称为正常运营时间(Uptime)。这项指标与服务的可靠性有关。

  • 平均系统事故间隔时间(Mean Time Between System Incidents-MTBSI):连续两次事故发生之间的平均间隔时间。平均系统事故间隔时间等于平均修复时间和平均无故障时间之和。这三个指标的关系如下:

ITIL4 讲解:可用性管理

具体的计算公式为:

  • 可用性(%)=(约定的服务时间-总停机时间)/约定的服务时间x 100%。
  • 可靠性:MTBSI(小时)=可用时间/中断次数
  • 可靠性:MTBF(小时)=可用时间-总停机时间/中断次数
  • 可维护性:MTTR(小时)=总停机时间/中断次数
    比如:一项全天候服务(24*7)到目前为止已经运行了5020小时,其间发生过两次中断,一次中断6小时,两一次持续14小时。那么

  • 可用性=(5020-6-14/)5020*100%=99.60%

  • 可靠性(MTBSI)=5020/2=2510小时

  • 可靠性(MTBF)=(5020-6-14)/2=2500小时

  • 可维护性(MTTR)=(6+14)/2=10小时

其实可用性主要是看系统的live time,就是一直运行了多长时间,主要是计算中断的。加入可靠性和可维护性的指标是因为,我们除了用百分比来衡量系统的运行时间,我们还有非常注意中断次数,因为系统1小时中断1次和1小时中断十次,客户的感受是完全不同的。

可用性的实施
可用性的管理,在ITIL中是有具体的方法的。其中最常用的方法之一是组件故障影响分析(CFIA)。CFIA最初是由IBM公司出于硬件设计和配置需要而在20世纪70年代首创的,但实际上,CFIA可以运用于所有IT基础架构组件,如硬件、网络、82软件、应用和用户等。此外,这种技巧还可以用于确定IT组件对IT支持部门技巧和能力的影响和依赖。其目标是可以确定系统的单点故障和组件故障对于业务的影响。

具体实施步骤为:

首先确定关键业务(VBF)的所有组成部件,可以参考该关键业务的系统框架,应该包括:平台级部件、IT部件、网络部件、数据部件、应用部件等等。
编制表格,见下:
ITIL4 讲解:可用性管理

将所有的配置项放到左边的一列中,将所有的关键业务放到顶部的一行中。
然后,对每一个配置项进行如下的评估:
a) 当配置项出故障后,不会影响到相应关键业务,则将对应的表格中留空白。

b) 当配置项出故障后,会影响到相应的关键业务,则对应的表格中插入字符“X”。

c) 当配置项出故障后,有另外的配置项替代,且关键业务不受影响,则对应的表格中插入字符“A”。

d) 当配置项出故障后,有另外的配置项替代,但是关键业务需要重新恢复,则对应的表格中插入字符“M”。

完成这个表格的制作后,对某一个关键业务来说,所有标有“X”的配置项,都有可能形成单点故障。并且从表中可以看出,每一个配置项对各个关键业务的影响程度,如下图所示。

ITIL4 讲解:可用性管理

CFIA组件故障影响分析

填写要素:

配置项:“CI”列,如“PC1”,“PC2”……
关键服务:“服务1”,“服务2”。
M:代表“配置项出故障后,有另外的配置项替代,但是关键业务需要重新恢复”。
X:代表“配置项出故障后,会影响到相应的关键业务”。
A:代表“配置项出故障后,有另外的配置项替代,且关键业务不受影响”
从这个方法的输出我们可以看出,基于CFIA,我们可以直接得到系统的拓扑图。虽然这个方法比较老,但是非常有效,直至今天,还是一个非常好用的方法。在进行组件风险分析时,我们可以使用标准的风险分析表,分析结果也可以作为多个流程的输入,如连续性管理(灾备),容量管理等。

可用性在ITIL 4的亮点
可用性在ITIL V3是纳入服务设计部分的流程,因为可用性从服务在设计阶段就应该考虑。ITIL V3中强调了其重要性,也强调了可用性的设计要基于和业务直接的协议和IT的预算成本考量,符合ITIL V3从服务的生命周期的角度来考虑。

在ITIL 4中的可用性Best Practice 中,开篇2.2.3突出描述了可用性的衡量标准。原文如下:

When defining service availability, it isessential to considerthe following:

●the criticality of business functions that are enabled by the service

●thresholds for various forms of underperformance and unavailability; for example, delays in sending or receiving e-mail may be treated as service level degradation, not service unavailability, until they reach the agreed threshold

●the number of users, business units, and/or sites that are impacted; for example, the service may only be considered unavailable if more than a certain percentage of users are impacted

●whether certain vital users, business units,sites, and so on, areimpacted; for example, for an e-mail service, it may be that, if users who need to communicate directly with customers and partners are able to use the service, the service is considered available

●the service delivery schedule and peak hours: aservice that only has outagesat night or on weekends may not be considered unavailable. 

总体而言,就是需要考虑哪些情况视为不可用。这就是本文开头部分客户的问题。

可以说,ITIL 4还是结合了目前企业运营的实际情况,融入了互联网运营的思想。基于ITIL 4的指南,我给客户的建议是,页面响应速度慢这种情况可以计入可用性的指标计算,但是我们需要考虑:

  1. 影响范围 - 什么时候才能计入

  2. 和业务部门商定“慢”的数值 - 什么指标才能计入

当我们讨论指标时,我们发现了业务指标和IT指标的关联问题。我把这个话题放入下一篇文章“业务指标<>IT指标”,敬请期待吧。