Erfahrung statt Technik!

Kommentieren Drucken

Welche Messgeräte benötigt man zur Fehlersuche in Netzen? Welche Tools empfehlen Sie für das Performance-Monitoring? Wie binde ich meinen Protokollanalysator in das Netzwerkmanagement ein? Diese oder ähnliche Fragen stellt man mir immer wieder im Rahmen meiner Fehlersuche-Einsätze oder auch anlässlich von Seminaren. Nun, dass ich Werkzeuge zur Protokollanalyse nützlich finde, wissen Sie spätestens seit den bereits veröffentlichten Artikel von mir.

Der Standpunkt Troubleshooting von Dr. Joachim Wetzlar greift als regelmäßiger Bestandteil des ComConsult Netzwerk Insiders technologische Argumente auf, die Sie so schnell nicht in den öffentlichen Medien finden und korreliert sie mit allgemeinen Trends.
Welche Messgeräte benötigt man zur Fehlersuche in Netzen? Welche Tools empfehlen Sie für das Performance-Monitoring? Wie binde ich meinen Protokollanalysator in das Netzwerkmanagement ein? Diese oder ähnliche Fragen stellt man mir immer wieder im Rahmen meiner Fehlersuche-Einsätze oder auch anlässlich von Seminaren. Nun, dass ich Werkzeuge zur Protokollanalyse nützlich finde, wissen Sie spätestens seit der Lektüre meines „Standpunktes“ vom September 2011.

weiter auf nächster Seite
Aber wie sieht es mit all den anderen Tools aus, die uns die Hersteller anbieten und dabei versprechen, dass sich damit nun endlich Fehler in Netzen und Anwendungen „proaktiv“ finden lassen? Der erhöhte Service Level, den Sie Ihren Anwendern dadurch bieten, dass Sie nun alle Fehler beseitigen, bevor dieser sie überhaupt bemerkt hat, rechtfertigt doch die Investition in teure Tools, oder?

Ja, es gibt nützliche Tools, die z.B. das Netzwerkmanagement mit seiner einfachen „geht/geht nicht“-Aussage um die Aufzeichnung von Performance-Parametern ergänzen. Für die Problemanalyse nützen solche Tools aber nur, wenn die aufgezeichneten Parameter eine gewisse Aussagekraft besitzen.

Ein Beispiel: Anwender in Außenstellen klagen plötzlich über schlechte Antwortzeiten. Für die Lösung dieses nicht gerade seltenen Problems ist es von großem Nutzen, sofort zu erkennen, ob das Weitverkehrsnetz eine Störung hat oder aber die zentrale Server-Farm. Sinnvoll ist an dieser Stelle ein Tool, das die Antwortzeit des Weitverkehrsnetzes über einen längeren Zeitraum aufgezeichnet hat, und zwar unabhängig von Ressourcen der zentralen Server-Farm.

Ein Gegenbeispiel: TCP Retransmissions werden allgemein (auch von mir) als Indikator für Paketverluste angesehen. Leider gibt es aber auch andere Ursachen für Retransmissions, wie einer meiner Kunden erfahren musste. Das entsprechende Tool war fehlerhaft in das Netz eingebunden worden, so dass es bestimmte TCP-Pakete fälschlicherweise zweimal zu Gesicht bekam und folglich als Retransmissions klassifizierte. Gerade Retransmissions eigenen sich also nicht als Performance-Indikatoren. Es lassen sich allenfalls Trends erkennen, die man immer mittels Protokollanalyse verifizieren muss.

Sie sollten sich also genau überlegen, welche Parameter es also wert sind, mit Monitoring-Tools aufgezeichnet zu werden. Und vergessen Sie das Wort „proaktiv“: Problemanalyse ist und bleibt reaktiv. Nur wenn Sie auf die Störungsmeldungen Ihrer Anwender schnell und effektiv reagieren können, werden Sie einen hohen Service Level erzielen. Und darauf sollten alle Ihre Werkzeuge ausgelegt sein.

Und mehr noch die Prozesse. Ich kenne Unternehmen, die sich umfassend mit Analyse- und Monitoring-Tools ausgestattet haben und dennoch bei jedem Problem in dieselben Fallen tappen: Es gibt niemanden, der ein Problem zu Ende löst. Jedes Team versucht anhand seiner Tools nachzuweisen, dass es keine Verantwortung für das Problem hat. Trouble Tickets werden zu Kreisläufern. Der ganzheitliche Blick fehlt. Die Beschaffung von Tools und der Aufwand zu ihrer Einführung binden wertvolle finanzielle und vor allem personelle Ressourcen, die für eine Optimierung der Prozesse dringend gebraucht würden.

Daraus ergibt sich ein klarer Standpunkt: Betrachten Sie vor Auswahl und Beschaffung von Tools erst einmal den Status quo. Wer ist eigentlich für die Problembeseitigung verantwortlich? Wer sorgt dafür, dass alle Beteiligten gemeinsam und zielgerichtet an der Lösung eines Problems arbeiten? Wer prüft, dass ein Problem tatsächlich behoben wurde, und wer dokumentiert in lesbarer Form (!), welche Schritte und Erkenntnisse letztlich die Lösung herbeigeführt haben? Aus meiner Sicht ist es eine gute Idee, diese Verantwortung im Netzwerk-Bereich zu verankern, denn hier findet sich das umfassendste Know-how über alle Protokollschichten, vom Kabel bis zur Anwendung.

Und zuletzt schauen Sie auf Ihre Tools. Welche gibt es bereits und wer ist in der Lage, sie zu bedienen? Wo gibt es noch Informationslücken? Sorgen Sie dafür, dass alle Beteiligten wissen, welche Daten aus Netzwerk, Servern und anderen Systemen mit welchen Tools erhoben werden und wie man im Zweifelsfall an diese Daten gelangt. Nutzen Sie Ihr großes Know-how und Ihre Erfahrung, und auch die Fähigkeiten Ihrer Kollegen! Sie lassen sich durch kein Werkzeug, und sei es noch so teuer, ersetzen.

zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.