Is jouw bedrijf afhankelijk van zijn helpdesk? Wees er dan trots op. Om businesscontinuïteit te garanderen, zijn er namelijk maar weinig vaardigheden waardevoller dan het oplossen van it-problemen. Ja, zelfs de werkdruk van de marketingafdeling en vergelijkbare afdelingen verbleekt naast die van de medewerkers die zich dagelijks bezighouden met troubleshooting.
Zoals bij de meeste beroepen is ook in it niet iedereen hetzelfde, en de vaardigheden van it-personeel verschillen van bedrijf tot bedrijf (net als hun salaris, overigens). Wat onderscheidt het doorsnee it-personeel van de echte professionals, oftewel degenen die geraadpleegd worden bij een crisis?
Misschien zijn het wel zebra’s
Sommige werkgevers gebruiken diploma’s en certificaten, de werkervaring of zakelijke prestaties als richtlijn. Maar hoe kom je – als je het cv opzij schuift – er nu echt achter of iemand goed is in het oplossen van it-problemen? Door hun vaardigheden te testen. It-problemen oplossen is een vaardigheid die zich door de tijd heen ontwikkelt. In tegenstelling tot wat veel mensen denken, is het niet jarenlange ervaring (al helpt dat wel) of een onderbuikgevoel waar de beste it-werknemers in de praktijk op vertrouwen om problemen te achterhalen.
Een veelgebruikte term is ‘confirmation bias’: de neiging van mensen om te zien wat ze verwachten te zien. Het gaat dan om een situatie waarin een it-probleem wordt vastgesteld zonder analyse en voordat daadwerkelijk een oplossing is gevonden. Bijvoorbeeld de neiging om de analyse op zo’n manier te interpreteren, dat het past bij het probleem. Zo’n ad-hoc-benadering is echter geen goed plan, en helemaal niet wanneer bedrijfskritische processen ervan afhankelijk zijn om te blijven draaien.
Een gezegde in de medische wereld luidt: ‘Als je hoefgetrappel hoort, denk dan eerst aan paarden en niet meteen aan zebra’s.’ Oftewel, gebruik bij een diagnose je gezonde verstand en ga uit van de meest alledaagse verklaring. Dit gaat echter niet op voor de it-wereld. Voor mensen in bepaalde delen van Afrika zijn zebra’s waarschijnlijker, en hetzelfde geldt voor de helpdesk: die ziet bedreigingen die andere gebruikers wellicht niet zouden verwachten. Als je serieus aan de slag wilt met probleemoplossing in it, dan is een vast proces noodzakelijk. Of je het nu troubleshooting of diagnostiek noemt: een gestructureerde en logische methode is altijd aan te raden. Hoewel het advies ‘uit- en aanzetten’ nog altijd relevant kan zijn, is het geen vervanger voor logica – hoe vluchtig ook – wanneer je op zoek bent naar een fout.
It-problemen zijn er in veel soorten en maten, en hebben soms meerdere mogelijke oplossingen en die kunnen allemaal in bepaalde mate helpen. Documenten met standard operating Pprocedures (sop) zijn iets flexibeler in het vereenvoudigen van diagnostiek, zonder dat je direct beperkt bent tot één vaste processtroom. In tegenstelling tot andere afdelingen is het voor it onmogelijk om processen en procedures in steen te beitelen. Troubleshooting is per definitie een zoektocht door allerlei aanwijzingen die zomaar kunnen leiden naar een gloednieuwe bron – die op zijn beurt weer een oplossing verschaft – die je opnieuw kunt gebruiken als het probleem zich nogmaals voordoet.
Echt waar, Sherlock?
Net als detectives hebben it-professionals te maken met een case – meestal een klacht van een gebruiker of de observatie dat het netwerk abnormaal overbelast is. Het oplossen van het probleem omvat altijd vijf hoofdstappen die doorlopen moeten worden. En dit proces biedt geen ruimte voor geïmproviseerde patches. De vijf stappen beginnen bij de signalering van een probleem, gevolgd door:
- verzamelen van alle beschikbare informatie of de vraag ‘Hoe openbaart het probleem zich?’;
- analyse van de informatie ‘Wat betekent dit, technisch gezien?’;
- eliminatieproces: als het draadloze netwerk traag is, is het onwaarschijnlijk dat het koffiezetapparaat er iets mee te maken heeft (dat op een apart netwerk zit);
- nadenken over de oorzaak: ‘Wat kan het probleem zijn?’ Er zijn meerdere mogelijkheden en die moeten op volgorde van waarschijnlijkheid gerangschikt worden;
- testen van de oplossing: afhankelijk van het tijdstip en het risico op downtime, is verdere analyse wellicht noodzakelijk voor de implementatie.
Diagnostische methoden
Een vast proces volgen is één ding, maar hoe zit het met methoden? Helaas zijn er meerdere methoden die regelmatig toegepast worden tijdens het oplossen van it-problemen. De keuze is vaak afhankelijk van het betreffende probleem. De meest voorkomende zijn:
- volgen van verkeer: met netwerkmonitoringtools is veel mogelijk om diagnostiek te vereenvoudigen, zoals het in de gaten houden van routes, ping en verkeersanalyse;
- zoeken van verschillen: vergelijk apparaten of processen die wel werken, met de apparaten of processen die niet werken;
- verplaatsing van het probleem: als je een apparaat verplaatst of kabels omwisselt, verplaatst het probleem dan mee?
It-diagnostiek vraagt om een protocol van een specialist. En hoewel gangbare problemen mogelijk prima op te lossen zijn op basis van instinct of logica, is het beter om alle problemen op een gestructureerde manier aan te pakken. Een ticketsysteem is wellicht de meest zichtbare vorm hiervan, waarmee je bedrijf een tastbaar naslagwerk in handen heeft met alle problemen, de tijd die het heeft gekost om ze op te lossen, en de gebruikte oplossingsmethoden. Dit is in ieder geval een betere manier dan slechts vertrouwen op een onderbuikgevoel of aannames over bepaalde apparaten of software.
Michael O’Dwyer, copywriter bij Ipswitch
Artikel dat lijkt te pleiten voor 1 uniform probleemoplossingsalgoritme hetgeen enigzins in tegenspraak is met de stelling dat het “om een protocol van een specialist” vraagt. Immers iedereen kan die 5 stappen doorlopen.
Wat betreft het realiteitsgehalte: in het algemeen moeten IT problemen zo snel mogelijk worden opgelost en is het systematisch opstellen en doorzoeken van volledige probleemruimte geen optie. Specialisten worden er in de regel juist bij geroepen omdat zij ervaring hebben met diagnostiek en een eigen heuristiek (informele, intuïtieve en speculatieve oplossingsstrategieën), een set kortste paden in de probleemruimte hebben opgebouwd.
De suggestie om een ticketsysteem in te zetten bij diagnostiek zou wellicht kunnen bij eenvoudige problemen waar er een 1 op 1 relatie bestaat tussen symptoom en oplossing. Bij complexe problemen biedt het in de regel geen soelaas.
Je stukje over zebra’s en paarden weet je alleen als je ervaring hiermee opgedaan hebt, waarmee je jezelf dus al tegenspreekt met de opmerking dat ervaring niet zo belangrijk is.
Ik heb zelf o.a enkele jaren 3e lijns ondersteuning gegeven op IBM mainframe / SNA netwerken (voor de oudere jongeren onder ons). Wil je op dat niveau problemen een beetje snel op kunnen lossen, is ervaring (met name herkenning van problemen / patronen / begrijpen logfiles etc) van zeer groot belang.
Over paarden en zebra’s gesproken: als het koffiezetapparaat op een ander netwerk zit dan je apparatuur van het draadloze netwerk, maar wel op dezelfde stroomvoorziening, dan kan kortsluiting in je koffiezetapparaat wel degelijk je netwerk beïnvloeden ….
Vreemd verhaal, incidenten en problemen lijken willekeurig door elkaar gehaald te worden waardoor de essentie van IT diagnostiek gemist wordt. Ik haal dit aan omdat punt 2 in de opsomming nog de bedrijfskundige motivatie mist door de impact van problemen (change management?) voor de business niet aan te geven. Hierbij kan een ticketsysteem uiteraard helpen maar dan zal daar dus wel een proces voor moeten zijn. Veelal wordt namelijk alleen de oplostijd (MTTD/MTTR) gemeten terwijl MTBF heel indicatief kan zijn voor een probleem.
Aangezien de incidenten vaak niet doorbelast worden mist de economische prikkel bij de business om de problematische oplossingen in de architectuur te elimineren. Dat hierdoor de werkdruk bij de beheer afdeling toeneemt lijkt me evident als er geen proces van afvoer is ingericht. Zwakke punt in het betoog van de auteur zit in de diagnostische methode van de ‘paardenhandel’ die alleen maar kijkt naar de infrastructuur. Processen hier zijn namelijk wel in steen gebeiteld door fysieke wetmatigheden. Pa Va Ke haalt een goed punt aan met de stroomvoorziening, het draadloze netwerk draait tenslotte ook niet op batterijen.
Probleemruimte van KJ is interessant, de dimensionale kant van architectuur neemt vaak de operationele tooling niet op in haar beschouwingen waardoor een proces zoals capaciteit management steeds afhankelijker wordt van de belofte van QoS. Mooi voorbeeld hiervan is de jaarlijkse belastingaangifte, zomaar een voorbeeld. Want als je gateway gelimiteerd is tot 10.000 concurrent connecties en je moet in 12 uur 8.000.000 transacties verwerken dan kun je de downtime als gevolg van DDoS wel uitrekenen.
Daarmee kom ik aan de Theory of Constraints, een simpel bedrijfskundig principe welke stelt dat elke investering in een non-bottleneck een verspilling is en niet investeren in een bottleneck een verlies. Het spreiden van de aangifte als slimme vorm van job scheduling is een logica die voorbij de techniek gaat door naar het proces zelf te kijken. Want de kortste paden zijn nog altijd de ‘olifantenpaadjes’ welke om instinct gaat. Simpele oplossingen voor complexe problemen vraagt gewoon de logica van een genie;-)