SRE vs DevOps: What Each Role Does and Which to Aim For

If you have spent any time reading cloud job adverts, you will have seen both "DevOps Engineer" and "Site Reliability Engineer" (SRE), often with job descriptions that look almost the same. Both mention Linux, Kubernetes, CI/CD, Terraform and monitoring. So what is the actual difference, and which one should a beginner or career switcher aim for? This guide explains what each role does, introduces the ideas that make SRE distinct (SLIs, SLOs and error budgets) with worked examples and real config, and finishes with a practical eight-week plan you can follow from a laptop.

The short answer

DevOps is a culture and a set of practices for getting software from a developer's laptop into production quickly and safely. SRE is one specific way of doing that, which started at Google, and which treats reliability as an engineering problem measured with numbers.

A common way to put it, popularised by Google's own SRE material, is that SRE is a concrete implementation of DevOps ideas. DevOps says "developers and operations should share responsibility and automate everything". SRE says "here is exactly how we decide how reliable a service must be, how we measure it, and what we do when it falls short".

In practice, job titles are messy. Some companies call their whole platform team "DevOps", some call it "SRE", and some use "Platform Engineer" for both. Read the responsibilities, not the title.

What a DevOps engineer usually does

In most companies hiring in Nigeria and across Africa, a DevOps engineer spends most of their time on the path from code to production:

• CI/CD pipelines: building, testing and deploying code automatically with GitHub Actions, GitLab CI, Jenkins or Azure DevOps.
• Infrastructure as code: creating servers, networks and databases with Terraform, Bicep or CloudFormation instead of clicking in the console.
• Containers: writing Dockerfiles, managing images and running workloads on Kubernetes or a managed container service.
• Environments: keeping development, staging and production consistent.
• Developer support: helping product teams ship faster and unblocking broken builds.

The question a DevOps engineer is usually answering is: how do we ship changes faster without breaking things? If you want to go deeper on this side, our guide on how to become a DevOps engineer in Nigeria covers the full path.

What an SRE usually does

An SRE uses many of the same tools but spends more time on what happens after deployment:

• Defining reliability targets: agreeing with the business how reliable a service needs to be.
• Monitoring and alerting: building dashboards and alerts that fire when users are actually affected, not on every CPU spike.
• Incident response: being on call, leading the response to outages and getting services back.
• Postmortems: writing blameless reviews after incidents and making sure the fixes happen.
• Reducing toil: automating repetitive manual work so the team can spend time on engineering.
• Capacity planning and performance: making sure the system can handle growth and traffic spikes.

The question an SRE is usually answering is: is the service reliable enough for our users, and how do we know?

Side-by-side comparison

Notice that the tools overlap heavily. Both roles need Linux, Git, containers, a cloud platform and at least one scripting language. The difference is mainly in what you are responsible for and how you measure success.

The core SRE ideas: SLIs, SLOs and error budgets

These three terms are what make SRE different, and they come up in interviews for both roles. They are simpler than they sound.

SLI: Service Level Indicator

An SLI is a measurement of something users care about. Good SLIs are usually a ratio of good events to total events:

• Availability: successful requests divided by total requests.
• Latency: requests served faster than a threshold (say 300 ms) divided by total requests.
• Freshness: for a data pipeline, the share of records updated within the expected time.

A bad SLI is "CPU usage". Users do not care about your CPU; they care whether the page loads and the payment goes through.

SLO: Service Level Objective

An SLO is a target for an SLI over a time window. For example:

99.5% of HTTP requests to the checkout API return a non-5xx response, measured over a rolling 30 days.

The SLO is an internal goal. It is different from an SLA (Service Level Agreement), which is a contractual promise to customers, usually with penalties such as service credits. Your SLO should be stricter than any SLA so you have warning before you breach the contract.

Error budget

The error budget is simply what the SLO allows you to get wrong: 100% - SLO. With a 99.5% SLO, your error budget is 0.5% of requests.

This is the clever part. The error budget turns the old argument between "ship features fast" and "keep it stable" into a number both sides can agree on:

• If you have plenty of budget left, the team can deploy freely and take some risks.
• If the budget is nearly spent, the team slows down, freezes risky releases and works on reliability.

Worked example: turning an SLO into real numbers

Say a fintech's transfer API handles about 2,000,000 requests in 30 days, and the SLO is 99.5% availability.

• Error budget = 0.5% of 2,000,000 = 10,000 failed requests allowed in the window.
• If an incident last week caused 6,000 failed requests, you have used 60% of the budget and have 4,000 left.

You can also express it as time. A 30-day window has 43,200 minutes:

You can check these yourself with a one-line Python calculation:

python3 -c "
for slo in [99, 99.5, 99.9, 99.95, 99.99]:
    mins = 30 * 24 * 60 * (100 - slo) / 100
    print(f'{slo}% -> {mins:.1f} minutes of downtime per 30 days')
"

Each extra "nine" cuts your budget by a factor of ten and usually costs much more in engineering and infrastructure. This is why a sensible SLO is not 100%. Your users' own networks, phones and power supply are not 100% reliable either, so they will not notice the difference between 99.95% and 99.99%, but your cloud bill will.

Hands-on: measure an SLI with Prometheus

Theory is easy to memorise; interviewers want to know if you have done it. Here is a small lab you can run on a laptop with Docker installed. If Docker is new to you, start with our Docker for beginners guide.

Step 1: run Prometheus

Create a folder and a minimal config file that tells Prometheus to scrape itself:

mkdir sre-lab && cd sre-lab
cat > prometheus.yml <<'CONF'
global:
  scrape_interval: 15s

rule_files:
  - /etc/prometheus/rules.yml

scrape_configs:
  - job_name: prometheus
    static_configs:
      - targets: ["localhost:9090"]
CONF

Step 2: add a recording rule and an SLO alert

Prometheus exposes its own HTTP request counter, prometheus_http_requests_total, with a code label. That is enough to practise availability SLIs without writing an app.

cat > rules.yml <<'CONF'
groups:
  - name: slo
    rules:
      - record: sli:availability:ratio_rate5m
        expr: |
          sum(rate(prometheus_http_requests_total{code!~"5.."}[5m]))
          /
          sum(rate(prometheus_http_requests_total[5m]))

      - alert: AvailabilityBelowSLO
        expr: sli:availability:ratio_rate5m < 0.995
        for: 10m
        labels:
          severity: page
        annotations:
          summary: "Availability below 99.5% SLO for 10 minutes"
CONF

Step 3: start it

docker run -d --name prom -p 9090:9090 \
  -v "$PWD/prometheus.yml:/etc/prometheus/prometheus.yml" \
  -v "$PWD/rules.yml:/etc/prometheus/rules.yml" \
  prom/prometheus

Validate your rules before trusting them. The Prometheus image ships with promtool:

docker exec prom promtool check rules /etc/prometheus/rules.yml

Open http://localhost:9090, go to the query page and run sli:availability:ratio_rate5m. Refresh the page a few times to generate traffic. You should see a value close to 1 (100%). Visit a few non-existent API paths to see how the code label changes, and check the Alerts page to see your rule.

Step 4: calculate remaining error budget

This PromQL gives the fraction of error budget left over the last 30 days for a 99.5% SLO (on a fresh lab, it only covers the data you have collected):

1 - (
  (1 - (
    sum(increase(prometheus_http_requests_total{code!~"5.."}[30d]))
    /
    sum(increase(prometheus_http_requests_total[30d]))
  ))
  / (1 - 0.995)
)

A result of 1 means the whole budget is left; 0 means it is spent; a negative number means you have breached the SLO. In real teams this goes on a Grafana dashboard that everyone can see.

When you are done, clean up:

docker rm -f prom

To practise these ideas in a game format, try the SRE & DevOps Arena in CloudArcade.

A better alert: burn rate

Beginners often alert when the SLI dips below the SLO for a few minutes. That is noisy. The approach described in Google's Site Reliability Workbook is to alert on burn rate: how fast you are spending the error budget.

A burn rate of 1 means you will spend exactly your budget over the full window. A burn rate of 14.4 sustained for one hour spends about 2% of a 30-day budget, which is serious enough to wake someone up. A simplified version:

- alert: HighErrorBudgetBurn
  expr: |
    (
      sum(rate(prometheus_http_requests_total{code=~"5.."}[1h]))
      /
      sum(rate(prometheus_http_requests_total[1h]))
    ) > (14.4 * 0.005)
    and
    (
      sum(rate(prometheus_http_requests_total{code=~"5.."}[5m]))
      /
      sum(rate(prometheus_http_requests_total[5m]))
    ) > (14.4 * 0.005)
  for: 2m
  labels:
    severity: page

The long window (1 hour) confirms the problem is real; the short window (5 minutes) makes sure it is still happening, so the alert clears quickly after a fix. You do not need to memorise the numbers, but being able to explain the idea sets you apart in interviews.

Incidents and postmortems

The other big SRE habit is handling incidents in a calm, structured way. A simple incident flow:

1. Detect: an alert fires or a user reports a problem.
2. Declare: someone says "this is an incident" and takes the role of incident lead.
3. Mitigate first: roll back, fail over or scale up to stop user pain. Finding the root cause comes later.
4. Communicate: post regular updates in one channel, even if the update is "still investigating".
5. Resolve and review: write a blameless postmortem within a few days.

A short postmortem template you can reuse in your portfolio:

## Summary
What happened, in two sentences.

## Impact
Who was affected, for how long, and how much error budget was used.

## Timeline (WAT)
- 14:02 Alert fired: HighErrorBudgetBurn on transfer-api
- 14:06 Incident declared, rollback started
- 14:15 Error rate back to normal

## Root cause
The technical cause, without blaming individuals.

## Action items
- [ ] Add a database connection pool limit (owner, due date)
- [ ] Add a canary stage to the pipeline (owner, due date)

"Blameless" does not mean nobody is responsible. It means you assume people acted sensibly with the information they had, and you fix the system so the same mistake is harder to make.

Toil: the work SREs try to remove

Google's SRE book describes toil as work that is manual, repetitive, automatable and grows with the size of the service. Restarting a stuck service by hand every morning is toil. So is manually rotating log files or copying files between servers.

A simple example: instead of checking disk space by hand on every server, a short script can do it and warn you.

#!/usr/bin/env bash
# disk-check.sh - warn when any filesystem is above a threshold
THRESHOLD=80
df -hP | awk -v t="$THRESHOLD" 'NR>1 {gsub("%","",$5); if ($5+0 > t) print "WARNING:", $6, "is at", $5"%"}'

Run it with bash disk-check.sh, then schedule it with cron (crontab -e and add `/15 * /home/you/disk-check.sh >> /home/you/disk.log`). Better still, replace it with a Prometheus Node Exporter metric and an alert, which is what a real SRE team would do. Solid Linux skills underpin all of this; see our guide on Linux skills for cloud jobs.

Local realities worth planning for

A few practical points for learners in Nigeria and across the continent:

• Run labs locally where you can. Everything above runs on Docker on your own machine, which costs nothing in dollars. Use the cloud for things you cannot simulate locally.
• Set budget alerts before your first cloud resource. AWS Budgets, Azure Cost Management budgets and Google Cloud budget alerts are all free to set up. Cloud is billed in dollars, and a forgotten load balancer or Kubernetes cluster can quietly run up a bill. Naira cards sometimes hit international spending limits, so check with your bank before relying on one.
• Use free tiers carefully. Each provider's free tier has different rules and time limits. Read the current terms on the official site rather than relying on old blog posts.
• Plan for power and internet interruptions. Run long-lived labs in short sessions, commit your work to Git often, and tear down cloud resources at the end of each session with terraform destroy so nothing runs overnight. Our Terraform for beginners guide shows how.
• Reliability thinking is very relevant locally. Banks, fintechs, telcos and e-commerce businesses here deal with real outages, network issues and payment failures. Being able to talk about SLOs in terms of failed transfers or payment timeouts is a strong interview answer.

Which one should you aim for?

For most beginners and career switchers, the honest answer is: start with DevOps fundamentals, and add SRE practices as you grow.

Reasons:

• Entry-level roles are more often advertised as DevOps, cloud engineer or cloud support than as SRE. SRE roles commonly expect some production experience, especially for on-call work.
• The foundations are the same. You cannot run SLOs on a system you cannot deploy, monitor or debug.
• SRE skills make you a better DevOps engineer immediately. A junior who can explain error budgets and has a monitoring project in their portfolio stands out.

Lean towards SRE if you:

• Enjoy debugging and finding out why something broke.
• Are comfortable with (or want to grow into) more programming, especially Python or Go.
• Come from a sysadmin, network operations, NOC or backend development background.
• Do not mind on-call rotations.

Lean towards DevOps if you:

• Enjoy building pipelines, automation and developer tooling.
• Like seeing changes ship quickly.
• Are newer to tech and want the most common entry point.

Either way, the career paths cross often. Many SREs started in DevOps roles and many DevOps engineers end up owning SLOs. For the wider picture of entry routes, read cloud jobs for beginners in Africa.

Common mistakes

• Treating SRE as a fancy title for ops. If a team has no SLOs, no error budget policy and no postmortems, it is not really doing SRE, whatever the job title says.
• Choosing SLIs users do not feel. CPU, memory and disk are useful for debugging, but your SLOs should be based on requests, latency and correctness.
• Aiming for 100%. It is impossible and very expensive. Pick a target that matches what users actually need.
• Alerting on everything. Too many alerts teach people to ignore them. Page only for things that need a human now.
• Skipping the fundamentals. Jumping straight to Kubernetes and Prometheus without understanding Linux, networking and HTTP status codes makes incidents very hard to debug.
• Writing postmortems that blame people. This makes engineers hide mistakes, which makes the system less reliable.
• Only reading. Interviewers can tell quickly whether you have actually broken and fixed something.

An eight-week practice plan

This plan assumes about 8 to 10 hours a week alongside work or study.

Week 1: Linux and networking basics. Practise processes, logs, systemctl, journalctl, ss, curl and dig. Learn the meaning of HTTP status codes. Use the Linux Arena for daily practice.

Week 2: Git and scripting. Put all your lab files in a GitHub repository. Write two small Bash scripts and one Python script that checks a URL and prints the status code and response time.

Week 3: Docker. Containerise a small web app (Flask or Node.js). Add a /health endpoint. Run it with Docker Compose.

Week 4: CI/CD. Build a GitHub Actions pipeline that tests the app, builds the image and pushes it to a registry. Our CI/CD with GitHub Actions guide walks through it.

Week 5: Monitoring. Add Prometheus metrics to your app (the official prometheus_client Python library makes this a few lines). Run Prometheus and Grafana with Docker Compose. Build a dashboard showing request rate, error rate and latency.

Week 6: SLOs and alerts. Write down an SLO for your app. Add a recording rule for the SLI, an error budget panel and a burn rate alert. Validate everything with promtool.

Week 7: Break things on purpose. Add a setting that makes 10% of requests return a 500 error, or stop the database container. Watch the alerts fire, fix it and write a proper postmortem.

Week 8: Polish and present. Write a clear README with an architecture diagram, your SLO document, screenshots of dashboards and your postmortem. This becomes a strong portfolio piece; see cloud portfolio projects for how to present it.

If you want structured teaching and mentoring through this, our courses cover the full DevOps and SRE path.

FAQ

Is SRE harder than DevOps?

It is not harder so much as broader. SRE usually expects comfort with production systems, on-call and some software engineering. That is why many people move into SRE after a DevOps, sysadmin or backend role.

Do I need to be a strong programmer to become an SRE?

You need to be able to write and read code comfortably, usually Python, Go or Bash, and automate your own work. You do not need to be a computer science expert, but expect more coding than in a typical junior DevOps role.

Is there an SRE certification?

There are some vendor and training-body certifications with SRE in the name, but there is no single dominant one. Cloud certifications such as AWS, Azure or Google Cloud associate-level exams, plus Kubernetes certifications from the Linux Foundation, are more widely recognised. Check the official sites for current exam details and prices.

What is the difference between an SLA, an SLO and an SLI?

The SLI is the measurement, the SLO is your internal target for it, and the SLA is the contractual promise to customers. The SLO should be stricter than the SLA.

Can I learn SRE without paying for cloud?

Yes, most of it. Prometheus, Grafana, Docker, Kubernetes (with kind or minikube) and Git all run locally for free. Use the cloud for specific exercises, with budget alerts set first.

Get personal guidance

Not sure whether DevOps or SRE fits your background, or where to start? Book a free consultation with SKILL.SCH and we will help you pick a path and a realistic plan for your situation.