Felsökningsmetodik för IT-problem — tips och tekniska lösningar

IT-problem löses sällan snabbare av att man arbetar hårdare. De löses snabbare av att man arbetar metodiskt.

En erfaren IT-tekniker som går igenom ett problem med en tydlig metodik är snabbare än en oerfaren tekniker som provar saker på måfå — varje gång. Det är inte magi. Det är process.

Den här artikeln beskriver den felsökningsmetodik vi använder på Geekteq vid IT-driftsuppdrag, med konkreta tekniker och verktyg.

Varför metodik spelar roll

Kaotisk felsökning ser ut så här: "Det fungerar inte, låt oss försöka det här... och det här... och starta om servern... och kolla loggarna... och kanske det är nätverket..."

Resultatet: du hittar lösningen av en slump. Du vet inte varför. Nästa gång det händer börjar du om från noll.

Metodisk felsökning ser ut så här: du formulerar en hypotes, testar den, drar slutsatser, och går vidare. Varje steg begränsar sökutrymmet.

Resultatet: du hittar lösningen systematiskt. Du vet exakt varför. Du kan dokumentera och förhindra att det händer igen.

Steg 1 — Definiera problemet precist

Det vanligaste misstaget är att börja felsöka utan att förstå vad problemet faktiskt är.

Frågor att ställa:

• Vad händer exakt? (Inte "det fungerar inte" — utan "felmeddelande X visas vid Y")
• När började det hända?
• Vad har förändrats nyligen? (Uppdateringar, ny hårdvara, konfigurationsändringar)
• Påverkar det alla användare eller bara några?
• Sker det alltid eller intermittent?
• Kan det reproduceras?

Skriv ner svaren. Inte mentalt — skriv ner dem. Det tvingar precision och ger underlag om du behöver eskalera.

Steg 2 — Isolera komponenten

IT-system består av lager. Problemet sitter i ett av dem. Uppgiften är att ta reda i vilket.

En klassisk modell är OSI-modellens sju lager, men för praktisk felsökning räcker det ofta med:

1. Hårdvara — kablar, portar, strömförsörjning, temperatur
2. Nätverksinfrastruktur — switches, routrar, VLAN, brandväggsregler
3. Operativsystem — drivrutiner, tjänster, loggfiler, diskutrymme
4. Applikation — konfiguration, beroenden, databaskopplingar
5. Användardata — rättigheter, profiler, behörigheter

Testa nerifrån och upp (eller uppifrån och ner om du vet var lagermodellen pekar). Eliminera lager för lager.

Exempel: En användare kan inte nå en intern webbapplikation.

• Kan de pinga servern? (Lager 3 — nätverksanslutning fungerar)
• Kan de nå en annan webbsida? (Lager 7 — browser/DNS fungerar generellt)
• Kan en annan användare nå applikationen? (Isolerar till den specifika användaren)
• Har användaren rätt behörigheter i applikationen? (Lager 5 — applikationsrättigheter)

Varje svar halverar sökutrymmet.

Steg 3 — Formulera och testa hypoteser

Undvik att testa saker på måfå. Formulera en hypotes: "Jag tror problemet beror på X — om jag testar Y bör jag se Z."

Testa en sak i taget. Om du ändrar tre inställningar samtidigt och problemet försvinner — vet du inte vilket som löste det.

Hypotesformat:

"Problemet uppstår förmodligen på grund av [orsak]. Om jag [åtgärd], förväntar jag mig att [förväntat resultat]."

Dokumentera:

• Hypotes
• Genomförd åtgärd
• Faktiskt resultat
• Slutsats

Steg 4 — Läs loggfilerna rätt

Loggar är inte sidoläsning. De är din primära datakälla.

Windows — vanliga loggar:

Händelsevisaren → Windows-loggar → System / Program / Säkerhet
%SystemRoot%\System32\winevt\Logs\

Filtrera på Error och Critical. Titta på tidpunkter kring när problemet inträffade.

Linux — vanliga loggar:

/var/log/syslog        # Systemhändelser (Debian/Ubuntu)
/var/log/messages      # Systemhändelser (RHEL/CentOS)
/var/log/auth.log      # Autentisering
journalctl -xe         # Systemd journal, senaste poster med kontext
journalctl -u nginx    # Loggar för specifik tjänst
journalctl --since "2 hours ago"

Vad du letar efter:

• Felmeddelanden (Error, CRITICAL, WARN)
• Tidsstämplar — händer felet precis vid rätt tidpunkt?
• Upprepade mönster — samma fel varje 5 minuter?
• Korrelationer — vad hände strax INNAN felet?

Steg 5 — Nätverksdiagnostik

Nätverksproblem är vanliga och har välkända diagnostikverktyg.

Grunddiagnostik (Windows och Linux):

# Testa anslutning till host
ping 8.8.8.8
ping google.com

# Traceroute — var tappar paketen?
tracert google.com       # Windows
traceroute google.com    # Linux/macOS

# DNS-lookup
nslookup google.com
dig google.com           # Linux/macOS

# Visa routing-tabell
route print              # Windows
ip route show            # Linux

# Visa nätverkskort och IP-konfiguration
ipconfig /all            # Windows
ip addr show             # Linux

Portdiagnostik:

# Testa om en port är öppen
telnet 192.168.1.10 443
nc -zv 192.168.1.10 443      # Linux/macOS

# Visa öppna portar och lyssnade tjänster
netstat -an              # Windows och Linux
ss -tlnp                 # Linux (modernare)

Paketanalys:

Om du behöver djupare diagnostik är Wireshark det bästa verktyget. Det låter dig fånga och analysera nätverkstrafik i realtid. Kombination med tcpdump på Linux-servrar (som skickar output till Wireshark) är en kraftfull teknik.

Steg 6 — Systemresurser och prestanda

Många problem beror på resursbrist: CPU, minne, disk, eller nätverksbandbredd.

Windows:

Task Manager (Ctrl+Shift+Esc) → Performance
Resource Monitor (resmon.exe)
Performance Monitor (perfmon.exe) — för historisk data

Linux:

# CPU och minne
top
htop              # Mer läsbart, installerbart med: apt install htop

# Diskutrymme
df -h             # Diskanvändning per partition
du -sh /var/log/* # Diskanvändning per katalog

# Diskprestanda
iostat -x 1       # I/O per sekund (kräver: apt install sysstat)

# Minnesstatus
free -h
cat /proc/meminfo

# Nätverkstrafik
iftop             # Realtidstrafik per anslutning
nethogs           # Nätverkstrafik per process

Vad som indikerar problem:

• CPU >90% under längre tid
• Swappanvändning (swap-in/swap-out hög = minnesbrist)
• Diskutrymme <10% — Linux börjar vägra skriva till disk vid 0%
• I/O-wait hög — disk är flaskhals

Steg 7 — Dokumentera och dela lösningen

Det sista steget är det lättast att hoppa över och det viktigaste att inte göra.

Dokumentera:

• Vad var symptomet?
• Vad var grundorsaken?
• Vilka steg utfördes för att diagnostisera?
• Vad löste problemet?
• Hur förhindrar vi att det händer igen?

En intern wiki, ett ärendesystem, eller till och med en textfil räcker. Nästa gång samma problem uppstår — och det gör det — har du en utgångspunkt.

Vanliga misstag att undvika

Starta om utan att logga. "Starta om servern" löser symptomet tillfälligt men inte orsaken. Logga alltid vad du observerar innan du vidtar åtgärder.

Anta att det är det senaste du ändrade. Ibland är problemet en bugfix som introducerades för tre veckor sedan men bara triggas under vissa förutsättningar.

Arbetar ensam på kritiska system. Ha alltid en kollega informerad när du arbetar i produktionsmiljö. Fyra ögon ser mer än två.

Hoppar till slutsatser. "Det är säkert brandväggen" utan att testa är inte en hypotes — det är en gissning.

Sammanfattning

En fungerande felsökningsprocess:

1. Definiera problemet precist med konkreta observationer
2. Isolera lagret — hårdvara, nätverk, OS, applikation, användare
3. Formulera hypoteser och testa en sak i taget
4. Läs loggfilerna — de berättar vad som faktiskt hände
5. Mät resurserna — CPU, minne, disk, nätverk
6. Dokumentera lösningen för nästa gång

Metodiken är inte komplicerad. Svårigheten är att hålla sig till den när stressen är hög och chefen frågar varför det fortfarande inte fungerar.

Behöver du hjälp med ett konkret IT-problem eller vill ha ett löpande driftsstöd som inte kräver att du är IT-expert? Kontakta oss så tittar vi på situationen.