Chapter 14 — Web3, blockchain and cryptoasset security: automation
Lesson map
Lesson 14 published. Map, example, EX053.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Choosing what to automate"]
N2["14.2 Scheduling and reporting"]
N3["14.3 Keeping people in control"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX053"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Choosing what to automate"]
N2["14.2 Scheduling and reporting"]
N3["14.3 Keeping people in control"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX053"]
[Learning outcomes]
|
v
[14.1 Choosing what to automate]
|
v
[14.2 Scheduling and reporting]
|
v
[14.3 Keeping people in control]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX053]
Learning outcomes
You will (1) automate routine checks safely; (2) schedule and report results; (3) keep people in control of changes.
14.1 Choosing what to automate
Aiko automates checks she runs repeatedly: node height comparison, configuration comparison, backup digest and age, reconciliation of releases against returns, and matching privileged events to approved changes. She chooses these because they are frequent, rule-based and read-only. She does not automate actions such as pausing or changing settings, because those need human judgement and approval. Automation is most valuable for checks that people would otherwise skip when busy, and least appropriate for decisions that carry real risk if made wrongly.
14.2 Scheduling and reporting
Each check runs on a schedule on the monitoring server and writes results to a dated log. A morning summary email lists anything needing attention, with links to details. Urgent findings, such as an unapproved role change, send an immediate alert to the duty technician. Aiko names who reads the summary each day. She tests each scheduled check with seeded problems in the test environment before relying on it. Mr Kowal warns that automated reports nobody reads are worse than none, because they create false confidence.
14.3 Keeping people in control
All automated checks are read-only. When a check finds a problem, a person decides what to do and makes changes through the change process. Aiko documents each check's purpose, inputs, schedule and owner, and keeps the scripts in version control with peer review. She also adds a heartbeat: if a check does not run, an alert is sent. This prevents silent failure of the automation itself. People remain responsible for decisions, while automation ensures that the information they need arrives reliably and on time.
Worked example
Aiko automates five read-only checks with a morning summary, immediate alerts for unapproved role changes and a heartbeat for missed runs.
Synthetic case. The automation is synthetic.
Errors and limits
Automating risky actions like pausing removes the human judgement they require.
Exercises
- EX053 — Automation criteria. Why were these checks chosen for automation? Rubric: 3 = frequent, rule-based and read-only;; 2 = routine;; 1 = random;; 0 = none.
- EX054 — Not automated. Which actions are not automated? Rubric: 3 = pausing or changing settings;; 2 = risky actions;; 1 = reporting;; 0 = none.
- EX055 — Urgent alert example. What sends an immediate alert? Rubric: 3 = an unapproved role change;; 2 = role change;; 1 = normal transfers;; 0 = none.
- EX056 — Heartbeat purpose. What does the heartbeat detect? Rubric: 3 = a check that fails to run;; 2 = silent automation failure;; 1 = slow blocks;; 0 = none.
Synthesis
Read-only automation with named readers and heartbeats supports human decisions.
Continue studying — chapter 14 of 18
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →