Am Anfang war es ein Test. Ein paar Klicks im Portal, weil es schnell gehen musste und weil du sehen wolltest, ob die Idee überhaupt trägt. Sie trug. Dann kam die nächste Komponente dazu, wieder im Portal, wieder schnell. Heute läuft ein Teil deines Geschäfts darauf, und niemand hat je gesagt, so, das reissen wir jetzt ab und bauen es sauber mit Infrastructure as Code.

Das ist kein Versagen schlechter Teams. In jedem einzelnen Moment war es die vernünftige Entscheidung. Abreissen und neu bauen kostet Wochen, und am Tag danach kann dein Produkt keine einzige Sache mehr als vorher. Also passiert es nicht. Mit jedem Jahr wächst der Bestand, und mit dem Bestand wächst der Preis, ihn nachträglich in Code zu giessen. Deshalb sitzen ganze Unternehmen auf einer Infrastruktur, die sie nicht über Code steuern, und finden keinen Zeitpunkt, an dem sich der Umbau rechnet.

Der Tag, an dem es zählt

Richtig teuer wird der fehlende Code beim Business Continuity Management. Das BSI nennt in den RZ-Standortkriterien (Version 2.1, Dezember 2024) einen Mindestabstand von rund 200 Kilometern zwischen Rechenzentren, die sich gegenseitig Georedundanz geben. Weniger als 100 Kilometer sollen es keinesfalls sein, und jeder deutlich geringere Abstand ist schriftlich ausführlich darzulegen und einer Risikoanalyse zu unterziehen.

Die Zahl ist nicht gegriffen. Das BSI leitet sie aus der Flächenausdehnung vergangener Grossschadensereignisse ab, aus der sinkenden Wahrscheinlichkeit, dass ein Ereignis beide Standorte gleichzeitig trifft. Sobald dein BCM diesen Abstand übernimmt, verpflichtest du dich damit auch, deine Infrastruktur zweihundert Kilometer weiter weg in einer vereinbarten Zeit wieder hochzuziehen.

Ohne Code heisst das, dass Menschen unter Druck nachbauen, was über Jahre gewachsen ist, und zwar genau in den Stunden, in denen dein System steht. Das werden keine Stunden. Das werden Wochen, und so lange hält dir kein Kunde die Treue.

Code allein rettet dich an diesem Tag allerdings auch nicht. Infrastructure as Code baut das leere Haus. Daten, Secrets, Zertifikate, Identitäten und DNS stehen nicht im State, und sie gehören auch nicht dorthin. Ein Wiederanlaufplan, dessen einziges Artefakt ein Terraform-Repository ist, fällt im Ernstfall trotzdem durch.

Was dich das kostet, bevor überhaupt etwas passiert

Das Erste, was fehlt, ist die Revisionssicherheit. Dass niemand nachvollziehen kann, wer wann was umgestellt hat, stimmt in dieser Schärfe nicht. Das Activity Log deiner Plattform protokolliert Zugriffe durchaus. Nur ist ein Ereignisstrom mit begrenzter Aufbewahrung kein Nachweis. Du kannst ihn nicht nebeneinanderlegen, du kannst ihn nicht vorher prüfen, und auf die Frage, wie die Produktion im März konfiguriert war, gibt er dir keine Antwort.

Eine Änderung, die über einen Pull Request geht, wird geprüft, bevor sie wirkt. Eine Änderung im Cloud Portal wird protokolliert, nachdem sie gewirkt hat. Für einen Auditor ist das Erste eine Kontrolle und das Zweite ein Protokoll.

Warum das jetzt anders ist

Der naheliegende Einwand kommt sofort. Werkzeuge, die eine bestehende Cloud auslesen und daraus Code schreiben, gibt es längst, von aztfexport bis terraformer, und eine ARM-Vorlage lässt sich auch ohne KI nach Bicep übersetzen. Das Auslesen war nie das Problem.

Wer so einen Export einmal geöffnet hat, weiss warum. Was herauskommt, ist ein Abzug des Ist-Zustands. Jede Ressource einzeln, jede Eigenschaft ausgeschrieben, IDs fest verdrahtet, keine Module, keine Variablen, keine Umgebungen, dazwischen die Reste aus zwei Jahren Ausprobieren. Technisch korrekt und als Grundlage für die nächsten fünf Jahre wertlos.

Die Arbeit liegt im Übersetzen, und die ist Urteilsarbeit, Ressource für Ressource.

  • Was gehört fachlich zusammen und wird ein Modul.
  • Was ist umgebungsspezifisch und wird zur Variable, damit Test und Produktion aus derselben Quelle entstehen.
  • Was ist Überbleibsel und fliegt raus, statt die nächsten Jahre im Code mitzufahren.
  • Welche Eigenschaften sind blosse Vorgabewerte, die dir sonst bei jedem Lauf eine Abweichung melden, die keine ist.

Diese Arbeit hat bisher niemand bezahlt, weil sie in Personenwochen gemessen wird und am Ende keine neue Funktion liefert. Ein Modell, das an deiner Plattform hängt, den Ist-Zustand liest und diese Entscheidungen vorschlägt, verschiebt den Preis von Wochen auf Tage. An diesem Preis ist die Entscheidung bisher gescheitert.

Die Abnahme ist ein leerer Plan

Dafür gibt es ein Kriterium, das du ohne Spezialwissen prüfen kannst. Du lässt den Trockenlauf gegen die laufende Umgebung laufen, den Plan. Er muss leer sein. Keine Änderung, kein Neuaufbau, nichts.

Ein leerer Plan bedeutet, dass der Code exakt das beschreibt, was in der Cloud steht. Meldet er Änderungen, beschreibt der Code etwas anderes als die Realität, und dann ist er gefährlicher als gar kein Code, weil ihm jemand glauben wird.

Was das Modell nicht auflösen konnte, gehört auf eine Liste. Ein Secret, eine von Hand gesetzte Firewall-Regel, eine Abhängigkeit, die nirgends dokumentiert ist. Ein Werkzeug, das an dieser Stelle rät statt zu markieren, kostet dich irgendwann eine Produktionsumgebung.

Danach wird weiter geklickt

Mit dem leeren Plan ist es nicht vorbei, denn im Portal wird weiter geklickt. Der Plan läuft von da an regelmässig, und jede Abweichung stellt dieselbe Frage. Gehört die Änderung in den Code, oder gehört sie zurückgedreht.

Diese Richtung ist jedes Mal eine Entscheidung. Die Firewall-Regel, die um drei Uhr nachts die Produktion gerettet hat, gehört in den Code. Die Regel, die jemand auf eigene Faust gesetzt hat, gehört weg. Im Diff sehen beide identisch aus, und der Unterschied steht nirgends in der Cloud, sondern nur im Kopf der Person, die geklickt hat.

Deshalb endet die Automatik beim Vorschlag. Das Modell erkennt die Abweichung, ordnet sie ein, schreibt den Pull Request mit Begründung, und ein Mensch merged. Wer eine KI unbeaufsichtigt apply ausführen lässt, hat sein Drift-Problem gegen ein Risiko mit besserem Vokabular getauscht.

Der unbequeme Teil

Der Bestand ist nach ein paar Tagen in Code. Ob er in Code bleibt, entscheidet kein Werkzeug. Bleibt der Weg über das Portal offen, stehst du in einem halben Jahr wieder am selben Punkt, nur mit einem Repository, dem niemand mehr traut. In der Produktion haben Menschen lesenden Zugriff, geändert wird über die Pipeline. Das ist eine Führungsentscheidung, und sie durchzusetzen ist härter als alles Technische daran.

Wenn du wissen willst, wo du stehst, brauchst du dafür kein Programm. Nimm die Ressourcengruppe, an der dein wichtigstes System hängt, lass den Ist-Zustand in Code übersetzen und lass den Plan laufen. Was dann an Abweichungen auftaucht, ist dein ehrlicher Ausgangspunkt.

Und bevor das Ergebnis in deinem BCM als Nachweis auftaucht, baust du damit einmal wirklich in der Zielregion auf. Bis dahin ist es ungetesteter Code.