Troubleshooting, oftewel probleemzoeken7 min

100 dagen Algemeen

Ik werk ondertussen alweer de nodige jaren met allerlei computersystemen. Mijn eerste computer kreeg  toen ik op de lagere school zat. Ik behoorde tot het kamp van de MSX. Al vroeg had ik door dat niet alles altijd deed wat het moest doen. De truc was dan ook uitzoeken wat er mis ging en waarom. Als je weet wat er mis gaat en waarom, kun je het in ieder geval oplossen.

Dit trucje heb ik in de jaren daarna veel toegepast en verfijnd. Ik ben bezig om het te beschrijven voor een artikel op VMGuru.com. Het komt kort gezegd neer op het volgende:

 

 

Een van de meest belangrijke dingen bij het zoeken naar problemen is dat je een systeem of workflow hebt. Je moet het probleem methodisch en analytisch te lijf gaan. In mijn ogen is er niets ergers dan van alles problemen en spontaan begint het weer te werken. Je weet dan nog steeds niet wat er mis was, waardoor je het een volgende keer ook niet kunt voorkomen.

De aanpak

Er zijn verschillende manieren om het probleem op te lossen. Mijn manier is ruwweg hieronder beschreven. Ondanks dat ik roep dat je een workflow moet hanteren, doe ik het zelf niet altijd in dezelfde volgorde. Hier komt ie dan:
  1. Haal diep adem, neem een kop koffie of thee en denk rustig na over je probleem
  2. Omschrijf het probleem zo gedetailleerd mogelijk
  3. Controleer of het probleem nog steeds optreedt
  4. Check bekende problemen en oplossingen
  5. Maak een situatieschets
  6. Controleer de connectiviteit tussen de componenten
  7. Controleer componenten en foutlogs
  8. Wijzig onderdelen aan de hand van je documentatie
  9. ‘If everything else fails, try a new approach’

Ik ga de stappen niet in alle details beschrijven, maar ik hoop dat het je genoeg structuur geeft op je troubleshoot reis.

1. Haal diep adem, neem een kop koffie of thee en denk rustig na over je probleem

Dit is wat mij betreft één van de belangrijkste, zo niet, de belangrijkste actie die je moet nemen. Raak niet in paniek, maar zit en relax. Neem de tijd. Wanneer je begint met allerlei dingen aan te passen ben je misschien verder van huis. Iets anders wat je zéker niet moet doen is CYA, cover your ass, je straatje schoonvegen, of hoe je het ook wilt noemen.  Wis de logfiles niet, maar geef toe dat je wat fout hebt gedaan. Uiteindelijk komt het toch wel uit.

Focus je eerst op het oplossen van het probleem. Het redden van je baan of carriere komt daarna pas.

2. Beschrijf het probleem

Het is belangrijk dat je het probleem zo goed mogelijk beschrijft. ‘Het werkt niet’ is nou niet echt een goede omschrijving van het probleem. Het helpt je ook niet verder bij het oplossen van het probleem.

Wat werkt er nou precies niet? Kun je iets niet installeren of gebruiken? Kun je het systeem niet bereiken? Krijg je geen beeld? Werkt het systeem niet zoals je het zou verwachten? En hoe uit zich dat dan?

Wees zo precies mogelijk. Beschrijf zoveel mogelijk symptomen als je kunt. En nee, ‘ik denk dat dit of dat gebeurde’ of ‘iemand ergens zei tegen iemand anders dat het stuk was’. En begin ook niet met filteren. Het moet zo specifiek mogelijk zijn, maar uitsluiten van symptomen kan er wel eens voor zorgen dat je het probleem niet kunt oplossen.

Als onderdeel van het beschrijven van je probleem kun je gebruik maken van Wie, Wat, Waar, Waarom, Wanneer, Waar vragen, maar ook andere vragen:

  1. Wie heeft het probleem
  2. Wat is het probleem
  3. Wat was je aan het doen toen het probleem optrad
  4. Waarom is het een probleem
  5. Wanneer treedt het probleem op
  6. Waar treedt het probleem op
  7. (indien mogelijk) Waarom treedt het probleem op
  8. Heeft het überhaupt gewerkt?
  9. Wat is er gewijzigd sinds het moment dat het wel werkte?

3. Controleer of het probleem nog steeds optreedt

Repliceer het probleem. Constateer het zelf. Vertrouw geen andere architect/consultant/engineer/monteur/<vul in>. Vertrouwen is goed, controleren is beter.

Een probleem proberen op te lossen dat ondertussen alweer verdwenen is, of een probleem wat je niet zelf hebt gezien oplossen is zonde van de tijd in het proces. Het is belangrijk om te weten of het probleem nog steeds aanwezig is. Wanneer je foutmeldingen verwacht, maar niet ziet, probeer ze dan zelf op te wekken. Misschien was het probleem tijdelijk van aard door een oorzaak van buiten en is het al op een ander niveau opgelost, bijvoorbeeld een stroomstoring of netwerkstoring.

4. Check bekende problemen en oplossingen

Zoek op internet naar de bekende problemen met hun oplossingen. Vaak kun je op de site van de leverancier of producent een kennisbank/knowledge base vinden. Hierin kun je gericht zoeken naar de symptomen. Vaak komt hier een oplossing uit, of in ieder geval een richting om in te zoeken.

5. Maak een situatieschets

Het maken van een schets of tekening waarin het probleemcomponent zit kan je een goed beeld geven van waar je moet zoeken. Door het tekenen van de situatie zorg je er voor dat je de informatie ordent, ook voor jezelf. En als je met meerdere mensen op zoek gaat naar het probleem helpt het dat iedereen hetzelfde beeld heeft van de infrastructuur of de situatie.

6. Controleer de connectiviteit tussen de componenten

Nu je weet hoe de componenten aan elkaar gerelateerd zijn kun je controleren hoe de communicatie verloopt. Met communicatie bedoel ik iedere willekeurige uitwisseling. Dit kan ook de brandstofstroom van bijvoorbeeld tank naar motor zijn, maar ook de verbinding tussen je e-mail client en de e-mailserver op internet. De controle kun je vaak heel basaal uitvoeren. Bij een verbinding met internet kun je een ‘ping’ commando uitvoeren. Bij een brandstofstroom zou je één kant van de slang los kunnen halen om te zien of er brandstof uit komt.

7. Controleer componenten en foutlogs

Check alle componenten op basis van je situatieschets. Controleer alle foutlogs. Componenten die gewijzigd zijn sinds de vorige keer dat het nog wel werkte, zijn bij voorbaat verdacht.

  1. Ga na wat het component zou moeten doen en check of die het ook echt doet
  2. Controleer foutmeldingen, eventlogs, logfiles, onboard management system en dergelijke systemen.
  3. Controleer de configuratie aan de hand van je documentatie (Je hebt documentatie, toch? Toch?), maar wijzig nog niets!!

Hou er rekening mee dat het ontbreken van foutmeldingen in bepaalde gevallen ook een fout is.  Ga ook na of je het detectieniveau van meldingen kunt verhogen. Bij bepaalde systemen kun je ‘debug’ logs aanzetten, zodat je letterlijk alle acties en activiteiten voorbij kunt zien komen. Dit geeft je inzicht in wat er precies mis gaat.

8. Wijzig onderdelen aan de hand van je documentatie

Wanneer je gereed bent met de controle van systemen en componenten, heb je ongetwijfeld een lijst met zaken die afweken van de documentatie. Dit is het moment om die zaken aan te passen, nadat je natuurlijk maatregelen hebt getroffen om terug te kunnen keren naar de vorige situatie, zoals een backup.

  1. Wijzig één ding tegelijk
  2. Documenteer je wijziging
  3. Controleer of het nu wel werkt. Wanneer het niet werkt, draai terug.

9. ‘If everything else fails, try a new approach’

Als bovenstaande niet geholpen heeft, of wanneer het te lang gaat duren, blijf dan niet te lang zoeken naar de oorzaak. Onderneem actie:

  1. Schakel de leverancier/producent in
  2. Vervang componenten door componenten waarvan je zeker weet dat ze werken
  3. ‘maak stuk’ wat werkte. Op deze manier weet je in ieder geval zeker wat je zou moeten kunnen verwachten.

Afsluitend

Ieder probleem is uniek. Ik gebruik zelf bovenstaande proces regelmatig. Niet alleen om zelf probleem op te lossen, maar ook wanneer ik met een team een probleem moet oplossen. Het helpt om te beschrijven wat iedereen in zijn of haar verantwoordelijkheid moet doen of controleren.

Een probleem hoeft geen paniekvoetbal te veroorzaken, zolang je maar een proces hebt waarmee je het probleem te lijf kan gaan.

 

Anne Jan Elsinga

vExpert 2009-2017, Virtualization Consultant, loves to cook, salsa, latin, ballroom dancing. Daarnaast helemaal gek van domotica, smart homes en comfort.

Reageer op dit artikel

avatar
   
Abonneren op