Ausfallsicherheit
Krisenfest statt fehlerfrei

Ausfallsicherheit

Am 4. Juni hatte der britische National Air Traffic Service (Nats) ein Problem: Ein “Routine-Upgrade” – oft eine gute Methode, um Systeme zu stören – führte zu einem 45 Minuten dauernden Ausfall und einer Menge von Unannehmlichkeiten, da Flugzeuge am Boden blieben.

Davon hörte ich zuerst, als mich ein Journalist anrief und um einen Kommentar bat. Die Bewertung von Software-Pannen kann allerdings schwierig sein, da in den seltensten Fällen so detaillierte Informationen vorliegen, dass das Thema ausreichend erhellt wird.

Ich möchte hier etwas ausholen. Beginnen wir mit dem Konzept der fehlerfreien Systeme, ein faszinierendes, aber unerreichbares Produkt, das sich jemand mit überentwickelter Fantasie ausgedacht hat. Die Wirklichkeit sieht so aus: Es ist ziemlich unwahrscheinlich, dass irgendein Programmierer jemals ein fehlerfreies System von einer gewissen Komplexität produzieren wird. Selbst wenn er es schaffen sollte, würde er es nicht wissen, da es keine Technologie gibt, die die Abwesenheit von Fehlern garantiert. Und der Programmierer könnte das Wunder nicht wiederholen, da es nicht mehr als eine statistische Anomalie wäre. Es bleiben zwei Programmierpflichten, die sich angehende Software-Entwickler (und auch alte Hasen) hinter die Ohren schreiben sollten.

Erstens: Wenn ein Software-Entwickler ein System entwirft, sollte es so gestaltet sein, dass es bei einem Ausfall – der fast sicher passieren wird – so ausfällt, dass nur ein Minimum von Unannehmlichkeiten und Gefahren für den User entsteht.

Zweitens: Das System sollte so entworfen werden, dass der oder die mit dem Ausfall korrespondierenden Fehler schnell und effizient aufgespürt werden können, um sie zu beheben und das Problem aus der Welt zu schaffen. Im Ergebnis wird das System im Laufe der Zeit zunehmend besser werden.

Diese beiden Verpflichtungen sind für die Software-Entwicklung so fundamental wie es Isaac Asimovs ehrwürdige Robotergesetze für die Roboter-Ingenieure der Zukunft wären – immer natürlich vorausgesetzt, dass das System zur Robotersteuerung nicht dummerweise abgestürzt wäre und den Roboter von der Ausübung seiner elementaren Pflichten abgehalten hätte.

Es war nicht das erste Mal, dass Nats Probleme hatte. Im Frühjahr 2002 gab es beispielsweise drei Ausfälle in fünf Wochen. Es wird auch nicht das letzte Mal sein. Ich kenne die Policies von Nats nicht, aber in den meisten Organisationen sind die Abläufe nicht so ausgerichtet, dass sie die oben erläuterten best practices unterstützen. Es gibt Ausnahmen wie die Untersuchung des spektakulären Scheiterns von Ariane 5 im Jahr 1996, die sehr schnell eine detaillierte Beschreibung der Gründe des Scheiterns hervorbrachte und es anderen ermöglichte, daraus wichtige Lektionen zu lernen. Solange nicht nach Ausfällen systematisch solche Berichte erstellt werden, werden weiterhin Systeme produziert, die jedes Jahr zu Milliardenverlusten führen werden – zu diesem Schluss kommt jedenfalls eine neue britische Studie der Royal Academy of Engineering und der British Computer Society.

Ich weiß nicht, wie lange wir noch schlecht entworfenen Systeme produzieren werden, wenn wir viel Besseres erreichen könnten. Wenn allerdings Web-Software ein Vergleichsmaßstab ist, werde ich nicht die Luft anhalten, während ich auf Verbesserungen warte.