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指標」，敬請期待吧。