Hoe los je je (IT-)probleem op in 9 stappen
Gepubliceerd op 16 augustus 2017 • 8 min leestijd • 1.669 woorden
Een van de belangrijkste dingen bij het oplossen van problemen in het algemeen is dat je een systeem of workflow volgt. Je moet het probleem methodisch en analytisch aanvallen. Er is niets erger dan allerlei dingen proberen en plotseling beseffen dat het werkt en niet weten wat je hebt gedaan om het aan de praat te krijgen. Het is geweldig dat het weer werkt, maar je weet niet wat het veroorzaakt heeft.
De aanpak
Er zijn veel verschillende benaderingen die je kunt nemen.
Mijn aanpak lijkt ruwweg op de onderstaande lijst. Ik doe niet altijd de dingen in dezelfde volgorde.
- Haal diep adem, neem een kop koffie of thee en beheer de verwachtingen
- Analyseer het probleem
- Verifieer dat je nog steeds het probleem hebt dat je hebt beschreven.
- Weet wanneer je jouw leverancier/integrator moet bellen
- Doe je onderzoek
- Maak een schets van de systemen of componenten die betrokken zijn.
- Zorg ervoor dat je systemen overeenkomen met de documentatie of logbestanden
- Controleer op veelvoorkomende problemen en oplossingen
- Bel je leverancier/integrator
Ik ga niet te veel in detail in op alle bovenstaande stappen, maar ik hoop dat het je voldoende structuur geeft in je reis naar probleemoplossing. En vergeet niet, afhankelijk van je specifieke situatie kun je naar een andere stap in het proces springen. Ik kan me voorstellen dat in veel gevallen
1. Haal diep adem, neem een kop koffie of thee en beheer de verwachtingen
IMHO is dit een van de belangrijkste, zo niet de belangrijkste dingen om te doen. Raak niet in paniek, ga zitten en ontspan. Wanneer je begint met allerlei dingen te veranderen, zul je waarschijnlijk verder van een oplossing af zijn dan ooit. Een ander ding dat je zeker NIET moet doen, is CYA, jezelf indekken. Wissen geen logbestanden om je fout te verbergen. Uiteindelijk komt het toch allemaal uit. Focus op het oplossen van het probleem. Het redden van je baan of carrière komt daarna. Bovendien, de actie van het wissen van je sporen komt altijd uit, je maakt het moeilijk, of zelfs onmogelijk om de oorzaak van je probleem te vinden.
Het is ook cruciaal dat je begint met het beheren van de verwachtingen. Iedereen wil dat hun probleem zo snel mogelijk wordt opgelost, maar het oplossen van problemen kost tijd. Mensen die de hele tijd over je schouder meekijken helpen ook niet mee om het probleem op te lossen. Probeer een communicatieproces op te zetten, bijvoorbeeld ‘we hebben elke 30 minuten een gesprek’ afhankelijk van het probleem. En als je zegt dat je elke 30 minuten belt, DOE dat dan ook. Ze willen graag weten wanneer ze terug kunnen naar hun werk/proces/bedrijf.
2. Analyseer het probleem
Het is erg belangrijk dat je je probleem kunt beschrijven. “Het werkt niet” kwalificeert echt niet als weten wat het probleem is.
Wat werkt er niet? Kun je iets niet installeren? Kun je een systeem niet bereiken? Gedraagt het systeem zich niet zoals het zou moeten? En hoe manifesteert dat zich? Wees zo specifiek mogelijk. Lijst zoveel mogelijk symptomen op. Geen ‘ik denk dit of dat gebeurt’ of ‘iemand ergens zei dat het kapot was’ en geen filtering. Het moet zo specifiek mogelijk zijn.
Als onderdeel van het beschrijven van het probleem kun je proberen de Wie, Wat, Waarom, Wanneer, Waar vragen te beantwoorden, maar ook andere vragen zoals:
- Wat is het probleem
- Wie heeft het probleem
- Wanneer doet het probleem zich voor
- Waar doet het probleem zich voor
- (als je kunt) Waarom doet het probleem zich voor
- Heeft het ooit eerder gewerkt?
- Wat is er veranderd sinds de tijd dat het systeem of component werkte.
3. Verifieer dat het probleem nog steeds bestaat
Repliceer het probleem. Vertrouw niet op een andere architect/consultant/engineer/<vul maar in>. Proberen een probleem op te lossen dat is verdwenen of vertrouwen op iets dat je zelf niet hebt gezien is een verspilling van tijd in het proces. Het is belangrijk om te weten of de fout nog steeds bestaat. Als je geen gebeurtenissen in je gebeurtenislogboeken hebt gekregen, probeer dan een fout of bericht te genereren waarvan je weet dat het programma of systeem daarover zou moeten rapporteren. Misschien was het probleem intermitterend en is het al op een ander niveau opgelost, bijvoorbeeld netwerkuitval.
4. Weet wanneer je je leverancier/integrator moet bellen
Afhankelijk van de prioriteit van het probleem is dit misschien een goed moment om je leverancier of integrator op de hoogte te stellen. Tenminste, je hebt nagedacht over je probleem en je hebt het in detail beschreven. Je weet zelfs dat het probleem nog steeds bestaat.
Ik wil met deze uitspraak niet zeggen dat je voor elk probleem dat je nu hebt meteen je leverancier/integrator moet bellen. Meestal is het nuttig om eerst zelf het voorwerk te doen voordat je belt. Je hebt het probleem misschien zelf opgelost. Aan de andere kant is er het punt van tijdverspilling. Vaak wil je leverancier/integrator zelf wat controles uitvoeren, zoals in de eerste alinea van punt 3.
5. Doe je onderzoek
Verdenk de componenten die zijn veranderd sinds de laatst bekende goede staat. Ik heb veel problemen opgelost op systemen waar het probleem werd veroorzaakt door een eerder uitgevoerde wijziging. Na een terugdraaiing van de wijziging ‘werkte alles weer’.
Als je ze hebt gecontroleerd, is het tijd om logbestanden, systemen, configuraties te controleren.
- Controleer wat het systeem zou moeten doen en of het dat doet. Het is vooral belangrijk om te weten of het systeem of component werkte, zelfs vóór het incident.
- Controleer op fouten, gebeurtenislogboeken, logbestanden
- Controleer de configuratie op basis van je documentatie (je hebt toch documentatie, nietwaar?), maar verander nog niets!!
Meestal geeft dit logboek je een hint waar je vervolgens moet kijken. Echter, overweeg dat de afwezigheid van een fout ook als een fout kan worden beschouwd. Soms mist het logboek de details die je nodig hebt of wilt om problemen op te lossen. Wanneer dat gebeurt, kun je het detailniveau van de logberichten verhogen.
Als je na het lezen van de logbestanden nog steeds geen idee hebt wat er aan de hand is, dan moet je een ondersteuningscase loggen bij de leverancier van je product, zoals VMware. Wacht hier niet te lang mee. Als het in eerste instantie lijkt dat je hulp nodig hebt om het binnen een redelijke tijd op te lossen, maak dan een ondersteuningscase aan. Een van de dingen die je kunt doen om het proces te versnellen, is vooraf een ondersteuningsbundel te maken, zodat je deze aan je ondersteuningscase kunt toevoegen.
6. Maak een schets van de betrokken systemen of componenten.
Neem een stuk papier of loop naar een whiteboard en begin met het tekenen van de situatie. Meestal, als je je omgeving uitschetst met het probleemcomponent erin, geeft het je de gebruikelijke verdachten waar je problemen moet oplossen. Het geeft je in ieder geval en iedereen die betrokken is bij het oplossen van het probleem dezelfde basisinformatie over hoe de omgeving is geconfigureerd.
Ik vind het erg nuttig om het aan iemand anders uit te leggen. Als je met iemand praat, moet je je gedachten structureren en een logische tijdlijn/verhaal creëren. Als de andere persoon ook vragen stelt over het probleem of de omgeving, kun je inzichten krijgen die je voorheen niet had.
7. Zorg ervoor dat je systemen overeenkomen met de documentatie of logbestanden
Als je klaar bent met de controle van systemen en componenten, zou je een lijst moeten hebben van dingen die niet overeenkomen met je documentatie. Ga je gang en verander de items (nadat je natuurlijk een back-up hebt gemaakt of de instellingen hebt genoteerd)
- Verander één item tegelijk.
- Documenteer je wijziging
- Als het niet werkt, draai dan terug naar de staat vóór de wijziging
- Vervang componenten voor werkende componenten
- ‘Breek’ componenten met opzet zodat je weet welke uitkomst je kunt verwachten. GEBRUIK MET VOORZICHTIGHEID!!
8. Controleer op veelvoorkomende problemen en oplossingen
Nu je weet hoe de componenten met elkaar verbonden zijn, kun je controleren of ze kunnen communiceren. Een van de dingen die je wilt controleren is ‘kan ik de server pingen vanaf het gerelateerde component/server?’. Natuurlijk werkt dit alleen als ping-pakketten zijn toegestaan tussen client en server (verifieer dit voordat je conclusies trekt!)
Zoek ook op internet naar oplossingen voor je probleem. Een van de belangrijkste plaatsen om te controleren is de kennisdatabase. Er is een kans dat andere mensen je probleem al hebben opgelost. Voor VMware-producten controleer je natuurlijk kb.vmware.com .
En misschien is het iets eenvoudigs, zoals ‘start de server opnieuw op’.
9. Bel je leverancier/integrator
Tegen deze tijd heb je alles gecontroleerd, ben je door je configuratie gelopen en heb je de dingen veranderd die niet overeenkwamen met de documentatie. Als het probleem nog steeds niet is opgelost, moet je echt de troepen inschakelen. Als je dat niet in stap 4 hebt gedaan, is nu echt de tijd om je leverancier/integrator te bellen.
Wees je ervan bewust dat dit ook tijd kost. Ze hebben alle informatie nodig die je hebt verzameld, zoals een goede probleembeschrijving, logbestanden, schetsen, enzovoort. Dit is waarom ik eerder zei dat het in sommige gevallen belangrijk is om niet te lang te wachten voordat je een ondersteuningscase aanmaakt bij je leverancier/integrator.
Afsluitende gedachten
Elk probleem is anders. Ik heb het hier geschetste proces vaak gebruikt, niet alleen wanneer ik mijn eigen probleemoplossing moet doen, maar vooral wanneer ik probleemoplossing moet doen met verschillende teams. Het helpt om te beschrijven wat iedereen in zijn of haar expertise moet doen of controleren. In geval van een probleem is er geen reden voor paniek. Zorg er gewoon voor dat je de juiste dingen op het juiste moment doet. Een helder hoofd houden helpt je een lange weg om het probleem op te lossen.
Als je meer wilt weten over de kunst van het oplossen van problemen, kun je ook “The art of troubleshooting” bekijken. Het beschrijft meer benaderingen van probleemoplossing in detail.