Rufbereitschaft – Nachspiel

Montag, 11.11.19. Gütersloh.

Wenn man etwas erwartet, dann trifft es auch nicht ein. So einfach ist das. Aber das weiß man vorher nicht, denn so funktioniert es nicht. So bekam ich gestern nach meinem gestrigen Blogeintrag keinen weiteren Anruf in meiner verbleibenden Rufbereitschaft. Es gab also vor meinem Schlaf kein aufregendes Ereignis und dennoch schlafe ich nicht gut.

Ich drücke an der Seite meiner Smartwatch, den ich beim Schlafen immer am Handgelenk trage, den Knopf, um das Display aufleuchten zu lassen. 2:30. Puh.

Irgendwie schaffe ich es, einzuschlafen und genau fünf Minuten bevor mein Wecker klingelt, aufzuwachen. Zu meiner Überraschung fühle ich mich nicht zermürbt, müde oder sonst etwas in der Art wie als wäre eine Herde wildgewordener Affen durch mein Gesicht getrampelt und hätte meinen Körper zerschlissen.

Vermutlich ist es die Neugier. Mich interessiert natürlich, was gestern im Produktiv-System schiefgelaufen ist und wodurch es verursacht wurde. Es muss schon etwas Kniffliges gewesen sein, an das keiner gedacht und unsere Qualitätsmaßnahmen „ausgetrickst“ hat.

So ist es denn auch. Die Analyse von dem Kollegen mit dem Spezialwissen auf dem Gebiet, wo sich der Fehler ereignete, weiß sofort, was passiert ist.

Dazu muss man wissen, dass bei einem SAP System Änderungen von einem System in ein anderes transportiert werden (und nicht deployed wie z.B. bei Java). Es gab zwei Änderungen an Daten, die als Datenpakete (Customizing) mit größerem zeitlich Abstand nacheinander vom Entwicklungssystem ins Qualitätssystem transportiert wurden.

Als wir an diesem Wochenende auf das Produktionssytem gingen, wurden beide Datenpakete gleichzeitig transportiert, was so üblich ist.

Dieser gleichzeitige Transport führte zum Datenschiefstand. Warum das so ist, kann bisher keiner sagen.

Dieser Datenschiefstand hatte allerdings noch keine Folgen. Daher waren die Tests (Smoke Test) am Samstag erfolgreich.

Am Sonntagmorgen wurde ein Programm durch einen eingeplanten Job gestartet, dass die neuen Daten verwendete. Dieses Programm verteilte die fehlerhaften Daten im System.

Als dann der Testroboter lief, lieferte ein Prozessschritt, der auf diese Daten angewiesen war, ein falsches Ergebnis. Daraufhin schlug der Testroboter Alarm.

Und da kamen wir ins Spiel und spielten mit geringen Aussichten, zu gewinnen, denn ohne Kenntnis dieses speziellen Programms hat man keine Chance. Der Witz ist, dass dieses Programm im Grunde sehr simpel ist, aber über die Wirkung eines kleinen, umkippenden Dominosteins verfügt.

Natürlich werden wir sofort gefragt, wie wir Fälle wie diese in Zukunft verhindert können. Die Lösung ist hier recht simpel: ausgewählte Jobs nach den Smoke Tests einmalig laufen lassen und anschließend eine weitere Testiteration durchzuführen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.