Alle, die noch den Sinn einer Prüfung der Infrastruktur im Vorfeld eines Unified-Communications- (UC-)Projects anzweifeln, sollten sich die bekannten UC-Desaster bzw. fehlgeschlagenen UC-Projekte ansehen, und erkennen, was passieren kann, wenn etwas schief läuft, denn dann läuft es richtig in die falsche Richtung.
Erinnern Sie sich noch an das Fiasko von HealthCare.gov. Im Herbst 2013 wurde darüber in den einschlägigen Fachmedien eingehend berichtet. Das Versagen der Technologie wurde dadurch begründet, dass das Projektteam versucht hat, zu viele verschiedene Funktionalitäten auf einmal umzusetzen. Auch dauerte die Implementierungs- und Installationsphase wesentlich länger als ursprünglich geplant. Trotzdem wollte oder konnte die Projektleitung das Umschaltdatum nicht verändern. Stattdessen wurden die notwendigen Zeiten, die für die Tests und die Überprüfung der Implementierung drastisch verkürzt bzw. in Teilen sogar komplett gestrichen. Das Projektteam drückte alle Daumen, dass alles funktionieren würde. Leider nützte es nichts und das gesamte Projekt endete in einer grandiosen Katastrophe.
Ich lebe in Deutschland. Trotz deutscher Ingenieurskunst und deutscher Gründlichkeit enden viele staatliche Projekte im Desaster oder sind heillos überteuert. Im Prinzip enden alle IT-Großprojekte der öffentlichen Auftraggeber (im Bund, wie in den Ländern) irgendwann am Abgrund und es wird mit viel Kraft und Geld versucht den bereits halbtoten Patienten noch zu retten. Die Projektpläne (siehe Gesundheitskarte bzw. Maut) haben sich verzögert, die Kosten sind explodiert und man kann die Systeme nicht ausreichend testen. Ohne größere Prüfungen wird der Schalter umgelegt und das System geht in Betrieb, obwohl jeder der Beteiligten weiß, dass dies ein großer Fehler ist.
Die bekannten Beispiele zeigen, warum Tests so wichtig sind. Nur durch ausreichende Tests kann die Projektleitung sicher sein, dass keine Probleme auftreten. Bei den Tests werden potenzielle Konfigurationsprobleme oder tieferliegende Probleme aufgedeckt.
Ich habe kürzlich von einer Telekommunikationslösung gehört, die gleichzeitig bis zu 600 Telefongespräche entwickeln sollte. Leider lieferte das System in der Praxis jedoch nur 300 gleichzeitige Anrufe. Die Ursache lag beim Provider, denn sein System war mit den bereitgestellten 300 Verbindungen vollkommen ausgelastet. In diesem Projekt kam es zu der klassischen Art eines Missverständnisses. Die eine Person bestellte 600 ein- und ausgehende Anrufe und die andere Person beim Provider verstand anhand der Bestellung 300 Voll-Duplex-Verbindungen.
Prüfung der Zusammenarbeit der Komponenten
Die Herausforderung beim Auf- bzw. Umbau einer komplexen Datenverarbeitungs- oder Telekommunikationsumgebung besteht darin, dass alle Komponenten zusammenarbeiten müssen. Die Gesamtkomposition umfasst die Integration von Software und Hardware vieler unterschiedlicher Quellen und die Interaktion über Netzwerke hinweg. Jede Komponente kann dabei für sich isoliert perfekt funktionieren, aber die Interaktion mit anderen Komponenten kann zu Problemen führen. Meist liegt es an den unterschiedlich genutzten Application-Programming-Interfaces (APIs).
Um die Performance und Leistungsgrenze beispielsweise von VoIP-Komponenten zu ermitteln, ist im Vorfeld ein umfassender Produkttest in einem Testnetz notwendig. Dabei wird zuverlässig erkannt, an welchen Stellen das Netz „VoIP-fähig“ ist und wo nicht. Wichtiger noch: Man erhält Aufschluss darüber, in welcher Qualität die UC/VoIP-Anwendung bereitgestellt werden kann. Schwachstellen werden noch vor der eigentlichen Installation und Inbetriebnahme erkannt; Nachbesserungen können vorgenommen werden. Meist arbeitet ein neues System problemlos, wenn nur wenige Benutzer aktiviert werden. Ein zu kurzer Mess- und Testintervall berücksichtigt oftmals nicht die verkehrsreichsten Zeiten. Bei Voice over IP besteht die Herausforderung darin, die Sprache in hoher Qualität und ohne Performance-Einbußen für die bestehenden Anwendungen zur Verfügung zu stellen. Die Basis dafür bilden die Funktionalität und Skalierbarkeit der VoIP-Komponenten. Die Akzeptanz bestimmen den Quality of Service (QoS) der Signalisierung und der eigentlichen Sprachübermittelung. Aber wie verhält sich das neue Telekommunikations-System oder die neue Web-Umgebung unter Volllast oder sogar bei einer Überlast? Die Qualität der Komponenten im Zusammenwirken mit dem vorhandenen Netzwerk- und Server-Systemen spielt eine wichtige Rolle, wenn es um die Voice-Readiness des Netzwerks geht. Kleinste Ungereimtheiten können oft eine Kettenreaktion auslösen. Die Suche nach der Ursache der Schwachstellen wird oft zur Suche nach der Nadel im Heuhaufen. Daher sollte jedes neue System unter voller Last über einen längeren Zeitraum betrieben werden. Nur so kann man sicher sein, dass es im späteren Regelbetrieb keine unliebsamen Überraschungen gibt.
Bei der VoIP Vormessung wird überprüft:
- ob das Netzwerk VoIP-Ready ist,
- wie gut die Anwendung VoIP im bestehenden Netzwerk funktionieren wird und
- an welchen Stellen im Netzwerk Engpässe bestehen und/oder nachgebessert werden muss.
Es wird ein bestehendes und für andere Anwendungen genutztes Netzwerk auf VoIP-Readiness getestet. Zwischen im Netz verteilten Messendpunkten (Mess-Software) wird der VoIP-Verkehr entsprechend eines zu definierenden VoIP-Nutzungsprofils erzeugt. Dabei können tausende VoIP/UC-Anwender mit entsprechendem VoIP-Codec simuliert werden. Durch die Simulation in einem solchen Umfang erreicht man Aussagen über die Qualität in einem Szenario, welchen den späteren Einsatz der UC-Lösung perfekt nachbildet.
Periodische Checks sind Pflicht
Aber auch im Betrieb müssen regelmäßig Tests und Überprüfungen der geforderten Leistungsmerkmale durchgeführt werden. Im Laufe der Zeit verändern sich die Systeme und unter der Oberfläche werden ständig Konfigurationsanpassungen vorgenommen.
Durch regelmäßige Kontrollen werden die Verfügbarkeit, die Funktionalität und die Leistungsmerkmale aller Komponenten überprüft und sichergestellt, dass alle beteiligten Komponenten sich innerhalb der für den Betrieb notwendigen Parameter bewegen. Diese Parameter ermittelt der IT-Verantwortliche durch Monitoring – also die Überwachung entsprechender Indikatoren. Dabei ist die wiederholte regelmäßige Durchführung ein zentrales Element der jeweiligen Untersuchungsprogramme, um anhand von Ergebnisvergleichen Schlussfolgerungen ziehen zu können. Eine Funktion des Monitorings besteht darin, bei einem beobachteten Ablauf bzw. Prozess steuernd einzugreifen, sofern dieser nicht den gewünschten Verlauf nimmt bzw. bestimmte Schwellwerte unter- bzw. überschritten sind.
Fazit
Unabhängig davon, ob man für den Betrieb von Clients und Servern oder von Anwendungen zuständig ist, man muss bereits vor der eigentlichen Inbetriebnahme die zu installierenden Komponenten testen. Auch im Regelbetrieb, muss dafür gesorgt werden, dass die installierten Komponenten genau so funktionieren wie dies ursprünglich geplant war. Deshalb müssen im Betrieb die wichtigen Systemparameter ständig beobachtet, besser laufende Tests erfolgen, und bei Bedarf eingeschritten bzw. die jeweilige Fehlerursache behoben werden. (mh)
