6.6.2 Faultlessness measures

What this heading covers

A failure count without exposure is not comparable. Exposure can be time, transactions, users or sessions, and the right unit depends on the product. The draft separates faultlessness from availability because a product can be unavailable for reasons other than failure, such as planned maintenance, and can fail without becoming unavailable if it recovers. The measure should use a written failure definition and a severity scale, and it should name the window.

Record position: family 17 of 40 in clause 6, under 6.6 Reliability, which carries 4 families. It is one of the 40 families a programme has to map its measures to, and its elements are listed below. The heading is 6.6.2 in the public contents; the text behind it is not public.

How a measure for this family is built

Divide the number of failures by the exposure: failures per thousand hours of operation, per million transactions, or per hundred users. State the severity threshold that counts. A rate is comparable across releases; a raw count is not. If the product is new, use test exposure and label it as such.

What to put in place before publication

1. Write the failure definition and the severity scale before collecting.
2. Report the exposure with the rate, and keep the raw failures.

Evidence to keep

Two questions to ask

• What is the failure definition and the severity threshold?
• What exposure produced these failures, and over what window?

Where teams usually fall short

• A defect count from a tracker that mixes customer failures with internal test findings.

What the number cannot tell you

It cannot tell you how long a failure lasted. A short outage and a long one count the same in a failure rate.

What happens next

Availability adds the time dimension. Read the two together before reporting either.