Troubleshooting
Method before tools
Use a repeatable method: gather symptoms, identify the problem, form a hypothesis, test it, plan and implement the fix, verify service, and document. Compare against a known-good baseline and correlate with recent changes; most incidents follow a change. Work the layers: provider or physical, network, host, application. Top-down starts at the user symptom; bottom-up starts at the link; divide and conquer narrows the path. Change one variable at a time.
Evidence
Metrics show trends, logs show events, traces show a request across services. Confirm time synchronization, DNS resolution, certificate validity, routing, and quota limits before assuming a code bug. Distinguish latency, bandwidth, and throughput. Packet captures and health-check results are evidence, not guesses. Check autoscaling limits, connection pools, and noisy-neighbor effects under load.
Recover and learn
Stabilize first: roll back, fail over, or scale out, then find root cause. Use 5 Whys or a fishbone diagram, record the known error, and update runbooks and monitoring. Escalate with clean evidence and a timeline.
Traps
Jumping to a fix, ignoring the last change, blaming the provider before checking configuration, confusing latency with bandwidth, and closing without verifying the user's experience. Restarting everything destroys evidence and may spread the fault.
Worked example
Users see intermittent 500 errors only at peak. Check the timeline against deployments, then examine error rate, latency, and saturation. Suppose the autoscaling maximum is too low and the database connection pool is exhausted. Raise the maximum, increase the pool within database limits, tune health-check grace periods, and load-test to verify. Rule of thumb: stabilize, then explain; verify before you close.