SRE in Practice | Day 2: SRE vs DevOps

Day 2 of 30 Detailed guide by Srilakshmi Thulasiraman For beginners and working Linux, cloud, and DevOps engineers

What you will learn

• Why "SRE vs DevOps" is the wrong framing, and what they share
• What DevOps emphasizes and what SRE emphasizes, side by side
• How one software release looks through both lenses, stage by stage
• A worked release example with real calculations and rollback criteria
• A hands-on lab: map a release, and run safe read-only health checks
• Common myths and mistakes about both

Safety first: The commands in the lab are read-only. Do not deploy, roll back, or change production while practising. Use a staging system or a hypothetical release for the mapping exercise.

1. DevOps helps you ship. SRE helps you keep it reliable.

Teams often ask: "Should we do DevOps or SRE?" or "Is SRE replacing DevOps?" The question assumes they compete. They do not.

Both aim at the same outcome: deliver value to users reliably. They approach it from different angles.

Core idea: DevOps improves how software flows from idea to production. SRE applies software-engineering practices to operating reliable services. Together they cover the whole release lifecycle.

2. What each one emphasizes

DevOps is a culture and set of practices that bring development and operations together: shared ownership, automation of build, test, and delivery (CI/CD), and fast feedback. Its focus is flow and collaboration. DevOps research (for example the DORA program) popularized delivery metrics such as deployment frequency, lead time for changes, change failure rate, and time to restore service.

SRE began at Google. It applies software engineering to operations problems: define reliability in measurable terms (SLIs and SLOs), monitor what users experience, respond to incidents, learn from failures with blameless postmortems, and automate away repetitive toil. Google's SRE materials describe SRE as one concrete way to put DevOps ideas into practice.

Where they overlap

• Both rely on automation instead of manual, error-prone steps
• Both value shared ownership between building and running software
• Both use monitoring and feedback to improve
• Both treat failures as learning, not blame

3. One release, two complementary perspectives

Take a single software release and follow it through four stages. At each stage, DevOps and SRE ask different, complementary questions.

Practical takeaway: DevOps and SRE are not competing teams or tools. They are complementary ways to improve how software is delivered and operated.

4. A production-style example: releasing payment service v2.4

A team releases a new version of a payment API. The target (SLO) is 99.9% successful requests over 30 days.

What the DevOps side does

• Developers merge code; the pipeline builds it and runs unit and integration tests
• The pipeline packages the release and deploys it the same way every time
• Deployment steps are automated and version controlled, so they are repeatable

What the SRE side adds

• Reliability target: 99.9% over 30 days, so the error budget is 43,200 min x 0.001 = 43.2 minutes of full-outage equivalent
• Safe rollout: send the new version to a small share of traffic first (a canary), for example 5%
• Health checks: watch the error rate and latency of the canary against the old version
• Rollback criteria, agreed before the release: for example, roll back if the 5xx rate stays above 1% for 5 minutes, or if p95 latency stays above an agreed limit
• Response plan: who is on call, where the runbook is, how to communicate

Why the canary matters: a calculation

Suppose the new version has a bug that makes every request it handles fail, and it takes 10 minutes to notice and roll back. Assume traffic is spread evenly over those 10 minutes.

The same bug costs about 23% of the monthly budget with a full rollout, and about 1.2% with a 5% canary. The release was equally buggy; the SRE practice limited the damage. The DevOps automation is what makes the canary and the rollback fast and repeatable. You need both. 

A note on realism: Real traffic is rarely even, and a very small canary can produce too few requests to be statistically meaningful. Choose canary size and observation windows based on your traffic and your SLO, and adjust them over time.

5. Hands-on lab

Safety notes: All commands below are read-only. Run them on a system you are authorized to use, preferably staging. Do not run deployment or rollback commands as part of this lab.

Part A: map one release across four stages (no commands)

Choose one recent release, real or hypothetical, and answer the four questions. A filled example is shown for the payment service release.

Part B: quick release-health checks (read-only)

1. See which versions exist in a Git repository you work with:

git log --oneline -5
git tag --list | tail -5

Expected: the five most recent commits, and up to five recent tags. If the repository has no tags, the second command prints nothing.

2. Probe the application a few times and watch status and timing (replace the URL):

for i in 1 2 3 4 5; do
  curl -s -o /dev/null --max-time 5 \
    -w "%{http_code} %{time_total}s\n" http://localhost/
  sleep 1
done

Expected on a healthy system: five lines such as 200 0.011s (times will differ). A 503 or 000 means the request failed. Brief probing like this is not a load test; keep it light on shared systems.

3. Calculate the error rate from an access log and compare it with a rollback threshold. If you do not have a log, generate the same sample file used on Day 1:

awk 'BEGIN{for(i=1;i<=10000;i++){
  s=(i%2500==0)?500:200
  printf "10.0.0.%d - - [01/Nov/2026:10:00:00 +0000] \"GET /api HTTP/1.1\" %d 512\n",
         (i%250)+1, s}}' > /tmp/access.log

awk '{t++; if ($9 ~ /^5/) e++}
END {printf "requests=%d errors=%d error_rate=%.2f%%\n",
     t, e+0, (e+0)/t*100}' /tmp/access.log

Expected result on the sample file: requests=10000 errors=4 error_rate=0.04%. With an example rollback threshold of 1%, this release would be considered healthy. Your real threshold should come from your own SLO, not from this example.

The status code is field 9 in the common Nginx combined log format. Check your own log format before relying on that field.

6. Common myths and mistakes

• "SRE replaces DevOps." No. They address different, overlapping concerns.
• "SRE is just a renamed operations team." SRE is defined by engineering work: measurable targets, automation, and learning loops.
• "DevOps means no one owns reliability." DevOps emphasizes shared ownership; SRE makes reliability targets explicit.
• Shipping releases with no agreed rollback criteria
• Alerting on every metric instead of user-facing symptoms
• Treating the pipeline as done once the deployment succeeds, without watching the release afterwards
• Blaming individuals after a failed release instead of fixing the process

7. Quick check: test yourself

• In your own words, why are SRE and DevOps complementary?
• Name one DevOps focus and one SRE focus at the deployment stage.
• Using the table above, how much of a 43.2-minute budget does a 4-minute full outage use?
• Write one rollback criterion for a service you support.
• Who owns release health after deployment in your team, and how do you know a release is reliable?

Suggested answers: they share the goal of reliable delivery and cover different parts of the lifecycle; DevOps automates delivery while SRE adds health checks and rollback criteria; 4 / 43.2 is about 9.3% of the budget.

Glossary

The 30-day roadmap at a glance

Your turn: In your team, who owns release health after deployment, and how do you know the release is reliable? Share it in the comments on the LinkedIn post.

Coming next, Day 3: follow @leadwithsree for the next topic in the roadmap (toil and automation).