The best embedded debugging loop I have found is not complicated: preserve the symptom, narrow the surface area, then make the device tell you what changed.
That usually means starting with the boot path, service ownership, kernel logs, device-tree assumptions, and the first measurable point where expected behavior diverges from actual behavior.
symptom -> boundary -> signal -> hypothesis -> patch -> repeatThe hard part is not inventing a clever theory. The hard part is collecting a signal clean enough that the next experiment has fewer possible explanations.
For long-lived devices, a good debug loop should also leave behind something durable: a metric, a test, a trace point, or a dashboard that makes the next failure cheaper.