10 minuten
Een medewerker meldt dat inloggen traag is. Je vraagt wanneer het gebeurt en krijgt als antwoord: soms. Meestal ’s ochtends. Vraag je welke applicatie het betreft, dan is het antwoord: eigenlijk alles. Sta je er zelf bij, dan gaat het natuurlijk prima.
Wie een remote werkplek beheert op basis van Citrix, RDS of Parallels kent dit patroon. Een storing heeft een begin en een einde. Traagheid heeft dat niet. Die sluipt erin, wordt langzaam erger en komt pas op tafel als het echt onwerkbaar wordt. Op dat moment liggen er maanden aan changes, updates en uitbreidingen overheen en is er geen startpunt meer om op terug te vallen.
Troubleshooting van performanceproblemen werkt daarom als het pellen van een ui. Je haalt er laag voor laag iets af, je vindt zelden meteen de dader, en pas na een aantal lagen zie je welke kleine dingen samen het probleem vormen. Dat kost tijd. In dit artikel lees je waarom dat zo is, welke lagen je afpelt, wat je moet meten om het de volgende keer sneller te vinden en hoe je voorkomt dat een sluimerend probleem dagenlang productie kost.
Waarom duurt het oplossen van traagheid langer dan het oplossen van een storing?
Een storing en een prestatieprobleem lijken op elkaar, maar gedragen zich totaal verschillend. Dat verschil bepaalt hoe lang je zoekt.
Een storing
- Heeft een duidelijk moment waarop het begon
- Geeft een foutmelding of een logregel
- Is reproduceerbaar, je kunt het aan iemand laten zien
- Raakt meestal iedereen tegelijk, dus escalatie gaat vanzelf
- Heeft vaak één oorzaak
Traagheid
- Kent geen begin, het is geleidelijk ontstaan
- Levert geen foutmelding op, alles werkt technisch gezien
- Is niet op afroep te reproduceren
- Verschilt per gebruiker, per locatie en per moment van de dag
- Heeft bijna nooit één oorzaak, maar een optelsom van kleine afwijkingen
Dat laatste punt is waar de meeste tijd in gaat zitten. Je vindt een timeout die net iets te vaak terugkomt, een driver die een versie achterloopt, een share die trager reageert dan de rest. Ieder detail is op zichzelf te klein om alarm over te slaan. Pas als je ze naast elkaar legt, zie je het patroon en blijkt er een of twee de werkelijke boosdoener.
Wat gebeurt er als elke afdeling alleen naar het eigen dashboard kijkt?
Bij een klant waar ik weken aan zo’n melding zat, gebeurde het volgende. De netwerkbeheerders zagen geen verzadiging en wezen naar het storageteam. Storage liet latency zien die keurig binnen de norm bleef en wees naar de virtualisatiebeheerders. Die zagen genoeg geheugen en CPU vrij en wezen naar het image.
Ze hadden alle drie gelijk. Binnen hun eigen grafieken klopte alles. Alleen keek niemand naar het stuk ertussen, en juist daar zat het. Elke afdeling pelde één laag en gaf de ui door aan de volgende.
Dit is geen kwestie van onwil. Het is een gevolg van hoe verantwoordelijkheden zijn verdeeld. Zolang niemand de opdracht heeft om de hele keten te bekijken, blijft die cirkel draaien en pelt er niemand door. Bij organisaties met meerdere leveranciers is het effect nog sterker, omdat elke partij ook nog een commercieel belang heeft om aan te tonen dat het niet aan hen ligt.
Welke risico’s loop je als traagheid blijft liggen?
Traagheid voelt als een ongemak, niet als een risico. In de praktijk kost het meer dan de meeste organisaties denken.
Direct productieverlies
Onderzoek van Markteffect in opdracht van Sharp laat zien dat bijna een kwart van de Nederlandse werkenden dagelijks minimaal een kwartier kwijt is aan IT-problemen, met trage systemen en netwerkverbindingen als grootste ergernis. Het gemiddelde verlies komt uit op ruim zes euro per medewerker per dag, wat neerkomt op miljarden op jaarbasis. Bron: ICT Magazine.
Reken dat eens door voor je eigen organisatie. Een kwartier per dag bij vijftig medewerkers is meer dan twaalf uur productie per dag. Dat is een fulltime medewerker die niets oplevert, elke dag opnieuw, zonder dat er iemand een ticket aanmaakt.
Meldingen die nooit binnenkomen
Uit onderzoek van SPS onder ruim duizend Nederlandse werknemers bleek dat 91 procent last heeft van IT-problemen op kantoor en dat een trage reactietijd van software de grootste ergernis is. Een kwart besteedt meer dan een uur per week aan IT-problemen. Bron: HR Praktijk.
Het probleem is dat die tijd zelden in je ticketsysteem terechtkomt. Mensen halen koffie tijdens het inloggen, starten hun applicaties alvast op voor de koffiepauze en accepteren het als hoe het nu eenmaal werkt. Je servicedesk ziet daardoor een fractie van wat er speelt.
Verkeerde investeringsbeslissingen
Als je niet weet waar de tijd blijft, is bijkopen de verleidelijkste oplossing. Meer geheugen, snellere storage, extra hosts. Soms helpt dat. Vaker verplaats je het probleem en heb je een investering gedaan die de werkelijke oorzaak niet raakt.
Gebruikers die hun eigen oplossing zoeken
Wanneer de remote werkplek te traag wordt, gaan mensen eromheen werken. Bestanden lokaal opslaan, privé-clouddiensten gebruiken, mailen naar het eigen adres. Daarmee wordt een prestatieprobleem stilletjes een beveiligings- en compliancevraagstuk.
Hoe pel je een prestatieprobleem laag voor laag af?
Ik werk altijd van de gebruiker naar achteren. Dat is de enige volgorde die logisch is, omdat de klacht daar ontstaat. Deze lagen kom je in een remote werkplekomgeving tegen:
- Het endpoint: de laptop, thin client of tablet, inclusief drivers, lokale beveiligingssoftware en de versie van de client
- De verbinding: bandbreedte, latency, pakketverlies, wifi versus bekabeld, thuiswerkverbindingen
- De toegangslaag: gateway, load balancer, authenticatie en multifactor
- Het inlogproces: profiel, group policies, logon scripts, drive mappings, printers
- De sessie zelf: image, geïnstalleerde applicaties, agents, antivirus, energiebeheer
- De hosts: CPU ready time, geheugenoverboeking, plaatsing van workloads
- De storage: latency, IOPS, snapshots, achtergrondtaken zoals back-up
- De backend: fileservers, databases, applicatieservers, licentieservers
Bij elke laag sluit je iets uit en noteer je wat opvalt. Dat voelt als stilstand, maar het is precies het werk. Het is ook de reden dat een goede analyse dagen tot weken kan kosten wanneer er niets gemeten is. Je reconstrueert dan achteraf een situatie die maanden geleden is ontstaan.
Wat moet je meten om trends te zien in plaats van incidenten?
Meten op het moment dat de klachten al binnen zijn levert een getal op zonder vergelijkingsmateriaal. Je weet dan dat een inlog vijfenzestig seconden duurt, maar niet of dat afwijkt. Zonder baseline zoek je in het donker.
Wat je nodig hebt is structurele meting over de hele keten, dagelijks vastgelegd. Denk aan:
- Logon duration, opgesplitst per stap zodat je ziet welk onderdeel de tijd opeet
- Application launch times per applicatie
- Latency van de sessie richting de gebruiker
- Netwerklatency en pakketverlies tussen de belangrijkste punten in de keten
- Responstijden richting databases en fileservers
- Storage latency en IOPS, ook tijdens back-upvensters
- Profielgrootte en de groei daarvan over de tijd
- Belasting van de hosts, inclusief CPU ready time
De waarde zit niet in de losse getallen, maar in het verloop. Een inlog die over zes maanden geleidelijk oploopt is geen incident maar een verschuiving. Daar kun je op acteren voordat gebruikers gaan klagen.
Meet je maar één laag, dan mis je precies waar het misgaat. Een kleine verandering ergens in de keten kan verderop grote gevolgen hebben. Een paar milliseconden extra latency op een databaseverbinding valt in geen enkele grafiek op, maar bij duizenden queries per sessie loopt dat op tot minuten wachttijd aan de gebruikerskant. Die samenhang zie je alleen als je de keten in zijn geheel meet.
Wat zijn de veelgehoorde bezwaren tegen structureel meten?
Onze leverancier monitort al
Meestal klopt dat, maar het gaat dan om beschikbaarheid van servers en services. Groen betekent dat de machine draait, niet dat de gebruiker binnen dertig seconden aan het werk is. Vraag je leverancier eens of hij de logon duration van vorige maand kan laten zien.
Dat is weer een tool erbij die niemand bekijkt
Terecht punt. Een dashboard zonder eigenaar is verspilling. Spreek daarom af wie er wekelijks vijf minuten naar kijkt en welke drempelwaarde een gesprek waard is. Zonder die afspraak kun je het meten beter overslaan.
Wij zijn te klein voor dit soort monitoring
De omvang bepaalt vooral het gereedschap, niet de noodzaak. Bij dertig gebruikers kun je al veel zien met de tooling die in je platform zit, aangevuld met een periodieke meting. Zet de kosten daarvan eens af tegen weken zoeken en dagen verloren productie.
Niemand klaagt, dus het gaat goed
Dat is de gevaarlijkste aanname. Mensen melden een applicatie die crasht, maar melden geen inlog die een minuut langer duurt. Stilte in je ticketsysteem betekent niet dat het snel is.
We gaan toch naar de cloud
Een migratie verandert de keten, maar hij verdwijnt niet. Latency, profielafhandeling, applicatiestart en backendrespons blijven bestaan en worden soms zelfs gevoeliger. Zonder baseline weet je na de migratie niet of het beter of slechter is geworden.
Welke checklist loop je af als traagheid wordt gemeld?
Gebruik deze stappen zodra de eerste melding binnenkomt, niet pas als het escaleert.
- Leg vast wie het meldt, op welk moment van de dag en vanaf welke locatie en welk apparaat
- Vraag naar het verschil: is het inloggen traag, een specifieke applicatie, of alles
- Controleer of het bij meer gebruikers speelt, actief navragen levert altijd meer op dan wachten
- Kijk of er recent changes, updates of uitbreidingen zijn geweest en leg die tijdlijn ernaast
- Meet de logon duration per stap voor een testgebruiker op hetzelfde tijdstip als de klacht
- Loop de lagen van gebruiker naar backend af en noteer bij elke laag wat opvalt, ook het kleine
- Leg de bevindingen naast elkaar en zoek naar de optelsom in plaats van naar één oorzaak
- Zet na de oplossing een meting neer, zodat je de volgende keer wel een vertrekpunt hebt
Wat levert een health check van je Citrix-, RDS- of Parallels-omgeving op?
New Yard richt zich op de digitale werkplek voor het MKB. Ik voer zelf de health checks uit op Citrix-, RDS- en Parallels-omgevingen, kom bij klanten over de vloer en doe naast advies ook de licenties en de implementatie. Dat betekent dat een bevinding niet in een rapport blijft hangen, maar ook opgelost kan worden.
Bij zo’n health check kijk ik naar de opbouw van de omgeving, de inrichting van het inlogproces, de belasting van de hosts en storage, de configuratie van profielen en beleid en de versies en levensduur van de componenten. Je krijgt daarna een overzicht van wat goed staat, wat aandacht vraagt en waar de risico’s zitten. Doe je dat jaarlijks, dan bouw je vanzelf een historie op en zie je verschuivingen aankomen in plaats van achteraf.
Hoe weet je of jouw omgeving er klaar voor is?
Als je nu niet kunt vertellen hoe lang een gemiddelde inlog vorige maand duurde, heb je geen baseline. Dan is de vraag niet of je een keer wekenlang gaat zoeken, maar wanneer.
Er is nog een reden om er nu naar te kijken. Veel MKB-organisaties draaien op versies van Citrix, RDS of Parallels die richting hun einde van support lopen, en een migratie zonder meetgegevens vooraf is een gok. Je weet dan achteraf niet of de nieuwe omgeving beter presteert dan de oude.
Plan een vrijblijvend kennismakingsgesprek via newyard.nl. We kijken samen naar je omgeving, ik vertel wat ik zou meten en wat een health check in jouw situatie oplevert. Geen verplichtingen, geen verkooppraatje.