在电信和可靠性理论中，可用性是指：

系统，子系统，或者设备在开始一项任务时处在指定的可操作或可提交状态的程度，这项任务什么时候被用到是未知的，例如，是随机的。简单的说，可用性就是一个系统处在可工作状态的时间的比例。这通常被描述为任务可行率。数学上来讲，相当于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

=================================================================