Exercise 2: Why Tying Updates to the Change Process Would Have Prevented the Outage — Possible Solution ==================================================================== WHAT ACTUALLY WENT WRONG, PER THE RESOLUTION ------------------------------ Per this chapter, "the migration's own checklist never included 'update the runbook' as a step - the documentation quietly drifted out of sync with reality, completely undetected, until the exact moment a real outage depended on it being correct." The server was decommissioned as part of a planned, deliberate migration - a known event, not a surprise - but nothing in that migration's own process connected it to the runbook that referenced the old hostname. WHY A "LAST REVIEWED" DATE ALONE WOULDN'T HAVE CAUGHT THIS ------------------------------ A "last reviewed" date only helps if someone actually performs a review before the document is needed - it's a passive signal, not an active trigger. Nothing about the migration itself would have prompted anyone to go check the runbook's own review date, or to notice it was overdue, unless a review happened to be scheduled at exactly the right moment purely by coincidence. The date can sit accurately reflecting "reviewed 11 months ago" for as long as nobody happens to look at it. WHY TYING UPDATES TO THE CHANGE PROCESS ITSELF CLOSES THAT GAP ------------------------------ If "update any documentation referencing this system" were a required step on the migration's own checklist, the update would have happened at the exact moment the underlying reality changed - during the migration itself - rather than depending on someone unrelated later noticing a stale review date or stumbling onto the outdated reference by accident. The trigger becomes the actual event that caused the document to become wrong, not a separate, disconnected schedule that has no direct relationship to when systems actually change. WHY THIS IS A FUNDAMENTALLY DIFFERENT KIND OF SAFEGUARD ------------------------------ A review cadence and a "last reviewed" date are periodic and passive - they catch decay eventually, on a schedule, regardless of when it actually occurred. Tying updates into the change process is event- driven and active - it catches decay at its actual source, the moment the underlying system changes, closing the gap between "the world changed" and "the documentation still says the old thing" almost immediately rather than leaving it open until the next scheduled review, if one even happens to land before the document is needed. WHY THIS WORKS AS AN ANSWER ------------------------------ It restates exactly what went wrong (the migration checklist never included a documentation-update step), explains why a passive review date wouldn't reliably have caught this specific gap, and explains why an event-driven safeguard tied to the change itself addresses the actual root cause more directly.