Het probleem identificeren en definiëren

Een krachtige vraag is: "wat is er veranderd?" De meeste problemen beginnen vlak na een wijziging: nieuwe hardware, een wijziging in de configuratie, een software-update of een stroomincident. Vraag het aan gebruikers en controleer wijzigingslogboeken. Als een dienst gisteren nog werkte en vandaag niet meer, is er iets anders, en het vinden van dat verschil leidt vaak rechtstreeks naar de oorzaak. Recente wijzigingen zijn de voornaamste verdachten.

Gebruikers beschrijven symptomen in hun eigen woorden, dus ondervraag hen zorgvuldig en vriendelijk. Stel open vragen: "Wat deed je toen het misging?" en "Is er nog iets anders veranderd?" Vermijd sturende vragen die een vals antwoord suggereren. Houd er rekening mee dat gebruikers details kunnen weglaten of gevolgen kunnen beschrijven in plaats van oorzaken. Geduld en goede vragen zetten een vage klacht om in bruikbare gegevens.

Het bepalen van de omvang verkleint het zoekgebied aanzienlijk. Als slechts één pc is getroffen, kijk dan naar dat apparaat of de kabel ervan. Als een hele VLAN is uitgevallen, verdenk dan een switch of de gateway. Als de hele locatie geen internet heeft, richt je dan op de WAN-verbinding of de ISP. Door de omvang van het probleem te koppelen aan de omvang van de waarschijnlijke oorzaak bespaar je enorm veel tijd.

Als het kan, bootst je het probleem zelf na. Door de fout te reproduceren bevestig je dat deze echt is, ontdek je de exacte omstandigheden en krijg je een test die je na een oplossing kunt herhalen. Als een website bij de gebruiker niet werkt, probeer je die vanaf je eigen apparaat op hetzelfde netwerk. Onderbroken problemen zijn moeilijker na te bootsen, maar dit is zeer waardevol om een oplossing te bevestigen.

CompTIA zegt expliciet dat je het voor de hand liggende ter discussie moet stellen. Veel uitval heeft alledaagse oorzaken: een losgekoppelde kabel, een uitgeschakeld apparaat, een verlopen wachtwoord of Caps Lock tijdens het aanmelden. Deze controles eerst uitvoeren kost seconden en lost het probleem vaak op. Eenvoudige controles overslaan omdat het "dat toch niet kan zijn" is een klassieke manier om uren te verspillen aan een onbeduidend defect.

Apparaten kondigen hun eigen problemen vaak aan. Lees logboeken op foutmeldingen, let op verbindingslampjes van interfaces en bekijk waarschuwingen van het bewakingssysteem. Een rood lampje op een switchpoort, een geregistreerde gebeurtenis "interface down" of een DHCP-foutmelding kan rechtstreeks naar het defect wijzen. Door de apparatuur te laten vertellen wat deze waarneemt, vul je de informatie van de gebruiker aan.

Ga na of je met één probleem of met meerdere problemen te maken hebt. Soms treden twee niet-gerelateerde defecten tegelijk op en lijken ze één vreemd symptoom te veroorzaken. Als aanwijzingen niet bij één oorzaak passen, vraag je dan af of twee problemen elkaar overlappen. Door verstrengelde problemen van elkaar te scheiden voorkom je de verwarring die ontstaat wanneer je alles met één geforceerde theorie probeert te verklaren.

Combineer je bevindingen tot een nauwkeurige probleembeschrijving: wie is getroffen, wat werkt niet, wanneer is het begonnen en welk patroon is zichtbaar? "Sinds de herstart van de switch om 9.00 uur kunnen alle telefoons op VLAN 20 zich niet registreren" is veel nuttiger dan "de telefoons zijn kapot". Een goede beschrijving vormt de basis waarop de rest van de methode wordt gebouwd.

Een goede probleembeschrijving wijst vanzelf in de richting van theorieën over de oorzaak. Als het probleem begon na een configuratiewijziging op één switch en alleen de gebruikers van die switch treft, ligt je eerste theorie voor de hand. Echt tijd besteden aan identificatie maakt het opstellen van theorieën, testen en repareren veel sneller en nauwkeuriger. Definieer het probleem goed, dan verloopt de rest van het oplossen van problemen vanzelf.

Je hebt geleerd problemen te identificeren en te definiëren. Belangrijkste punten:

• Verzamel omvang, timing en symptomen bij gebruikers, uit logboeken en met tests.
• Vraag altijd: "wat is er veranderd?"
• Bepaal de omvang om de waarschijnlijke oorzaak in te schatten en bootst het probleem na als dat kan.
• Stel het voor de hand liggende ter discussie voordat je verder zoekt.
• Schrijf een nauwkeurige probleembeschrijving die richting geeft aan elke volgende stap.