Chapter 26 — Web3, blockchain and cryptoasset security: operational handoff
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Preparing for handoff"]
N2["26.2 Writing runbooks"]
N3["26.3 Transferring knowledge"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Preparing for handoff"]
N2["26.2 Writing runbooks"]
N3["26.3 Transferring knowledge"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Preparing for handoff]
|
v
[26.2 Writing runbooks]
|
v
[26.3 Transferring knowledge]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) prepare systems for handoff; (2) document runbooks; (3) transfer knowledge to operators.
26.1 Preparing for handoff
The makerspace plans for its volunteers to run the ledger operations day to day, with Lucas available for escalation. He prepares a handoff package: system diagram, asset inventory, control owners, monitoring guide, runbooks, credential locations (not the credentials themselves) and open issues. He checks that every automated check has a named reader and every runbook has been tested. A system is ready for handoff when someone else can run it safely without the original builder present, which is a higher standard than simply working while the builder watches.
26.2 Writing runbooks
Runbooks give step-by-step instructions for common tasks and problems: restarting a node, responding to lag, handling an unmatched privileged event, rotating a service credential, replacing a lost signer device and restoring from backup. Each runbook starts with when to use it, lists steps with expected results, and ends with how to confirm success and whom to inform. Lucas writes them in plain language and has a volunteer follow each on the test ledger. Two steps are unclear and he rewrites them. Tested runbooks work under pressure; untested ones often fail at the worst moment.
26.3 Transferring knowledge
Lucas runs three short sessions for volunteers: an overview of the system, a walk-through of the monitoring dashboard and a practice drill responding to a seeded lagging node. Volunteers ask questions he had not considered, which he adds to a frequently asked questions page. He shadows the volunteers for two weeks, intervening only when needed. Knowledge transfer is complete when volunteers handle routine work confidently and know when to escalate. The manager signs off the handoff, and Lucas moves to an advisory role for the remainder of the course.
Worked example
Lucas hands off with a tested runbook set, three training sessions and two weeks of shadowing before the manager signs off.
Synthetic case. The handoff and sessions are synthetic.
Errors and limits
Handing off untested runbooks leaves operators with instructions that fail under pressure.
Exercises
- EX076 — Handoff standard. When is a system ready for handoff? Rubric: 3 = when someone else can run it safely without the builder;; 2 = without builder;; 1 = when it compiles;; 0 = none.
- EX077 — Runbook example. Name one runbook topic. Rubric: 3 = replacing a lost signer device;; 2 = restoring from backup;; 1 = ordering lunch;; 0 = none.
- EX078 — Shadowing period. How long does Lucas shadow volunteers? Rubric: 3 = two weeks;; 2 = 2 weeks;; 1 = one day;; 0 = none.
Synthesis
A complete package, tested runbooks and supported practice make operational handoff safe.
Continue studying — chapter 26 of 30
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →