Exercise 1: How Ticket 1's Scoping Answers Narrowed Things Before top — Possible Solution ==================================================================== THE FOUR ANSWERS ------------------------------ Per this chapter, "one machine (not the whole pool), sudden onset, correlating with a known event - yesterday's deploy." WHY "ONE MACHINE, NOT THE POOL" RULED OUT SHARED CAUSES ------------------------------ Per Chapter 1's own reasoning, many machines affected would point toward a shared cause (a database, a shared dependency, a network issue); since only one of eight pool members was affected, the cause was very likely specific to that one machine's own current state - not something upstream or shared across the whole pool. WHY "SUDDEN ONSET TIED TO A DEPLOY" POINTED AT SOMETHING SPECIFIC ------------------------------ Per Chapter 1, a sudden change points toward a specific triggering event rather than a slow capacity drift, and a known event happening at the same time is often the actual explanation. Since the slowness started right when yesterday's deploy went out, and only on the machine(s) actually running the new code, the deploy itself became the leading candidate before any resource metric was even checked. WHAT THIS NARROWED THE INVESTIGATION TO, BEFORE top ------------------------------ By the time load average was checked (Chapter 2) and top was run (Chapter 8), the scoping answers had already narrowed the search to "something specific to this one machine, introduced by yesterday's deploy" - so finding a CPU-bound process from the new deploy version confirmed a theory the scoping questions had already pointed toward, rather than being found through blind searching. WHY THIS WORKS AS AN ANSWER ------------------------------ It states the specific scoping answers from the ticket, explains what each one ruled in or out per Chapter 1's own reasoning, and connects that narrowing to why the later technical checks confirmed rather than discovered the direction of the investigation.