Exercise 3: What Should Trigger Promoting a Ticket Into a Runbook — Possible Solution ==================================================================== THE SPECIFIC TRIGGER, PER THIS CHAPTER ------------------------------ Per this chapter, "once the same problem recurs - the specific pattern incident1's own material teaches recognizing - that recurring pattern deserves promotion into a genuine runbook." The trigger isn't "this was a difficult problem" or "this took a long time to resolve" - it's specifically recurrence: the same issue showing up more than once. WHY A SINGLE OCCURRENCE DOESN'T JUSTIFY A RUNBOOK YET ------------------------------ Per this chapter's own definitions, a runbook is meant to be "general, durable" and "reusable" - properties that can't really be verified from a single instance. Writing a runbook after the very first occurrence means generalizing from exactly one data point: there's no way yet to know whether this specific sequence of steps would actually apply the next time, or whether this incident was a one-off with its own unique circumstances that won't recur in the same shape. WHY WRITING ONE TOO EARLY IS A REAL COST, NOT JUST WASTED EFFORT ------------------------------ A runbook written from a single incident risks being subtly wrong or incomplete for the actual range of situations the real recurring problem produces - the next occurrence might differ in a detail the premature runbook didn't anticipate, undermining trust in the document exactly the way Chapter 1's own stale-runbook scenario did, just for a different underlying reason (written too early and too narrowly, rather than decayed over time). WHY WAITING FOR RECURRENCE ACTUALLY PRODUCES A BETTER RUNBOOK ------------------------------ By the time a problem has genuinely recurred, there's real evidence about what stays consistent across occurrences and what varies - information a single ticket alone can't provide. A runbook written from that accumulated pattern is more likely to actually generalize correctly to the next occurrence than one guessed at from a single event. WHY THIS WORKS AS AN ANSWER ------------------------------ It states the specific trigger this chapter names (recurrence, not difficulty or duration), explains why a runbook's own claimed reusability can't be verified from one instance, and explains why waiting for genuine recurrence produces a more reliable document than writing one prematurely.