Is troubleshooting kunde of toeval?
Het is niet meer te voorkomen dat je niet een keer moet troubleshooten. Jouw IT-omgeving wordt steeds complexer. Als er zich een verstoring voordoet dan is het niet altijd eenvoudig om de oorzaak snel te vinden. Soms heb je mazzel en vind je per toeval direct de oorzaak, maar in de meeste gevallen vergt het wat meer onderzoek. Maar hoe en waar begin je?
Er zijn een aantal uitgangspunten die jou kunnen helpen om gestructureerd tot de oplossing voor het probleem te komen. Wij hebben er hieronder een aantal op een rij gezet.
1. De werking van de omgeving
Het eerste uitgangspunt is dat je moet weten hoe de omgeving, waar het probleem is ontstaan, werkt. Als we spreken van problemen met een webserver, dan moet je ervoor zorgen dat je weet hoe de verkeerstromen naar de webserver lopen. In een simpele setup hangt de webserver rechtstreeks aan het internet. Bij een complexere setup hangt de webserver bijvoorbeeld achter een firewall en een reverse proxy of een Web Application Firewall.
2. Zoekgebied
Wanneer we de problemen met de webserver als voorbeeld nemen, dan kun je wel stellen dat het probleemgebied de gehele omgeving bestrijkt. Denk hierbij aan de webbrowser via de firewall waarachter de klant zich bevindt. Maar ook het internet naar de webserver met daarvoor eventuele firewalls en proxy’s en dergelijke.
Dit is een enorm zoekgebied en beperkt zich niet tot de webserver. Toch is het noodzakelijk dat je naar de totale scope kijkt om tot een oplossing voor het probleem te komen.
De kunst hierbij is dan ook om snel je zoekgebied te verkleinen. Dat zorgt ervoor dat je gericht naar de oplossing van het probleem aan het zoeken bent.
3. Grafisch weergave
Wat ook altijd helpt is om de situatie grafisch weer te geven. Maak een design van de situatie, als je dat nog niet in je documentatie hebt. Neem hierin alle elementen op. Een duidelijke schets geeft je vaak een goed beeld van waar je het zoeken moet.
4. Jezelf vragen stellen
In het verkleinen van je zoekgebied, stel vragen die ervoor zorgen dat je zaken uit kan sluiten. Bijvoorbeeld:
- Hebben alle gebruikers er last van of slechts een aantal?
- Wanneer er slechts een aantal gebruikers last van hebben, wat maakt dan die gebruikers uniek en/of afwijkend?
Op het moment dat je een idee hebt over waar het probleem zit, ga je inzoomen. Denk hierbij aan een sniffer. Hiermee kan je, op specifieke punten in de omgeving, naar het verkeer kijken. Je kan letterlijk zien wat er over het netwerk gaat. Juist in de packets kunnen de antwoorden voor het probleem gevonden worden. Een complicerende factor is het gebruik van SSL verbindingen (https). Met de toenemende sterkte van versleuteling is soms het verkeer niet meer zichtbaar te maken. Dan moet je op een andere manier gaan zoeken naar crashende processen (segfaults) in een webserver.
5. Meten
Meten is weten! Meet wat je omgeving doet. Een wijziging in het gebruik van verbindingen, CPU en disk IO, zijn indicatoren en geven vaak al aan waar je problemen moet zoeken. Zorg dat je de tijdlijn van het probleem naast de grafieken en de informatie uit je monitoring legt.
Maak gebruik van tooling, zoals Atop, die laat zien waar een systeem mee bezig is. Zet wat je leert om in structuur. Hiermee bedoelen we dat je vooraf informatie in je monitoring kunt verzamelen en daar de juiste triggers aan kunt hangen. Bijvoorbeeld het bewaken van een diskruimte, door de juiste triggers, kun je ervoor zorgen dat je tijdig wordt gealarmeerd en een probleem vóór bent!
6. Configuratiemanagement
Een belangrijk onderdeel bij het debuggen van een probleem is configuratiemanagement. Zorg ervoor dat je de historie van configuratie bewaart en het altijd kan raadplegen. Het kan zijn dat een configuratiewijziging in het verleden tot het probleem heeft geleid.
Leg de configuratiewijzigingen naast de tijdlijn van het probleem. Een stuk missende configuratie, na een stroomstoring, is dan binnen enkele minuten gevonden in plaats van dat je uren aan het zoeken bent.
Conclusie
Troubleshooting heeft baat bij toeval. Je kan, als je aan het zoeken bent, over het probleem struikelen. Het structureel aanpakken van het probleem door het inzetten van alle tooling die je beschikbaar hebt is veelal efficiënter en effectiever. Troubleshooting is vooral veel doen! Ervaring is onmisbaar en maakt dat je in de toekomst sneller een oplossing vindt.
Wat we ook zien is dat de ene persoon een goede troubleshooter is en de andere er minder talent voor heeft. Daarom is het belangrijk dat je samen aan troubleshooting doet. In dit geval is 1 + 1 heel vaak 3!
Wil je meer weten over troubleshooting en hoe wij je kunnen helpen, neem dan vrijblijvend contact met ons op!