Chapter 17 — Control and feedback basics
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Feedback"]
N2["17.2 Configuration as control"]
N3["17.3 Delay"]
N4["17.4 Over-correction"]
N5["17.5 Monitoring the loop"]
N6["Stability"]
N7["Measuring loop health"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Feedback"]
N2["17.2 Configuration as control"]
N3["17.3 Delay"]
N4["17.4 Over-correction"]
N5["17.5 Monitoring the loop"]
N6["Stability"]
N7["Measuring loop health"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Feedback]
|
v
[17.2 Configuration as control]
|
v
[17.3 Delay]
|
v
[17.4 Over-correction]
|
v
[17.5 Monitoring the loop]
|
v
[Stability]
|
v
[Measuring loop health]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) describe feedback loops; (2) apply them to configuration and restore; (3) avoid unstable responses.
17.1 Feedback
A feedback loop measures a system's state, compares it with a target and acts to reduce the difference. A thermostat is the classic example.
The thermostat measures temperature, compares it with the setting and switches the heating on or off. Every loop has those parts: a sensor, a target, a comparison and an action. Mateo uses the thermostat to explain the restore design to librarians, because everyone has met one and knows what happens when its sensor breaks. Mateo then names each part for the restore loop.
17.2 Configuration as control
The nightly restore is a feedback loop: measure (compare with the golden image), compare (detect differences) and act (restore).
Strictly, the restore does not need to find differences before acting; it resets the patron area whatever its state. The comparison with the manifest still matters, because it measures how far each PC drifted during the day and confirms the reset worked. Mateo keeps both: the restore acts, and the check afterwards measures. Without the measurement, Fernhill would know the restore ran but not whether it succeeded.
17.3 Delay
Loops with long delays let problems grow before correction. Fortnightly manual clean-ups had a 14-day delay; nightly restore has one day.
The exposure calculation earlier in the course is a measure of the same thing: the longer the delay, the larger the area under the curve. Shortening the delay from a fortnight to a day reduces exposure by roughly the ratio of the two. Further shortening, such as restoring after every session, would cut exposure again but would need more time between patrons, which branch managers rejected.
17.4 Over-correction
Aggressive loops can cause disruption, such as restoring during a patron's session. The restore runs after closing time to avoid this.
Mateo considered restoring after each logoff and rejected it for now: a full restore takes several minutes, and patrons queue for PCs at busy times. A lighter clean-up of the patron profile at logoff, with the full restore overnight, gives most of the benefit without the queue. Any change to the restore timing is tested at one branch first, because a loop that disrupts service soon loses staff support.
17.5 Monitoring the loop
The loop itself must be monitored: if restores fail silently, the system drifts.
Mateo's morning report lists every PC whose restore did not finish successfully, and staff check that list before opening. A PC that has not reported at all is listed too, since silence may mean the restore never started. Counting failures each night also feeds the incident alert. Without these checks, a broken restore would leave the PC carrying yesterday's files while everyone believed it was clean. The report reaches staff before eight.
Stability
A control loop should correct problems without causing new ones. If the restore loop ran too often, it might interrupt patrons; if too rarely, problems accumulate. Nightly after closing balances both. Mateo also adds a guard: if five or more PCs fail restore in one night, the system stops releasing new images until IT investigates, preventing a bad update from repeatedly breaking PCs.
This guard links the probability work in chapter 7 to operations.
Measuring loop health
The loop's health is measured by restore success rate and time to repair failures.
Feedback beyond restore
Patching, allowlist reviews and baseline updates are also feedback loops with different delays: monthly, weekly and yearly.
Delays elsewhere
A month-long patch cycle is a slower loop, acceptable because updates are tested before release.
Worked example
Mateo sketches the loop and adds a second loop: if restore fails, alert staff, who repair the PC before opening. This nested loop handles failures of the first.
Synthetic case. Synthetic.
Errors and limits
A control loop that is not monitored can fail without anyone noticing.
Exercises
- EX049 — Loop steps. Name the three steps of the restore loop. Rubric: 3 = measure, compare, act; 2 = two; 1 = one; 0 = none.
- EX050 — Delay effect. How does delay affect a loop? Rubric: 3 = problems grow before correction; 2 = partial; 1 = vague; 0 = none.
- EX051 — Nested loop. What does the second loop do? Rubric: 3 = alert on failed restore, repair before opening; 2 = partial; 1 = vague; 0 = none.
Synthesis
Treat restore as a monitored feedback loop.
Continue studying — chapter 17 of 50
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →