Turning Vague NFRs into Math
You cannot optimize "fast." You can only optimize "p99 latency under 200ms." The SLI/SLO/SLA framework, popularized by Google's Site Reliability Engineering (SRE) practice, gives you the vocabulary to turn subjective quality expectations into measurable engineering targets.
The Three Layers:
- SLI (Service Level Indicator): The raw metric you actually measure. "Current p99 latency is 150ms." An SLI is just a number — it has no judgment attached to it.
- SLO (Service Level Objective): The internal target your team commits to. "We aim for 99% of requests to complete in under 200ms." This is an engineering promise to the business, not a legal contract.
- SLA (Service Level Agreement): The external, legally binding promise to customers. "If p99 latency exceeds 500ms for more than 0.1% of requests in a month, we issue a service credit." SLAs are always looser than SLOs — the gap between them is your safety margin.
The Error Budget:
If your SLO is 99.9% uptime, you have 0.1% of "allowed failure" per month — approximately 43 minutes. This budget is the key management tool:
- Budget remaining: The team can ship risky features, run experiments, and push infrastructure changes.
- Budget exhausted: Feature work freezes. All engineering effort goes to reliability until the budget resets next month.
The error budget transforms reliability from a vague cultural value into a concrete resource that engineering and product teams negotiate over. It removes the adversarial dynamic of "ops says no to deploys" and replaces it with "we have 20 minutes of budget left this month — do we want to spend it on this deploy?"