Exercise 3: What the perfdiag1 Capstone Demonstrates About Stopping at "Mitigated" — Possible Solution ==================================================================== WHAT THE perfdiag1 CAPSTONE SCENARIO WAS ------------------------------ Per this chapter, "System Monitoring & Performance Diagnosis's own capstone shows exactly this pattern taken to its natural extreme - weeks of nightly restarts masking a genuine memory leak, never actually fixed because the mitigation kept working well enough that nobody circled back." A nightly restart (a mitigation) kept relieving the symptom every single day, well enough that the underlying leak (the actual root cause) was never diagnosed or fixed. WHY THIS DEMONSTRATES THE RISK OF STOPPING AT "MITIGATED" ------------------------------ Per this chapter, "once the immediate pain stops, there's a strong pull to treat the incident as closed and move on, leaving the actual root cause never properly diagnosed." The nightly restart was "successful" in the narrow sense that it kept the symptom from causing a real outage each night - which is exactly what made it so easy to never revisit. A mitigation that works reliably removes the visible pressure to ever return and do the actual fix. WHY THIS ISN'T A ONE-TIME MISTAKE BUT AN ONGOING RISK ------------------------------ Unlike a single incident where someone might simply forget to follow up once, the perfdiag1 example shows this failure mode compounding over weeks - each successful nightly restart reinforced the appearance that everything was fine, making it progressively less likely anyone would question the pattern, until the underlying leak eventually grew severe enough to matter regardless. WHY THIS WORKS AS AN ANSWER ------------------------------ It accurately describes the perfdiag1 scenario the chapter references, explains specifically how a working mitigation removes the pressure to pursue the actual fix, and explains why this risk compounds rather than being a single isolated mistake.