Chapter 20 — Human factors and cyber policy: troubleshooting | Technologist Human factors and cyber policy

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

Chapter 20 — Human factors and cyber policy: troubleshooting

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 A sudden drop"]
  N2["20.2 Separating causes"]
  N3["20.3 Root causes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX058"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["20.1 A sudden drop"]
  N2["20.2 Separating causes"]
  N3["20.3 Root causes"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 A sudden drop]
    |
    v
[20.2 Separating causes]
    |
    v
[20.3 Root causes]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) troubleshoot problems in the reporting service; (2) separate technical from human causes; (3) fix root causes rather than symptoms.

20.1 A sudden drop

In month seven, reports from three clinics fall almost to zero. Lucas investigates. He checks whether attacks fell, but filtering logs show normal volume. He visits one clinic and finds the report button missing after a software update reset the toolbar. Staff assumed it had been removed deliberately and did not ask. The technical cause was the update; the human cause was uncertainty about whether reporting was still wanted. He checks the other two clinics and finds the same problem on every reception computer there.

20.2 Separating causes

Lucas lists both causes. Technically, the update process does not check add-ins. Humanly, staff had no easy way to tell IT that something looked wrong with the tool. He also checks another clinic where reports fell modestly and finds a different cause: a new receptionist had not been told about reporting. Separating causes prevents a single fix being applied to problems with different origins, which would leave some of them unresolved. He writes both causes in the log so that each has its own fix and owner.

20.3 Root causes

Lucas fixes root causes. The IT contractor adds a post-update check that the button exists on every computer. The thank-you message now includes a line inviting staff to tell IT if the button disappears. Induction for new staff includes reporting. He records the incident and fixes in the troubleshooting log. Marta notes that fixing only the button would have left the next update to cause the same problem, and that inviting feedback creates an early warning system. The log is reviewed quarterly.

Worked example

Lucas traces a reporting drop to a toolbar reset and staff uncertainty, separates causes at two clinics and fixes root causes.

Synthetic case. The incident is synthetic.

Errors and limits

Visits take time. Checks may miss other add-ins.

Exercises

EX058 — Drop cause. What caused the reporting drop at three clinics? Rubric: 3 = an update reset the toolbar and removed the button;; 2 = update;; 1 = fewer attacks;; 0 = none.
EX059 — Second clinic cause. What caused the modest drop at another clinic? Rubric: 3 = a new receptionist was not told about reporting;; 2 = induction;; 1 = vague;; 0 = none.
EX060 — Post-update check. What does the contractor now do after updates? Rubric: 3 = check that the button exists on every computer;; 2 = check;; 1 = vague;; 0 = none.

Synthesis

Troubleshooting separates technical and human causes and fixes roots, not symptoms.

Continue studying — chapter 20 of 30

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →