Troubleshootin’ Method

Here you pin down one bug with a single test, compare what oughta happen to what actually did, and pick your next move. This method works on programs, containers, or network services. You need a known user action that should’ve worked, plus access to dig into the setup in question.

Kick things off with them seven steps and “Compare Expected vs Actual,” then put ‘em to work in Task 1. Network order is just backup if the trouble’s got somethin’ to do with networking. The Linux/Proxmox table’s just an example, not commands y’all gotta run fer every last error. That self-test? Purely optional practice.

Wanna see this method applied to a real-world snafu? Follow along with [[Feilsokingsmetode Level 2 - Modellert feilsøking av en app|walkthrough of troubleshootin’ an app]]. Over there, ya justify yer next test before ye even peek at the answer key.

The Seven Steps

1. Map out the circumstances. What happened, an’ when’d it start?
2. Reproduce the bug if it’s safe to do so again.
3. Pinpoint an’ narrow down possible sources of error – which layer or component might be the culprit?
4. Gather information – logs, error messages, command results.
5. Figure out potential fixes based on what you know now.
6. Test one fix or hypothesis at a time. If ya change several things all at once, ye won’t know what actually fixed it.
7. Document the bug an’ the solution, so that ye (or somebody else) can recognize it next time round.

Network and Service Troubleshooting Order

When y’all can’t tell where a network problem’s hidin’, this order gives ya a place to start off at. If ye already got a relevant test result on hand, use it to pick out where to dig deeper. Ye don’t need to run every single network test just ‘cause there’s a bug in the code.

flowchart TD
    A[Physical connection] --> B[Network interface]
    B --> C[IP configuration]
    C --> D[Local network]
    D --> E[Gateway and routing]
    E --> F[DNS]
    F --> G[Service]

Video: How to Test Network Connectivity with Ping

The video shows how ping can be used to check if a device is reachable on the network.

For each point, you should be able to:

• explain what the checkpoint actually checks
• find relevant values using the right command (see [[Protocol Level 1 - Network Protocols|🌐 Network Protocols]] for ping, nslookup, and more)
• tell an observation apart from a guess
• pick the next check based on the result of the last one, not just gut feelin’

Commands per layer in a Linux VM on Proxmox

This is an application of the method when a Linux VM can’t reach a service. Run relevant commands inside the VM’s Console, not in the Proxmox host’s Shell. See 🧭 Navigate in Proxmox VE if needed. Pick tests for what you’re lookin’ into; that table ain’t no requirement for Task 1.

If you’re missing the default route, dig into how the VM is supposed to reach targets outside its own net; some targets might have their own routes. Some nets block ping, so no answer ain’t proof on its own that the line’s cut. If name lookup and package sources are workin’, then you got solid results to ride with next. 🌐 IP, subnets, and standard gateway explains addresses, prefixes, and routes.

Expected vs Actual Tests

A debuggin’ test ain’t nothin’ but a waste o’ time if y’all don’t know what to expect before ye run it. Jot down here:

Needs:          What should the user be able to do?
Goal:           Which address/service are we testin' on?
Expected:       What oughta happen if all's well?
Actual:         What actually went down?
Proves:         What does this outcome prove?
Doesn't Prove Alone:  What ain't proven by this outcome?

Task 1 - Apply the method to a real-world issue

Grab a trouble you’ve run into in another Ops or Dev course (a container that won’t start, a service you can’t reach, a script throwin’ errors):

1. Walk through them seven steps up top, one by one.
2. Write down “expected vs. actual” fer every test ya run.
3. Jot down which component or layer the test narrows down. Use the network order only when it fits the problem.
4. Try one reasoned fix in a test environment yer allowed tinker with. Repeat the original user action and check if the fix actually works. Keep a way back to the old setup.

Got no bugs on hand? Ya can analyze this example: An app gives the expected page on /, but throws an HTTP 404 on /status. What do them two responses tell ya, and what would ya look at first? Both requests got HTTP replies; the first thing t’check is whether /status actually exists in the app and if the client’s usin’ the right route. This example is just practice for analysis, not proof that ye fixed yer own mess.

Checkpoint: The Bug Is Contained and Controlled

Show the test log an’ explain which observation backed up the next test or fix. After the fix is done, that original action oughta give ya the expected outcome. You can lay it out verbal or on paper with commands an’ results right there before ya. If the bug’s still hangin’ loose, spell out what got tested, what’s still a mystery, an’ one precise next test to run. Don’t go writtin’ down a guessed cause like it’s confirmed fact.

Test Yourself

Optional self-test with feedback. The answers are not sent to the teacher. Use your own testing log to demonstrate actual troubleshooting; the self-test does not replace the practical check.

Summary

• Troubleshooting is a method, no guessin’ – seven set steps from mappin’ it out to puttin’ it down on paper
• The binary search method can narrow down a chain when ya know which links the test uses
• For networks: use the layers to pick the next right test based on what ya see
• Always write down expected versus actual before ya run a test, an’ remember that one test rarely proves everything