grceng.academy
YAML lab 50 bonus XP

Specify incident response as code

Start labRead the room

Objectives

Three runbooks contradict each other, severity is decided by whoever sounds most alarmed, and the last postmortem's recommendations were 'kept impersonal', so nobody owned them. The on-call rota is a screenshot in the wiki.

Write the specification for response-as-code: versioned runbooks rendered to the incident channel, a declared severity matrix, the rota as data, and postmortems that land as tracked changes.

Current state (from the postmortem)

runbooks: wiki + google docs + slack screenshots (3 versions, contradictory)
severity: decided on the call, "based on impact"
on-call: wiki screenshot of a rota, updated manually
postmortems: 40-page docs; recommendations "impersonal", unowned
regulatory_clock: started 2 days late on the last restricted-data event

Checks the server runs (7)

  • Runbooks live in version control with review
  • Current runbook is rendered where responders look
  • Severity comes from a declared matrix on two axes
  • On-call rota is machine-readable data
  • Postmortem recommendations become owned action items
  • The postmortem updates the runbook it exercised
  • Severity that triggers a regulatory clock is declared, not felt

Check names are all you see here: the expectations that decide pass or fail, and the reference solution, stay on the server.

Step-by-step hints

The guided walkthrough, in full. It is free: no XP cost, and it does not touch the paid hint ladder or the reveal gate.

  1. Step 1

    One runbook, one source of truth

    Three contradictory runbooks cost the responder the search and the guess. Version control with review gives one current version; rendering it to the incident channel puts it where the responder already is.

    Runbooks live in version control with reviewCurrent runbook is rendered where responders look

  2. Step 2

    Severity as a lookup

    Replace the alarm-based call with a declared matrix: scope of impact on one axis, data sensitivity on the other. The level decides the page, and the decision is defensible afterwards.

    Severity comes from a declared matrix on two axes

  3. Step 3

    The rota is data

    A screenshot of a rota cannot be paged programmatically and cannot be validated. As data, 'who do I page' is a lookup with an answer you can test.

    On-call rota is machine-readable data

  4. Step 4

    The postmortem changes the system

    Recommendations become action items with owners, the runbook that was just exercised gets the commit, and severities carrying regulatory clocks are named in the matrix so the timer starts on declaration, not on someone's follow-up email.

    Postmortem recommendations become owned action itemsThe postmortem updates the runbook it exercisedSeverity that triggers a regulatory clock is declared, not felt

Rules summary

  • XP on pass

    50 bonus XP the first time every check goes green.

  • Paid hints

    2 available. Each costs 25% of the lab XP (about 13 XP).

  • Reveal solution

    Scores 0 XP and unlocks only after 3 check runs.

  • Attempt cap

    60 check runs per learner. The runner warns you in the last 10.

  • Drafts

    Your editor content is saved in this browser, so a reload will not lose work.

  • Walkthrough

    Always free and never penalised: use it before spending a hint.