Ein Skript, das «lief»

Die automatische Übernahme der Produktivdatenbank ins Testsystem galt als erledigt. Ein genauer Blick zeigte: Sie tat in 18 Punkten etwas anderes, als sie sollte.

Ausgangslage

Ein über Jahre gewachsenes Skript spielte die ERP-Produktivdatenbank regelmässig ins Testsystem ein. Fehler meldete es keine – die Erfolgsmail kam immer. Bei der Durchsicht fanden sich 18 Defekte, die alle stillschweigend passierten, zum Beispiel:

• Datenbank-Jobs wurden nie wirklich gestoppt – es wurde nur ein Merker gesetzt, den der Dienst gar nicht auswertet.
• Nach einem gescheiterten Restore liefen Bereinigung und Verkleinerung trotzdem weiter.
• Ein nicht kompilierbarer Block sorgte dafür, dass ein Bereinigungsschritt nie ausgeführt wurde.
• Die Erfolgsmail meldete auch bei Totalausfall «erfolgreich».
• Zwei Befunde waren datenschutz- bzw. sicherheitsrelevant.

Lösung

Statt zu flicken, habe ich das Ganze als modulares 9-Phasen-Verfahren neu aufgebaut:

• Trockenlauf vor jedem Echtlauf.
• Backup-Auswahl über die Backup-Historie statt über die Sortierung von Dateinamen – mit Prüfsummen-Verifikation.
• Saubere Abbrüche mit garantierter Aufräumphase.
• Automatische Zertifikatserneuerung auf dem Server, mit Rollback.
• Offline-Selbsttest der gesamten Kette, bevor sie auf die echte Umgebung trifft.
• Eine Konfigurationsstelle für alle Umgebungswerte – das Verfahren ist auf weitere Systeme übertragbar.

Ergebnis

Ein Betriebsverfahren, das tut, was es meldet – und meldet, was es tut. Als Nebeneffekt entfiel eine dauerhaft offene Angriffsfläche des alten Verfahrens ersatzlos. Alles ist in einer Betriebsdokumentation festgehalten.