Infrastructure & Reliability · Chapter 6 of 8
Debugging that transfers
One method, applied to every resource. It turns troubleshooting from intuition into a checklist you can hand to someone else.
The most valuable skill in infrastructure is not knowing a particular system — it is having a method that works on a system you have never seen. The USE method is that: for every resource, check utilisation, saturation and errors.
Applying it
| Resource | Utilisation | Saturation | Errors |
|---|---|---|---|
| CPU | percent busy | run queue length, pressure stall | throttling |
| Memory | used | swapping, reclaim, OOM kills | ECC errors |
| Disk | percent busy | queue depth, await | I/O errors, retries |
| Network | bits per second | interface discards | CRC errors, drops |
The column that matters is saturation, and it is the one almost never on the default dashboard.
Two habits worth more than any tool
- Diff against a working comparator. If identical hosts exist and one is slow, mechanically compare everything — firmware, kernel parameters, negotiated link speed, memory population. The difference is nearly always in that diff, and finding it that way is much faster than reasoning about it.
- Reason from the timing signature. Failing at a consistent elapsed time suggests something thermal or accumulating; failing at a consistent iteration suggests code; failing at a consistent time of day suggests a scheduled job or a neighbour.