Chapter 13 — Human factors and cyber policy: troubleshooting
Lesson map
Lesson 13 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["13.1 The problem"]
N2["13.2 Separating causes"]
N3["13.3 Fixes and prevention"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 The problem"]
N2["13.2 Separating causes"]
N3["13.3 Fixes and prevention"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes]
|
v
[13.1 The problem]
|
v
[13.2 Separating causes]
|
v
[13.3 Fixes and prevention]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) diagnose problems in the reporting service; (2) separate technical and human causes; (3) fix causes and prevent recurrence.
13.1 The problem
Two months after launch, reports from South depot terminals stop. Priya investigates. The terminal form still exists, but submissions fail silently because a network change blocked the form's server. Workers who tried to report saw no error and assumed it worked, so nobody raised a problem. Meanwhile, the IT lead had noticed the drop but assumed South simply had fewer suspicious messages. Priya checks the mail filter logs and confirms that South received a normal number of malicious messages during the period.
13.2 Separating causes
Priya separates causes. The technical cause was the network change, made without a test of dependent services. The design cause was that the form showed no confirmation, so failures were invisible to users. The human cause was that a drop in reports was interpreted as good news without checking. Each cause needs its own fix. Treating only the technical cause would leave the service vulnerable to the next silent failure, whatever its source, and would miss the lesson about interpreting data.
13.3 Fixes and prevention
Priya and the IT lead fix all three causes. The network change is corrected and added to a checklist of services to test after changes. The form now shows a confirmation number when a report is received and an error message if it fails. A weekly check compares reports with malicious messages delivered for each depot and flags any depot where reports fall sharply. She records the incident in the troubleshooting log. The weekly check would have caught the South problem within days.
Worked example
Priya traces a South depot reporting drop to a network change, a missing confirmation and a misread metric, and fixes all three.
Synthetic case. The incident is synthetic.
Errors and limits
Weekly checks need attention. Checklists can be skipped.
Exercises
- EX049 — Silent failure. Why did workers not notice the failure? Rubric: 3 = the form showed no error or confirmation;; 2 = silent;; 1 = vague;; 0 = none.
- EX050 — Misread drop. How did the IT lead misread the drop? Rubric: 3 = as fewer suspicious messages;; 2 = good news;; 1 = vague;; 0 = none.
- EX051 — Form fix. What does the form now show? Rubric: 3 = a confirmation number or an error;; 2 = feedback;; 1 = vague;; 0 = none.
- EX052 — Weekly check. What does the weekly check compare? Rubric: 3 = reports with malicious messages delivered per depot;; 2 = ratio;; 1 = vague;; 0 = none.
Synthesis
Troubleshooting finds technical, design and human causes, and prevention needs all three fixed.
Continue studying — chapter 13 of 18
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →