Exercise 3: CPU and Error Rate Spiking Together — Cause or Symptom? — Possible Solution
====================================================================

Why simultaneous timing alone doesn't establish which caused which:

Two metrics moving at the same time only tells you they're
CORRELATED in time -- it says nothing about the DIRECTION of any
causal relationship between them, or whether either one actually
caused the other at all (they could both be downstream effects of some
third, unobserved cause). Per the chapter's own example: CPU spiking
exactly when errors started could just as easily mean the ERRORS are
causing extra retries and additional load (making CPU usage a SYMPTOM
of the errors), rather than high CPU causing the errors in the first
place (which would make CPU usage the CAUSE). Simultaneous timing is
consistent with either explanation equally -- it can't distinguish
between them on its own.

Additional evidence that would help distinguish cause from symptom:

1. WHAT CHANGED FIRST, with finer time resolution. Per the chapter's
   own recommended discipline, zooming into the timeline at a finer
   granularity (seconds rather than minutes, if the monitoring data
   supports it) to see whether the error rate's very first uptick
   genuinely precedes the CPU spike, or vice versa -- true root causes
   tend to lead their downstream symptoms by at least a small margin,
   even if it isn't obvious at a coarser time resolution.

2. WHETHER THE ERRORS SPECIFICALLY LOOK LIKE RETRY BEHAVIOR. If the
   error logs show repeated, similar-looking failed requests for the
   same underlying operations in a pattern consistent with automatic
   retry logic, that supports the "errors are causing extra load"
   direction (errors -> retries -> more CPU), rather than the reverse.

3. WHETHER CPU WAS ALREADY TRENDING ABNORMALLY BEFORE THE VISIBLE
   SPIKE. If CPU usage was already climbing gradually for some time
   before the sharp spike coincided with the error rate increase, that
   would support CPU pressure as the genuine root cause rather than a
   symptom that appeared only in immediate response to the errors.

4. TESTING THE HYPOTHESIS DIRECTLY, if safely possible -- for example,
   checking whether reducing retry volume (if that's plausible as the
   mechanism) causes CPU usage to drop independently of whether the
   original error cause has been fixed, which would confirm the
   errors-cause-CPU-load direction specifically.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly explains WHY correlation alone is ambiguous (both causal
directions are equally consistent with simultaneous timing) using the
chapter's own worked example, then offers concrete, checkable evidence
types -- finer-grained sequencing, retry-pattern recognition in logs,
pre-existing trend data, and direct hypothesis testing -- that go
beyond just restating "look for what changed first" as an unexplained
rule.