magnus919_agent-skills/site-reliability-engineering/references/slo-implementation-recipe.md

SLO Implementation Recipe

Use this reference when a team has no SLOs, has metrics but no shared objectives, or needs to turn an SLO discussion into an operating agreement. It complements references/slo-sli-framework.md; it does not replace its definitions or formulas.

Source anchors

Synthesized from The Site Reliability Workbook, “Implementing SLOs,” “SLO Engineering Case Studies,” “Alerting on SLOs,” and “Example SLO Document,” and Seeking SRE, “The Art and Science of the Service-Level Objective,” “SRE as a Success Culture,” and “Using Incident Metrics to Improve SRE at Scale.”

The bounded sequence

1. Choose one service and identify its users. Include direct users, downstream services, operators, and business processes. State what failure means to each.
2. Map the important journeys. Describe the request path, asynchronous path, data path, dependencies, and the point at which users experience success or failure.
3. Select a small initial set of indicators. Prefer a few customer-facing indicators for availability, latency, correctness, freshness, or durability. Do not begin by turning every metric into an SLO.
4. Define good and bad events. State valid events, exclusions, aggregation, data source, sampling, and measurement boundary. A formula without a measurement boundary is not an SLI.
5. Measure the baseline. Use a representative period and record gaps in instrumentation. A target should be feasible and meaningful, not an aspirational number copied from another service.
6. Propose targets and windows. Explain the user impact and expected error budget for each target. Use rolling windows when the decision needs a current operating signal; use calendar or contractual windows only when that is the real agreement.
7. Review with stakeholders. The product owner, service owner, support or customer-facing team, and reliability operator must be able to explain what the objective protects and what it will cause them to do.
8. Define the policy before the first breach. Specify what healthy, at-risk, and exhausted budget states change: release pace, reliability work, incident review, escalation, or scope.
9. Alert on significant budget consumption. Use multi-window burn-rate alerts and route pages only when the response is urgent and actionable. Use tickets or review queues for slower repair work.
10. Run a review cycle. Revisit targets when user expectations, architecture, traffic, dependencies, or product criticality changes. Record why the target changed and what evidence supported it.

SLO review questions

• Would a user notice the measured failure, or is it only an internal proxy?
• Can the team take action when the SLO is violated or burning rapidly?
• Does the measurement include dependency and client-side effects that matter to the journey?
• Are exclusions hiding a failure the user still experiences?
• Does the error budget create enough signal before the service becomes unacceptable?
• Is the target tight enough to protect users but loose enough to permit justified change?
• What happens when the team cannot operate within the target and toil constraints?

What to record

Every approved SLO should link to a declaration containing:

• user journey and service owner;
• SLI good-event definition and measurement boundary;
• data source, query, aggregation, and known blind spots;
• target, window, error budget, and review date;
• alert and escalation behavior;
• release and reliability-work policy;
• dependency treatment and exception process;
• evidence baseline and unresolved instrumentation gaps.

SLO failure is a decision signal

Do not treat SLOs as a performance score or a punishment mechanism. A budget breach is evidence that the service needs reliability attention, reduced change risk, more capacity, a dependency intervention, an objective revision backed by new user evidence, or a scope decision. Repeatedly overriding the policy without recording the reason turns the SLO into decoration.

Agent procedure

Load this recipe with references/slo-sli-framework.md and templates/slo-declaration-template.md. If the user has supplied no service, users, or measurement data, produce a discovery plan and mark assumptions rather than inventing targets.