In mijn vorige blog eindigde ik met “uithuilen en opnieuw beginnen”, wat langzamerhand de “standaardmanier” lijkt te worden om problemen op te lossen.
Systemen en netwerken worden steeds complexer en teruggaan naar een known good situatie kan zorgen een snel herstel van de diensten.
Vanuit een operationeel perspectief is dit een goede oplossing: je bent snel weer “in de lucht”. Op de langere termijn is dat wat mij betreft nog maar de vraag. Een goede “root cause analysis” kan veel tijd kosten, maar uiteindelijk lijkt het mij van groot belang om te weten waaróm iets gefaald heeft.
Troubleshooting is lastigste vaardigheid van IT'er
Nu is natuurlijk de vraag: waaróm is de primaire oplossing tegenwoordig vaak het opnieuw uitrollen van een systeem of applicatie? Ik denk dat één van de belangrijkste oorzaken is, dat “troubleshooting” één van de lastigste vaardigheden in de IT is. Er zijn maar weinig mensen die, geconfronteerd met een probleem, dit probleem structureel kunnen benaderen en één voor één de mogelijke oorzaken kunnen uitsluiten.
Ik heb in mijn carrière dan ook meerdere malen voorbeelden gezien van relatief eenvoudige problemen die toch niet opgelost werden omdat ze niet op de juiste manier bekeken werden.
Een mooi voorbeeld hiervan is een klant die mij belde met een probleem: er was 9 maanden eerder een nieuw stuk netwerk uitgerold en daarop was een camera aangesloten. Ondanks diverse pogingen van verschillende leveranciers, deed deze camera het niet. Toen ik eenmaal ingelogd was op het netwerk, had ik het in 10 minuten opgelost. Was dit nu zo’n complex probleem, waar alleen mijn unieke kennis een oplossing voor had? Welnee: elke netwerkengineer met een jaar ervaring had dit probleem op kunnen lossen, maar blijkbaar had voor mij niemand op de juiste plaats gekeken.
Training
Trainingen leggen vaak de nadruk op de technische kennis. Natuurlijk is voldoende technische kennis onontbeerlijk bij het oplossen van complexe issues. Op Cisco Live is er veel aandacht is voor de “Troubleshooting” sessies. In deze sessies gaat een medewerker van Cisco, meestal iemand uit het productteam of het TAC (Technical Assistance Center) diep in op een platform of techniek. Hier leer je de diepe details van bijvoorbeeld een serie routers. Details die je niet op de Cisco site, in een boek of op een andere training hoort. Er wordt tot het diepste niveau uitgelegd hoe deze apparaten een pakket van de ene interface naar de andere sturen en hoe zo'n apparaat intern functioneert. Je gaat hierdoor ook de beperkingen van het apparaat beter begrijpen.
In het voorbeeld wat ik gaf, was technische kennis echter niet het probleem. Elke junior netwerkengineer had voldoende technische kennis gehad om dit probleem op te lossen. Toch wordt er in de meeste trainingen maar weinig aandacht besteed aan “troubleshooting-vaardigheden”: hoe benader je een probleem nu structureel en elimineer je mogelijke oorzaken en mogelijke oplossingen?
Sabotagespel
Een leuk voorbeeld hoe je speels om kan gaan met deze troubleshooting vaardigheden, was het “Sabotage!”-spel dat ik op Cisco Live! speelde. In een groep van 3 personen moest je het netwerk van de andere groepen saboteren. Tegelijkertijd probeerden de andere groepen natuurlijk ook jouw netwerk te saboteren. Omdat je steeds maar toegang had tot één device bij de “concurrent” moest je steeds creatief blijven. De netwerken waren redundant opgebouwd, dus het rücksichtlos slopen van een device zorgde er alleen maar voor dat het verkeer via het redundante pad gestuurd werd. De score werd bijgehouden door een ping die door het netwerk liep. Zolang de ping aankwam, liep je score op. Een erg leuke manier om je troubleshootingskills, creatief denken maar zeker ook samenwerken te oefenen. Helemaal leuk was dat mijn groepje uiteindelijk als winnaar uit de bus kwam.
Tools en documentatie
Naast troubleshooting-vaardigheden zijn ook tools van groot belang. Dit kunnen de algemene tools als Wireshark of zelfs gewoon ping zijn, maar ook platform-specifieke tools. Daarnaast is goede en up-to-date documentatie van wezenlijk belang. Zeker in een complexe omgeving met wellicht meerdere lagen van virtualisatie en afhankelijkheden is het zonder tools en documentatie vrijwel onmogelijk om de juiste inschatting te maken. Maar die tools en documentatie zijn niks waard zonder een kundige beheerder.
Conclusie
Simpelweg weggooien en opnieuw beginnen wordt steeds meer de “standaard” oplossing. Als je een “continual improvement” van je kwaliteit wilt hebben is dit, naar mijn mening, geen oplossing. Wellicht wel om snel weer online te zijn, maar niet als definitieve oplossing. Bovendien is het soms helemaal niet mogelijk om alles weg te gooien. Helaas ontbreken goede troubleshooting-vaardigheden bij veel IT’ers, wellicht doordat daar in trainingen maar weinig aandacht aan besteed wordt.
Jeroen Roos
Jeroen Roos is principal consultant bij NiVo network architects met ruim 20 jaar ervaring in IT infrastructuren. Jeroen werkt als netwerk- en securityspecialist bij klanten van Nivo in onder andere overheid, service provider, retail en industrie. Hij heeft ervaring met architectuur, ontwerpen, bouwen en beheren van netwerken.