Field guide

1. 1
   Read the signals — then distrust them

   The ticket is vague, and sometimes wrong, on purpose — that's how real tickets arrive. Note what's claimed versus what you can actually verify.

2. 2
   Observe the real state before theorising

   Don't guess first; look. What's running, restarting, pending? Statuses and restart counts tell you where to point your attention.

3. 3
   Ask: what would have to be true?

   For this exact symptom, what could cause it? Form two or three hypotheses before you change anything.

4. 4
   Follow the system's own breadcrumbs

   The answer is usually already printed somewhere — in logs, in describe output, in events. Read them before you theorise further.

5. 5
   Change one thing, then re-verify

   One variable at a time. Re-deploy your edit and run bin/sim verify. If it didn't move the needle, undo it before trying the next idea.

6. 6
   Solved? Read the postmortem

   The senior writeup — and especially the 'class of bug' it belongs to — is the real lesson. The fix is the smallest part.

# docker / compose
$ docker compose ps                       # what's up / restarting?
$ docker compose logs -f <service>        # why did it die?
$ docker inspect <container>              # env, mounts, config

# kubernetes — your first three moves
$ kubectl get pods -n <ns>                # status, restarts, age
$ kubectl describe pod <pod> -n <ns>      # events at the bottom = gold
$ kubectl logs <pod> -n <ns>             # add -p (previous crash), -c (container)
$kubectl get events -n <ns> --sort-by=.lastTimestamp