ced4568andClaude Sonnet 5
de6c5b3286
root-12-real-ops gains a Detect -> Triage -> Diagnose -> Mitigate ->
Recover -> Verify -> Learn incident-response framing lesson at the
front of the existing 4-incident module, and a post-incident reflection
at the end — the incidents themselves are unchanged, still deliberately
un-guided ('you are responsible for this environment,' not 'complete
this exercise'). No fixes revealed; instructor notes carry the deeper
solution guidance the student-facing lesson intentionally withholds.
root-capstone-m02-capstone-readiness — a new READY orientation module:
what the Capstone measures, how the timed/randomized draw works, time
management and troubleshooting strategy under a clock, and a genuine
self-assessment checklist. Never publishes the current draw or answers.
See docs/ROOT_CAPSTONE_READINESS.md for why this module's completion is
deliberately independent of the real capstone's server-side unlock gate.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
48 lines
2.6 KiB
Markdown
48 lines
2.6 KiB
Markdown
# Post-Incident Reflection: What Real Ops Actually Feels Like
|
|
|
|
You just worked through four incidents that "own it, don't just complete it" framing described.
|
|
Take a few minutes to reflect on the module as a whole, not just any single incident.
|
|
|
|
## Reflection questions
|
|
|
|
1. Which of the four incidents took the longest to even understand what was actually wrong,
|
|
before you got to fixing anything? What made diagnosis slower there than the others?
|
|
2. `rootnode-runaway-monitor` and `rootnode-enforce-limits` are the same underlying incident,
|
|
split into "fix it now" and "prevent it forever." Which one did you find more satisfying to
|
|
solve, and why do you think real teams sometimes skip the second one under time pressure?
|
|
3. If you were handing these four incidents off to a teammate mid-shift, what's the one-sentence
|
|
summary you'd give for each, so they could pick up without re-diagnosing from scratch?
|
|
4. Compare how this module felt to the earlier, more guided modules in ROOT_. What specifically
|
|
was different about the experience, not just the difficulty?
|
|
|
|
## Real Ops takeaway
|
|
|
|
**"It's fixed" and "it won't happen again" are two different jobs, and skipping the second one
|
|
is how the same incident recurs.** `rootnode-enforce-limits` exists as its own scenario
|
|
specifically to make this point structurally, not just rhetorically — the immediate fix and the
|
|
prevention work are genuinely separate efforts, and a real team's incident isn't actually closed
|
|
until both are done.
|
|
|
|
**Being handed an unfamiliar, under-specified problem is the actual job.** Every other module in
|
|
ROOT_ told you roughly what concept you were about to practice. This one didn't — and that gap
|
|
is deliberate, because real production incidents don't come with a syllabus telling you which
|
|
concept they're testing. The framework from this module's opening lesson is what you reach for
|
|
instead of a hint system.
|
|
|
|
This module is complete. If a Capstone is part of your program, its readiness module is next.
|
|
|
|
## Instructor Notes
|
|
|
|
**Discussion questions for a live classroom:** question 2 is the module's core point — spend
|
|
real time on it rather than treating it as a quick check-the-box question.
|
|
|
|
**Approximate timing:** 10-12 minutes live discussion; 8 minutes self-paced writing.
|
|
|
|
**Optional extension:** ask students to identify which incident from this module most closely
|
|
resembles something they'd expect to encounter in an actual job, and why — grounds the module in
|
|
something beyond the classroom.
|
|
|
|
**Expected takeaway:** Real operational work is less about knowing every possible failure mode
|
|
in advance and more about having a repeatable process for approaching the ones you've never
|
|
seen before.
|