Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

04.05.1990 - 

Betriebssystem wird automatisch überwacht

RZ-Automatisierung: Statt zwei Schichten nur noch eine

Peter Braunstein ist Rechenzentrumsleiter bei den Anglo-Elementar-Versicherungen in Wien.

Automation des Rechenzentrums bedeutet für viele Unternehmen nicht nur Optimierung der Informationsverarbeitung, sondern führt auch zu konkreten Rationalisierungsschritten. Peter Braunstein schildert seine Erfahrungen bei der Neuorganisation der Datenverarbeitung: Job-Steuerung und Betriebssystem-Überwachung sollten automatisiert werden.

Aufgrund des zunehmenden Datenaufkommens stand unser Versicherungsunternehmen vor der Frage, ob automatisiert werden sollte oder ob wir eine dritte Arbeitsschicht einführen wollten. Wir sind heute froh darüber, daß wir uns für den Weg der Automatisierung entschieden haben.

Unser Rechenzentrum hat drei Funktionen wahrzunehmen: Die Arbeitsvorbereitung beziehungsweise die Produktionssteuerung, das Operating und die Arbeitsnachbereitung. Derzeit haben wir eine Hitachi EX 30 mit 32 MB Hauptspeicher, 16 Kanälen und einer Leistung von etwa 11 MIPS im Einsatz. Der Umfang an Aufgaben für die DV nimmt bei uns - wie bei vielen anderen Unternehmen - seit Jahren zu. Ende 1987 überstieg der Bedarf an Maschinenzeit endgültig den vorhandenen Rahmen. Der Wunsch nach Automatisierung war entstanden.

Im Operating arbeiteten wir im Zwei-Schicht-Betrieb mit jeweils zwei Operatoren pro Schicht. Abends wurde die Maschine herunter- und morgens wieder hochgefahren. Um die Einführung einer dritten Schicht zu vermeiden, faßten wir den Plan, die "dunkle Zeit" der Maschine im Power-off zu nutzen.

Uns war klar, daß eine durchgehende Inbetriebnahme der CPU ohne Aufsicht mit Risiken verbunden ist. Nach ersten "leeren" Probeläufen gingen wir dazu über, unproblematische Programme durchlaufen zu lassen, darunter vor allem Statistiken ohne verbindlichen Termin, die beim Eintreten von Schwierigkeiten am folgenden Tag noch einmal hätten gestartet werden können.

Als nächsten Schritt wollten wir dann die eigentliche Produktion fahren. Hier mußten Vorkehrungen getroffen werden, um ein ausreichendes Maß an Sicherheit zu erlangen und für alle Eventualitäten gerüstet zu sein. Dazu wollten wir Automatisierungs-Tools einsetzen. Eine erste Marktanalyse ergab, daß es die allumfassende Software nicht gibt. Für verschiedene Problemkreise werden verschiedene Lösungen angeboten. Darum mußten wir zunächst einmal ein Anforderungsprofil erstellen .

Unser Werkzeug sollte auf jeden Fall die Möglichkeit für Restart oder Recovery anbieten, wenn ein Job-Steuer-System implementiert wird Falls ein Update-Programm abstürzt, ist es wichtig, daß das Backup zuverlässig läuft, denn ein Absturz des Recovery-Jobs würde die automatische Verarbeitung zum Stillstand bringen. Das Tool mußte daher auch eine Verbindung nach draußen schaffen, damit wir im Notfall einen Call machen konnten.

Die Planung verlief anders als vorgesehen

Diese Voraussetzungen schränkten die Zahl der Anbieter erheblich ein. Dazu kamen dann weitere nach Priorität gestaffelte Anforderungen. Interessant war dabei, daß sich schon bald viele unserer vermeintlichen Muß-Voraussetzungen als unwichtig entpuppten, während scheinbar Nebensächliches eine außerordentliche Bedeutung erhielt.

Beispielsweise hatten wir beim Job-Steuer-System die Querverbindung zu einem Bandverwaltungs-System gefordert. Doch in der Praxis zeigte sich, daß innerhalb der unbesetzten Zeit keine Bänder eingelesen werden. Lediglich die Datensicherung wird auf Band erledigt, während der Daten-Input von der Platte kommt Daten, die auf Bändern abgelegt sind, werden in der Regel tagsüber verarbeitet. Band-Input in der Nacht wäre nur dann interessant, wenn ein Bandroboter verfügbar wäre, der sich - meiner Meinung nach - aber erst bei einem Bandarchiv von mehr als 10 000 Kassetten lohnt. Bei uns sind momentan aber nur 3000 Kassetten im Einsatz.

Auf der anderen Seite erschienen uns Reports in der Vorbereitungsphase zunächst nur als "Nice-to-have-Ausstattung". Schon bald erwies es sich aber als großer Vorteil, morgens einen Bericht über den Produktionsablauf der vergangenen Nacht auf dem Tisch zu haben. Dabei stellte sich heraus, daß der Report überschaubar zu sein hatte, so daß wir nicht in einzelnen Logbereichen recherchieren mußten.

Automatisiert werden sollten bei uns in erster Linie die Bereiche Job-Steuerung und CPU-Überwachung. Für beide Aufgaben hatten wir die Auflage, mit einer kleinen Mannschaft zurechtzukommen. Deshalb war ein Programm erforderlich, das vom ersten Implementierungsschritt an sofortige Wirkung zeigte.

Selbstverständlich sollten die einzelnen Implementierungsschritte aufeinander aufbauen. Außerdem mußten wir darauf achten, daß das jeweils Implementierte auch umgehend genutzt werden konnte. Ein wichtiger Punkt für unsere Entscheidungsfindung war, welche Qualifikationsanforderungen an unsere Mitarbeiter gestellt wurden. Denn der Operating-Bereich sollte nach der Installation selbständig arbeiten können, ohne auf die Hilfe der Systemprogrammierer zurückgreifen zu müssen.

Die Operatoren sollten möglichst in der Lage sein, die Implementierung selbst vorzunehmen. Eine eventuelle Abhängigkeit von der Systemgruppe hätte das Arbeiten mit Automatisierungs-Tools über Gebühr erschwert, zumal die Automatisierung für die Systemprogrammierer nur eine Aufgabe unter vielen dargestellt hätte. Wir wären vermutlich in ungewollte Terminabhängigkeiten geraten. Um für Notfallsituationen gerüstet zu sein, sollte das von uns gesuchte Überwachungs-Tool in der Lage sein, einen sogenannten "Dial-out", einen Hilferuf per Telefon durchzuführen. Zu diesem Zeitpunkt der Planung, im Sommer 1988, gab es kaum Angebote, die über diese Möglichkeit verfügten. Eines der wenigen war ein Produkt von Legent, das wir dann auch ausführlich testeten.

Wie ein Automatisierungs-Tool im Notfall reagieren kann, soll folgendes Beispiel zeigen: Das Job-Steuer-System startet ein Programm, das mit "not o.k." endet. Es folgt ein Recovery-Job, aktiviert durch die Job-Steuerung. Erscheint nun ein weiteres Mal die Meldung "not o.k.", dann kann diese Situation nicht mehr auf automatischem Wege repariert werden. Das Job-Steuer-System schickt eine Meldung an die Console.

Unser Produkt, das auf den WTO-Buffer (WTO = Write to Operator) zugreift, reagiert darauf und aktiviert eine bestimmte Leitung auf dem Remote-Netz. Über ein Wählmodem wird die gespeicherte Telefonnummer des Bereitschafts-Mitarbeiters angerufen. Dieser kann sich dann von zu Hause einwählen, das Problem lokalisieren und entsprechende Commands absetzen. Das klappt in der Regel reibungslos Allerdings ist im vergangenen Jahr auch zweimal die Situation eingetreten, daß ein Mitarbeiter zum Rechenzentrum fahren und den Fehler vor Ort beheben mußte.

Die eigentliche Testphase für die Werkzeuge erstreckte sich vom September bis zum Jahresende 1988. Wir entschieden uns für ein flexibles, leicht bedienbares Job-Steuer-System und für ein CPU-Überwachungsprodukt, das mit dem Job-Steuerungswerkzeug kommunizieren konnte. Im Frühjahr '89 wurde dann mit der eigentlichen Implementierung begonnen Währenddessen zeigte die Automatisierung bereits erste Erfolge.

Damals liefen bei uns routinemäßig etwa 200 bis 250 Programme ab, die untereinander in einem Abhängigkeitsverhältnis standen. Alle Informationen, die am Tage über das Online-System hereinkamen, führten am Abend zu Datenbankveränderungen. Daher waren die Programmdurchführungen in den Abendstunden nach dem Online-Betrieb besonders sensibel.

Diese Routine wurde zuerst automatisiert, wobei zunächst noch ein Operator die Vorgänge am Bildschirm beobachtete. Dabei und während der Nachtstunden traten keine Unregelmäßigkeiten auf.

Der RZ-Betrieb lauft jetzt mit einer Schicht

So drängte sich eine weitere Überlegung auf: Ist es möglich, nicht nur auf die dritte Schicht, sondern auch auf die zweite (von 14 bis 22 Uhr) zu verzichten und die Mitarbeiter nur während der normalen Arbeitszeit einzusetzen?

Während der Urlaubszeit, im Sommer '89, testeten wir den reduzierten Schichtbetrieb. Von Montag bis Mittwoch kamen die Mitarbeiter innerhalb der Gleitzeit.

Während dieser Zeit mußte das gesamte Handling stattfinden. Donnerstags und Freitags wurde weiterhin in zwei Schichten gearbeitet. In diesem Zeitraum konnten Produktionsabläufe erfüllt werden, die noch nicht automatisiert waren.

Im November war die Implementierung soweit fortgeschritten, daß wir den Schichtbetrieb einstellten.

Die Operatoren sind seitdem unseren anderen Angestellten gleichgestellt und haben jetzt die normale Gleitzeit. Im Rahmen der Automatisierung wurde keiner unserer Mitarbeiter überflüssig - im Gegenteil, es entstanden neue anspruchsvolle Aufgabengebiete.

Die beiden Arbeitsvorbereiter, die vorher in klassischer Art Jobs vorbereiteten, betreuen heute das Job-Steuer-System. Ein Mitarbeiter aus dem Operating, der ohnehin mit den Console-Aufgaben vertraut war wurde auf unser Automatisierungs-Tool umgeschult. Mußte er vorher noch Routinearbeiten im Operating leisten, so hat er jetzt eine neue, qualifiziertere Aufgabe.