OpenCyber Academy
Engineering · Chapter 29 · English
Course code: OCA-127Chapter 29: OCA-127-C029

Chapter 29 — Systems, endpoints and hardware security: measurement

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Lesson map

Lesson 29 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 Measures"]
  N2["Lab — Lab — restore timing"]
  N3["29.2 Reading the result"]
  N4["29.3 Eastgate variation"]
  N5["29.4 Action"]
  N6["Why spread matters"]
  N7["Sampling"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 Measures"]
  N2["Lab — Lab — restore timing"]
  N3["29.2 Reading the result"]
  N4["29.3 Eastgate variation"]
  N5["29.4 Action"]
  N6["Why spread matters"]
  N7["Sampling"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX085"]

[Learning outcomes]
    |
    v
[29.1 Measures]
    |
    v
[Lab — Lab — restore timing]
    |
    v
[29.2 Reading the result]
    |
    v
[29.3 Eastgate variation]
    |
    v
[29.4 Action]
    |
    v
[Why spread matters]
    |
    v
[Sampling]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes

You will (1) measure restore times across branches; (2) summarise variation; (3) check against the operating window.

29.1 Measures

Restore duration per PC per night, by branch, over a week of pilot operation.

Mateo chose restore duration as the first measure because it decides whether the nightly design fits the time available. A restore that overruns the window could leave PCs unready at opening, failing an objective. Measuring by branch shows whether local conditions such as network links or older hardware change the result. A week of pilot data gives seven nights for each sampled PC. Sampled PCs cover every hardware model.

Lab — Lab — restore timing

"""Summarise synthetic nightly restore times across branches (stdlib only)."""
import statistics
t = {"Central": [6.1, 6.4, 5.9, 6.8, 7.2, 6.0, 6.3], "Eastgate": [8.9, 9.4, 9.1, 12.8, 9.0, 9.2, 9.3],
     "Millbrook": [5.2, 5.5, 5.1, 5.4, 5.3, 5.6, 5.2]}
for b, xs in t.items():
    print(f"{b:9} median {statistics.median(xs):.1f} min, max {max(xs):.1f}, stdev {statistics.stdev(xs):.2f}")
allx = [x for xs in t.values() for x in xs]
print(f"all: median {statistics.median(allx):.1f}, within 15-min window {sum(x <= 15 for x in allx)}/{len(allx)}")

Run with python3 lab_timing.py. Verified output:

Central   median 6.3 min, max 7.2, stdev 0.47
Eastgate  median 9.2 min, max 12.8, stdev 1.39
Millbrook median 5.3 min, max 5.6, stdev 0.18
all: median 6.3, within 15-min window 21/21

29.2 Reading the result

Central median 6.3 minutes (max 7.2), Eastgate median 9.2 (max 12.8, stdev 1.39), Millbrook median 5.3 (max 5.6). All 21 sampled restores finished within the 15-minute window.

The figures come straight from the lab output. Mateo reports the median and the maximum together, since the maximum shows how close the worst night came to the limit. All restores fitting the window is the result that matters for the requirement, and the spread at Eastgate is the result that matters for planning. The standard deviations show how predictable each branch is from night to night.

29.3 Eastgate variation

Eastgate is slower and more variable. Investigation finds older disks and a congested network link.

Mateo compared Eastgate's slow nights with the network supplier's records and found they matched evenings when the branch's link was busy with backups. The older disks added a steady delay on every night. Together they explain both the higher median and the wider spread. Neither problem appeared at Millbrook, which has newer disks and a quieter link. The supplier confirmed the busy periods from its own logs.

29.4 Action

Eastgate's disks are scheduled for replacement and its restore traffic is staggered.

Staggering means Eastgate's PCs start their restores in small groups a few minutes apart rather than all at once, which spreads the network load. The disk replacement is planned for a quiet week. Mateo will rerun the timing measurement after both changes to confirm the effect, and records the expected improvement in advance so the result can be judged fairly. Branch staff are told about both changes in advance.

Why spread matters

If restore times varied widely, some nights might overrun the window and leave PCs unavailable at opening. The standard deviation shows how predictable restores are. Eastgate's 1.39 minutes is much larger than Millbrook's 0.18, signalling that something there is unstable. Investigating spread often reveals hardware or network problems before they cause failures.

Mateo plots each branch's times on a simple chart for the dashboard.

Sampling

The lab uses seven nights per branch; production monitoring uses every PC every night.

Pilot setup

The pilot week runs restore on a sample of seven PCs per branch, chosen to include each hardware model. Results are collected automatically.

Communicating

Branch staff are told about the pilot and asked to report any PC problems at opening.

Linking to requirements

The 15-minute window is part of R4, so timing results also count as verification evidence.

Alert on slow restore

A restore exceeding 13 minutes triggers a warning, giving time to act before the window closes.

Repeat

Timing is re-measured monthly.

Worked example

Marta asks whether 12.8 minutes is a problem. Mateo notes it is within the window but close enough that growth could exceed it, so the fix is worthwhile.

Synthetic case. Synthetic.

Errors and limits

Medians hide outliers; report maximum and spread too.

Exercises

Synthesis

Measure spread as well as averages and act on outliers.

Continue studying — chapter 29 of 50

← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →

Worked answers

EX085. Central 6.3, Eastgate 9.2, Millbrook 5.3 minutes.

EX086. All 21.

EX087. Older disks and a congested network link.