Wenn Infrastruktur-Richtlinien im Weg stehen: Ausnahmen handhaben, ohne die Sicherheit zu gefährden

Sie haben Wochen damit verbracht, Infrastruktur-Richtlinien zu erstellen. Jede Ressource muss Namenskonventionen einhalten, genehmigte Instanztypen verwenden und bestimmte Ports niemals öffentlich freigeben. Die Pipeline setzt diese Regeln automatisch durch. Alles ist sauber, kontrolliert und sicher.

Dann kommt ein Team mit einer Anfrage, die gleich drei Richtlinien verletzt. Sie brauchen eine speicherintensive Instanz, die normalerweise aus Kostengründen verboten ist. Sie müssen temporär einen Debug-Port öffnen, weil sich ein Produktionsproblem nur in der echten Umgebung reproduzieren lässt. Und das Altsystem, das sie migrieren, zwingt sie zu einem Ressourcennamen, der gegen Ihre Namenskonvention verstößt.

Was tun Sie?

Das Problem mit starren Richtlinien

Wenn Ihre Antwort lautet „Richtlinie ist Richtlinie, keine Ausnahmen“, dann bereiten Sie den Boden für Misserfolg. Teams werden Workarounds finden. Sie werden stillschweigend Richtlinien ändern, Ressourcen außerhalb der Pipeline erstellen oder die Regeln einfach ignorieren. Die Richtlinie wird nutzlos, weil Menschen lieber das System umgehen, als gegen starre Regeln zu kämpfen.

Das Ziel ist nicht, Richtlinien abzuschaffen. Es geht darum, sie flexibel genug zu machen, dass sich niemand gezwungen fühlt, sie zu umgehen. Sie brauchen einen klaren Mechanismus für Ausnahmen, der alle in die Pflicht nimmt.

Drei Dinge, die jede Ausnahme braucht

Ein gut durchdachtes Ausnahmesystem hat drei unverzichtbare Komponenten: Protokollierung, Genehmigung und Ablauf.

Protokollierung

Jede Ausnahme muss aufgezeichnet werden. Wer sie beantragt hat, welche Richtlinie umgangen wurde, welche Ressourcen betroffen waren, warum die Ausnahme nötig war und wer sie genehmigt hat. Diese Informationen dürfen niemals verloren gehen. Sie dienen mehreren Zwecken: Prüfpfade, Post-Mortem-Analysen und eine sanfte Erinnerung daran, dass das Team außerhalb der normalen Regeln arbeitet.

Ohne Protokollierung werden Ausnahmen zu unsichtbaren technischen Schulden. Sie wissen nicht, wie viele Ausnahmen existieren, wer sie gewährt hat oder ob sie noch benötigt werden.

Genehmigung

Die Person, die eine Ausnahme beantragt, kann sie nicht selbst genehmigen. Jemand anderes muss zustimmen – idealerweise jemand, der die Risiken versteht, die die Richtlinie eigentlich abmildern sollte. Betrifft die Ausnahme die Sicherheit, genehmigt das Sicherheitsteam. Betrifft sie Kosten, genehmigt die Finanzabteilung oder ein Engineering Manager.

Diese Genehmigung kann direkt als Gate in Ihre Pipeline integriert werden. Die Pipeline pausiert, bis die autorisierte Person den Ausnahmeantrag prüft und genehmigt. Keine Genehmigung, kein Deployment.

Ablauf

Ausnahmen sollten niemals dauerhaft sein. Jede Ausnahme braucht ein Zeitlimit, in der Regel 7 bis 30 Tage. Danach greift die Richtlinie automatisch wieder. Die verstoßende Ressource muss korrigiert oder entfernt werden. Ist die Ausnahme weiterhin nötig, muss das Team einen neuen Antrag mit aktualisierter Begründung stellen.

Dieser Mechanismus verhindert, dass Ausnahmen zum neuen Normal werden. Er zwingt Teams dazu, entweder das zugrunde liegende Problem zu beheben oder zu rechtfertigen, warum die Richtlinie geändert werden muss.

Den Ausnahmeablauf gestalten

Der Ausnahmeprozess sollte ein wenig unbequem sein. Nicht um Leute zu bestrafen, sondern um sicherzustellen, dass sie die Ausnahme wirklich brauchen. Ist es zu einfach, werden alle Ausnahmen statt Richtlinien nutzen. Ist es zu schwer, finden Leute Schlupflöcher. Der ideale Punkt liegt irgendwo dazwischen: lästig genug, um zweimal nachdenken zu lassen, aber nicht so schmerzhaft, dass es legitime Arbeit blockiert.

In der Praxis sieht der Ablauf so aus:

Das folgende Diagramm veranschaulicht den Ausnahmeantragsprozess:

flowchart TD A[Pipeline erkennt Richtlinienverstoß] --> B{Aktion wählen} B -->|Abbrechen| C[Änderung blockiert] B -->|Ausnahme beantragen| D[Ausnahmeantrag einreichen] D --> E[Antragsdetails protokollieren] E --> F[Genehmiger benachrichtigen] F --> G{Genehmigt?} G -->|Nein| H[Änderung blockiert] G -->|Ja| I[Pipeline fährt mit Ausnahmestatus fort] I --> J[Ablaufdatum setzen] J --> K[Erinnerungen vor Ablauf senden] K --> L{Ablaufdatum erreicht?} L -->|Nein| M[Ressource im Ausnahmezustand] L -->|Ja| N[Richtlinienprüfung erneut durchführen] N --> O{Konform?} O -->|Ja| P[Ausnahme geschlossen] O -->|Nein| Q[Richtlinie durchsetzen / Ressource korrigieren]
  1. Die Pipeline führt ihre Richtlinienprüfungen während des Plan- oder Apply-Schritts durch.
  2. Ein Verstoß wird erkannt. Die Pipeline bietet zwei Optionen: die Änderung abbrechen oder einen Ausnahmeantrag stellen.
  3. Reicht das Team einen Ausnahmeantrag ein, erstellt die Pipeline ein Ticket oder eine Benachrichtigung für den autorisierten Genehmiger.
  4. Nach der Genehmigung fährt die Pipeline fort, markiert die Ressource jedoch als im Ausnahmestatus.
  5. Das System sendet Erinnerungen vor Ablauf der Ausnahme. Nach Ablauf führt es automatisch die Richtlinienprüfung erneut durch.

Was Sie vermeiden sollten

Erstellen Sie niemals Ausnahmen ohne Ablaufdatum oder Genehmigung. Das kommt einer fehlenden Richtlinie gleich. Eine Ausnahme, die nie abläuft, ist nichts anderes als eine stillschweigend umgeschriebene Richtlinie.

Nutzen Sie Ausnahmen auch nicht als Ausrede, um Ihre Richtlinien nicht zu verbessern. Taucht immer wieder derselbe Ausnahmetyp auf, ist Ihre Richtlinie womöglich zu streng. Vielleicht brauchen Sie eine neue Ressourcenkategorie, oder die ursprüngliche Regel ergibt keinen Sinn mehr. Häufige Ausnahmen sind ein Signal, dass Ihre Richtlinien überdacht werden müssen – nicht nur Workarounds.

Praktische Checkliste für den Ausnahmeumgang

  • Jede Ausnahme wird protokolliert mit Antragsteller, umgangener Richtlinie, betroffenen Ressourcen, Grund und Genehmiger
  • Ausnahmen erfordern die Genehmigung durch jemanden, der das Risiko der Richtlinie versteht
  • Alle Ausnahmen haben ein explizites Ablaufdatum (7–30 Tage empfohlen)
  • Die Pipeline blockiert das Deployment, bis die Ausnahme genehmigt ist
  • Automatisierte Erinnerungen werden vor Ablauf der Ausnahme gesendet
  • Abgelaufene Ausnahmen lösen eine automatische Richtlinienprüfung aus
  • Die Ausnahmehäufigkeit wird vierteljährlich überprüft, um Richtlinienverbesserungen zu identifizieren

Das Fazit

Richtlinien ohne Ausnahmemechanismen erzeugen Schattensysteme. Teams umgehen sie, und Sie verlieren den Überblick darüber, was tatsächlich in Ihrer Infrastruktur läuft. Ein gut gestalteter Ausnahmeablauf schwächt Ihre Richtlinien nicht. Er stärkt sie, indem er sie realistisch genug macht, dass Menschen sie tatsächlich befolgen. Der Schlüssel liegt in Protokollierung, Genehmigung und Ablauf. Fehlt auch nur eines dieser Elemente, haben Sie keinen Ausnahmeprozess – sondern eine Richtlinie, die bereits gebrochen ist.