Das Netz steht!" - Mitarbeiter urteilen rasch, wenn die von ihnen benötigten Anwendungen einmal nicht wie erwartet reagieren. In der IT-Abteilung bringen die Beschwerden und Notrufe dann schnell die Telefonleitungen zum Glühen. Beim Bayerischen Rundfunk (BR) in München war das bis vor kurzem nicht anders. Die Mitarbeiter beschwerten sich immer wieder über zu lange Antwortzeiten von Programmen, woraufhin das IT-Team sich dann umgehend auf die Suche nach dem Quell des Übels machen musste. Denn Störungen der IT-Infrastruktur sind für eine moderne Rundfunkanstalt genauso inakzeptabel wie für andere Unternehmen.

Allerdings ist es in einer komplexen IT-Landschaft kein Leichtes, die Ursache eines Leistungsengpasses ausfindig zu machen. Wie viele Unternehmen verfügt auch der Bayerische Rundfunk über eine historisch gewachsene, heterogene Infrastruktur. Laut Kay Galinsky, Projekt-Ingenieur beim BR, hat die Komplexität des Netzes in den vergangenen Jahren stark zugenommen. Das liege unter anderem an neuen Applikationen oder zusätzlichen Diensten wie DHCP oder Authentifizierungstechniken, die die Sendeanstalt eingeführt hat.

Vielfalt ist auch bei der Hardware angesagt: Wie Marcus Brückner, im Bereich Kommunikationstechnik zuständig für Server und Systeme, berichtet, existieren beispielsweise in mehreren IT-Bereichen des Senders unterschiedliche Server-Kulturen: Von Intel/Windows-Maschinen über Linux-Server bis hin zu AIX-Systemen ist bei der Sendeanstalt alles vertreten.

Um den Überblick zu bewahren, installierte der BR vor drei Jahren ein System-Management-Projekt, das zur Implementierung diverser Lösungen führte, um dem IT-Personal mehr Kontrollmöglichkeiten zu geben. Nach Angaben von Brückner setzt die Netzabteilung seitdem auf "The Guard" von Realtech. Im System-Management-Bereich kommt "Netcool" von Micromuse zum Einsatz, und die Server-Überwachung erfolgt mit Hilfe des "Microsoft Operations Manager" (MOM). Sämtliche Meldungen laufen auf der zentralen Netcool-Konsole zusammen.

"Wir dachten eigentlich, dass wir damit gut aufgestellt sind, mussten dann aber feststellen, dass die Anwender immer noch über zum Teil sehr schlechte Performance und sogar Ausfälle klagten", berichtet Brückner. Die Suche nach den Ursachen war dem IT-Profi zufolge jeweils sehr zeitaufwändig und erbrachte nicht immer zufrieden stellende Resultate.

Komplexe Zusammenhänge

Das führt sein Kollege Galinsky nicht zuletzt darauf zurück, dass heute wesentlich mehr Server an einer Kommunikation beteiligt sind als früher: "Eins-zu-eins-Beziehungen zwischen einem Client und einem Server gibt es praktisch nicht mehr." Daher sei die Analyse von Problemen immer ziemlich kompliziert: Einzelne Komponenten können für sich gesehen einwandfrei laufen und trotzdem im Zusammenspiel Aussetzer verursachen.

Vor zwei Jahren gab es dann ein weiteres Projekt, bei dem der BR sein Netz von 10 Mbit/s auf 100 Mbit/s umstellte. "Danach hieß es manchmal, die Performance sei nun noch schlechter, was aus unserer Sicht gar nicht sein konnte", erinnert sich Brückner. Hinzu kamen immer wieder Ausfälle und Engpässe, die weder die für Server und Systeme zuständigen IT-Mitarbeiter noch die Kollegen von der Netzverwaltung messen konnten. So reifte der Entschluss, eine Lösung zu implementieren, die dem IT-Personal ein Bild davon vermitteln sollte, "wie die Mitarbeiter die Qualität von Anwendungen und Diensten erleben". Dabei war klar, dass punktuelle, stichprobenartige Messungen keine Lösung waren, stattdessen eine kontinuierliche Überwachung hermusste.

Brückner gab das Projekt "End-to-End-Monitoring" in Auftrag. "Wir betreuen mit 20 Mitarbeitern etwa 200 Server und benötigten ein Tool zur Überwachung der Performance", erzählt der IT-Profi. "Genauso, wie wir Lösungen zur Überwachung von Servern und Netzen im Einsatz haben, wollten wir uns die Situation auch von der Gegenseite, also vom Anwender aus, anschauen können."

Klare Vorstellungen

Das IT-Team hatte klare Vorstellungen für das Projekt: "Wir dachten an eine eher kleine Installation von lediglich zehn Mess- stationen, mit denen wir zunächst sechs Applikationen überwachen können würden", erzählt Brückner. Mit derartigen Probes wollten er und sein Team erst einmal Erfahrungen sammeln und herausfinden, wie aufwändig es ist, solch ein System zu betreuen. Zunächst sollten von insgesamt zehn Standorten nur die zwei wichtigsten überwacht werden. Neben dem Funkhaus in der Münchner Innenstadt ist dies das Fernsehstudio in Freimann. Die Versorgung der anderen Außenstellen mit Probes war erst für später geplant.

Analysen im Vorfeld

Nachdem die Experten im Frühjahr 2005 die Anforderungen formuliert hatten, schauten sie sie sich um, welche Lösungen und Hersteller überhaupt in Frage kämen. Als nächstes ließen sie sich Produkte von Anbietern präsentieren. "Es hat uns überrascht, dass es doch einige ganz gute Tools in diesem Bereich gibt - anscheinend haben mehrere Unternehmen ähnliche Probleme wie wir", schmunzelt Brückner.

Es folgten Gespräche mit Referenzkunden, die den BR-Profis auch ihre Systeme zeigten. "Das war sehr lehrreich, weil wir dabei noch auf Dinge gestoßen sind, an die wir vorher nicht gedacht hatten", erinnert sich Galinsky. Auf Basis all dieser Informationen und Gespräche erstellten die Experten dann das Pflichtenheft. An der anschließenden Ausschreibung beteiligten sich neben Compuware auch Anbieter wie Concord und Mercury Interactive.

Im September 2005 stand schließlich fest, welcher Anbieter das Rennen machte: Die Wahl war auf Compuware und dessen Tool "ClientVantage" gefallen. "Dann ging es los", erinnert sich Galinsky: "Wir mussten uns überlegen, welche Komponenten wir außer der Software benötigen, welche Server, PCs für die Probes, welche Lizenzen und so weiter." Auch die Zahl der benötigten Datenbanken musste geklärt werden. Mitte Oktober konnte dann die praktische Umsetzung beginnen.

Schrittweises Vorgehen

Zunächst einmal galt es, die Server-Komponente einzurichten. Dann kamen die Probes an die Reihe. Die Mess-Tools wurden auf Standard-PCs installiert, die dem typischen Arbeitsplatzrechner des BR entsprechen. Dazu gehören neben der Standardhardware das Betriebssystem sowie sämtliche wichtigen Anwendungen inklusive aller Patches und Updates. "Damit wir realistische Ergebnisse erhalten, war uns wichtig, dass die PCs den normalen Rechnern entsprechen", erläutert Galinsky. Hinzu kamen dann jedoch noch eine spezielle Software, um die Test-Rechner vor unbefugten Zugriffen zu schützen, sowie die "Vantage"-Client-Komponente. Wegen dieser notwendigen Module erhielten die auch als "Robots" bezeichneten Systeme lediglich etwas zusätzlichen Arbeitsspeicher spendiert.

Die IT-Profis installierten zunächst einmal Referenz-Probes in den Server-Räumen, die den "Optimalzustand" erfassen sollen. Daneben positionierten sie weitere Messstationen im Funkhaus selbst sowie in der Außenstelle in München/Freimann.

Die Hauptaufgabe bestand jedoch darin, die tatsächliche Überwachung zu definieren. Dazu mussten als Erstes diejenigen Anwendungen bestimmt werden, deren Verfügbarkeit für den BR eine große Rolle spielt: Neben "OpenMedia", dem hausinternen Nachrichtenverteilsystem für die Meldungen der Agenturen, sind dies beispielsweise das BR-Intranet, der "MediaBroker" (eine Archivanwendung), "Lotus Notes", die Authentifizierungsfunktion sowie die Druck- und File-Services. "Außerdem mussten wir uns Gedanken machen, welche Funktionen der Anwendungen wir im Einzelnen überwachen wollten", erinnert sich Brückner. Als auch das erledigt war, erstellten die BR-Mitarbeiter mit Hilfe der Compuware-Profis spezielle Skripte. Dazu benutzten sie eine vom Hersteller selbst entwickelte Programmiersprache, die an andere Skriptsprachen angelehnt ist.

Das Erstellen der Routinen erleichtert die Aufzeichnungsfunktion: Sie protokolliert bestimmte Aktionen in einer Anwendung - beispielsweise das Aufrufen der Speisekarte im Intranet - und übernimmt sie auf Knopfdruck direkt in das eigentliche Skript, das der Entwickler lediglich anpassen muss - beispielsweise, indem er die gewünschten Reaktionszeiten einträgt.

Anpassung notwendig

Nun mussten die Spezialisten die Referenzwerte für die gewünschten Antwortzeiten definieren und die Skripte so modifizieren, dass die Überwachung einerseits brauchbare Resultate liefert, andererseits aber keine Falschmeldungen bringt. So ist es beispielsweise normal, wenn bei der Überwachung des Nachrichtenverteilsystems nachts länger keine neuen Meldungen auftauchen - auch das kontrolliert das System.

Als knifflig erwies sich die Überprüfung der Authentifizierung, weil diese stattfindet, bevor die Probe läuft und das Skript ausführen kann. Das laut Brückner "kleine Problem" ließ sich von den Compuware-Experten allerdings mit einem Kunstgriff lösen.

Die Bedienung des Systems und die Auswertung der gesammelten Informationen erfolgt über eine Web-basierende Oberfläche, die optisch für den BR angepasst wurde. Dort sehen die IT-Profis sofort den aktuellen Status ihrer Systeme und können bei Bedarf via Drill-down-Funktion nach der Ursache von Leistungsengpässen suchen. Das Compuware-Tool schickt aber auch Alarme in die Netcool-Oberfläche - die Integration mit dem System-Management-Tool war eine der Anforderungen bei der Ausschreibung. Außerdem lassen sich via E-Mail die zuständigen Personen benachrichtigen wenn es zu Engpässen kommt. Umfangreiche Reporting-Funktionen helfen den Spezialisten, Fehler auch im Nachhinein zu analysieren.

Die Gesamtabnahme erfolgte im Dezember 2005. "Zu diesem Zeitpunkt hatten wir die Skripte schon einige Wochen laufen", berichtet Galinsky. Für weitere Verbesserungen beziehungsweise nochmaliges Feintuning der Referenzwerte gab es allerdings zusätzliche Termine, die jedoch noch zum Rahmen des Projekts gehörten. Darüber hinaus galt es auch, dem "System mitzuteilen, wenn es mal Wartungsarbeiten gibt, die Servicestörungen verursachen", erzählt Brückner. Dann brauche man eine Möglichkeit, um allen Probes zu sagen, dass die Applikation derzeit nicht verfügbar ist. Mittlerweile seien die Werte "gut eingestellt", resümiert der Fachmann.

Hilfe bei der Fehlersuche

Welchen Nutzung die Lösung hat, belegt ein Beispiel: Die IT-Profis "spürten vor einiger Zeit, dass sich etwas bei den Clients tut", berichtet Brückner. Die Bearbeitung von PDFs war langsam, auch der Start des Programms und das Drucken liefen nicht so schnell. Die Überwachung des Speiseplans im Intranet, der als PDF-Datei abgelegt ist, half, dem Problem auf die Spur zu kommen: Die Auswertung mit Hilfe von automatisch durch das Compuware-Tool hinterlegten Netz-Traces ergab eindeutig, dass die Performance-Probleme auf die Clients zurückzuführen waren. Die weitere Analyse zeigte dann klar, dass die Verzögerungen in Folge eines Software-Updates von Adobe aufgetreten waren, das die IT-Profis eingespielt hatten.

Den Fehlern auf der Spur

Besonders freut sich Brückner, dass dafür keine umfangreichen Spezialanalysen nötig waren. Alle Informationen ständen "gut lesbar und verständlich" im Compuware-System bereit, erzählt der Spezialist. In besonders kniffligen Fällen können auch die Screenshots hilfreich sein, die die Software-Probes automatisch erzeugen, wenn ein Fehler auftritt. Diese werden wie alle anderen bei der Überwachung erfassten Daten in der zentralen SQL-Datenbank gespeichert. Dort sind sie dann über einen längeren Zeitraum recherchierbar. Das ist laut Galinsky deshalb wichtig, "weil sich viele Probleme erst allmählich hochschaukeln". Auch die Anwender nehmen dem Experten zufolge vieles erst spät wahr - es dauert, bis das Fass überläuft. Wenn das jedoch passiert, helfen die historischen Daten bei der Ursachenforschung.

Pläne für den Ausbau

Derzeit sind acht Probes stationär installiert, zwei weitere befinden sich auf Notebooks. So haben die IT-Spezialisten des BR die Möglichkeit, bei Problemen einen Rechner an einem bestimmten Punkt ins Netz zu hängen und ein paar Tage mitlaufen zu lassen, um Informationen zu sammeln. Wichtiger sind jedoch die fest installierten Überwachungspunkte, die zum einen auf Referenzsystemen direkt im Rechenzentrum vorhanden sind, zum anderen "draußen" bei den Anwendern stehen.

Der BR hat bereits weitere Pläne für das Tool: Zum einen sollen noch mehr Probes installiert werden, die dann auch die Überwachung von Standorten wie Nürnberg oder Regensburg ermöglichen. Zum anderen wird überlegt, die Skriptsprache für automatische Tests im Umfeld von Software-Updates oder nach dem Einspielen von Patches zu benutzen. Wie Brückner erläutert, ließe sich dann überprüfen, ob ein Patch eine Anwendung beinträchtigt.