In my research, I have found two conflicting definitions of 'availability' as it relates to software engineering and architecture. According to [1]:
"The availability of a system can be calculated as the probability that it will provide the specified services within required bounds over a specified time interval. When referring to hardware, there is a well-known expression used to derive steady-state availability:
MTBF/(MTBF+ MTTR)
where MTBF refers to the mean time between failures and MTTR refers to the mean time to repair. In the software world, this formula should be interpreted to mean that when thinking about availability, you should think about what will make your system fail, how likely that is to occur, and that there will be some time required to repair it."
However according to [2]:
"Availability is normally expressed as a ratio or percentage of the time that the service or service component is actually available for use by the customer to the agreed time that the service should be available. Availability is a combination of maturity (which reflect the frequency of failure), fault tolerance, and recoverability (which reflects the length of downtime following each failure). This concerns the start and finish (execution) of the application, the processing at the correct times and in the correct order, the execution of incidental processing, the opening times of online processing, and the storage period of files."
So which is correct? Source 1 is actually endorsed under the architecture section of the IEEE SWEBOK v3, so it has to be considered canonical. However, the ISO/IEEE standard is also canonical. So is availability calculated using the mean time to failure over the mean time to failure plus the mean time to repair? or a simple ratio of uptime versus agreed/target uptime?
1 - Bass, Len, et al. “Understanding Quality Attributes” Software Architecture in Practice. Third ed., Pearson Education, Inc., 2012. p. 98
2 - ISO/IEC/IEEE 24765:2017(E) 3.313 "availability"
There is a small incongruity between the definitions.
To give an example of how these two definitions can differ, consider a hypothetical company which takes down it’s servers for 8 hours every Tuesday in order to do maintenance which is accounted for in their SLA. Otherwise the system is supposed to be up.
7 days in a week * 24 Hours in a day * 60 Minutes in an Hour = 10080 minutes a week
8 Hours of downtime * 60 Minutes in an Hour = 480 minutes.
10080 – 480 = 9600.
The company promises 9600 minutes of uptime a week.
However in addition to the scheduled downtime the system occasionally crashes. Assume it crashes 20 times a week and takes 4.81 minutes to restart each time.
(24x7) MTBF = 10080 minutes a week / 20 crashes a week = 504 MTBF in minutes
(SLA) MTBF = 9600 minutes a week / 20 crashes a week = 480 MTBF in minutes
504/ (504+4.81) = ~0.99054656944 = ~99.0547%
480/ (480+4.81) = ~0.99007858748 = ~99.0079%
However using the second formula its based on AGREED uptime is a simple percentage of uptime versus downtime.
20 crashes a week * 4.81 minutes = 96.2 minutes of downtime.
(9600-96.2)/9600 = ~0.98997916666 = ~98.9979% uptime
So imagine a client or customer sues the provider saying they promised “2 nines” of uptime in the SLA, while arguing using the latter definition that they only are providing one nine of uptime.
I’ll agree this is an unlikely edge case that becomes even less likely if we calculate MTBF to include scheduled downtime (which it usually doesn’t) but one could imagine a legal case (ex: breach of SLA) hinging upon this.
