Troubleshooting Methodology

Introduction

Large organisations don't want engineers randomly trying solutions in production. They expect structured investigation, evidence gathering, risk assessment, documentation, communication, and escalation. This module teaches how to think when something breaks — and the methodology applies across Help Desk, Desktop Support, Systems Administration, Network Operations, Cloud Engineering, SOC, IAM, Application Support, DevOps, SRE, Incident Response, and vendor technical support alike. The technology underneath keeps changing; the troubleshooting process stays remarkably consistent.

Learning Objectives

By the end of this module (all 6 lessons), you should be able to approach technical problems systematically; separate symptoms from root causes; collect evidence before making changes; determine scope and impact; build a troubleshooting timeline and identify what changed before a failure; troubleshoot layer by layer using logs, packet captures and monitoring platforms; develop and test hypotheses while changing one variable at a time; distinguish workaround, mitigation, fix, root cause and preventive action; escalate effectively and communicate clearly during major incidents; document your investigation so another engineer could reproduce it; and perform post-incident analysis.

1🔍 What Troubleshooting Actually Means

Troubleshooting is the process of identifying why a system isn't behaving as expected: Observe → Gather evidence → Form hypothesis → Test → Evaluate → Resolve → Verify → Document. The purpose is never simply to make the problem disappear — a reboot can make a problem vanish without explaining why it happened at all.

A web application stops responding; an administrator restarts it; it works again. Technically resolved — but was memory exhausted? Did database connections drop? Did a certificate expire? Did a dependency fail? Was there unusually high traffic? Could it happen again? Enterprise troubleshooting exists to answer questions like these, not just to restore service and move on.

2⇆ Symptoms vs Root Cause

"The internet is broken" is a symptom, not a diagnosis. Possible causes: Wi-Fi disconnected, DHCP failed, DNS unavailable, the default gateway unreachable, VPN routing, a firewall block, proxy unavailable, an ISP outage, or a browser configuration problem — a genuinely long list behind one short complaint.

"MFA isn't working" is the same trap: incorrect password, a disabled account, an unregistered device, blocked push notifications, no connectivity on the phone, a changed authentication policy, a Conditional Access block, an unavailable identity provider, clock drift affecting TOTP, an expired certificate, or the user simply attempting an unsupported method. A professional troubleshooter never assumes the reported symptom is the cause — that assumption is exactly what the rest of this module is built to prevent.

📚 Lessons in This Module

Work through these in order — each builds on ideas from the last. Every lesson has its own "Mark lesson complete" button; your progress across all six is tracked below.