在電信和可靠性理論中，可用性是指：
系統，子系統，或者設備在開始一項任務時處在指定的可操作或可提交狀態的程度，這項任務什麼時候被用到是未知的，例如，是隨機的。簡單的說，可用性就是一個系統處在可工作狀態的時間的比例。這通常被描述爲任務可行率。數學上來講，相當於1減去不可用性。
在一個給定的時間間隔內，對於一個功能個體來講，總的可用時間所佔的比例。
例如，一個一週裏（168小時）有100小時可用的單元的可用性爲100/168。可用性的值通常用小數來表示（如0.9998）。在高可用性的應用中，使用一個被稱爲幾個九的度量，對應小數點後9的個數。在這個系統中，“五個九”相當於0.99999（或者99.999%）的可用性。
例子
如果我們使用的設備的MTBF(平均故障間隔)爲81.5年，MDT(平均修復時間)爲1小時：
MTBF in hours = 81.5*365*24=713940
Availability= MTBF/(MTBF+MDT) = 713940/713941 =99.999859%
Unavailability = 0.000141%
每年每設備的當機時間以小時計爲： U=0.01235 小時每年。
==============================================================
ISO9241/11中的定義是：一個產品可以被特定的用戶在特定的境況中，有效、高效並且滿意得達成特定目標的程度(The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.)。
GB/T3187-97對可用性的定義：在要求的外部資源得到保證的前提下，產品在規定的條件下和規定的時刻或時間區間內處於可執行規定功能狀態的能力。它是產品可靠性、維修性和維修保障性的綜合反映。
==============================================================
下面是一個可用性的圖例，在不同的可用性標準下，每年允許的宕機時間，每月允許的宕機時間和每週允許的宕機時間。
==============================================================
延展知識
RPO（Recovery Point Object）
指一個過去的時間點，當災難或緊急事件發生時，數據可以恢復到的時間點。例如每天23:00進行數據備份，那麼如果今天發生了宕機事件，數據可以恢復到的時間點（RPO）就是昨天的23:00。
(對比RTO，恢復時間目標，是指宕機發生後多長時間要恢復運行。)
短時間的RPO能夠更少地丟失數據。例如，一個五分鐘的RPO表明必須在五分鐘內恢復數據，而一個一小時的RPO表明這種數據恢復的弱點在於，在這一個小時內，要備份的數據可能已經丟失了。相反地，一個零分鐘的RPO表明沒有數據可以丟失，因爲您的數據及時地備份、複製或記錄下來，從而阻止任何數據的丟失。RPO要考慮的另外一個層面是數據的保護要完整和全面到什麼程度。例如：您的RPO如果每隔8小時備份一次的話，意味着這8個小時內數據可能會丟失。完全和全面的數據保護注重的是您的數據是否100%的被保護起來或者說只有部分的文件和數據被保護起來。再舉一例，打開的文件可能不能被完全的備份，除非內存裏面的緩存中的數據存儲到了磁盤裏。另外還要考慮的因素是您所要備份的文件是否是某個特殊的目錄或文件共享中的某種特定文件，以及數據是否完全備份下來了。小的RPO意味着要付出更多的費用以及更少的數據丟失量，我們必須在這之間作一個權衡。
簡單來說：就是故障發生時，允許的最大數據丟失。
RTO：（RecoveryTime Object）是指災難發生後，從IT系統宕機導致業務停頓之刻開始，到IT系統恢復至可以支持各部門運作，業務恢復運營之時，此兩點之間的時間段稱爲RTO。
簡單來說：就是故障發生時允許的最大宕機時間，通常表示爲數字，例如9s。
目標越高，成本越高。
=================================================================
The Myth of the 9’s of Availability
It is common for organizations to state that they provide a number of 9’s of availability when referring to their environments. The truth is often much different than what is advertised and even then, it is often meant for only operating hours or not counting planned downtime, which may not be clearly documented in the SLA. Committing to only business hours and unplanned outages is acceptable as long as it is supported by what is documented in the SLA.
Note: Microsoft recommends that the 9’s of availability are based on agreed upon hours of operation, which should be clearly stated in the SLA.
The table on the slide above outlines the 9’s of availability and what actually means to have that level of uptime. Based on the table above, if an organization claims to have 3 – 9’s of availability and they are a 24/7 operation, they can only have 8.76 hours of downtime per year.
Additional resources
The table above provides only a brief idea of availability impact and understanding high availability for operations. For more information, refer to the following Microsoft Operations Framework (MOF) resources:
Microsoft Operations Framework – SLA Review –
http://www.microsoft.com/technet/solutionaccelerators/cits/mo/mof/omr/sla.mspx
High Availability and the Microsoft Operations Framework –
http://technet.microsoft.com/en-us/library/aa560207.aspx
=================================================================