Autor: Oliver Oehlenberg, Field CTO EMEA, Riverbed 
Zielgruppe: IT-Fachverantwortliche für Desktop, Netzwerk und Anwendungen, Beschreibung Vorgehensweise für datengestütztes Troubleshooting 

Jeder kennt den Spruch: „Wer billig kauft, kauft zweimal“. Dass dieser Spruch auch in der IT seine Gültigkeit hat, zeigt das folgende Kundenbeispiel: In diesen Fall hat der Kunde eine neue (selbst entwickelte) Anwendung eingeführt, welche Arbeitsabläufe digitalisieren sollte. Auch an die Anwender hatte man gedacht, und so wurde den Mitarbeitern ein neuer „schicker“ 2-in-1 Business Laptop zur Verfügung gestellt, welcher als Arbeitsplatzlaptop als auch als Tablet genutzt werden konnte. 

Neue Software – aber keine Akzeptanz

Als jedoch die Anwender anfangen sollten, mit der neuen Anwendung zu arbeiten, haben viele Anwender gesagt, dass sie so nicht arbeiten können und viel zu lange z.B. auf den Abschluss einer Aufgabe in der neuen Anwendung warten müssen. Die Akzeptanz sank in wenigen Tagen dramatisch.

Als erste Reaktion der IT-Abteilung, wurde ein War-Room einzurichten, um das Problem zu analysieren. Die Anwendungsentwickler haben keinen Fehler bei sich gesehen, da die Anwendung in ihren automatischen Tests keine großen Latenzen zeigte. Auch die Server- und Rechenzentrum-Verantwortlichen konnten keine Probleme feststellen, es standen genügend Ressourcen zur Verfügung und es waren keine Lastspitzen erkennbar. So wurde das Problem im Ausschlussverfahren im Netzwerk vermutet.

Silo Denken und Komplexität

Man erkennt bereits, dass die unterschiedlichen IT-Fachabteilungen das Problem aus Ihren „Silo“ betrachten. Dieses Verfahren hat früher recht gut funktioniert, als die IT noch nicht so komplex war. Die IT ist aber in den letzten Jahren immer komplexer geworden. Benutzer arbeiten mobil und Backend-Systeme sind immer verteilter und (teilweise) in die Cloud verlagert. Das führt dazu, dass IT-Abteilungen für sie unbekannte Umgebungen (z.B. das Internet- oder WLAN-Verbindung) im Homeoffice mit in ihre Troubleshooting Überlegungen einbeziehen müssen. Und gerade, weil man diese Umgebungen nicht kennt, fällt man auf Best Practices zurück. So wurde z.B. den Homeoffice-Mitarbeitern geraten, nicht das WLAN, sondern die LAN-Verbindung zu benutzen.

Glücklicherweise war bei diesen Kunden schon Teile von Alluvio insbesondere vom Desktop/Laptop, aber auch aus dem Netzwerk installiert. Das ermöglichte dem IT-Leiter, die Teams auffordern, eine datengetriebene Troubleshooting Analyse unabhängig von den Fachabteilungen zu starten.

Datengetriebenes Troubleshooting

Der Startpunkt für die Analyse war die Erfahrung des Benutzers in der neuen Anwendung. Hierbei überwacht Alluvio Aternity, z.B. wie lange der Benutzer für bestimmte Aktionen in der Anwendung warten muss. Die „Commonalities Analaysis“, welche nach Gemeinsamkeiten in den Daten sucht, zeigte sofort auf die Performance-Unterschiede zwischen den Laptops (Lenovo Yogas) und Desktops. Ein Anwender, welcher ein Yoga verwendet, musste z.B. im Durchschnitt über 3,3 Sekunden auf eine bestimmte Aktion warten. Ein Anwender, welcher einen klassischen Desktop verwendete, hatte eine fast um die Hälfte kürzere Wartezeit.

Damit war klar, dass es kein grundsätzliches Problem mit der Anwendung, Standort, Rechenzentrum oder Netzwerk ist, sondern sich rein auf ein bestimmtes Endgerätemodel konzentriert.  Im nächsten Schritt wurden die Endgeräte näher analysiert, um die Unterschiede zwischen Desktop und Yoga zu identifizieren. Dabei wurde kein Unterschied in der installierten Software oder Betriebssystem festgestellt, sondern dass einige Yoga-Geräte eine um die Hälfte kleinen Netzwerkdurchsatz hat. Bei der weiteren Betrachtung der Daten wurde festgestellt, dass ein großer Teil der Yoga-Geräte einen no-name USB-C to Ethernet Adapter verwenden. Ein kleinerer Teil hatte glücklicherweise die Original Lenovo Ethernet Adapter, sodass man die Benutzererfahrung beider Typen vergleichen konnte: 

No-Name vs. Original

In der letzten Analyse konnte zügig feststellen werden, dass nur die Yoga-Anwender, welcher den billigen USB-C to Ethernet Adapter hatten, von den Performanceproblemen betroffen waren.  Geräte mit dem original Ethernet Adapter hatten keine Probleme.

In den weiteren Gesprächen wurde herausgefunden, dass ein Einkäufer gedacht hat, dass ein billiger Ethernet Adapter genauso gut ist, wie der Originaladapter. Wie auch beim vielen anderen Situationen ist billig nicht gerade die beste Alternative. Das Beispiel zeigt auch, dass Observability Tools wie Alluvio in solchen komplexeren Umgebungen notwendig sind, um proaktiv nach Verbesserungsmöglichkeiten zu suchen. Viel interessanter ist aber auch im Fehlerfall schnell die richtige Spur zu finden, ohne dabei wertvolle Zeit zu verlieren.

Wollen Sie mehr über Alluvio erfahren? Schauen Sie einfach auf unserer Webseite vorbei. Gefällt Ihnen, was Sie sehen, und möchten Sie es selbst ausprobieren? Laden Sie hier Ihre kostenlose Testversion herunter und erleben Sie es aus erster Hand. Oder sprechen Sie mit uns, wenn Sie Fragen haben.