ITIL4 讲解：可用性管理

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）：连续两次事故发生之间的平均间隔时间。平均系统事故间隔时间等于平均修复时间和平均无端障时间之和。这三个指标的关系以下：

具体的计算公式为：

• 可用性(%)=（约定的服务时间-总停机时间）/约定的服务时间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部件、网络部件、数据部件、应用部件等等。
编制表格，见下：

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

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

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

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

完成这个表格的制做后，对某一个关键业务来讲，全部标有“X”的配置项，都有可能造成单点故障。而且从表中能够看出，每个配置项对各个关键业务的影响程度，以下图所示。

CFIA组件故障影响分析

填写要素：

配置项：“CI”列，如“PC１”，“PC２”……
关键服务：“服务１”，“服务２”。
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指标”，敬请期待吧。