The Launch Gap
Imagine a restaurant that perfects a dish in the test kitchen — the flavors are right, the presentation is beautiful. But the test kitchen has one chef, one stove, and no time pressure. On opening night, 300 customers arrive simultaneously. The dish that worked perfectly in testing now takes 45 minutes per plate, the stove catches fire, and nobody wrote down the recipe. The food was "ready." The kitchen was not.
Software has the same problem. Developers focus on Functional Requirements — does the feature work correctly for a single user in a controlled environment? SREs focus on Non-Functional Requirements — is the system scalable, observable, secure, recoverable, and affordable when real users hit it at 3 AM during a traffic spike?
Operational Readiness is the structured process of verifying that a service meets these non-functional requirements before it is allowed to take real production traffic. It is the difference between "the code works" and "the system is ready." Without it, prototype-quality code quietly becomes a production nightmare — usually at the worst possible moment.
The Two Pillars
This topic covers the two complementary tools that define operational readiness:
- Production Readiness Review (PRR): The qualitative checklist — a structured audit that asks "Have we thought about everything that could go wrong?"
- Capacity Planning: The quantitative math — a modeling exercise that asks "Do we have enough resources to handle the load we expect?"
Neither pillar alone is sufficient. A service can pass every PRR checklist item and still fall over because nobody calculated how many servers were needed. Conversely, you can provision infinite hardware and still have an outage because nobody wrote a runbook or set up an alert.