Kepner-Tregoe for Network Troubleshooting

Kepner-Tregoe for Network Troubleshooting

What this skill is for

This skill gives a network-troubleshooting agent a disciplined method so it reaches a verified root cause before acting, instead of pattern-matching to a familiar cause and swapping components. The entire value is sequencing and separation: appraise before diagnosing, specify before theorizing, verify before fixing, decide before acting, protect before executing.

You will usually have tools that can read network state (telemetry, device configs, routing/ARP/session tables, logs, packet/flow data, inventory/CMDB). Use those tools to gather the evidence that fills the specification — do not reason from memory when you can observe. The method tells you which evidence matters and what to conclude from it.

Non-negotiable principles

1. Specify before you hypothesize. Never name a cause until you have drawn the fault's boundary (what IS affected vs. what IS-NOT). The boundary is where the cause hides; skipping it is why troubleshooting drifts from symptom to symptom.
2. The IS-NOT carries the answer. Recording what is broken eliminates almost nothing. Recording the nearest comparable thing that could be broken but isn't eliminates whole classes of cause in one line.
3. Test every candidate cause against the whole specification. A cause that explains what IS but contradicts an IS-NOT is wrong, however plausible. Prefer the cause that fits with the fewest assumptions.
4. Verify in the real world before you fix. A cause proven on paper is a hypothesis until a log line, a counter, a table entry, or a controlled test confirms it. Fixing an unverified cause "fixes" a symptom and leaves the root.
5. Separate the incident fix from the permanent fix. Stop the bleeding with the fastest reversible known-good action; the proper fix is a separate, planned decision. Conflating them extends outages.
6. Protect every change before executing it. Prevention + contingency with explicit triggers.
7. Do not take state-changing actions without authorization. Diagnose and recommend freely. Before any config change, failover, reboot, or traffic-affecting action, confirm with the human/operator unless you have standing authorization for that specific action. Read-only investigation needs no confirmation.

Step 0 — Route to the right process

Ask these in order and stop at the first "yes". Running the wrong process is the most common misuse (e.g. debating fixes before the cause is known).