Chapter 26 — Operational handoff
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 What handoff means"]
N2["26.2 Runbooks"]
N3["26.3 Training"]
N4["26.4 Confirming understanding"]
N5["26.5 Ownership"]
N6["26.6 Go-live"]
N7["26.7 Feedback"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 What handoff means"]
N2["26.2 Runbooks"]
N3["26.3 Training"]
N4["26.4 Confirming understanding"]
N5["26.5 Ownership"]
N6["26.6 Go-live"]
N7["26.7 Feedback"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 What handoff means]
|
v
[26.2 Runbooks]
|
v
[26.3 Training]
|
v
[26.4 Confirming understanding]
|
v
[26.5 Ownership]
|
v
[26.6 Go-live]
|
v
[26.7 Feedback]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) hand over a new detection or process to operations; (2) write runbooks analysts can follow; (3) train analysts and confirm understanding; (4) plan ownership and review.
26.1 What handoff means
A detection built by an engineer becomes the analysts' daily work. Handoff ensures they understand it, can act on it and know whom to ask.
For the sequence rule, Mei knows why it joins three events on one session and why contractor sessions in support windows are excluded. An analyst meeting the alert at night does not, unless the handoff passes that knowledge on. Handoff is finished when another analyst can handle the alert correctly without calling Mei. Mei treats the questions analysts ask during handoff as evidence of what the runbook still fails to explain.
26.2 Runbooks
Each alert type gets a runbook: what the alert means, what to check first, decision points, actions allowed per client agreement, and how to close. Mei writes the runbook for the sequence rule from chapter 16.
For the sequence rule, the runbook starts by explaining that the alert means an external session created an account and made it an administrator within 30 minutes. It then asks the analyst to check whether the session came from the contractor's VPN inside a support window, and states the actions each client's agreement allows, such as isolating the host or disabling the account.
26.3 Training
A 20-minute session walks analysts through the runbook using the BrightSmile replay. Each analyst then triages two lab alerts alone.
The BrightSmile replay is a good training case because analysts know how it ended: support2 created at 01:22 and renames starting at 01:34. Seeing the sequence alert at 01:22 shows them how much time the rule gives. Triaging two lab alerts alone then checks that they can apply the runbook without help. Short sessions fit the shift pattern, so analysts can attend between shifts without leaving the night queue short of people.
26.4 Confirming understanding
Mei checks that analysts reach the right decisions in the lab. One analyst isolates on a contractor-window alert that should have been a phone call; the runbook is clarified.
The mistake came from the runbook, not the analyst: it listed isolation among the actions but did not say that an alert from the contractor's account outside a support window should first lead to a call to the contractor. Mei adds that step, because isolating a server during an agreed emergency repair would stop the repair.
26.5 Ownership
The rule has an owner (Mei during placement, then a named engineer), a review date and a feedback channel.
Naming a person rather than a team means someone is responsible for answering analysts' questions and for the review date. When Mei's placement ends, the named engineer takes over the rule with its runbook and change history. The review date ensures the contractor exceptions are checked before they expire. The feedback channel collects analysts' comments in one place, which is how the two wording changes during the first fortnight were found.
26.6 Go-live
The rule goes live on a Monday morning, not before a weekend, so problems are found while staff are available.
A Monday start gives a full working week, with Mei and the engineers present, to see the rule's first real alerts. If it misfired on a Friday night, two analysts covering forty clients would have to deal with it alone until Monday, the situation that the night-capacity limits of chapter 19 are meant to avoid. Mei also tells the night analysts that the rule is new, so an unusual alert in the first week is reported to her rather than quietly closed.
26.7 Feedback
Analysts' comments in the first two weeks lead to two wording changes in the alert text.
The feedback came from analysts handling real alerts, who found that two phrases in the alert text were unclear at a glance. Small changes like these matter because the alert text is the first thing read at night. Mei records both changes in the rule's history so later readers can see why the wording differs from the first version. Mei also checks the three firings in the worked example against the runbook, to see whether analysts followed it.
Retiring old procedures
When the new rule goes live, the old manual check it replaces is removed from the shift checklist, so analysts are not doing duplicate work. The change is noted in the shift log and in the rule's change history, which lets anyone reviewing the rule later see what it replaced and why.
Worked example
Two weeks after go-live, the rule has fired three times: one real sequence at a client's accounts PC (contained) and two contractor actions outside agreed windows that turned out to be agreed emergencies. Mei adds a field for "emergency support approved by" to contractor tickets so analysts can check quickly.
Synthetic case. Runbooks and events are invented.
Errors and limits
Runbooks cannot cover every variation; analysts must escalate when unsure.
Exercises
- EX076 — Runbook contents. List the runbook sections. Rubric: 3 = meaning, first checks, decisions, allowed actions, closure; 2 = four; 1 = two; 0 = none.
- EX077 — Training check. What did the lab check reveal and how was it fixed? Rubric: 3 = analyst isolated on contractor-window alert; runbook clarified; 2 = partial; 1 = vague; 0 = none.
- EX078 — Go-live timing. Why go live on a Monday morning? Rubric: 3 = problems found while staff available; 2 = partial; 1 = random; 0 = none.
Synthesis
Handoff turns a detection into reliable practice through runbooks, training, ownership and early feedback.
Continue studying — chapter 26 of 30
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →