systematic-debugging

Start by reading the full error message and stack trace, then reproduce the failure consistently with a command like pytest -v. Check recent git changes, trace the data flow to the root cause, and only then form a hypothesis and write a regression test before fixing.

Root cause analysis means identifying why a bug occurs before attempting any fix, rather than patching symptoms. It involves reproducing the issue, gathering evidence at component boundaries, and tracing bad values upstream to their source.

Check all three firewall layers: the cloud firewall (GCP VPC rules, AWS security groups), the VM firewall (ufw or iptables), and whether the app is actually listening via ss -tulnp. GCP also drops hairpin traffic, so test reachability with an external port checker.

Stop after three failed fix attempts. If each fix reveals new coupling or creates symptoms elsewhere, the pattern indicates an architectural problem, and you should discuss refactoring with the team instead of attempting a fourth fix.

No. Simple bugs have root causes too, and skipping investigation leads to symptom patches that mask the real issue. The systematic process is fast for simple bugs and prevents rework from guess-and-check thrashing.