ced4568andClaude Sonnet 5
831486d664
The Phase 6A gold-standard Health Probes module is preserved byte-for- byte unchanged — it's the template, not a page to rewrite for consistency. root-10-m03-troubleshooting-framework — a new PARTIAL module introducing a repeatable Observe -> Gather Evidence -> Form Hypothesis -> Test -> Repair -> Validate -> Prevent Recurrence framework, applied to a CrashLoopBackOff and a broken Service selector. Lesson, demonstration (the full framework walked through a real CrashLoopBackOff, command by command), knowledge check, and real Labs (crashloop-fix, endpoint-fix-task). Sequenced between the gold module and the existing bare-lab bank, which now sits behind it. Co-Authored-By: Claude Sonnet 5 <[email protected]>
51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
# Knowledge Check: The Troubleshooting Framework
|
|
|
|
---
|
|
|
|
**1. You spot what looks like an obvious typo causing a failure and fix it immediately without
|
|
writing down a hypothesis first. What's the actual cost of skipping that step, even if the fix
|
|
works?**
|
|
|
|
*Answer:* You don't get a confirmed, testable claim about the cause — if the fix happens to
|
|
"work" for an unrelated reason (a coincidental restart, a different underlying issue also
|
|
resolving), you'd have no way to distinguish that from your fix actually being correct. The
|
|
hypothesis step is what makes Validate meaningful.
|
|
|
|
---
|
|
|
|
**2. During the "Gather Evidence" step for a CrashLoopBackOff, which two commands give you the
|
|
most direct evidence, and what does each one tell you that the other doesn't?**
|
|
|
|
*Answer:* `kubectl logs` (what the container itself printed, if anything, before exiting) and
|
|
`kubectl describe pod`/`describe deployment` (the container's actual configuration, plus recent
|
|
Events). Logs show application-level output; describe/Events show what Kubernetes itself
|
|
observed and configured — a crash with no logs at all often means the failure happened before
|
|
the application could log anything, which describe/Events can still reveal.
|
|
|
|
---
|
|
|
|
**3. True or false: "Prevent Recurrence" only applies to major incidents, not small
|
|
one-off mistakes like a typo.**
|
|
|
|
*Answer:* False. A small mistake that recurs repeatedly across a team becomes a real, ongoing
|
|
cost even if no single instance is severe — the framework applies the same reasoning regardless
|
|
of incident size: could a small, structural change catch this earlier next time?
|
|
|
|
---
|
|
|
|
**4. A broken Service selector (endpoint-fix-task's scenario) and a CrashLoopBackOff
|
|
(crashloop-fix's scenario) are very different failures. What's the SAME about how you'd
|
|
approach both?**
|
|
|
|
*Answer:* The same seven-step framework — Observe the specific symptom, Gather Evidence before
|
|
guessing, form a specific testable Hypothesis, Test it, make the minimal Repair the evidence
|
|
supports, Validate with the same kind of evidence you started with, and consider how to Prevent
|
|
Recurrence. The framework doesn't change; only the specific commands and evidence do.
|
|
|
|
## Instructor Notes
|
|
|
|
**Facilitation:** Question 4 is the whole point of this module — make sure it's discussed even
|
|
if answered correctly, since it's the transferability claim the entire framework rests on.
|
|
|
|
**Approximate timing:** 5-7 minutes.
|