OpenCyber AcademyLesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Feedback in operations"]
N2["17.2 Thresholds"]
N3["17.3 Oscillation"]
N4["17.4 Human loop"]
N5["Measuring the loop"]
N6["Stability of automated controls"]
N7["Learning from incidents"]
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 in operations"]
N2["17.2 Thresholds"]
N3["17.3 Oscillation"]
N4["17.4 Human loop"]
N5["Measuring the loop"]
N6["Stability of automated controls"]
N7["Learning from incidents"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Feedback in operations]
|
v
[17.2 Thresholds]
|
v
[17.3 Oscillation]
|
v
[17.4 Human loop]
|
v
[Measuring the loop]
|
v
[Stability of automated controls]
|
v
[Learning from incidents]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) describe feedback loops in network operations; (2) tune thresholds; (3) avoid oscillation.
17.1 Feedback in operations
Monitoring, alerts and changes form a feedback loop: observe, decide, act, observe again.
Operations form a feedback loop: monitoring measures the network, people or automation compare measurements with targets, and actions adjust the system. A good loop corrects problems quickly and steadily. A poor one reacts too slowly, so problems grow, or too aggressively, so corrections cause new problems. Seeing operations as feedback helps engineers design alert rules and automated responses that keep the network stable rather than chasing noise.
17.2 Thresholds
Alert thresholds set when action happens. Too low creates noise; too high misses problems.
A threshold turns a continuous measurement into a decision, such as alerting when link utilisation exceeds 85 percent for five minutes. Set too low, thresholds produce constant alerts that staff learn to ignore; set too high, they miss real problems. Engineers choose thresholds from measured normal behaviour, add a duration condition to avoid reacting to brief spikes, and review them periodically as traffic patterns change.
Each threshold has a documented owner.
17.3 Oscillation
Automatic responses, such as blocking sources, can oscillate if they react too quickly. Damping, such as minimum durations, helps.
Oscillation happens when a control loop overcorrects repeatedly, such as traffic shifting back and forth between two links as each in turn becomes busy. It wastes capacity and makes behaviour unpredictable. Remedies include hysteresis, using different thresholds for switching on and off, and adding delay before acting again. Engineers watch for oscillation whenever an automated response feeds back into the measurement that triggers it.
17.4 Human loop
Most council responses involve humans; clear runbooks reduce delay in the loop.
Many network responses keep a person in the loop: an alert is raised, an operator investigates, and decides on action. People add judgement but also delay and fatigue. Engineers design alerts that give the operator enough context to decide quickly, document runbooks for common cases, and limit alert volume so attention stays on what matters. Measuring time from alert to action shows whether the human part of the loop is working.
Measuring the loop
A feedback loop can be measured. Kofi defines the time from an event, such as a burst of denied connections, to an alert, from alert to acknowledgement by an analyst, and from acknowledgement to action. Each interval points to a different improvement: faster detection, better on-call arrangements or clearer runbooks. Measuring these intervals during exercises shows where the council's response is slowest, which is usually acknowledgement outside office hours rather than detection itself. Repeating the measurement after each improvement shows whether the change actually shortened the slowest interval.
Stability of automated controls
Some network controls adjust automatically, such as rate limits that tighten when traffic surges. Poorly designed automation can amplify problems: a rate limit that blocks a busy service causes retries, which increase traffic, which tightens the limit further. Kofi avoids automatic blocking in the council design except for clearly defined cases, and where automation is used, he requires limits on how often it can act and an alert to humans whenever it does, so people stay in control of significant changes.
Learning from incidents
Each incident is a chance to adjust the loop. After an event, the team reviews whether alerts fired, whether thresholds were right and whether runbooks helped. Adjustments are recorded as changes like any other. Over time this tunes the monitoring to the council's actual network rather than generic defaults, which is the same principle as control engineering: a system is tuned by observing its response and correcting. Reviews are blameless, focusing on how the system and process can improve rather than on who made a mistake.
Worked example
A rate alert at 100 denies per minute fires constantly from guest; raising it to 300 and grouping by source reduces noise.
Synthetic case. Figures are synthetic.
Errors and limits
Automated blocking without damping can cut off legitimate services.
Exercises
- EX049 — Threshold trade-off. Describe the threshold trade-off.
Show marking criteria
Rubric: 3 = noise vs misses;; 2 = one;; 1 = vague;; 0 = none. - EX050 — Damping. Give an example of damping.
Show marking criteria
Rubric: 3 = minimum block duration or hold-off;; 2 = example;; 1 = vague;; 0 = none. - EX051 — Runbook role. How do runbooks affect the feedback loop?
Show marking criteria
Rubric: 3 = reduce human delay;; 2 = faster;; 1 = vague;; 0 = none.
Synthesis
Feedback thinking helps design stable monitoring and response.
Continue studying — chapter 17 of 50
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →