Troubleshooting fundamentals
You learn to work with method rather than panic when something breaks: defining the symptom, forming a hypothesis, testing one variable at a time and keeping notes.
Level 101 · 14 lessons · 12 practice labs
Lessons
Method
- The troubleshooting mindset: the doctor analogy
- Defining the symptom: what, when, for whom
- The first question: what changed?
- One change at a time
- Short task: turn a vague complaint into a clear problem statement
Where to look first
- A quick resource sweep: disk, memory, CPU
- Service status and the latest log lines
- "Permission denied": following the permission chain
- Checking configuration syntax
- Short task: run your five-minute first-response checklist
Records and communication
- Taking notes while fixing: commands and results
- Asking for help: a good problem report
- A way back: backing up before a change
- Capstone: fix an internal web page that won't load, step by step, and report
Practice labs
- Turn a vague complaint into a clear problem statement: Turn a "system is not working" report into one sentence answering what, when and for whom using evidence on the server.
- Find the last change and relate it to the problem: From package history, changed files and command history extract the last twenty-four hours' changes and identify the one that started the problem.
- Eliminate three possible causes by testing one at a time: Write three hypotheses for an app that cannot connect, test each with a single change, record the result and prove the real cause.
- Sweep disk, memory and CPU quickly: Check resource state with three commands and submit the resource that is at its limit.
- Read the cause from service status and last log lines: Find the error from the status output and last twenty entries of a service that will not start and confirm with a config test.
- Write your own first-response checklist and test it on two faults: Prepare an ordered checklist that fits in five minutes, apply it to two different prepared faults and add the step it missed.
- Keep timestamped notes while working: While fixing a small fault record the commands you ran and what you observed with timestamps and submit the notes.
- Write a clear status update for users: For an ongoing outage write a short non-technical text with impact, what is known, what is being done and when the next update comes.
- Write the incident record of a solved problem: For the file share fault at Sedirli Hukuk Bürosu write a record with symptom, root cause, fix, evidence and the step that prevents recurrence.
- Check configuration syntax: Run each of three services' own test command and submit the file and line number that fails.
- Find a broken setting by comparing with a working backup: Compare a broken config with yesterday's backup, identify the single line that causes the problem and revert only that.
- Follow the permission chain on "permission denied": For a file that cannot be read although its mode looks right, check parent directories, group membership and ACLs in turn to find the block.
About this course
You learn to work with method rather than panic when something breaks: defining the symptom, forming a hypothesis, testing one variable at a time and keeping notes.
What you will learn
- Method
- Where to look first
- Records and communication
Prerequisites
No prior knowledge is needed; the course starts from zero.
Lab environment
Lessons run in your own Kali Linux terminal that opens in the browser. Nothing to install; the lab starts clean in every lesson.
Frequently asked questions
- Is this course right for my level?
- The course is at beginner level; every term is explained where it first appears.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.