Architecture Security & Reliability

availability

Think of a shop. What customers care about is simple: when I walk up, is it open and able to serve me? Availability is that fraction — the share of time a system is up and ready to do its job. We hear it as 'four nines' or 'five nines', shorthand for 99.99 percent or 99.999 percent of the time available. The difference sounds tiny but matters enormously: 99.9 percent allows almost nine hours of downtime a year, while 99.999 percent allows only about five minutes.

The standard formula ties availability to two times. If MTBF is the mean time between failures (how long it usually stays up) and MTTR is the mean time to repair (how long it is down each time), then availability = MTBF / (MTBF + MTTR). The key insight hides in plain sight: you can raise availability either by failing less often (bigger MTBF) or by recovering faster (smaller MTTR). A system that fails often but heals in a second can still be extremely available, which is why fast automatic failover and quick restarts are such powerful tools.

Be honest about what availability does and does not promise. High availability does not mean nothing ever breaks — it means breakage is rare or brief. It also says nothing about whether the answers are correct: a system that is up but returning wrong results scores well on availability and badly on dependability (see dependability). And the 'nines' multiply when systems depend on each other: a service built from two components each available 99.9 percent of the time, both required, is only about 99.8 percent available overall. Real-world high availability is engineered with redundancy so that one failure does not take down the whole.

A server fails on average once every 1,000 hours (MTBF = 1,000 h) and takes 1 hour to restart each time (MTTR = 1 h). Its availability is 1000 / (1000 + 1) = 0.999, or 99.9 percent — about 8.8 hours of downtime per year. Cut the repair to 6 minutes (0.1 h) and availability jumps to 1000 / 1000.1 = 99.99 percent.

Faster repair (smaller MTTR) raises availability just as surely as failing less often does.

Availability is not correctness. A box that is 'up' but serving wrong answers looks perfect on an availability chart and terrible on dependability; never report uptime as if it were a guarantee of right results.

Also called
uptime可用性上線率