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.
Carry the same user journey forward: customer → edge/API → checkout → payment. Reuse prior SLI/SLO, alert, incident and recovery decisions where relevant so this module adds evidence to one reliability system rather than starting from zero.
The capstone is relationship-aware. The user journey, SLI, SLO, burn alert, incident severity, recovery check and postmortem must describe the same reliability concern.
A disconnected dashboard or generic runbook is not enough.
A reviewer should be able to inspect the event population, objective, observed failures, alert decision, incident timeline, rollback evidence and follow-up actions without relying on the learner’s narrative alone.
Make assumptions explicit and keep calculations reproducible.
The final design needs ownership, escalation, safe access, capacity headroom, rollback, recovery objectives and corrective-action tracking. Reliability is a socio-technical system, not a monitoring feature.
The relationship-aware validator checks structural consistency, but it cannot judge whether the chosen SLO, severity decision or resilience trade-off is appropriate. Use the rubric for self-review, peer review or instructor review.
For this Academy release, certificate eligibility is determined by the timed assessment and payment/issuance workflow; the capstone is recommended learning evidence and is not an additional automated pass/fail requirement.
Journey → SLI → SLO/error budget → burn alert → on-call → incident → mitigation → SLI recovery → postmortem → reliability backlogGoal: Run the supplied relationship-aware validator against a production-shaped reliability record.
if [ -f labs/sre-capstone/reliability.example.json ]; then
cp labs/sre-capstone/reliability.example.json /tmp/reliability.json
cp labs/sre-capstone/validate_reliability.py /tmp/validate_reliability.py
else
curl -fsS https://learn.gnugroup.org/academy/labs/sre/reliability.example.json -o /tmp/reliability.json
curl -fsS https://learn.gnugroup.org/academy/labs/sre/validate_reliability.py -o /tmp/validate_reliability.py
fipython3 /tmp/validate_reliability.py /tmp/reliability.jsonpython3 - <<'PY2'
import json
p='/tmp/reliability.json'
x=json.load(open(p))
x['incident']['recovery_sli']='wrong-sli'
json.dump(x,open('/tmp/reliability-bad.json','w'),indent=2)
PY2
python3 /tmp/validate_reliability.py /tmp/reliability-bad.json || echo 'expected: validator rejected inconsistent recovery evidence'Write a 150–250 word defense covering: why the SLI represents the user journey; why the SLO/error-budget policy is appropriate; why the alert deserves its urgency; and which rollback/recovery evidence would change your decision. The validator cannot grade this reasoning—use the rubric for self/peer/instructor review.
The capstone demonstrates that reliability is a connected operating system of objectives, telemetry, decisions, responders and learning—not a collection of isolated practices.
Start the demo service and Prometheus, inject failure, inspect burn, recover and save the evidence.
./ops/setup-sre-local-lab.shfor i in $(seq 1 20); do curl -s -o /dev/null http://127.0.0.1:8000/fail || true; donecurl -fsS http://127.0.0.1:9090/api/v1/query --get --data-urlencode 'query=sre_demo:burn_rate:1m' > /tmp/sre-burn.jsonfor i in $(seq 1 50); do curl -s -o /dev/null http://127.0.0.1:8000/ok; donecp labs/sre-capstone/reliability.example.json /tmp/reliability.json && python3 labs/sre-capstone/validate_reliability.py /tmp/reliability.jsonCritical user journey, valid/good event definitions, measurement location and limitations.
Target/window, exact budget calculation, stakeholders and policy actions.
Golden-signal context, burn-rate alert, urgency/actionability and low-traffic considerations.
Ownership, escalation, severity, roles, timeline, mitigation and communication.
Headroom, overload controls, timeout/retry policy, graceful degradation and safe-change rollback.
Symptom-first hypotheses, discriminating checks, safe actions, verification and escalation.
Blameless causal analysis, accountable actions, toil/reliability roadmap and verification metrics.
Three concept checks plus one scenario check.
The user journey, SLI, SLO, alerts, incident recovery and learning evidence must refer to a coherent reliability objective.
It does not prove the event population, objective, alert decision, response ownership, recovery or corrective-action relationships.
At minimum ownership, alert/response policy, escalation, mitigation/rollback, capacity/recovery context and measurable follow-up.
No. Recovery must be verified against the affected user-facing service indicator or another explicitly justified recovery criterion.
Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.
Attempt the core lab and knowledge checks before marking the module complete.