Wiederholzeitenanalyse (Fehlerarten)

30.04.1976

Man sollte über das Maß der im Rechenzentrum auftretenden Wiederholzeiten regelmäßig informiert sein, zumindest so lange, wie gravierende Wiederholzeiten auftreten. Wiederholzeiten sind dann

gravierend, wenn sie etwa 10 Prozent der mittleren Betriebszeiten erreichen oder überschreiten.

Es hängt allerdings auch stark von der Betriebsart des Rechenzentrums ab, viel hoch die Wiederholzeiten sind. Je anspruchsvoller ein EDV-System benutzt wird, um so höher werden auch relativ die Wiederholzeiten. Komplexe-Anwendungen reagieren speziell auf Änderungen sehr empfindlich, so daß das Risiko von Zusammenbrüchen mit wachsender Integration oder zusehens umfangreicher werden der Systemsoftware wächst, und zwar überproportional.

Hardwarefehler

Hardwarefehler können wieder auftreten. Es kommt darauf an, daß man sie jedoch auf ein erträgliches Maß reduziert. Mitunter hilft ein klärendes Gespräch mit dem EDV-Hersteller.

Systemsoftwarefehler

Systemsoftwarefehler können einerseits durch den Hersteller, andererseits aber auch durch die hauseigenen Systemprogrammierer verursacht werden. Es kommt hier sehr stark darauf an, daß man die Sicherheit der Verarbeitung als oberstes Ziel deklariert. Neue Techniken in der Systemsoftware müssen von eigenen Mitarbeitern auf Herz und Nieren geprüft werden, ehe man sie freigeben kann. Man sollte sich nicht unbedingt auf Beteuerungen und Garantien der Hersteller verlassen. Ein umfangreicher Test- bzw. Parallellauf bringt die benötigte Sicherheit und Ruhe in eine EDV-Installation hinein. Diese Vorgehensweise ist bei großen Systemen üblich. Auch kleinere und mittlere Installationen sollten sich darum bemühen.

Integrationsfehler

Je mehr Verarbeitungskomplexe ineinander integriert werden, um so mehr kommt es vor, daß Zusammenbrüche deshalb erfolgen, weil vorgelagerte Abläufe Fehler verursachten. Bei vorgangsorientierten Systemen kommt es darauf an, daß möglichst umfassende Gesamttests durchgeführt werden, ehe eine neue Version freigegeben wird.

Programmierfehler

Programmierfehler führen immer wieder zu Zusammenbrüchen. Auch Programme die Jahre hindurch reibungslos liefen, brechen plötzlich zusammen. Hier machen sich meist Spätwirkungen der Sünden der Vergangenheit bemerkbar. Es kann auch sein, daß ein Programm längere Zeit nicht mehr geändert worden ist, jetzt aber plötzlich deshalb zusammenbricht, weil ein neues, Compiler installiert worden ist,

das geänderte Programm jedoch nur mit der alten Version, des Compilers lief. Der Fehler liegt dann eigentlich in der Unverträglichkeit der Systemsoftware.

Organisationsfehler

Organisationsfehler kommen leider immer wieder vor. Sie wirken sich beim umfassenden Systemen besonders störend aus und sind schwer zu beheben. Man kann sich gegen derartige Fehler nur dadurch schützen, indem man möglichst umfassende Tests aufbaut und diese entsprechend gründlich prüft. Die Fachbereiche müssen sich hier entsprechend mit einschalten, indem sie diese Tests gründlich überprüfen. Man muß den Fachbereichen klarmachenen, daß sie diesen Aufwand vorab unbedingt leisten müssen, wenn sie reibungslos funktionierende Anwendungssysteme haben wollen.

Handlingsfehler

Handlingsfehler ergeben sich um so mehr je schlechter der Computer-Betrieb intern organisiert ist. Sie kommen vielfach durch übermäßige Wachstumsprobleme zustande. Wenn etwa die Computerlast in wenigen Jahren um den Faktor 5 oder 10 wächst, kommt die interne Organisation vielfach nicht mit. Die Ablaufverfahren im Rechenzentrum waren auf eine andere Größenordnung hin konzipiert und brechen nun

zwangsläufig zusammen. Spätestens zu diesem Zeitpunkt wird eine mehr oder weniger lange Konsolidierungsphase im Rechenzentrum notwendig.

Datenfehler

Datenfehler herkömmlicher Art sollten eigentlich der Vergangenheit angehören. Durch die Installation von Datenbanksystemen kann es jedoch vorkommen, daß Informationen der Verkettung von Daten verlorengehen. Das Risiko ist zwar gering, es kommen jedoch in unvorhergesehenen Intervallen immer wieder Datenverluste vor. Gegen diese Probleme kann man sich nur dadurch schützen, indem man in fest definierten Abständen Kontrolläufe der Bestände durchführt um von diesem Punkt an notfalls wieder aufsetzen zu können.