The operations function is part of the system
A security operations function is a production system with people inside it. It has an arrival rate, a service rate, a queue, a duty cycle, and a distinct failure mode when it saturates. Most of them are managed as though they were a documentation problem — write more procedure, buy more tooling, hire when it finally hurts. These essays take the other view: measure toil before automating it, design the rota the way you would design a service, keep runbooks true by running them, and borrow the parts of reliability practice that survive the move into security work.
All essays
- What Security Can Borrow From Reliability Practice
Error budgets, blameless review and load shedding transfer into security operations, but only if you are precise about which quantity is being budgeted and which one is not yours to control.
- Keeping a Runbook True
A runbook is a copy of knowledge about a system that changes without telling you. Decay is structural rather than cultural, and the only reliable detector is execution.
- The Rota Is a Design Artefact
Most on-call schedules are the output of a spreadsheet and a headcount, not a design. Writing down what the rota has to achieve — before drawing it — changes the shape of the answer and the size of the team.
- Measure the Toil Before You Automate It
Ask an operations team what to automate and they name the task that annoys them most, which is almost never the task that costs them most. The gap between those two answers is the whole of the problem.