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.

24.09.1999 - 

Buchungssystem stand eine ganze Nacht lang still

Großbank überlebte den Daten-GAU

MÜNCHEN (qua) - Die Kunden der Münchner Hypo-Vereinsbank AG dachten, es wäre bereits Weihnachten: Das Bargeld, das sie am 13. oder 14. September geholt hatten, wurde ihrem Konto nicht belastet. Doch der Spuk war nach zwei Tagen vorbei. Da hatte der Finanzdienstleister den dafür verantwortlichen Softwarefehler beseitigt.

Insider der IT-Zunft ahnten Schlimmes: Derzeit laufen bei vielen Großunternehmen die letzten Tests für den Jahrtausendwechsel. Doch Jochen-Michael Speek, IT-Chef der Hypo-Vereinsbank, winkt ab: Der Computerausfall, den die Großbank in der Nacht von Montag, den 13., auf Dienstag, den 14. September, erlitt, sei keineswegs dem Millennium-Bug anzulasten. Allerdings seien die Auswirkungen mit einem Jahr-2000-GAU vergleichbar.

Mitten in der Nacht war Speek aus dem Bett geklingelt worden. Das Buchungssystem, das nächtens die tagsüber veranlaßten Kontenbewegungen vollzieht, hatte sich eine Auszeit genommen, als die nicht kontierbaren Vorgänge eine kritische Masse erreichten. Offenbar konnte es die Kundenkonten nicht finden und mußte die Transaktionen auf ein internes Konto zwischenbuchen.

Die Ursache ließ sich nicht auf Anhieb feststellen. Da die IT-Experten der Bank nicht wußten, wie viele der 10 000 Batch-Jobs infiziert waren, entschieden sie, die gesamte Verarbeitung zu stoppen, den Fehler zu suchen und das System auf den Stand des Montagabends zurückzusetzen.

Das Durcheinander rührte, so Speek, von der Änderung eines Cobol-Programms her. Wie der IT-Manager einräumt, waren "nur 99,9 Prozent" der notwendigen Tests vorgenommen worden. Jedenfalls sei der Fehler zum ersten Mal unter Produktionsbedingungen aufgetreten.

Der Bug machte im Datenbank-Management-System DB2 genau jene Tabelle unbrauchbar, in der alle Kundenkonten gespeichert sind. "Es passiert uns häufiger, daß jemand in der Abwicklungslogik Fehler macht", konstatiert Speek, "seltener ist, daß sie so gravierende Auswirkungen haben."

Nachdem der Bug entdeckt und beseitigt war, nahm die Bank den Batch-Betrieb wieder auf und verarbeitete zunächst die Online-Daten des Montags. "Wir haben relativ lange dafür gebraucht, weil wir uns keine Abkürzungen gönnen, sondern einen vollwertigen Batch fahren wollten", erläutert Speek.

Die Filialen öffneten am Dienstag morgen wie gewohnt. Und damit das Geschäft möglichst wenig beeinträchtigt würde, liefen die Bankensysteme ungerührt weiter: Die Automaten spuckten Bargeld aus, Wertpapier-Orders wurden plaziert - wenn auch per Fax. In den dezentralen Systemen lief also eine große Anzahl von Buchungen auf.

Deshalb konnte die Bank nicht so tun, als hätte es die Zeit zwischen dem Ausfall und der Wiederherstellung nie gegeben. "Wir mußten das System durch verstärkte Zyklen von Batch und Online wieder an eine normale Verfügbarkeit heranführen", faßt Speek die Aktivitäten seiner Mannschaft zusammen. Dieses Ziel war am Donnerstag morgen erreicht.

Der normale Kunde bekam von all dem nur mit, daß er keine aktuellen Kontauszüge erhielt und seine Überweisungen mit teilweise mehrtägiger Verspätung verbucht wurden. Doch denjenigen, die ihre Rechnungen erst in letzter Minute beglichen haben, drohen jetzt Mahngebühren oder Zinsverluste. Zahlungen im Wert von mehr als zehn Millionen Mark wurden immerhin manuell verbucht. Und wie Speek verspricht, wird die Bank für die Kosten aufkommen, die durch den Rechnerausfall entstehen.