Design Patterns für hohe Verfügbarkeit

Anbieter zum Thema

MicroConsult Academy GmbH

Software-Fehlertoleranz

Ein Großteil der Hardwarefehler tritt zufällig als Folge physikalischer Mängel auf, also Herstellungsmängel oder Mängel, die sich mit der Zeit entwickeln, z.B. aufgrund zunehmender Abnutzung einer Komponente oder bei starker Belastung durch die Betriebsumgebung. Softwarefehler jedoch sind nicht physikalischen Ursprungs. Software nutzt sich nicht ab.

Softwarefehler entstehen, wenn Softwarepfade aufgerufen werden, die Mängel aus der Softwareentwicklung oder Implementierung aufweisen. Software ist meist viel komplexer als Hardware und enthält demnach meist auch mehr Fehler. Ergo gibt es mehr Software- als Hardwarefehler, und der Aufwand für Software-Fehlertoleranz ist viel höher als für Hardware-Fehlertoleranz.

Ein althergebrachtes Software-Fehlertoleranzverfahren ist “N-Version Programming”. In den siebziger Jahren kam ich erstmals damit in Berührung; damals nannten wir es “Dissimilar Software” (diversitäre Software). Es ist die softwarerelevante Analogie zum Hardware-N-Plexing (siehe Abbildung 1). Im Gegensatz zum N-Plexing genügt es hier jedoch nicht, Komponenten einfach nur zu replizieren.

Wenn von einer Software N Kopien ablaufen würden, enthielten diese identische Softwarefehler und würden N-mal identische Software-Zustandsfehler verursachen. Wenn es also erforderlich ist, dass N Einheiten einer Softwarefunktion parallel laufen, sollte es sich um N verschiedenartige Implementierungen dieser Funktion handeln, die von N eigenständigen Teams unabhängig voneinander entwickelt wurden. Das ist das Prinzip des „N-Version Programming“.

In den siebziger Jahren galt N-Version Programming als modernes Verfahren zur Software-Fehlertoleranz; inzwischen haben sich jedoch zahlreiche Schwachstellen herauskristallisiert. So steigen die Entwicklungskosten für Software in astronomische Höhen, denn es müssen ja N unabhängige Entwicklerteams für die Implementierung von N unabhängigen Softwaredesigns bezahlt werden.

Wer diese Kosten herunterschrauben will, stößt auf andere Herausforderungen: Weniger teure Entwicklungsteams bestehen aus geringer qualifizierten Softwareingenieuren, die qualitativ weniger hochwertige Software liefern. Am Ende haben Sie dann zwar Ihre N verschiedenen Programme, die auf N unterschiedliche Arten erzeugt wurden – sie sind aber allesamt fehlerbehaftet.

Ein weiterer Aspekt beim N-Version Programming ist die Frage, welche Angaben die N unabhängigen Entwicklungsteams bekommen sollen – meistens erhalten ja alle die gleiche Spezifikation. Enthält diese Spezifikation aber Fehler, entstehen N separat entwickelte Versionen einer ähnlich fehlerhaften Software. Wenn Spezifikations- oder Gebrauchsfehler erst nach der Einführung eines Systems auftreten, muss jeder neu eintretende Fehler N-Mal behoben werden – also einmal in jeder der N unterschiedlichen Implementierungen.

Dies hat exorbitante Wartungskosten zur Folge. Die hohen Kosten, die mit N-Programming einhergehen, lassen sich sinnvoller in ein einzelnes SW-Entwicklungsteam investieren, das hochqualifiziert ist und nur eine einzige, dafür aber qualitativ sehr hochwertige Version der Software entwickelt – und zwar unter Zuhilfenahme der bestmöglichen Infrastruktur, Software-Entwicklungstools, -methoden und -test.

(ID:44790372)