Reliable Releases and SRE: A Practical Beginner Guide

A release is successful when people can use the service. A green build is only one part of that result. Site reliability engineering, or SRE, uses software and clear operating practices to keep a service useful.

Start with a user task

Choose a task such as opening a lesson or submitting an order. Decide what a good result means. For example: the lesson request succeeds within two seconds. Measure from a place that represents the user. A healthy process does not prove that the full task works.

• SLI: the measurement, such as the share of valid requests that succeed.
• SLO: the target for that measurement over a chosen period.
• SLA: an agreement with customers. It may include a remedy if a promised level is missed.

Suppose your SLO is 99.9% successful valid requests over 30 days. With one million valid requests, the error budget is 1,000 unsuccessful requests. Agree what counts as valid and successful before measuring. A request-based target is not automatically a fixed number of minutes of downtime.

Use the error budget to make decisions

An error budget is the allowed gap between the target and perfect service. A team can agree to slow risky releases when it is using the budget too fast. The policy should name who decides, what work is paused, and when normal releases can resume. It should help the service, not blame a person.

Build a release path you can trust

1. Review a small code change.
2. Run useful tests and checks in CI.
3. Build one versioned artifact and record its source revision.
4. Test that artifact in a suitable environment.
5. Review database changes and their recovery plan.
6. Release in a controlled way and watch user-facing signals.
7. Stop or recover when the agreed limits are crossed.

Build once and promote the same artifact where practical. Rebuilding separately for production can give a different result. Keep credentials out of build logs, and give deployment jobs only the access they need.

Understand release choices

A rolling update replaces instances in steps. Blue-green keeps two environments and moves traffic between them. A canary sends a small share of traffic to a new version before a wider release. Two replicas alone do not create a canary: you need traffic control and a way to compare results.

A feature flag can hide a new feature while the code is deployed. Flags need owners and removal dates. They must not replace access checks. A rollback may restore old code, but it cannot always undo a database change. Plan compatible schema changes and test recovery first.

Watch useful signals

Track traffic, errors, latency and saturation. Saturation means a resource is near its limit, such as a full queue or busy connection pool. Look at slow requests as well as averages. An average can hide a small group of people waiting a long time.

The observability lab provides a small request counter. It is a teaching metric and includes health traffic, so do not copy its numbers straight into a customer SLO. Define your real user traffic and exclusions carefully.

A useful incident runbook

Write a short page with the service owner, user impact, key dashboards, safe checks, recovery steps and escalation contacts. Keep the page available when the main app is down. Mark steps that change state or need approval.

1. Confirm what users cannot do and when it started.
2. Name an incident lead and record a timeline.
3. Check recent changes, traffic and dependencies.
4. Choose the safest way to reduce impact.
5. Confirm recovery using user-facing checks.
6. Share a clear update and schedule follow-up work.

Afterwards, write what happened, what helped and what made recovery slow. Assign a few useful actions with owners. Avoid a long list that nobody can finish. Test backups by restoring them in a safe environment; a successful backup job alone is not proof of recovery.

Practice without a production incident

Run the local app. Call /health and /fail. The second path deliberately returns an error for this exercise. Write a mock incident note: impact, evidence, two possible causes, a safe next check and how you would know the service recovered. Do not invent a confirmed cause from one error.

Then change the app version and write a release checklist for it. Explain what you can roll back, what data might change, and who would decide to stop a release. Good operations begin with small, clear habits.

Official references and further reading

Reviewed on 25 October 2026. Tools change, so check the official documentation for the version you use.

• Google SRE: implementing SLOs
• Google SRE: error budget policy
• Google SRE: monitoring distributed systems

DevOps learning roadmap · All DevOps & Cloud tutorials