Troublin’ Method

Here ye shall isolate a single bug with one test, compare what we expected against the actual booty, and pick yer next move. This method be used on a program, a container, or a network service. Ye need a known user action that shoulda worked, an’ access to investigate the solution in question.

Start with the seven steps an’ “Test Expected vs Actual,” an’ use ‘em in Task 1. The network sequence be support when the trouble lies with the networks. The Linux/Proxmox table be just one example, not commands ye must run fer all bugs. The self-test be optional practice.

If ye want to see this method applied to a specific bug, follow [[Feilsokingsmetode Level 2 - Modellert feilsøking av en app|modelled troublin’ of an app]]. There ye justify the next test before openin’ the answer proposal.

The Seven Steps

1. Chart the circumstances. What happened, an’ when did it start?
2. Replicate the bug ‘tis safe to do so agin’.
3. Pin down an’ narrow likely sources o’ error – which layer or component could it be?
4. Gather intelligence – logs, error messages, command results.
5. Decide on possible fixes based on what ye know now.
6. Test one fix or hypothesis at a time. Change too many things at once, an’ ye won’t know what actually fixed it.
7. Record the bug an’ the solution, so that ye (or another soul) recognize it next time.

Troublin’ Order fer Nets an’ Services

When ye don’t know wher a nets bug’s hidin’, this order gives ye a star’ point. If ye’ve already got a relevent test result, use it ter pick where t’ look next. Ye needn’t run all da nets tests fer a code blunder.

flowchart TD
    A[Aye, physical connection matey!] --> B[B'arrr network interface ye scallywag!]
    B --> C[Ye IP configuration arr!]
    C --> D[Local net yer booty!]
    D --> E[Gateways an' routing o' course!]
    E --> F[DNS as per the charts!]
    F --> G[Service at hand ye landlubber!]

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.

Ye should know ye can do each o’ these points:

• explain what the checkpoint actually checks
• find the relevant values with the right command (see [[Protocols Level 1 - Network Protocols|🌐 Network Protocols]] fer ping, nslookup an’ such like)
• tell apart a sighting from a guess
• pick the next check based on the result o’ the last one, not based on yer gut feelin’

Commands per layer in a Linux-VM in Proxmox

This be the application o’ the method when a Linux-VM cannae reach a service. Run relevant commands inside the VM’s Console, not in the Proxmox host’s Shell. Consult 🧭 Navigate in Proxmox VE if ye need to. Pick the test fer what ye be investigatin’; the table ain’t no requirement fer Task 1.

If ye be missing the default route, investigate how the VM should reach targets outside its own net; some targets may have their own routes. Some nets block ping, so lack o’ reply alone don’t prove that the connection is broken. If name lookup and package sources works, ye got concrete results to use further on. 🌐 IP, subnet and standard gateway explains address, prefix and route.

Test Expected vs Actual

A debuggin’ test is nothin’ but useless if ye don’t know what to expect before ye run it. Write down:

Needs:            What should ye be able to do?
Goal:              Which address/service are y'all testin'?
Expected:          What oughta happen if all's well?
Actual:            Whatcha got fer a result?
Shows:             What does this outcome prove?
Doesn't show alone: What does NOT this outcome prove?

Task 1 - Apply the method t’ a real issue

Pick up an issue ye’ve stumbled upon in another Operations or Development course (a container that won’t start, a service ye can’t reach, a script throwin’ errors):

1. Walk through th’ seven steps above, one by one.
2. Write down “expected vs actual” fer every test ye run.
3. Note which component or layer th’ test isolates. Use network order only when it fits th’ trouble.
4. Try one reasoned fix in a test environment where ye have permission to make changes. Repeat th’ original user action and check dat th’ fix actually works. Keep a way back t’ th’ previous setup.

If ye don’t have any errors handy, ye can analyze this example: An app gives expected page on /, but HTTP 404 on /status. What do th’ two responses show, and what would ye look into first? Both requests got HTTP replies; first check is if /status actually exists in th’ app and if client’s usin’ right route. Th’ example is analysis practice, not proof ye fixed yer own solution.

Checkpoint: The bug is scoped and contained

Show me yer logbook an’ explain which observation backed up ye next trial o’ fixin’. Once patched, that original maneuver should yield th’ expected prize. Ye may speak it plain or set it down in writ with commands an’ results afore ye. If that bug still haunts the ship, declare what’s been tested, what remains a mystery to all hands, an’ one precise next trial. Do no mark a guessed cause as confirmed fact!

Test Ye’erself

A voluntary self-test with feedback. The answers are nae sent to the teacher. Use yer own logbook tae show actual troubleshooting; the self-test doesnae replace the practical checkin’.

Summary

• Troubleshootin’ is a method, no guesswork – seven fixed steps from chartin’ to loggin’ it all down
• The Bisection Method can narrow down the chain when ye know which links yer tests are usin’
• Fer networks: use the layers t’ pick the next proper test based on what ye’ve spied with yer own eyes
• Always jot down expected versus actual before ye run yer tests, an’ remember that one test rarely proves everything without a doubt