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]>
2.4 KiB
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.