Triage and recover postmortems

Map failure classes for summarization service: retryable vs fatal vs needs-human. Retries need budgets, jitter, and idempotency rules aligned to actions are owned, dated, verifiable; contributing factors include process not only code. The chapter’s signature failure — action 'be more careful' with no owner — recurrence in 6 weeks — must take a deliberate branch, not a generic catch-all.

Implement the degrade/rollback/refuse behavior EM facilitating review of INC-SUM-TOK-87 needs when INC-SUM-TOK-87 repeats. Prefer scoped controls (one flag, one weight, one tenant, one secret version) over fleet-wide restarts. Preserve evidence; do not delete logs to “clean the demo.”

Paging only on CPU — missed application 5xx for 9 minutes.

After containment, check actions_closed_on_time and recurrence_90d moves in the safe direction and watch for retry amplification. Write the stop condition that ends the incident response for this lab.

Chaos note: inject only one fault class at a time and restore fixtures after. Watch for dual failures — dependency down and retry amplifier — which is how action 'be more careful' with no owner — recurrence in 6 weeks becomes an outage. Customer communication templates (even if only for the drill) beat silence. If you queue deferred work, define poison-message handling. Budget documents should state the maximum extra spend allowed during retries. Close the loop by linking the containment action to a dashboard panel for actions_closed_on_time and recurrence_90d.

Draw a state diagram for degrade modes and put it in the repo as ASCII if needed. Cap concurrent retries across the process, not only per request. Ensure cancellation propagates to downstream HTTP clients. When failing closed, choose a user-visible message that does not leak internals. Practice the single command that flips the kill switch or weight to zero. After recovery, drain or inspect deferred work before declaring green. In this chapter the product is blameless postmortem for tokenizer-induced summarization outage, the human stakeholder is EM facilitating review of INC-SUM-TOK-87, and the incident id you design against is INC-SUM-TOK-87. Re-state the oracle in your notes — postmortem published with 3 actions; action A1 verified by test that fails on old tokenizer pin — and keep the invariant visible: actions are owned, dated, verifiable; contributing factors include process not only code. Track actions_closed_on_time and recurrence_90d as the scoreboard. Surface under change control: summarization service. If you only have forty minutes, finish the fixture for action 'be more careful' with no owner — recurrence in 6 weeks before polishing UI. Promotion language stays ternary: promote, hold, or roll back based on evidence, not hope.