The 9s
Specifying availability requirements is not as simple as the often quoted "99.999% availability." In its simplest form, the 9s is an indication of how much downtime an application is allowed to incur.
The following table shows that each additional 9 drops the amount of time the application could be down for by an order of magnitude:
| Percentage Uptime | Percentage Downtime | Amount of Downtime Each Year | Amount of Downtime Each Month |
|---|---|---|---|
| 98.0% | 2% | 7.3 days | 14.6 hours |
| 99.0% | 1% | 3.7 days | 7.3 hours |
| 99.8% | 0.2% | 17.5 hours | 1.5 hours |
| 99.9% | 0.1% | 8.8 hours | 43.8 minutes |
| 99.99% | 0.01% | 52.6 minutes | 4.4 minutes |
| 99.999% | 0.001% | 5.3 minutes | 26.3 seconds |
| 99.9999% | 0.0001% | 31.5 seconds | 2.6 seconds |
Therefore, specifying that a system have 99.999% availability means that the system can be down for less than 5.3 minutes in a year.
Problem with the 9s
The problem with using the 9s as a requirements is that not all outages are the same. In fact, some customers could architect their solution to tolerate a certain level or type of outage. For example, a customer can integrate the customer-facing Web site to Sterling Order Management System Software, using asynchronous messages. With this architectural pattern, Sterling Order Management System Software can be taken offline for maintenance (such as upgrades) without impacting the services provided by the Web site.
The use of the 9s also does not account for the different strategies or level of availability of certain workloads. For example, during failures, customers may want to consider shutting down lower-priority workloads.
In general, if architected correctly, the Sterling Order Management System Software, which is typically used as a backroom order processing engine, does not have high availability requirements. In contrast, some applications, for example, Internet facing applications, have very high availability requirements because they are customer facing.