Nicht alle Änderungen sind gleich: Standard-, Normal- und Notfall-Änderungen

Ein Entwickler erstellt einen Pull-Request, um einen Tippfehler auf der „Über uns“-Seite des Unternehmens zu korrigieren. Drei Tage später wartet die Korrektur immer noch auf Freigabe. In der Zwischenzeit bereitet sich ein anderes Team darauf vor, das Datenbankschema für Zahlungen zu migrieren – und wartet ebenfalls auf denselben Genehmigungsprozess. Die Tippfehler-Korrektur und die Datenbankmigration werden identisch behandelt: Beide benötigen ein Meeting, eine Unterschrift und einen Platz im nächsten Release-Fenster.

Diese Situation ist frustrierend, aber auch häufig. Wenn jede Änderung durch dieselbe Genehmigungspipeline läuft, bleiben kleine Korrekturen hinter schwerfälligen Prozessen stecken, und risikoreiche Änderungen erhalten möglicherweise nicht die Prüfung, die sie verdienen. Das Problem ist nicht die Governance an sich. Das Problem ist, alle Änderungen so zu behandeln, als hätten sie dasselbe Risiko.

Warum ein Einheits-Genehmigungsprozess scheitert

Der Impuls, jede Änderung zu kontrollieren, kommt von einem guten Ort: Niemand möchte eine kaputte Produktionsumgebung. Aber wenn der Genehmigungsprozess nicht zwischen einer Textaktualisierung und einer Schema-Migration unterscheidet, passieren zwei Dinge. Erstens stapeln sich risikoarme Änderungen und warten auf Genehmigungen, die keine echte Sicherheit bringen. Zweitens wird das Team gegenüber dem Prozess abgestumpft. Wenn alles eine Unterschrift erfordert, hören die Leute auf, darüber nachzudenken, ob die Unterschrift tatsächlich wichtig ist. Sie warten einfach auf das Häkchen.

Das Ergebnis ist ein System, das sichere Änderungen verlangsamt, ohne riskante Änderungen sicherer zu machen. Die Lösung ist nicht, Governance zu entfernen. Die Lösung ist, Governance proportional zum Risiko zu gestalten.

Drei Kategorien von Änderungen

Die meisten reifen Teams unterteilen Änderungen basierend auf Risiko und Vertrautheit in drei Kategorien: Standard, Normal und Notfall. Jede Kategorie hat einen anderen Genehmigungsweg.

Das folgende Flussdiagramm zeigt, wie eine Änderung in die Pipeline gelangt und basierend auf ihrer Klassifizierung an den entsprechenden Genehmigungsprozess weitergeleitet wird.

Standard-Änderungen

Eine Standard-Änderung ist etwas, das das Team schon viele Male durchgeführt hat. Der Ablauf ist bekannt, das Ergebnis ist vorhersehbar und das Risiko ist gut verstanden. Beispiele sind die Aktualisierung statischer Inhalte auf einer Marketingseite, das Hinzufügen eines Servers zur Bewältigung von Verkehrsspitzen oder das erneute Ausführen einer Pipeline, die aufgrund eines vorübergehenden Netzwerkproblems fehlgeschlagen ist.

Da das Team bereits genau weiß, was passieren wird, und einen bewährten Ablauf hat, benötigen Standard-Änderungen keine manuelle Überprüfung oder Genehmigung. Das Team folgt einfach dem dokumentierten Ablauf. Die wichtigste Voraussetzung ist, dass der Ablauf dokumentiert und prüfbar sein muss. Wenn etwas schiefgeht, kann das Team zurückverfolgen und prüfen, ob der Ablauf korrekt befolgt wurde.

Standard-Änderungen sind der Bereich, in dem Automatisierung glänzt. Wenn ein Ablauf wirklich vorhersehbar ist, sollte er in der CI/CD-Pipeline codiert werden. Die Pipeline selbst wird zum Genehmigungsmechanismus: Wenn die automatisierten Prüfungen bestanden werden, wird die Änderung durchgeführt.

Normale Änderungen

Eine normale Änderung ist etwas, das das Team noch nicht gemacht hat oder bei dem das Risiko nicht vollständig verstanden ist. Beispiele sind das Hinzufügen einer Funktion, die die Geschäftslogik ändert, das Upgrade einer Datenbankversion oder die Änderung der Sicherheitskonfiguration.

Normale Änderungen erfordern eine Überprüfung. Der Prüfer kann je nach Risikograd ein Peer-Entwickler, ein Sicherheitsteam-Mitglied oder ein Change Advisory Board (CAB) sein. Aber Überprüfung muss nicht einen langsamen Prozess bedeuten. Bei risikoarmen normalen Änderungen reicht eine schnelle Überprüfung durch ein oder zwei Personen aus. Bei risikoreichen normalen Änderungen kann die Überprüfung mehr Stakeholder und zusätzliche Tests umfassen.

Der entscheidende Punkt ist, dass normale Änderungen nicht standardmäßig blockiert werden. Sie werden proportional überprüft. Ein Team, das klare Kriterien dafür hat, was eine Änderung risikoarm versus risikoreich macht, kann jede Änderung automatisch an die entsprechende Prüftiefe weiterleiten.

Notfall-Änderungen

Eine Notfall-Änderung ist etwas, das sofort durchgeführt werden muss, um ein Live-Problem zu beheben. Beispiele sind ein Produktionsserver, der ausgefallen ist, beschädigte Daten oder eine Sicherheitslücke, die aktiv ausgenutzt wird. In diesen Situationen würde das Warten auf eine Überprüfung oder ein Genehmigungsmeeting das Problem verschlimmern.

Notfall-Änderungen haben einen Schnellweg. Das Team kann die Änderung sofort vornehmen, aber es gibt einen Haken: Die Änderung muss dokumentiert und im Nachhinein bewertet werden. Das Team muss aufzeichnen, was geändert wurde, wer es geändert hat, warum es ein Notfall war und welche Auswirkungen es hatte. Nachdem der Vorfall behoben ist, bewertet das Team, ob die Notfall-Änderung angemessen war oder weitere Korrekturen erforderlich sind.

Der Schnellweg ist kein Freifahrtschein. Es ist ein Kompromiss: Geschwindigkeit jetzt, Rechenschaftspflicht später. Teams, die den Notfallweg missbrauchen, indem sie Routineänderungen als Notfälle klassifizieren, werden irgendwann Vertrauen verlieren und echte Risiken schaffen.

Wie man Änderungen klassifiziert

Die drei Kategorien sind nur nützlich, wenn das Team klare Kriterien für jede hat. Ohne Kriterien wird die Klassifizierung willkürlich. Die Standard-Änderung des einen ist die normale Änderung des anderen, und das ganze System bricht zusammen.

Beginnen Sie damit, zu definieren, was eine Standard-Änderung ausmacht. Eine gute Faustregel: Wenn das Team dieselbe Änderung mindestens fünfmal ohne Zwischenfall durchgeführt hat und der Ablauf vollständig dokumentiert ist, ist sie ein Kandidat für den Standard-Status. Bei Unsicherheit gehört sie in die normale Kategorie.

Definieren Sie für normale Änderungen, was eine Änderung risikoreich versus risikoarm macht. Häufige Faktoren sind: Betrifft die Änderung das Datenbankschema? Beeinflusst sie Authentifizierung oder Autorisierung? Ändert sie, wie mit Geld umgegangen wird? Erfordert sie einen Rollback-Plan? Je mehr Ja-Antworten, desto höher das Risiko.

Definieren Sie für Notfall-Änderungen, was als Notfall gilt. Ein Tippfehler auf einer Landingpage ist kein Notfall. Ein Produktionsausfall, der zahlende Kunden betrifft, schon. Das Team sollte sich auf Beispiele für echte Notfälle und Beispiele für Situationen einigen, die dringend aussehen, es aber nicht sind.

Integration der Klassifizierung in die Pipeline

Sobald die Kriterien klar sind, besteht der nächste Schritt darin, die Klassifizierung in die CI/CD-Pipeline zu integrieren. Das bedeutet nicht, ein komplexes Genehmigungssystem aufzubauen. Es bedeutet, ein einfaches Feld zum Change Request oder zum Deployment-Ticket hinzuzufügen, das den Entwickler auffordert, die Änderung zu klassifizieren. Die Pipeline kann die Änderung dann an den entsprechenden Überprüfungspfad weiterleiten.

Ein GitHub Actions-Workflow kann beispielsweise einen Pull-Request automatisch als standard labeln, wenn er nur Dokumentation oder Konfigurationsdateien betrifft, und dann den manuellen Genehmigungsschritt überspringen:

name: Classify Change
on: pull_request

jobs:
  classify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v5
        with:
          repo-token: "${{ secrets.GITHUB_TOKEN }}"
          configuration-path: .github/labeler.yml

  deploy-standard:
    if: contains(github.event.pull_request.labels.*.name, 'standard')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy without manual approval
        run: echo "Deploying standard change..."

Und die dazugehörige .github/labeler.yml-Datei definiert, welche Pfade auf das standard-Label abgebildet werden:

standard:
  - changed-files:
      - any-glob-to-any-file: ['docs/**', 'config/**', '*.md']

Bei Standard-Änderungen kann die Pipeline nach Bestehen der üblichen Tests automatisch fortfahren. Bei normalen Änderungen kann die Pipeline pausieren und die entsprechenden Prüfer benachrichtigen. Bei Notfall-Änderungen kann die Pipeline das Deployment zulassen, aber eine Dokumentationsanforderung nach dem Deployment auslösen.

Das Ziel ist nicht, eine Bürokratie aufzubauen. Das Ziel ist, die Pipeline das Risikoverständnis des Teams widerspiegeln zu lassen. Wenn die Pipeline die Klassifizierung automatisch übernimmt, verbringt das Team weniger Zeit mit Prozessen und mehr Zeit mit der eigentlichen Arbeit.

Eine praktische Checkliste

Stellen Sie sich vor Ihrem nächsten Deployment diese Fragen:

• Ist diese Änderung etwas, das wir schon einmal mit einem dokumentierten Ablauf gemacht haben? Wenn ja, behandeln Sie sie als Standard und automatisieren Sie die Genehmigung.
• Ist diese Änderung neu oder unsicher? Wenn ja, identifizieren Sie das Risikoniveau und weisen Sie den entsprechenden Prüfer zu.
• Ist diese Änderung erforderlich, um ein Live-Problem zu beheben? Wenn ja, führen Sie die Änderung jetzt durch, dokumentieren Sie aber alles und planen Sie eine Überprüfung nach dem Vorfall.

Das Fazit

Governance bedeutet nicht, alle auszubremsen. Es geht darum, die richtige Menge an Kontrolle auf die richtige Änderung anzuwenden. Standard-Änderungen sollten durchfliegen. Normale Änderungen sollten eine proportionale Überprüfung erhalten. Notfall-Änderungen sollten Geschwindigkeit mit Rechenschaftspflicht verbinden. Wenn das Team sich auf die Kriterien einigt und sie in die Pipeline einbaut, wird die Genehmigung intelligenter, nicht schwerfälliger.