Trouble-
shooting

The Loop

Six steps. Steps 1–3 are diagnosis; 4–6 are remediation and closure. If a fix doesn't work, you don't push forward — you revert and loop back to the evidence.

Four Standing Rules

These govern how you execute every step, especially the change itself.

1. One change at a time. Multiple simultaneous changes make the result unattributable and the rollback messy.
2. Least-impact change first — when several causes are plausible, try the least disruptive. Exception: in an active security incident, containment speed can outrank user impact (isolating a compromised host now beats a tidy low-impact change later).
3. Don't open a security hole. No disabling AV/EDR, opening firewall rules, sharing credentials, or granting standing admin as a "workaround." A fix that widens the attack surface is a new incident.
4. Always have a back-out. Before you touch anything, know how to revert it and record the prior state. This is the rule that makes every other step safe to attempt.

Triage First

Before you dive in, set priority = impact × urgency. It decides how far down the loop you go and how fast — and whether it jumps the queue.

Step 1 · Define

• One sentence: what's broken, what should happen instead, who/what is affected, and the scope.
• Separate fact from assumption. Don't start fixing without data.
• Capture the error text verbatim, when it started, and what changed recently.

Step 2 · Gather

• Basic checks first. Connectivity, power, cabling, account/license status, service running, recent patch or config change. Trivial causes are common — rule them out before the deep dive.
• Reproduce the error if it's safe to do so; pull the relevant logs and metrics.
• Consult the people involved; check the internal KB, vendor docs, and known-issue trackers.

Step 3 · Isolate the Cause

Don't fix the symptom. Break the path into components and test one at a time until the fault localizes.

• Prioritize branches by impact and likelihood; don't chase a branch that can't be the cause.
• 5 Whys — ask "why" down the chain until you reach a cause you can actually fix.
• The visible failure (alert, popup, outage) is the symptom; keep going until you reach what produced it.

Step 4 · Plan

• List a few options before judging any; don't grab the first workable one.
• Pick against: solves it without new problems, acceptable to users, feasible, acceptable risk.
• Decide quick-fix vs. durable fix deliberately — note if a quick fix will force later rework.
• Confirm the back-out path exists (Rule 4).

Step 5 · Change & Verify

• Make the single planned change.
• Test against the expected result; use built-in diagnostics and reproduce the original failure to confirm it's gone.
• If it didn't work, revert it and return to the loop — don't layer on a second change.

Step 6 · Close

• Document in the ticket: symptom, cause, the exact change, outcome, and time. This is your future search hit and your pattern source.
• Prevent recurrence: address the cause, not just this instance — patch/firmware, config standard, monitoring, backups.

Escalate / Hand Off

Knowing when to stop is part of the method. Hand off cleanly rather than burning time you should have escalated.

Stop and escalate to security immediately on any of

• Ransomware / file encryption / a ransom note.
• Credential theft or unexpected MFA prompts.
• New or unknown admin accounts or privilege changes.
• EDR/AV alert on active malware.
• Signs of data exfiltration or lateral movement.
• Cleared or tampered logs.

Technique Quick-Picks

• Basic checks — always first. Cables, power, account, service, recent change.
• Divide & conquer — isolate which component in a path is at fault.
• Half-split (binary search) — on a long chain, test the midpoint and keep bisecting the failing half. Fastest localization.
• 5 Whys — drill a single cause chain to something you can fix. Weak when causes interact.
• Work backwards — start from the failed end state and trace to the trigger; ideal for "it worked yesterday."
• Fishbone — when the cause is unclear and you need to enumerate candidates across categories before narrowing.

For recurring or high-impact problems, graduate from troubleshooting to a structured Root Cause Analysis — the RCA Field Guide and Methods Handbook cover the techniques in depth.

Evidence Tiers

Tag every claim in a ticket, escalation, or incident note by how well you actually know it.

• confirmed directly observed in this environment, with evidence attached.
• suspected consistent with the evidence but not proven; state what would confirm it.
• theoretical known to be possible; not yet tied to this case.

A labeled "suspected" beats a confidently wrong "confirmed." Don't carry a vendor's general advisory into your report as if you observed it locally.

Anti-Patterns

• Stacking changes — you can't tell what worked and can't cleanly revert.
• Fixing the symptom so it recurs.
• No back-out path — a failed change becomes a second incident.
• Acting before you have data — solving the wrong problem confidently.
• "It worked there, close enough" — context differs; prior fixes don't always transfer.
• Triage bias — anchoring on the first theory, optimism, deferring to the senior person's guess.
• (Security) Closing on the alert instead of the access path; remediating before preserving evidence.
• Not escalating when stuck or out of scope.

Quick-Reference Card