Kommunikationsprobleme
Der Datentransfer zwischen Zürich und Bern wurde im Hinblick auf Zeitpunkt (Freitag 14 Uhr) und benötigte Bandbreite mit den Netzwerkern abgesprochen und geplant. Trotzdem tauchen neuerdings Freitagnachmittags Kommunikationsprobleme auf, weil der Vertrieb des Unternehmens freitags von 14 bis 16 Uhr seine Mitarbeiter per Business-TV schult. Die Schulung, die zudem in einer unnötig hohen Übertragungsqualität läuft, ist zwar mit den Applikations-Administratoren abgesprochen, jedoch nicht mit den Netzwerkern. Der geplante Datenbankabgleich und ein zum gleichen Zeitpunkt für den Netzwerker ungeplantes Business-TV führen zum einen zu einer Bandbreitenüberschreitung. Zum anderen entsteht eine Vielzahl weiterer Fehler – mit der Folge, dass in der Kommunikation eine grössere Verzögerung eintritt, die wiederum auch andere Dienste in Mitleidenschaft zieht. So treten beispielsweise Packet Drops auf: Bereits gesendete Pakete müssen komplett noch einmal verschickt werden. Dadurch wiederum vervielfacht sich die Bandbreite, die nötig ist, um ein einzelnes Paket zu transportieren.
Ursache unbekannt
Der Datenbank-Administrator, der den Datenbankabgleich zwischen Zürich und Bern mit drei Stunden geplant hat, muss jetzt mit sechs statt drei Stunden rechnen. Auch für die Endanwender verschlechtert sich die Kommunikation. Voice over Internet Protocol (VoIP) ist stark eingeschränkt, ebenso wie das Instant Messaging. Vom freitäglichen Bandbreitenproblem ist aber immer nur die Strecke Berlin-München betroffen. Es ist deswegen schwer herauszufinden, warum dieser Transfer so langsam ist. Weil diese Störungen aber regelmässig auftreten, überlegt das Unternehmen, eventuell einen neuen Vertrag mit seinem Service Provider abzuschliessen. Es weiss, dass am Ende der Woche zu wenig Bandbreite vorhanden ist, kennt aber nicht die Ursache des Problems.
Ohne Performance Management
Ein Netz-Administrator bekommt einen Anruf vom Help Desk, dass sich Anwender über das langsame Netzwerk beschwert haben. Er schaltet sich per Telnet auf einen Router, um die Bandbreitenauslastung abzufragen. Wie der Zufall es will, ist zu diesem Zeitpunkt die verfügbare Bandbreite punktuell wieder kurze Zeit angestiegen. Die Mitarbeiter haben sich über die schlechte Bild- und Tonqualität beschwert und der Fehler wird im Moment in der möglichen falschen Paket-Priorisierung gesucht. Es findet in diesem Augenblick keine Übertragung statt. Beim nächsten Router trifft der Netzwerker dann einen Peak (die Applikationsverantwortlichen führen einen Testlauf mit neuer Priorisierung durch) und sieht, dass die Auslastung bei 90 Prozent liegt. Er kann die Fehlerursache jedoch nicht lokalisieren. Mit Telnet erhält er immer nur einen Schnappschuss der Netzbelastung. Er bekommt keine grafische Auswertung, die ihm auf einen Blick zeigt, wie sich die Bandbreite über den Tag oder über eine Woche entwickelt hat.
Der Administrator schlägt deshalb vor, beim Service Provider mehr Bandbreite einzukaufen, um die Auslastungsspitzen abzufangen. Der Zukauf von Bandbreite würde die Kosten jedoch unnötig in die Höhe treiben, während bereits eine einfache zeitliche Entzerrung von Business-TV und Datenbanksynchronisation die Fehler beheben würde.
