Entwicklung & Code
Aus Softwarefehlern lernen – Teil 4: Eine Patriot-Rakete verfehlt fatal ihr Ziel
Zeit ist eine der größten Illusionen in der Softwareentwicklung. Für viele Entwicklerinnen und Entwickler ist sie nur ein Zahlenwert – ein Datentyp wie int und long oder auch ein DateTime-Objekt. Doch in der Praxis ist Zeit komplex, unzuverlässig und voller Fallstricke. In jeder Anwendung, die mehr als ein paar Sekunden lebt oder mit der realen Welt interagiert, sind Zeitzonen, Sommerzeitumstellungen, Schaltsekunden, Uhren-Drift und Latenzen ein Thema. Wer das ignoriert, riskiert fatale Fehler.
Weiterlesen nach der Anzeige
Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.
Die Teile der Serie „Aus Softwarefehlern lernen“:
Muster 4: Zeit, Kalender und Geografie: Wenn die Uhr nicht das misst, was man denkt
Ein klassisches und tragisches Beispiel ist der Patriot-Raketenvorfall von 1991 während des Golfkriegs. Das Patriot-System war dafür gedacht, eingehende Scud-Raketen abzufangen. In Dhahran in Saudi-Arabien scheiterte die Abwehr jedoch, und die Rakete schlug in einer US-Kaserne ein: 28 Soldaten starben, viele weitere wurden verletzt.
Die Untersuchung ergab, dass das System eine akkumulierende Rundungsungenauigkeit hatte. Die interne Zeitmessung der Patriot war in Zehntelsekunden implementiert. Um aus diesem Wert auf Sekunden zu kommen, wurde ein Gleitkommawert mit endlicher Präzision genutzt. Über die Zeit summierte sich ein kleiner Fehler auf. Nach vielen Stunden Betriebsdauer war die berechnete Position der Scud-Rakete so weit verschoben, dass die Abfanglogik versagte.
Die Lehre: Zeit ist fehleranfällig und driftet, selbst wenn die Hardware perfekt funktioniert. Dieses Phänomen beschränkt sich nicht auf Militärtechnik. Ähnliche Effekte treten in Finanzsystemen, verteilten Datenbanken oder IoT-Geräten auf. Schon einfache Begebenheiten wie eine Sommerzeitumstellung können dazu führen, dass geplante Tasks doppelt oder gar nicht ausgeführt werden.
Besonders perfide sind Fehler, die erst bei längerer Betriebsdauer auftreten. Ein System, das im Labor wenige Stunden stabil läuft, kann nach Tagen oder Wochen in der Produktion plötzlich falsche Berechnungen durchführen. Hier greifen die normalen Teststrategien nicht, denn kaum ein Team führt komplette Langzeitsimulationen durch.
Typische Fehlerquellen rund um Zeit und Geografie sind:
Weiterlesen nach der Anzeige
- Systemzeit statt monotone Zeit: Viele Entwicklerinnen und Entwickler nutzen einfach die aktuelle Uhrzeit für Zeitdifferenzen. Verschiebt sich die Uhr (zum Beispiel durch NTP-Sync oder manuelle Korrektur), springen auch die Berechnungen.
- Fehlende Zeitzonenlogik: Ein Server in UTC, ein anderer in lokaler Zeit, eine Datenbank ohne Timezone-Feld – schon entstehen falsche Berechnungen bei Abrechnungen oder Deadlines.
- Sommerzeit und Schaltsekunden: Ein nächtlicher Batch-Job, der täglich um 2 Uhr läuft, kann plötzlich zweimal oder gar nicht laufen, wenn die Uhr umgestellt wird.
- Globale Verteilungen: Systeme, die um den Globus replizieren, müssen Latenzen und unterschiedliche lokale Zeiten berücksichtigen.
Was lässt sich aus diesen Erkenntnissen nun schließen, um diese Fehlerklasse in den Griff zu bekommen?
- Zeit als eigene Domäne behandeln: Den Unterschied zwischen der für Anwenderinnen und Anwender sichtbaren „Wandzeit“ und der „Monotonic Time“ für Berechnungen konsequent durchziehen.
- Monotone Uhren verwenden: Für Laufzeitmessungen oder Timeouts niemals die Systemuhr („wall clock“) nutzen. Moderne Sprachen und Frameworks bieten monotone Zeitquellen, die unabhängig von Zeitsprüngen sind.
- Explizite Zeitzonen: Timestamps immer in UTC speichern und Zeitzonen nur für die Anzeige oder Eingaben der Anwenderinnen und Anwender vorsehen.
- Langzeittests und Simulationen: Testumgebungen sollten Tage oder Wochen simulieren können, inklusive Uhrensprüngen. Das deckt akkumulierende Fehler und Probleme aufgrund von Uhrenumstellungen auf.
- Schutz vor akkumulativen Rundungen: Zeitdifferenzen mit hoher Präzision berechnen, interne Ticks in Ganzzahlen führen und Konvertierungen erst möglichst spät durchführen.
Der Patriot-Vorfall war sicherlich ein extremes Beispiel mit tragischem Ausgang. Aber die zugrunde liegende Erkenntnis betrifft jedes System, das Zeit berechnet oder über längere Zeiträume hinweg zuverlässig arbeiten muss: Zeit ist keine triviale Zahl. Wer sie wie eine gewöhnliche Variable behandelt, lädt Fehler ein. An dieser Stelle sei ergänzend auf das äußerst sehenswerte und lehrreiche Video The Problem with Time & Timezones von Tom Scott verwiesen.
Aus Softwarefehlern lernen – die Serie
Diese Artikelserie stellt neun typische Fehlerklassen vor, die in der Praxis immer wieder auftauchen – unabhängig von Branche oder Technologie. In jeder Kategorie wird die Serie ein konkretes Beispiel vorstellen, dessen Ursachen analysieren und daraus ableiten, was Softwareentwicklerinnen und Softwareentwickler langfristig lernen können.
Im nächsten Teil lesen Sie: Deployment, Konfiguration und Flags: Wenn ein Schalter Millionen kostet
(who)