Your cart is empty.
Keep shopping
Observability & Production Support: Crack SRE Interviews
New
102 students
Observability & Production Support: Crack SRE Interviews
OpenTelemetry, golden signals, SLOs and burn-rate alerts — measured on one running system, ready for the 3 a.m. page.
Created byPrasad Dimba Anandappa
Last updated 10/2026
English
English
What you'll learn
- Explain why monitoring failed at 3 a.m. — and design observability that answers questions you did not pre-ask
- Instrument any service with the four golden signals, RED and USE — and read a baseline board signal by signal
- Use Prometheus safely: counters, histograms, recording discipline — and never ship the label that creates 1.3 billion series
- Structure logs that carry trace IDs, cost what the volume math says they cost, and choose ELK vs Loki with numbers
- Trace requests end to end with OpenTelemetry — spans, context propagation, exemplars — and sample without going blind (31 GB/day → 3.4 GB/day)
- Build Grafana dashboards as answers: the four-panel rule that replaces the 63-panel wall
- Alert on symptoms with multi-window burn rates — and delete the cause-based pages that fire on nothing
- Set SLOs and error budgets (99.9% = 43.2 minutes = 117,000 requests) and let the budget arbitrate release decisions
- Debug production incidents with a six-step method — symptom, scope, recent change, trace, mitigate, verify
- Answer observability and SRE system-design interviews with live arithmetic: scale, cardinality budgets, telemetry cost
Explore related topics
Course content
8 sections • 22 lectures • 2h 4m total length
Requirements
- You run (or help run) at least one service in production, staging, or a realistic staging-like environment — this course starts where "it works on my machine" ends
- Working familiarity with HTTP services and JSON; the project programs are standard-library Python and every listing is run on screen
- No Prometheus/Grafana/OpenTelemetry experience assumed — each tool is introduced at the lecture that first needs it; no paid tooling or cloud account required: every project artefact runs locally and deterministically
Description
This course contains the use of artificial intelligence.
Your dashboards were green. Your users were failing. That gap — between what your graphs said and what your customers felt — is where production careers are made and lost, and closing it is a learnable engineering discipline. This course teaches it the way it is practised: on one running system, with every claim measured on a board, a drill, or a trace you can read yourself.
**The core ten lectures** build the discipline in order: why monitoring is not observability; the four golden signals and the RED/USE methods that tell you what to measure first; Prometheus metrics without the cardinality trap that melts servers (one label, multiplied by 2.1 million users, is 1.3 billion series — you will do that multiplication yourself); logs that earn their keep, structured and carrying trace IDs; distributed tracing with OpenTelemetry; dashboards built as answers to questions instead of walls of charts; alerting that pages on symptoms, not causes; SLOs and error budgets — the numbers that end arguments between product and engineering; a six-step incident method; and the full-stack blueprint with its sampling and retention economics priced out.
**Then you work three production projects on SwiftCart, one running example system you reproduce locally from fixtures.** Project 1: you write the telemetry contract, census its twelve signal groups, build RED metrics and the four-panel Grafana dashboard — then run the load drill that finds the saturation wall at 150 requests per second in an afternoon, instead of letting the sale find it in production. Project 2: you price full trace capture (31 gigabytes a day), design the sampling policy that cuts it to 3.4, and hunt the incident through a single 53-span trace to the 47 database calls an N+1 deploy was hiding — then prove the fix on a signed before/after board. Project 3: you set a 99.9% SLO, turn its 43.2-minute error budget into burn-rate alerts that page at 14.4× and ticket at 3×, strike the four cause-based paging rules — including a CPU page that cried wolf eleven times in a month with zero user impact — and pass PagerGate, a five-gate ship board you will watch fail three sabotage drills on purpose.
**Then you crack the interview.** Four lectures with the arithmetic done live: observability for a payments platform at 5,000 requests per second (432 million requests a day, budgeted to the series), a 3 a.m. incident debugged minute-by-minute — paged at 03:12, rolled back by 03:23, about half a budget-minute spent (≈1.2% of the month's budget) — whiteboard SLO and telemetry-cost math, and a five-move playbook with a ten-question rapid-fire drawn from the whole course.
Every number in this course comes from the system on screen — census counts, drill boards, trace trees, budget tables. Nothing is asserted from memory. You also get downloadable code and exercise books, six quizzes — four checkpoints, an interview primer and a cumulative final, with a 70% mastery rule on the checkpoints and the final — five hands-on assignments with worked solutions, and a capstone: make your own production system observable, behind your own PagerGate.
AI disclosure: this course's narration uses a cloned voice of the instructor, created with the instructor's consent; all content, code, and curriculum are authored and verified by the instructor team.
Who this course is for:
- Backend and platform engineers who own services in production and are tired of green dashboards during incidents
- SREs and production-support engineers formalising signals, SLOs and alerting in a team that pages too much (or learns from users)
- Technical leads who need defensible numbers for observability architecture, sampling and telemetry-cost decisions
- Engineers preparing for SRE / platform / production-support interviews who want measured answers, not memorised diagrams