10 Minuten
Ein Mitarbeiter berichtet, dass das Einloggen langsam ist. Sie fragen, wann dies auftritt, und erhalten folgende Antwort: „Manchmal. Meistens morgens.“ Wenn Sie fragen, um welche Anwendung es sich handelt, lautet die Antwort: „Eigentlich um alle.“ Sind Sie selbst vor Ort, funktioniert es natürlich einwandfrei.
Wer einen Remote-Arbeitsplatz auf Basis von Citrix, RDS oder Parallels verwaltet, kennt dieses Muster. Eine Störung hat einen Anfang und ein Ende. Bei einer Verlangsamung ist das anders. Sie schleicht sich ein, verschlimmert sich allmählich und wird erst dann thematisiert, wenn die Situation wirklich unhaltbar wird. Zu diesem Zeitpunkt liegen bereits Monate an Änderungen, Updates und Erweiterungen darüber, und es gibt keinen Ausgangspunkt mehr, auf den man zurückgreifen könnte.
Die Fehlerbehebung bei Leistungsproblemen funktioniert daher wie das Schälen einer Zwiebel. Man entfernt Schicht für Schicht etwas, findet den Verursacher selten auf Anhieb, und erst nach einigen Schichten erkennt man, welche kleinen Faktoren zusammen das Problem ausmachen. Das kostet Zeit. In diesem Artikel erfahren Sie, warum das so ist, welche Schichten Sie abtragen müssen, was Sie messen sollten, um das Problem beim nächsten Mal schneller zu finden, und wie Sie verhindern können, dass ein schlummerndes Problem tagelang Produktionsausfälle verursacht.
Warum dauert die Behebung von Langsamkeit länger als die Behebung einer Störung?
Eine Störung und ein Leistungsproblem ähneln sich zwar, verhalten sich jedoch völlig unterschiedlich. Dieser Unterschied bestimmt, wie lange Sie suchen müssen.
Eine Störung
- Es gibt einen eindeutigen Zeitpunkt, an dem es begann
- Wird eine Fehlermeldung oder ein Log-Eintrag ausgegeben
- Ist reproduzierbar; Sie können es jemandem vorführen
- Betrifft in der Regel alle gleichzeitig, sodass eine Eskalation von selbst erfolgt
- Hat oft eine einzige Ursache
Trägheit
- Es gibt keinen Anfang, es ist schrittweise entstanden
- Es wird keine Fehlermeldung angezeigt, technisch gesehen funktioniert alles
- Lässt sich nicht auf Abruf reproduzieren
- Unterscheidet sich je nach Benutzer, Standort und Tageszeit
- Hat fast nie eine einzige Ursache, sondern ist die Summe kleiner Abweichungen
Dieser letzte Punkt nimmt den größten Teil der Zeit in Anspruch. Man entdeckt ein Timeout, das etwas zu häufig auftritt, einen Treiber, der eine Version hinterherhinkt, oder eine Freigabe, die langsamer reagiert als die übrigen. Jedes Detail für sich genommen ist zu unbedeutend, um Alarm zu schlagen. Erst wenn Sie sie nebeneinander betrachten, erkennen Sie das Muster, und es stellt sich heraus, dass eines oder zwei davon die eigentlichen Übeltäter sind.
Was passiert, wenn jede Abteilung nur auf ihr eigenes Dashboard schaut?
Bei einem Kunden, bei dem ich wochenlang an einer solchen Meldung arbeitete, ereignete sich Folgendes. Die Netzwerkadministratoren stellten keine Auslastung fest und verwiesen auf das Speicherteam. Das Speicherteam wies auf eine Latenz hin, die ordnungsgemäß innerhalb der Norm lag, und verwies auf die Virtualisierungsadministratoren. Diese sahen ausreichend freien Arbeitsspeicher und CPU-Leistung und verwiesen auf das Image.
Alle drei hatten Recht. Innerhalb ihrer eigenen Diagramme stimmte alles. Nur schaute niemand auf den Abschnitt dazwischen, und genau dort lag das Problem. Jede Abteilung schälte eine Schicht ab und reichte die Zwiebel an die nächste weiter.
Dies ist keine Frage der mangelnden Bereitschaft. Es ist eine Folge der Art und Weise, wie die Verantwortlichkeiten verteilt sind. Solange niemand den Auftrag hat, die gesamte Kette zu betrachten, dreht sich dieser Kreislauf weiter, und niemand schält ihn durch. Bei Organisationen mit mehreren Lieferanten ist dieser Effekt noch stärker, da jede Partei zudem ein wirtschaftliches Interesse daran hat, nachzuweisen, dass es nicht an ihr liegt.
Welche Risiken gehen Sie ein, wenn die Trägheit bestehen bleibt?
Trägheit wird eher als Unannehmlichkeit empfunden, nicht als Risiko. In der Praxis verursacht sie höhere Kosten, als die meisten Unternehmen annehmen.
Unmittelbarer Produktionsausfall
Eine von Markteffect im Auftrag von Sharp durchgeführte Studie zeigt, dass fast ein Viertel der niederländischen Berufstätigen täglich mindestens eine Viertelstunde mit IT-Problemen verbringt, wobei langsame Systeme und Netzwerkverbindungen den größten Ärger bereiten. Der durchschnittliche Verlust beläuft sich auf gut sechs Euro pro Mitarbeiter und Tag, was auf Jahresbasis mehrere Milliarden ausmacht. Quelle: ICT Magazine.
Rechnen Sie das einmal für Ihr eigenes Unternehmen durch. Eine Viertelstunde pro Tag bei fünfzig Mitarbeitern entspricht mehr als zwölf Stunden Produktionszeit pro Tag. Das entspricht einem Vollzeitmitarbeiter, der keinen Beitrag leistet – Tag für Tag –, ohne dass jemand ein Ticket erstellt.
Meldungen, die nie eingehen
Eine Umfrage von SPS unter mehr als tausend niederländischen Arbeitnehmern ergab, dass 91 Prozent unter IT-Problemen im Büro leiden und dass eine langsame Reaktionszeit der Software den größten Ärger verursacht. Ein Viertel verbringt mehr als eine Stunde pro Woche mit IT-Problemen. Quelle: HR Praktijk.
Das Problem ist, dass diese Zeit selten in Ihrem Ticket-System erfasst wird. Die Mitarbeiter holen sich während des Einloggens einen Kaffee, starten ihre Anwendungen bereits vor der Kaffeepause und akzeptieren dies als den normalen Ablauf. Ihr Service-Desk erhält daher nur einen Bruchteil der tatsächlichen Vorgänge.
Falsche Investitionsentscheidungen
Wenn Sie nicht wissen, wo die Zeit bleibt, ist das Hinzukaufen die verlockendste Lösung. Mehr Arbeitsspeicher, schnellerer Speicher, zusätzliche Hosts. Manchmal hilft das. Häufiger jedoch verlagern Sie das Problem lediglich und haben eine Investition getätigt, die die eigentliche Ursache nicht angeht.
Nutzer, die nach eigenen Lösungen suchen
Wenn der Remote-Arbeitsplatz zu langsam wird, suchen die Nutzer nach Umgehungslösungen. Sie speichern Dateien lokal, nutzen private Cloud-Dienste oder senden E-Mails an ihre private Adresse. Dadurch wird aus einem Leistungsproblem still und leise ein Sicherheits- und Compliance-Problem.
Wie geht man ein Leistungsproblem Schicht für Schicht an?
Ich arbeite stets vom Nutzer ausgehend rückwärts. Das ist die einzige logische Reihenfolge, da die Beschwerde genau dort entsteht. In einer Remote-Arbeitsplatzumgebung begegnen Ihnen folgende Ebenen:
- Der Endpunkt: der Laptop, Thin Client oder das Tablet, einschließlich Treibern, lokaler Sicherheitssoftware und der Client-Version
- Die Verbindung: Bandbreite, Latenz, Paketverlust, WLAN im Vergleich zu kabelgebundenen Verbindungen, Homeoffice-Verbindungen
- Die Zugriffsebene: Gateway, Load Balancer, Authentifizierung und Multi-Faktor-Authentifizierung
- Der Anmeldevorgang: Profil, Gruppenrichtlinien, Anmeldeskripte, Laufwerkszuordnungen, Drucker
- Die Sitzung selbst: Image, installierte Anwendungen, Agenten, Antivirenprogramm, Energieverwaltung
- Die Hosts: CPU-Ready-Zeit, Speicherüberlastung, Verteilung der Workloads
- Der Speicher: Latenz, IOPS, Snapshots, Hintergrundaufgaben wie Backups
- Das Backend: Dateiserver, Datenbanken, Anwendungsserver, Lizenzserver
Bei jeder Ebene schließen Sie etwas aus und notieren, was Ihnen auffällt. Das fühlt sich wie Stillstand an, aber genau darin besteht die Arbeit. Das ist auch der Grund, warum eine gute Analyse Tage bis Wochen dauern kann, wenn nichts gemessen wurde. Sie rekonstruieren dann im Nachhinein eine Situation, die sich vor Monaten ereignet hat.
Was müssen Sie messen, um Trends statt Einzelvorfälle zu erkennen?
Eine Messung erst dann durchzuführen, wenn die Beschwerden bereits eingegangen sind, liefert eine Zahl ohne Vergleichsdaten. Sie wissen dann zwar, dass eine Anmeldung 65 Sekunden dauert, aber nicht, ob dies von der Norm abweicht. Ohne Basiswert tappen Sie im Dunkeln.
Was Sie benötigen, sind strukturelle Messungen über die gesamte Kette hinweg, die täglich erfasst werden. Denken Sie beispielsweise an:
- Anmeldedauer, aufgeschlüsselt nach einzelnen Schritten, damit Sie erkennen können, welcher Teil die meiste Zeit in Anspruch nimmt
- Anwendungsstartzeiten pro Anwendung
- Latenz der Sitzung in Richtung des Benutzers
- Netzwerklatenz und Paketverlust zwischen den wichtigsten Punkten in der Kette
- Antwortzeiten in Richtung Datenbanken und Dateiserver
- Speicherlatenz und IOPS, auch während der Backup-Fenster
- Profilgröße und deren Entwicklung im Zeitverlauf
- Auslastung der Hosts, einschließlich CPU-Ready-Zeit
Der Wert liegt nicht in den einzelnen Zahlen, sondern in der Entwicklung. Ein Anstieg der Anmeldezahlen, der sich über sechs Monate hinweg allmählich vollzieht, ist kein Einzelfall, sondern eine Verschiebung. Darauf können Sie reagieren, bevor sich die Nutzer beschweren.
Wenn Sie nur eine Ebene messen, übersehen Sie genau den Punkt, an dem es schiefgeht. Eine kleine Veränderung an einer beliebigen Stelle in der Kette kann weiter hinten erhebliche Auswirkungen haben. Ein paar Millisekunden zusätzliche Latenz bei einer Datenbankverbindung fallen in keinem Diagramm auf, doch bei Tausenden von Abfragen pro Sitzung summiert sich dies auf der Nutzerseite zu Wartezeiten von mehreren Minuten. Diesen Zusammenhang erkennen Sie nur, wenn Sie die Kette in ihrer Gesamtheit messen.
Was sind die häufigsten Einwände gegen strukturelle Messungen?
Unser Anbieter überwacht bereits
Meistens stimmt das, aber dabei geht es um die Verfügbarkeit von Servern und Diensten. Grün bedeutet, dass der Rechner läuft, nicht, dass der Nutzer innerhalb von dreißig Sekunden mit der Arbeit beginnen kann. Fragen Sie Ihren Anbieter doch einmal, ob er Ihnen die Anmeldedauer des letzten Monats zeigen kann.
Das ist wieder ein Tool mehr, das niemand ansieht
Ein berechtigter Einwand. Ein Dashboard ohne Verantwortlichen ist reine Verschwendung. Legen Sie daher fest, wer sich wöchentlich fünf Minuten lang damit befasst und ab welchem Schwellenwert ein Gespräch erforderlich ist. Ohne diese Vereinbarung sollten Sie auf die Messung besser verzichten.
Wir sind zu klein für diese Art der Überwachung
Der Umfang bestimmt vor allem die Wahl der Werkzeuge, nicht die Notwendigkeit. Bei dreißig Anwendern können Sie bereits viel mit den in Ihrer Plattform integrierten Werkzeugen erkennen, ergänzt durch regelmäßige Messungen. Vergleichen Sie die damit verbundenen Kosten einmal mit wochenlangen Suchvorgängen und Tagen an Produktionsausfällen.
Niemand beschwert sich, also läuft alles gut
Das ist die gefährlichste Annahme. Die Nutzer melden zwar, wenn eine Anwendung abstürzt, berichten aber nicht, wenn eine Anmeldung eine Minute länger dauert. Stille in Ihrem Ticket-System bedeutet nicht, dass das System schnell ist.
Wir steigen doch auf die Cloud um
Eine Migration verändert die Kette, lässt sie aber nicht verschwinden. Latenz, Profilverarbeitung, Anwendungsstart und Backend-Antwort bleiben bestehen und werden manchmal sogar noch sensibler. Ohne eine Basislinie wissen Sie nach der Migration nicht, ob es besser oder schlechter geworden ist.
Welche Checkliste gehen Sie durch, wenn Verzögerungen gemeldet werden?
Befolgen Sie diese Schritte, sobald die erste Meldung eingeht, und warten Sie nicht, bis sich die Situation zuspitzt.
- Erfassen Sie, wer die Meldung macht, zu welcher Tageszeit, von welchem Standort aus und über welches Gerät
- Fragen Sie nach den Einzelheiten: Ist die Anmeldung langsam, betrifft es eine bestimmte Anwendung oder alles?
- Prüfen Sie, ob das Problem bei mehreren Nutzern auftritt; aktives Nachfragen bringt immer mehr als Abwarten
- Prüfen Sie, ob es kürzlich Änderungen, Updates oder Erweiterungen gegeben hat, und stellen Sie diese Zeitachse daneben
- Messen Sie die Anmeldedauer Schritt für Schritt für einen Testnutzer zur gleichen Uhrzeit wie die Beschwerde
- Gehen Sie die Ebenen vom Benutzer bis zum Backend durch und notieren Sie bei jeder Ebene, was auffällt – auch die kleinen Details
- Stellen Sie die Ergebnisse nebeneinander und suchen Sie nach der Gesamtsumme statt nach einer einzigen Ursache
- Führen Sie nach der Lösung eine Messung durch, damit Sie beim nächsten Mal einen Ausgangspunkt haben
Was bringt ein Health Check Ihrer Citrix-, RDS- oder Parallels-Umgebung?
New Yard konzentriert sich auf den digitalen Arbeitsplatz für kleine und mittlere Unternehmen. Ich führe die Health Checks in Citrix-, RDS- und Parallels-Umgebungen selbst durch, besuche Kunden vor Ort und kümmere mich neben der Beratung auch um die Lizenzen und die Implementierung. Das bedeutet, dass ein festgestelltes Problem nicht in einem Bericht stehen bleibt, sondern auch behoben werden kann.
Bei einem solchen Health-Check prüfe ich den Aufbau der Umgebung, die Gestaltung des Anmeldeprozesses, die Auslastung der Hosts und des Speichers, die Konfiguration von Profilen und Richtlinien sowie die Versionen und die Lebensdauer der Komponenten. Anschließend erhalten Sie einen Überblick darüber, was in Ordnung ist, was Aufmerksamkeit erfordert und wo Risiken bestehen. Wenn Sie dies jährlich durchführen, bauen Sie automatisch eine Historie auf und erkennen Veränderungen bereits im Voraus, anstatt erst im Nachhinein.
Woher wissen Sie, ob Ihre Umgebung dafür bereit ist?
Wenn Sie derzeit nicht sagen können, wie lange eine durchschnittliche Anmeldung im letzten Monat gedauert hat, verfügen Sie über keine Basislinie. Dann ist die Frage nicht, ob Sie einmal wochenlang suchen müssen, sondern wann.
Es gibt noch einen weiteren Grund, sich jetzt damit zu befassen. Viele KMU-Unternehmen nutzen Versionen von Citrix, RDS oder Parallels, deren Support bald ausläuft, und eine Migration ohne vorherige Messdaten ist ein Glücksspiel. Sie wissen dann im Nachhinein nicht, ob die neue Umgebung eine bessere Leistung erbringt als die alte.
Vereinbaren Sie über newyard.nl ein unverbindliches Kennenlerngespräch. Wir sehen uns gemeinsam Ihre Umgebung an, und ich erkläre Ihnen, welche Messungen ich vornehmen würde und welchen Nutzen ein Health Check in Ihrer Situation bietet. Keine Verpflichtungen, kein Verkaufsgespräch.