Exercise 1: Why a "Mild" 60% Average Doesn't Tell the Whole Story — Possible Solution
====================================================================

THE UNDERLYING EVENT
------------------------------
Per this chapter's finding-box, "CPU usage spikes to 100% for 15
seconds - long enough to cause real request timeouts - then drops back
to normal." Something genuinely severe happened, briefly, and caused
real user-visible impact.

WHY AVERAGING PRODUCES A MISLEADING DISPLAY
------------------------------
Per this chapter, "averaged over a 5-minute window, that 15-second
spike might only nudge the displayed line up to a mild-looking 60%."
Averaging blends the 15 seconds of 100% usage together with the
remaining several minutes of normal, lower usage, mathematically
diluting the extreme value into something that looks unremarkable on
the graph.

WHY THIS ISN'T THE DASHBOARD "LYING"
------------------------------
Per this chapter, "the dashboard isn't lying, but the number it's
showing genuinely doesn't represent what actually happened at the
moment users felt it." The 60% figure is a mathematically accurate
average of the underlying data - the problem is that an average, by
its nature, isn't designed to preserve information about brief,
extreme values; it's designed to summarize a whole period into one
number, and that summary necessarily loses the moment-to-moment detail.

WHAT WOULD REVEAL THE REAL EVENT
------------------------------
Per this chapter, switching the same panel's aggregation from avg to
max over the same window would surface the actual 100% peak the
average smoothed away.

WHY THIS WORKS AS AN ANSWER
------------------------------
It explains the underlying severe-but-brief event, the mathematical
reason averaging dilutes it into an unremarkable-looking number, and
clarifies that this is an inherent property of averaging rather than
an error, using the chapter's own example throughout.