SRE / Basic: promises and measurements / Lesson 1

Reliability as a user and engineering decision

Connect service reliability to a specific user journey, a bounded risk decision, and shared engineering ownership before choosing reliability tools.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Define the user-visible service boundary.
Compare reliability costs with consequences.
Write an explicit ownership and risk agreement.

Begin with the promise

A service exists to help someone complete a task. For the fictional Library service, the promise is that a reader can reserve an available book and receive a durable confirmation. A healthy process is only one ingredient: a successful HTTP response that loses the reservation still violates the promise. Draw the path from the reader through the frontend, reservation logic, storage, and confirmation. State what is outside this service boundary, such as a separate delivery company. This prevents the team from calling an internal machine healthy while users cannot complete the task. Keep the initial scope narrow enough that one accountable team can explain the measurements and act on failures.

Distinguish risk dimensions

Availability, latency, correctness, freshness, and durability describe different failures. A slow reservation may be inconvenient; a duplicate charge can require reconciliation even if every response was fast. Estimate who is affected, how long the effect lasts, and whether recovery repairs the user outcome. The first record separates a response objective from a data obligation. Its values are fictional design inputs, not recommendations for all services. Legal, contractual, and safety obligations require their own competent review; an availability percentage does not replace them. Make known uncertainty visible rather than multiplying optimistic numbers until the architecture appears reliable.

yaml Synthetic service promise

journey: reserve-book
availability_scope: eligible-reservation-attempts
latency_boundary: reader-to-confirmation
data_obligation: preserve-confirmed-reservation
owner: library-team

This editorial record separates measurement scope, data correctness, and accountable ownership; it is not a service configuration.

Reason about marginal investment

Perfect availability is not a practical engineering promise. Additional redundancy, testing, support coverage, and complexity all have costs, and complexity can introduce new failure modes. Compare a proposed reliability improvement with the actual reduction in user harm. In the offline arithmetic example, reducing monthly failed attempts from two hundred to fifty avoids one hundred fifty failures; it says nothing about the financial value of that reduction. A product owner and engineers must decide whether that improvement outweighs its recurring cost. Include operational work and recovery complexity, not only infrastructure prices, when evaluating alternatives.

python Offline improvement arithmetic

attempts = 100_000
old_bad = 200
new_bad = 50
print(old_bad - new_bad)
print(f"{100 * (attempts - new_bad) / attempts:.2f}%")

Expected output

150
99.95%

Only synthetic counts are compared. The result is 150 fewer failed attempts and 99.95% success, not a prediction of a running service.

Share decisions without diluting ownership

SRE applies software engineering to reliability work. Product teams remain involved because they choose user promises and ship changes that influence risk. Name a service owner, escalation route, measurement owner, and authority for exceptional decisions. A team can own an outcome without granting every member unrestricted administrative access. Write the agreement in ordinary language and rehearse an ambiguous situation: who decides whether a failing optional recommendation panel should delay checkout? If nobody can answer, adding a monitoring dashboard will not resolve the missing decision. Review ownership whenever boundaries or team responsibilities change.

Turn uncertainty into an explicit review

Finish the first reliability discussion with a small set of open questions and evidence needed to answer them. Perhaps reservation correctness is known from reconciliation but the user-side latency distribution is missing. Assign an owner to obtain that evidence and set a review date. Avoid presenting an unmeasured aspiration as achieved reliability. The resulting agreement should connect user impact, measurement, investment, and response, allowing later SLO lessons to add precise ratios. Reliability decisions become easier to challenge constructively when the assumptions are written beside them instead of hidden inside a chart or a vendor availability claim.

Common errors and fixes

All servers are green but reservations disappear

Why it happens: Machine health was substituted for the user promise.
How to fix it: Measure confirmed reservations and reconcile their durable state.
Prevent it next time: Review correctness alongside availability.

Every service receives the same availability target

Why it happens: Different user harms and operating costs were ignored.
How to fix it: Discuss risk and marginal benefit for each journey.
Prevent it next time: Record the rationale and review it with product owners.

An incident has no decision owner

Why it happens: Shared responsibility lacked named authority.
How to fix it: Assign an accountable lead and escalation path.
Prevent it next time: Rehearse ambiguous cross-team failures.

Check your understanding

1. A frontend returns 200 but the confirmation is never stored. Is the reservation successful?

Show worked solution

Under the stated promise it is unsuccessful: a durable confirmation is part of the outcome. Count the attempt within the eligible scope and investigate the storage or acknowledgement boundary. A separate frontend-availability measure can remain useful diagnostically, but cannot establish reservation correctness.

2. What information is missing before buying a second region?