Sefism Platform Engineering and SRE Roadmap

What this roadmap is

The platform engineering and SRE roadmap is Sefism's next step for DevOps engineers who already deploy to the cloud and Kubernetes. Tauseef Fayyaz wrote it for people who can ship a service and now want to keep it reliable at scale, or build the internal platform other teams ship on. Everything is practised on a local kind cluster with open source tools, so you can break things freely without a cloud bill.

You choose a path at the start:

• Site reliability (the default): keep production up with SLOs, incidents and on-call. It adds topics on infrastructure changes as a reliability risk and production readiness reviews.
• Platform engineering: build the internal platform other teams ship on. It adds SLOs for the platform itself, observability as a platform default, namespaces, quotas and RBAC for many teams, and self-service infrastructure with control planes.

By the end you should be able to:

• Define SLIs, SLOs and an error budget policy for a real service, and turn them into multiwindow burn-rate alerts that page only when users are hurt.
• Debug a production issue from a dashboard to a trace to a log line, using PromQL and OpenTelemetry data you set up yourself.
• Run an incident with clear roles, mitigate before diagnosing, and write a blameless postmortem with owned action items.
• Operate Kubernetes, Terraform and Argo CD at team scale: disruption budgets, zone spreading, split state, policy as code and progressive delivery.
• Design a golden path or internal developer platform with Backstage, and plan capacity, cost, chaos experiments and an on-call rotation people can sustain.

Who it suits, and who should start elsewhere

It suits DevOps, cloud and backend engineers with real deployment experience who want to move into SRE or platform roles, and engineers already on call who want to do it better. It is not a beginner roadmap, and it has no foundation stage to skip.

The roadmap is explicit about this: if you have not yet deployed a service to Kubernetes with basic monitoring, do the DevOps and cloud roadmap first and come back. If you are still learning one cloud, start with Cloud engineering. If the Linux shell is unfamiliar, begin with Linux, terminal and Git.

Prerequisites and realistic time

Working knowledge of Linux, Docker, Kubernetes objects, Terraform basics and a CI system, plus a laptop that can run a multi-node kind cluster. The roadmap adds up to about 194 hours across 10 stages:

• At about 5 hours a week (the default on the public page): roughly 42 weeks.
• At about 8 hours a week: roughly 28 weeks.
• At about 12 hours a week: roughly 20 weeks.

A sample week for a student or someone between roles (10 to 12 hours). Two evenings reading the stage's chapters of the SRE books or documentation, one evening on timed troubleshooting scenarios, and a weekend block building the milestone on your kind cluster.

A sample week for someone working full time (5 hours). Most people taking this roadmap already work in DevOps, so use your job where you can: write the SLO document for a real service, sit in on incident reviews, and keep the home lab for the parts your workplace does not do. One weekday session and a weekend block is enough to move a stage forward.

Stage by stage

1. Reliability basics: SLIs, SLOs and error budgets (12 hours)

Why 100 per cent is the wrong target, SLIs users would recognise, SLOs and SLAs, error budgets and the nines table, error budget policies, dependencies and composite availability, and, on the platform path, SLOs for the platform itself. Milestone: a one-page SLO document for a service you run or built, with two SLIs, targets, the error budget in minutes and requests, and a policy. Short in hours, but every later alert, dashboard and postmortem points back to it.

2. Observability: metrics, logs and traces (30 hours)

Golden signals, RED and USE, the Prometheus data model, PromQL you use every week, cardinality, OpenTelemetry and the Collector, and sampling and correlating signals. Milestone: a demo app on a local cluster with Prometheus, an OpenTelemetry Collector, a RED dashboard on recording rules, tail sampling that keeps errors, and logs that carry trace IDs. The advice: learn the open source stack first, and you will understand paid tools' bills far better.

3. Incident response and postmortems (18 hours)

Alerting on burn rate, severity levels and incident roles, mitigating before finding the cause, troubleshooting under time pressure, blameless postmortems, action items that get done, and communicating during an incident. Milestone: burn-rate alerts, a severity scale, one practice incident run as commander with a live timeline, and a postmortem with owned, dated actions. Run practice incidents with a friend: one breaks the app, the other responds.

4. Kubernetes in production (30 hours)

A troubleshooting flow, disruption budgets and zone spreading, requests, limits and QoS classes, graceful shutdown and zero-downtime deploys, cluster upgrades and deprecated APIs, and policy guard rails, with multi-team namespaces, quotas and RBAC on the platform path. Milestone: a multi-node kind cluster where a rolling deploy under load produces zero errors, one admission policy in audit mode, and a written upgrade plan.

5. Infrastructure as code at scale (20 hours)

Splitting state by blast radius, versioned shared modules, plan on pull request and apply from the pipeline, policy as code, drift, imports and the wider Terraform ecosystem. Milestone: separate states per environment and layer, a pinned shared module, plans in CI with OIDC, two Conftest or Checkov policies and a scheduled drift check. "Most engineers can write Terraform; far fewer can organise it so fifty people can change it safely."

6. GitOps and progressive delivery (18 hours)

What GitOps means, Argo CD Applications and sync, app of apps and ApplicationSets, promotion between environments, secrets in a GitOps world, and canary releases with automatic analysis. Milestone: Argo CD deploying three services through an ApplicationSet with dev and prod overlays, secrets kept out of Git, and a canary that rolls back on its own.

7. Internal developer platforms (24 hours)

Platform as a product, golden paths, a software catalogue with Backstage, software templates and docs like code, cognitive load and team types, measuring whether the platform helps, and production readiness reviews on the SRE path. Milestone: a local Backstage with your services catalogued, one template that creates a new service with CI, GitOps and a dashboard, and a one-page platform plan with the metrics you would track.

8. Capacity, performance and cost (18 hours)

Estimation and Little's law, utilisation, queueing and headroom, load testing, autoscaling at every layer, cost allocation and FinOps, and rightsizing, spot and commitments. Milestone: a capacity note with peak traffic, pods needed with zone headroom, a k6 test confirming the per-pod limit, autoscaling settings and a cost breakdown with one rightsizing change.

9. Chaos and resilience testing (16 hours)

Chaos experiments done properly, fault injection in Kubernetes, timeouts, retries with backoff and jitter, circuit breakers and bulkheads, load shedding and graceful degradation, and game days. Milestone: three experiments with hypotheses and results, fixes where they showed gaps, a degraded mode behind a feature flag, and notes from a one-hour game day. Start with the boring faults: kill a pod and add 300 ms of latency.

10. On-call without burnout (8 hours)

Rotations and escalation, alert hygiene, runbooks that work at 3 a.m., measuring and cutting toil, handoffs and on-call reviews, and sustainable load and fair compensation. Milestone: an on-call handbook with every alert classified as page or ticket, two tested runbooks and a toil log with one item automated.

Projects to build alongside

• Status Page with Multi-Region Uptime Checks for Small SaaS Teams
• Lightweight Internal Developer Portal with Service Scorecards
• Chaos Engineering Toolkit for Teaching Distributed Systems
• Kubernetes Resource Right-Sizing Advisor
• Deployment Pipeline with Progressive Rollout and Automatic Rollback

How it works on Sefism

Everything on Sefism is free to learn from. The public roadmap page lists all ten stages with their summaries and length and opens the first two in full. Adding the roadmap to your dashboard opens every stage, tracks your progress and gives you the companion cheat sheet. Your first roadmap is free to add; after that, adding a roadmap uses credits, and new members get starting credits when they join.

Each topic in the dashboard has an explanation, a check question and an AI prompt that quizzes you one question at a time, and each stage has Tauseef's advice, a checklist and curated resources. You can ask Tauseef a question about any stage, or book a 1:1 session if you want to talk through a move into SRE or platform work.

The companion cheat sheet

The Platform engineering and SRE cheat sheet holds the numbers, queries and templates you reach for when production is on fire, with an edition for each path.

Related on Sefism

• How to move from DevOps to site reliability engineering
• Platform engineering vs DevOps
• Can I become an SRE or platform engineer straight after graduating?
• Google Site Reliability Engineering Book, The Site Reliability Workbook and SadServers, from the stage resources.
• Related roadmap: MLOps and LLMOps, which applies the same reliability ideas to models.

What you can do afterwards

Apply for SRE, platform engineer and senior DevOps roles with a portfolio that shows judgement: an SLO document, a postmortem, a GitOps repository, a Backstage template and a capacity note. When you interview, the on-call stage suggests asking how many pages a week the rotation gets and what happens after a bad night.

FAQ

How long does it take to become an SRE? For someone already working in DevOps, the roadmap estimates about 194 hours: roughly 20 weeks at 12 hours a week or 42 weeks at 5 hours a week.

What is the difference between SRE and platform engineering? SRE keeps production up through SLOs, incidents and on-call; platform engineering builds the internal platform other teams ship on. The roadmap shares most stages and lets you choose the emphasis.

Can I become an SRE as a fresh graduate? The roadmap assumes DevOps experience and sends newcomers to the DevOps and cloud roadmap first. The related career question covers this in more depth.

Do I need a Kubernetes certification? The Kubernetes stage puts hands-on debugging first and says a certification can come later.

Can I learn SRE without a big cloud bill? Largely, yes. Most milestones run on a local kind cluster with Prometheus, Grafana, OpenTelemetry, Argo CD, Backstage and Chaos Mesh; the infrastructure as code stage is the main one that touches real cloud resources.