Chapter 32 — Systems, endpoints and hardware security: reliability
Lesson map
Lesson 32 published. Map, example, EX094.
flowchart TD
N0["Learning outcomes"]
N1["32.1 Data"]
N2["Lab — Lab — availability"]
N3["32.2 Reading the result"]
N4["32.3 Meaning"]
N5["32.4 Assumptions"]
N6["Definitions"]
N7["Measuring after"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX094"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["32.1 Data"]
N2["Lab — Lab — availability"]
N3["32.2 Reading the result"]
N4["32.3 Meaning"]
N5["32.4 Assumptions"]
N6["Definitions"]
N7["Measuring after"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX094"]
[Learning outcomes]
|
v
[32.1 Data]
|
v
[Lab — Lab — availability]
|
v
[32.2 Reading the result]
|
v
[32.3 Meaning]
|
v
[32.4 Assumptions]
|
v
[Definitions]
|
v
[Measuring after]
|
v
[Worked example] --> [Exercise EX094]
Learning outcomes
You will (1) calculate availability and MTBF; (2) compare before and after self-restore; (3) interpret reliability figures.
32.1 Data
In a month, 42 PC failures occurred across 300 PCs. Before self-restore, each took about 18 hours to fix manually; after, about half an hour.
The forty-two failures are the baseline month's figure from the start of the project. Before self-restore, a failed PC waited for the technician's next visit to its branch and then needed manual cleaning, which explains the long repair time. After self-restore, most failures clear at the next restore or with a single rerun at the morning check. Mateo takes both repair times from Fernhill's job records rather than estimating them.
Lab — Lab — availability
"""Availability of the public PC service from synthetic failure and repair data (stdlib only)."""
pcs, hours = 300, 24*30
failures, mttr_before, mttr_after = 42, 18.0, 0.5
for label, mttr in (("before self-restore", mttr_before), ("after self-restore", mttr_after)):
down = failures * mttr
print(f"{label}: downtime {down:.0f} PC-hours, availability {1 - down/(pcs*hours):.4f}")
print(f"MTBF per PC {pcs*hours/failures:.0f} hours")
Run with python3 lab_avail.py. Verified output:
before self-restore: downtime 756 PC-hours, availability 0.9965
after self-restore: downtime 21 PC-hours, availability 0.9999
MTBF per PC 5143 hours
32.2 Reading the result
Downtime falls from 756 to 21 PC-hours; availability rises from 0.9965 to 0.9999. MTBF per PC is about 5,143 hours.
The availability figures look close because both are near one; the downtime in PC-hours shows the real difference much more clearly. Seven hundred and fifty-six PC-hours is like having about a full PC out of service for every working hour of the month. Mateo reports the downtime first for that reason, with availability as a secondary figure. MTBF depends only on the failure count, so it is the same before and after.
32.3 Meaning
Fewer PCs out of service means patrons wait less and staff handle fewer complaints.
At busy times every working PC has a queue, so each PC out of service makes waits longer for everyone. Librarians also spend less time explaining out-of-order signs and calling IT. Mateo connects the downtime figure to the third objective, PCs ready at opening, and to the fourth, less manual effort, since each repair avoided is staff time saved. The result is easier for the board to value than the availability ratio.
32.4 Assumptions
Failure count is assumed unchanged; self-restore may also reduce failures, which would further improve results.
Keeping the failure count fixed isolates the effect of faster repair. In practice, the nightly restore probably prevents some failures as well, such as those caused by unwanted software slowing a PC down. If so, the true improvement is larger than the estimate. Mateo states the assumption plainly so that nobody reads the result as a measured outcome, and plans to measure both failures and repair times after deployment.
Definitions
Availability is the share of time a service is usable: one minus downtime divided by total time. MTBF, mean time between failures, is total operating time divided by the number of failures. MTTR, mean time to repair, is average repair time. Availability improves by reducing failures (raising MTBF) or speeding repair (lowering MTTR). Self-restore mainly lowers MTTR, because a PC that misbehaves is fixed overnight automatically instead of waiting for a technician.
Mateo explains these terms on one slide for the board.
Measuring after
Three months after deployment, the team will measure actual failures and repair times to check the estimate.
Patron view
From a patron's view, availability means fewer "out of order" signs.
Board reporting
The board receives the downtime figure quarterly.
Uncertainty
The 42-failure figure comes from one month; another month might differ. Mateo presents the result as an estimate to be checked against three months of data.
Linking
Availability links to objective O3.
Format
Figures appear with units.
Worked example
The board asks for one number. Mateo offers "downtime fell from 756 to 21 PC-hours a month", which is concrete and understandable.
Synthetic case. Synthetic.
Errors and limits
Availability figures with four decimals can look more precise than data support.
Exercises
- EX094 — Downtime. Give downtime before and after. Rubric: 3 = 756 vs 21 PC-hours; 2 = partial; 1 = vague; 0 = none.
- EX095 — Availability. Give availability before and after. Rubric: 3 = 0.9965 vs 0.9999; 2 = partial; 1 = vague; 0 = none.
- EX096 — MTBF. What is MTBF per PC? Rubric: 3 = ~5,143 hours; 2 = partial; 1 = vague; 0 = none.
Synthesis
Reliability figures show operational value in concrete terms.
Continue studying — chapter 32 of 50
← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →