Define reliability
Choose user journeys, SLIs, SLOs and error budgets that represent real service expectations.
SRE / Reliability Engineering Fundamentals · SRE-FND
Engineer reliability as a measurable production system.
Learn Site Reliability Engineering from first principles: define user-focused reliability, measure SLIs, set SLOs and error budgets, build actionable alerts, design sustainable on-call and incident response, plan capacity, contain failure and turn postmortems and toil into engineering improvements.
My Learning progress
0% complete
0 of 12 curriculum modules completed · 0/12 currently published modules complete · 0 with lab + knowledge-check evidence.
LevelFundamentals · intermediate foundation
Required foundationLinux · HTTP/networking · containers/Kubernetes concepts · CI/CD · basic observability
Typical time~14–16 hours including active labs · capstone 2–3 hours
Labs12 account-free core labs + optional real-tool practica
Assessment30 questions · ≥14 scenarios · 35 min · pass ≥75%
CertificationOptional · ₹499 incl. GST
Learner outcomes
After this course, you should be able to build and defend a practical reliability operating model.
The course is not a monitoring-tool tutorial. It connects user expectations to measurable objectives, alerts, response, recovery and engineering improvement.
Detect and respond
Use golden signals, burn-rate alerting, on-call, incident roles, runbooks and verification to reduce user impact.
Engineer resilience
Plan capacity, bound retries, control overload, degrade safely and evaluate canary/rollback evidence.
Improve the system
Use blameless postmortems, corrective actions and toil measurements to drive a reliability roadmap.
Before you begin
Prerequisites are explicit.
You do not need prior SRE experience, but this course assumes basic production-system vocabulary so the learning time can focus on reliability decisions.
Recommended knowledge
- Linux command line and basic TCP/IP/HTTP
- Containers and Kubernetes concepts
- CI/CD and rollback concepts
- Basic cloud/runtime architecture
- Metrics, logs and traces at an introductory level
This course is not
- A Prometheus administration course
- A Kubernetes troubleshooting course
- An incident-management product tutorial
- A promise that every organization should copy Google’s exact SRE model
- A substitute for hands-on production experience
Core lab environment
Linux, macOS or Windows 11+WSL2 with bash and Python 3. Core labs are account-free. Optional Prometheus practica use Docker Compose and a disposable local demo service.
Recommended Academy preparation
SRE builds on capabilities already taught across the engineering path.
Review the prerequisite course when an underlying delivery, runtime or observability concept is unfamiliar.
Linux →Kubernetes →CI/CD →Cloud Infrastructure →Observability →DevSecOps →Platform Engineering→ SRE / Reliability Engineering
Running case study
Use one checkout service across all 12 modules.
The same critical journey—customer checkout through an edge/API layer, checkout service and payment dependency—carries forward from SLI design through burn-rate alerting, incident response, capacity, resilience and postmortem learning.
Downloadable SRE Lab Pack
The pack contains the disposable Prometheus demo, setup/cleanup scripts and capstone validator so website learners are not dependent on a source checkout.
Download lab packCore vs real-tool
Every module keeps an account-free core exercise. Prometheus practica are deliberately prominent where seeing real reconciliation, latency, burn or recovery evidence changes the learning outcome.
One evidence chain
Carry the checkout SLI, objective, alert decision, incident evidence and follow-up reasoning forward rather than treating each module as an isolated worksheet.
Learning sequence
User expectation first. Objective second. Operations around the objective.
The sequence deliberately moves from risk and measurement to alerting/response, then into capacity, resilience and continuous improvement.
SRE mindset: reliability, risk and toil
Understand SRE as a software-engineering approach to operations: define acceptable risk, protect engineering time, reduce toil and use reliability evidence to balance change with user impact.
Open module →SLIs: measure the user journey
Translate user expectations into service level indicators based on good events, valid events, latency, correctness and other observable outcomes instead of infrastructure convenience metrics.
Open module →SLOs and error budgets
Set user-focused reliability targets, calculate the allowable bad-event budget exactly, define an error-budget policy and use the result to guide engineering decisions rather than as a ceremonial percentage.
Open module →Monitoring signals and observability
Use black-box and white-box evidence, the four golden signals and symptom-versus-cause reasoning to build monitoring that supports reliability decisions instead of accumulating dashboards.
Open module →SLO-based alerting and burn rate
Design alerts that page on actionable threats to reliability objectives, calculate burn rate and use multiple windows to distinguish fast outages from slower budget erosion.
Open module →On-call, escalation and handoffs
Design sustainable on-call coverage with actionable pages, explicit escalation, handoff discipline, responder safety and enough context for the person receiving the page to act.
Open module →Incident response and severity
Coordinate incidents around impact, mitigation, roles and communication so responders reduce user harm quickly while preserving a clear timeline for later learning.
Open module →Troubleshooting, runbooks and automation
Use hypothesis-driven troubleshooting, change correlation, layered evidence and executable runbooks to shorten incidents without turning procedural documents into brittle magic.
Open module →Capacity, performance and overload
Forecast demand, preserve headroom, recognize saturation early and design overload behaviour so a system degrades intentionally rather than collapsing unpredictably.
Open module →Resilience, safe change and recovery
Design systems and delivery practices that contain failure: timeouts, bounded retries, isolation, graceful degradation, canaries, rollback and recovery objectives tied to tested evidence.
Open module →Postmortems, toil and reliability improvement
Turn incidents into system learning through blameless analysis, evidence-backed action items, toil reduction and a reliability roadmap that actually changes future behaviour.
Open module →Capstone: production reliability system
Assemble a defensible reliability operating model for one service: user journey, SLI/SLO, error budget, alerting, on-call, incident workflow, capacity, safe change, runbook and postmortem evidence.
Open module →Real-tool practicum
Core concepts remain account-free; key modules can be exercised against a disposable Prometheus lab.
The local lab runs a tiny deterministic HTTP service and Prometheus so learners can generate healthy, failed and slow requests, inspect SLIs, query burn rate and validate recording/alert rules.
One-command local substrate
./ops/setup-sre-local-lab.shStarts gnu-sre-demo on port 8000 and gnu-sre-prometheus on port 9090. Cleanup: ./ops/cleanup-sre-local-lab.sh.
Measure
Modules 02–04 query request, error and latency evidence from a real Prometheus instance.
Alert
Module 05 validates SLO/burn rules with promtool and inspects the current burn-rate series.
Respond
Modules 07, 10 and 12 inject controlled local failures, verify recovery and preserve evidence for the incident/capstone workflow.
Learning modules
FREE
All 12 modules are available without purchasing a certificate.
Hands-on labs
FREE
Core labs and provided disposable local-lab scripts are part of the learning experience.
Assessment
FREE
30 randomized questions, 35-minute server timer, pass mark ≥75%, maximum 2 attempts per 24 hours.
Certificate
OPTIONAL · ₹499 incl. GST
Purchase is only for certification after a qualifying timed assessment result; learning, labs and assessment remain free. The certificate records Academy assessment completion and is not vendor accreditation or a professional licence.
Course stewardship
Curriculum maintained by GNU Group Learning Academy. A named instructor/author profile should only be published when the role, biography and credentials have been verified for public use.
Reference model
The curriculum uses established SRE concepts such as user-focused SLOs, error budgets, the four golden signals, multiwindow burn-rate alerting, incident management, blameless postmortems and toil reduction while keeping implementation choices vendor-neutral.
Production principle
A green dashboard or successful deployment is never sufficient by itself. Reliability decisions must connect to the affected user journey and explicit objective.
Primary references
Use the course with the primary material: Google SRE — Monitoring Distributed Systems, Alerting on SLOs, Incident Management Guide, and Prometheus 3.15 documentation.
Knowledge assessment
Prove you can make reliability decisions, not just expand SRE acronyms.
30 questions are selected from an 84-question bank across seven domains. The bank contains 42 scenario/application questions and each attempt is guaranteed at least 14 scenarios while retaining category quotas.
12 MODULES→30 QUESTIONS · ≥14 SCENARIOS→35 MIN · PASS ≥75%→2 ATTEMPTS / 24H→OPTIONAL CERTIFICATION
2–3 hour reliability capstone
Build and defend one end-to-end reliability operating model.
The capstone validates one coherent chain from user journey and SLI to SLO/error budget, burn alert, on-call, incident mitigation, recovery verification, capacity/resilience evidence and postmortem actions. Tool screenshots alone are not sufficient. It is a formative self/peer/instructor-reviewed exercise; certificate eligibility is based on the timed assessment, not the capstone validator.
User journey→SLI/SLO→Alert→Incident→Recover→Learn