CompTIA Seven-Step Troubleshooting Model
Step 1 — Identify the problem: Gather information from users and systems. Ask: What changed? When did it start? Who is affected? What error messages appear? Check logs, monitoring systems, and alerts. Step 2 — Establish a theory of probable cause: Hypothesize the most likely cause based on symptoms. Use OSI model bottom-up: check physical first (Layer 1), then Layer 2, then higher layers. Or top-down for application issues. Question the obvious.
Step 3 — Test the theory to determine the cause: Verify or disprove the theory with a specific test (ping, traceroute, cable test, show commands). If the theory is confirmed, proceed to resolution. If not confirmed, establish a new theory and test again. Step 4 — Establish a plan of action to resolve the problem: Plan the resolution considering impact, required change control, and rollback options before making changes.
Step 5 — Implement the solution or escalate: Make the change. If beyond your authority or expertise, escalate to the appropriate person or team. Step 6 — Verify full system functionality: Confirm the problem is resolved — test the specific symptom AND check for unintended consequences (did fixing one thing break another?). Verify from the user's perspective. Step 7 — Document findings, actions, and outcomes: Record what the problem was, what caused it, what fixed it, and any preventive measures. Update documentation and knowledge base.
Systematic Troubleshooting Approaches
Bottom-up: start at Layer 1 (physical), work up. Best when the problem is physical or affects multiple users on the same segment. Check cables, link lights, switch ports, then IP config, then routing, then application. Top-down: start at Layer 7 (application), work down. Best when a specific application fails for a specific user — check the app config first, then system settings, then network. Divide and conquer: start in the middle of the OSI stack (usually Layer 3) and work up or down based on test results — fastest when the layer is unknown.
Change isolation: when something breaks after a recent change, the change is the most likely cause. Roll back the change first, verify the problem resolves, then re-implement with more care. Never make multiple changes simultaneously — you won't know which one fixed (or caused) the problem.