Chapter 10
Operability
Shipping creates an operational obligation. Proportional, instrumented, alert-disciplined.
On this page
Build it so you can run it.
The obligation
Shipping creates an operational obligation. Merged is not the same as operating: CI passed, the happy path worked, the flag turned on, and none of that tells you the system is alive in production. In P-Cubed terms, this chapter is what Produce must include before shipping counts as done. If you cannot tell whether it is working, you have not finished building it.
You don't just ship code. You ship a system that will run in production, probably at 2 AM, possibly while you're on vacation.
Operability means:
- You know when something is wrong before users tell you
- You can understand what's happening inside the system
- You can deploy changes safely
- You can recover quickly when things break
- You're not dependent on heroics to keep things running
If you can't operate it, you didn't really ship it.
The limit: the operational surface stays proportional. Not every internal helper needs a dashboard. What a system owes production depends on its consequence and its failure modes, not on a uniform standard applied to everything.
Know your instruments
Observability is only as good as your understanding of the instruments. An SSL handshake-failure counter once spiked on a system I worked on, and the room's first instinct was to chase it: production is burning, find the fire. The discussion that actually helped asked a smaller question first. What does this counter measure, exactly, and when does it reset? Eventually someone established that the counter decayed after successful connections. The number was telling a more complicated story than "failures are spiking," and the problem shifted from "production is burning" to "understand the measurement." That shift was the fix.
Trusting your instrumentation and understanding your instrumentation are different skills. The second one is the operability skill: know what each number actually measures, what resets it, and what it cannot see, before the night you have to bet on it.
Alert discipline
An alert is a claim that a human must act now. It earns its place by being actionable, specific, urgent, and rare. If it can wait until morning, it's a ticket. If there's nothing a human can do, it's noise.
If everything alerts, nothing alerts. An ignored alert is worse than no alert: it trains people to ignore pages. Deleting a noisy alert is an operability improvement.
Watch it run
The full shape of the obligation is easier to see on one real system than in a checklist. Finished Means Ready to Run Again walks it on the reloading bench: maintenance, provenance, cleanup, recovery, and restart as part of done.
The machinery this chapter no longer surveys, SLOs and error budgets, deployment strategies, on-call structure, is covered better by the SRE literature than I would cover it here. Start with Google's Site Reliability Engineering.
Build it so you can run it. Monitor so you know when it's broken. Deploy so you can fix it fast. Operability is part of the craft.