A machine's life is a cycle: it runs for MTBF, it is repaired for MTTR, and its availability is the running share of that cycle, MTBF/(MTBF + MTTR). The formula is symmetric in a way that is worth a lesson on its own — halving the repair time and doubling the time between failures produce the identical fraction — and one of the two is usually much cheaper to buy.
Core ideas
Availability has a mechanism underneath it, and the mechanism has exactly two parameters. Confusing either of them with the availability is the standard error.
MTBF is the mean time between failures and MTTR the mean time to repair, so one full cycle lasts MTBF + MTTR and the service is up for MTBF of it. The availability is that share: A = MTBF/(MTBF + MTTR). A machine that runs 1000 hours and is repaired in one is available 1000/1001 of the time, which is 99.90010%.
A(2M, R) = 2M/(2M + R) = M/(M + R/2) = A(M, R/2). That is an identity, not an approximation: halving the repair time buys exactly as much availability as doubling the time between failures. The lab draws both as bars and they are the same length. Which one to pull is then a question about cost, and repairing faster is usually the cheaper of the two.
Reliability is how rarely it breaks; availability is how much of the time it works. A machine that fails once a year and takes a day to fix is 365/366 = 99.72678% — two nines. A machine that fails every 100 hours, eighty-seven times a year, but is back in six minutes is 1000/1001 = 99.90010% — three nines. The unreliable machine is the more available one, and the user experiences availability.
The material
Where an availability comes from, why its two inputs trade off exactly, and what a target availability demands of a repair process.
For a component that alternates between working and being repaired, MTBF is the mean length of a working interval and MTTR the mean length of a repair. Over many cycles the fraction of time spent working tends to A = MTBF/(MTBF + MTTR), which is the steady-state availability.
This course takes the failure rate as constant: a component that has run for a year is no likelier to fail in the next hour than one installed this morning. That is a modelling assumption and it is wrong for anything with a wear-out mode, but it is the assumption under which MTBF is a single number rather than a curve.
For any M > 0 and R > 0, A(2M, R) = A(M, R/2).
A(2M, R) = 2M/(2M + R). Divide numerator and denominator by 2: = M/(M + R/2) = A(M, R/2).
Nothing about the sizes of M and R was used, so the equality holds everywhere, not merely for small R. The lab computes both fractions and compares them exactly; if they ever failed to agree the page would say so on its face.
□
M = 1000 h, R = 60 min gives A = 3 600 000/3 603 600 = 1000/1001 = 99.90010%, which is three nines and 8 h 45 min 4.50 s of downtime a year across 8.75 cycles. Halve the repair to 30 minutes and A becomes 2000/2001 = 99.95002%, cutting the annual downtime to 4 h 22 min 40.12 s. Double the time between failures instead and A is 2000/2001 again, to the digit.
Rearranging gives the two questions a target actually asks. MTTR = M(1 − A)/A is the repair time a target allows at the current reliability, and MTBF = R·A/(1 − A) is the reliability it would demand at the current repair time. Both are printed by the lab, and they are usually the moment a target stops being an aspiration.
Four nines on a component that fails every thousand hours means detecting, diagnosing and fixing inside six minutes, every time. Stated that way the target is a claim about paging, automation and rollback rather than about hardware, which is the useful form of it. The alternative is running 9999 hours between failures, which is a different and generally slower project.
The misconception this lesson exists to break is that a machine which rarely fails is the available one. Availability does not count failures, it counts seconds, and a rare failure that lasts a day costs more seconds than eighty-seven failures that last six minutes each. Both machines are in the lab's reach: set 8760 hours against a 1440-minute repair and then 100 hours against a six-minute one.
Machine A fails once a year and is repaired in a day: A = 365/366 = 99.72678%, 23 h 56 min 3.93 s down a year, two nines. Machine B fails every 100 hours — 87.51 times a year — and is repaired in six minutes: A = 1000/1001 = 99.90010%, 8 h 45 min 4.50 s down a year, three nines. Machine B breaks eighty-seven times as often and is down for a third as long.
Interactive
MTBF ÷ (MTBF + MTTR), and why repairing faster is the cheaper lever
Method
The target is given and the reliability is usually a fact about hardware you did not choose. That leaves one unknown, and it is the interesting one.
Seconds, for preference. MTBF quoted in hours against an MTTR quoted in minutes is the most common way to produce an availability that is wrong by a factor of sixty, and the error looks entirely plausible.
A = MTBF/(MTBF + MTTR). Leave it as a fraction: 1000/1001 is exact and carries its own sanity check, because the denominator is visibly one repair longer than the numerator.
MTTR = M(1 − A)/A for the repair time a target allows; MTBF = R·A/(1 − A) for the reliability it would otherwise demand. Compute both and compare them with what your organisation can actually do.
“Four nines” is not actionable; “detected, diagnosed and repaired within six minutes, every time, on a component that fails every thousand hours” is. If that sentence is not true of your team, the target is not either.
The reliability is given and cannot be changed this quarter. The target is three nines. The only unknown is how fast a failure has to be dealt with, and the answer is the specification for the on-call process.
The 43 minutes and 50 seconds is the whole answer: one failure a month and three nines means every failure is closed inside three quarters of an hour, including the part where somebody notices. The current three-hour repair is not close — it is two nines, and 4.09 times the annual downtime.
Note the coincidence and do not read anything into it: 43 min 50 s here and the 43 min 48 s of three nines a month are nearly the same duration for an unrelated reason, which is that this machine's MTBF happens to be one month. Change the MTBF and the two part company.
For a faded rehearsal, keep the monthly failure and ask for four nines. The supplied first move is that 1 − A falls by a factor of ten while M does not move at all. Produce the required MTTR, then answer the harder question: at a repair time your team could actually hold, what MTBF would four nines demand, and is that a hardware project or a redundancy one?
You should be able to compute A from the two lifetimes in consistent units, derive the MTTR a target allows, show that the two levers are identical rather than approximately so, and say why the machine that fails more often can be the one that is up more.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.