Troubleshooting
Method
Use a structured path: identify the problem and gather information (user questions, logs, recent changes), establish a theory by questioning the obvious, test the theory, plan the fix including downtime and rollback, implement, verify full functionality, and document. Change one variable at a time and escalate when the issue is outside your scope or data is at risk.
Hardware and boot
No POST: verify power at the outlet, PSU LED, and power button; reseat components; try a minimal configuration; listen for beep codes and use a POST card. Memory faults: reseat or replace DIMMs one at a time and check ECC logs. Thermal shutdowns: inspect fans, dust, airflow, and ambient temperature. Degraded RAID: identify the failed member, replace the hot-swap drive, confirm the rebuild completes, then monitor. Storage errors: check SMART data, cabling, and backplane seating.
OS, network, and performance
Boot failures: check boot order, bootloader, recovery console or safe mode, and recent updates. Blue screens and kernel panics: read the stop code, then suspect drivers or memory. A service that will not start: check Event Viewer or journalctl/dmesg, port conflicts, permissions, and dependencies. Network faults start at layer 1 - link lights, cable tester, swap the patch cable - then ipconfig/ifconfig, ping the gateway, tracert, and nslookup before blaming firewall or VLAN configuration. For slowness, compare against the baseline: high CPU, memory paging, disk queue length, or a saturated NIC; the bottleneck is usually the resource pinned at 100%.
Traps: swapping parts before testing a theory; skipping verification and documentation; treating a reboot as a permanent fix; overlooking simple causes such as an unplugged cable, an expired certificate, or a full disk.
Worked example: users report an application is "down." Ping succeeds, so the network is fine; the service is stopped, and Event Viewer shows the data volume is full. Clear space, restart the service, verify, then document the root cause.