Was nach einer erfolgreichen Bereitstellung passiert

Der Deployment-Log sagt, alles sei bestanden. Der Server ist fehlerfrei gestartet. Das Artefakt wurde sauber installiert. Die Pipeline zeigt in allen Stufen Grün.

Aber nichts davon sagt Ihnen, ob die neue Version tatsächlich für die Benutzer funktioniert.

Ein sauberes Deployment ist nur die Installationsphase. Die eigentliche Frage beginnt, sobald der Traffic auf den neuen Code trifft. Verhält sich die Anwendung wie erwartet? Bekommen die Benutzer die Erfahrung, die Sie beabsichtigt haben? Die Antwort finden Sie nicht in Ihren Deployment-Logs.

Die Lücke zwischen Deployment und Normalbetrieb

Wenn ein Team eine neue Version eines Backend-Dienstes ausrollt, sind die ersten Minuten nach dem Deployment die aufschlussreichsten. Dann trifft der neue Code auf echten Traffic, echte Daten und echte Abhängigkeiten. Probleme, die im Staging nie aufgetreten sind, können sofort sichtbar werden.

Der häufige Fehler ist, das Deployment als abgeschlossen zu betrachten, sobald die Pipeline grün wird. In der Praxis ist das Deployment erst dann vollständig, wenn Sie genügend Belege haben, dass die neue Version unter Produktionsbedingungen normal läuft.

Fünf Indikatoren, die Sie nach dem Deployment prüfen sollten

Fehlerrate

Die Fehlerrate ist das direkteste Signal, dass etwas nicht stimmt. Wenn Ihr API-Dienst normalerweise eine Fehlerrate von 0,1 Prozent hat und nach dem Deployment plötzlich auf 5 Prozent springt, haben Sie ein Problem.

Um die Fehlerrate direkt nach dem Deployment zu prüfen, fragen Sie Ihren Metrik-Endpunkt ab. Zum Beispiel mit Prometheus:

curl -s 'http://localhost:9090/api/v1/query?query=rate(http_requests_total{status=~"5.."}[5m])'

Dies gibt die Rate der 5xx-Fehler der letzten fünf Minuten zurück. Vergleichen Sie das Ergebnis mit Ihrer Baseline vor dem Deployment, um zu entscheiden, ob ein Rollback nötig ist.

Aber die Fehlerrate allein reicht nicht. Ein Spike könnte von einer nachgelagerten Abhängigkeit kommen, nicht von Ihrem Code. Wenn die Datenbank langsam reagiert, schlagen alle Anfragen fehl, die auf die Datenbank zugreifen. Das bedeutet, Sie müssen die Fehlerrate zusammen mit anderen Indikatoren betrachten, um zu verstehen, wo das eigentliche Problem liegt.

Latenz

Manchmal produziert eine neue Version überhaupt keine Fehler, aber jede Antwort dauert länger. Benutzer können die Anwendung noch nutzen, aber die Erfahrung leidet. Latenzanstiege können durch ineffizienten Code, geänderte Datenbankabfragen oder Serverressourcen entstehen, die an ihre Grenzen stoßen.

Wenn die Latenz nach dem Deployment stetig steigt und sich nicht wieder einpendelt, verbraucht etwas in der neuen Version mehr Zeit pro Anfrage als es sollte.

Sättigung

Hier geht es darum, wie voll Ihre Serverressourcen sind. CPU, Arbeitsspeicher, Datenbankverbindungen, Festplatten-I/O. Eine neue Version kann ressourcenhungrig sein, ohne dass es beim Testen auffällt.

Zum Beispiel Code, der für jede Anfrage eine neue Datenbankverbindung öffnet und nie schließt. Oder eine unnötige Schleife, die bei jedem API-Aufruf läuft. Sättigung kann unsichtbar bleiben, bis der Traffic steigt, und dann kann der Server keine zusätzliche Last mehr bewältigen, obwohl Fehlerrate und Latenz in Ordnung aussehen.

Zustand der Abhängigkeiten

Backend-Dienste laufen selten allein. Ein API-Dienst ist von Datenbanken, Caches und anderen Diensten abhängig. Ein Worker ist von einem Message Broker abhängig. Wenn Ihre neue Version Abhängigkeiten auf andere Weise anspricht, könnten diese Abhängigkeiten anders reagieren als erwartet.

Manchmal liegt das Problem gar nicht in Ihrem Dienst. Sondern in dem Dienst, den Sie aufrufen, und die neue Version ist das erste Mal, dass diese Abhängigkeit unter realen Bedingungen getestet wird.

Geschäftssignale

Dies ist der anwendungsspezifischste Indikator. Für eine Registrierungs-API ist das Geschäftssignal die Anzahl der abgeschlossenen Registrierungen pro Minute. Für einen Zahlungsabwicklungs-Worker sind es die erfolgreich verarbeiteten Transaktionen.

Wenn die Registrierungen nach dem Deployment stark zurückgehen, aber die technische Fehlerrate niedrig bleibt, haben Sie trotzdem ein ernstes Problem. Geschäftssignale müssen vom Team definiert werden, das versteht, was der Dienst liefern soll. Diese Signale sagen Ihnen, ob die Anwendung ihren Job macht, nicht nur, ob sie läuft.

Was tun, wenn etwas schiefgeht

Wenn die Indikatoren zeigen, dass die neue Version nicht richtig funktioniert, ist die sicherste Reaktion ein Rollback. Kehren Sie zur vorherigen Version zurück, die als stabil bekannt war.

Das folgende Flussdiagramm zeigt den Post-Deployment-Überwachungsprozess und die Entscheidung für Rollback oder Fortsetzung:

flowchart TD A[Deployment grün] --> B{Fehlerrate prüfen} B -- ok --> C{Latenz prüfen} B -- alarm --> R[Rollback] C -- ok --> D{Sättigung prüfen} C -- alarm --> R D -- ok --> E{Abhängigkeiten prüfen} D -- alarm --> R E -- ok --> F{Geschäftssignale prüfen} E -- alarm --> R F -- ok --> G[Überwachen] F -- alarm --> R

Ein Rollback muss automatisiert sein. Sich auf Server einzuloggen und Dateien manuell auszutauschen, ist zu langsam und zu fehleranfällig, wenn Benutzer bereits betroffen sind.

Wie Sie das Rollback automatisieren, hängt von Ihrer Deployment-Strategie ab:

  • Rolling Update: Konfigurieren Sie die Pipeline so, dass sie zur vorherigen Version zurückkehrt, wenn die Fehlerrate einen Schwellenwert überschreitet.
  • Blue/Green: Leiten Sie den Traffic zurück zur alten Umgebung.
  • Canary: Stoppen Sie den Canary und leiten Sie den gesamten Traffic zurück zur stabilen Version.

Der entscheidende Punkt ist, dass Rollback-Schwellenwerte vor dem Deployment festgelegt werden müssen, nicht während eines Incidents. Zum Beispiel: Wenn die Fehlerrate für zwei Minuten über 1 Prozent bleibt, automatisch Rollback. Oder wenn die durchschnittliche Latenz um 50 Prozent gegenüber der Baseline steigt, Rollback.

Jeder Dienst braucht seine eigenen Schwellenwerte. Eine kritische API, von der Benutzer direkt abhängen, sollte engere Schwellenwerte haben als ein Hintergrund-Worker, der Batch-Jobs verarbeitet.

Eine praktische Post-Deployment-Checkliste

Verwenden Sie diese Checkliste nach jedem Deployment, um zu überprüfen, ob die neue Version normal läuft:

  • Fehlerrate liegt im erwarteten Bereich (Vergleich mit Baseline vor dem Deployment)
  • Latenz hat nicht signifikant zugenommen
  • Server-Ressourcennutzung (CPU, Arbeitsspeicher, Verbindungen) ist stabil
  • Alle kritischen Abhängigkeiten reagieren normal
  • Geschäftssignale (Registrierungen, Transaktionen usw.) entsprechen den erwarteten Mustern
  • Rollback-Schwellenwert ist definiert und automatisiert

Das wahre Ende eines Deployments

Ein Deployment ist nicht abgeschlossen, wenn die Pipeline grün wird. Es ist abgeschlossen, wenn Sie bestätigt haben, dass die neue Version unter Produktionsbedingungen normal funktioniert. Die ersten Minuten, nachdem der Traffic auf den neuen Code trifft, sind die wichtigsten. Dann erkennen Sie Probleme, bevor sie alle Benutzer betreffen.

Setzen Sie Ihre Schwellenwerte, beobachten Sie Ihre Indikatoren und automatisieren Sie Ihr Rollback. Das Sicherheitsnetz funktioniert nur, wenn es bereit ist, bevor Sie es brauchen.