Fünf Signale, die nach jedem Deployment zeigen, ob die neue Version gesund ist

Du hast gerade eine neue Version deployed. Die Pipeline zeigt grün. Das Team beobachtet das Dashboard. Aber läuft die Anwendung wirklich gut für die Nutzer?

Ohne konkrete Signale rätst du nur. Raten mag funktionieren, wenn nur du die App nutzt. Aber wenn andere darauf angewiesen sind, brauchst du Daten. Du musst innerhalb von Minuten wissen, ob die neue Version gesund oder kaputt ist.

Hier sind fünf grundlegende Signale, die jedes Team nach einem Deployment überwachen sollte. Fang mit einem oder zwei an und ergänze nach und nach die restlichen.

Verfügbarkeit: Können Nutzer die Anwendung erreichen?

Die grundlegendste Frage nach einem Deployment ist einfach: Ist die Anwendung erreichbar? Wenn der Server down ist, die Anwendung beim Start abstürzt oder der Port nicht offen ist, fällt die Verfügbarkeit auf null.

Teams überwachen dies typischerweise mit einem Health-Check-Endpunkt. Das ist eine spezielle URL, die die Anwendung nur bereitstellt, um zu antworten: „Bin ich am Leben?“ Monitoring-Tools rufen diesen Endpunkt regelmäßig auf. Wenn er nicht mehr antwortet, stimmt etwas nicht.

Verfügbarkeit wird meist als Prozentsatz gemessen: 99 %, 99,9 % oder 99,99 % der erwarteten Betriebszeit. Je höher das Ziel, desto weniger Toleranz hast du für Unterbrechungen. Ein 99-%-Ziel bedeutet etwa 7 Stunden Ausfall pro Monat. Ein 99,99-%-Ziel bedeutet etwa 4 Minuten pro Monat.

Um die Verfügbarkeit direkt nach dem Deployment zu prüfen, führe einen einfachen curl-Befehl gegen deinen Health-Endpunkt aus:

curl -f http://localhost:8080/health && echo "OK" || echo "FAIL"

Das Flag -f sorgt dafür, dass curl einen Exit-Code ungleich null zurückgibt, wenn die HTTP-Antwort ein Fehler ist (4xx oder 5xx). Ein Exit-Code von null bedeutet, dass der Endpunkt erreichbar und gesund ist. Du kannst dies in einem Deployment-Skript verwenden, um automatisch zu entscheiden, ob du fortfährst oder zurückrollst.

Prüfe nach dem Deployment zuerst die Verfügbarkeit. Wenn die Anwendung nicht erreichbar ist, ist alles andere egal.

Fehlerrate: Wie viele Anfragen schlagen fehl?

Eine Anwendung kann leben, aber kaputt sein. Jede eingehende Anfrage könnte fehlschlagen. Die Fehlerrate misst, wie viele Anfragen mit einem Fehlercode enden, wie HTTP 500 oder einem Timeout.

Vor dem Deployment solltest du deine Basis-Fehlerrate kennen. Vielleicht liegt sie bei 0,5 % aller Anfragen. Springt diese Zahl nach dem Deployment auf 5 %, verursacht etwas in der neuen Version Fehler.

Spitzen in der Fehlerrate sind oft der erste Alarm, dass etwas schiefgelaufen ist. Sie sind leicht zu erkennen und deuten meist auf ein echtes Problem hin. Ein plötzlicher Anstieg der Fehler sollte eine sofortige Untersuchung auslösen, kein „Lass uns abwarten und sehen.“

Latenz: Wie schnell antwortet die Anwendung?

Nutzer warten nicht gern. Wenn eine Seite, die früher in einer Sekunde geladen hat, jetzt fünf Sekunden braucht, gehen die Nutzer. Die Latenz misst, wie schnell die Anwendung auf Anfragen antwortet.

Die Latenz kann aus vielen Gründen steigen. Der neue Code könnte langsamer sein. Der Datenbank-Verbindungspool könnte voll sein. Der Server könnte durch den Datenverkehr überlastet sein. Was auch immer die Ursache ist: Eine höhere Latenz verschlechtert direkt die Benutzererfahrung.

Du musst den normalen Latenzbereich vor dem Deployment kennen. Vergleiche nach dem Deployment die Zahlen. Wenn sich die durchschnittliche Antwortzeit verdoppelt, hat sich etwas geändert. Selbst kleine Latenzanstiege können auf Probleme hinweisen, die unter höherer Last schlimmer werden.

Sättigung: Wie voll sind deine Ressourcen?

Jedes System hat Grenzen. CPU, Arbeitsspeicher, Festplattenspeicher, Datenbankverbindungen, Thread-Pools, Netzwerkbandbreite – alle haben eine Obergrenze. Die Sättigung misst, wie nah du an diesen Grenzen bist.

Beobachte nach dem Deployment die Ressourcennutzung. Wenn die CPU-Auslastung von 40 % auf 90 % gestiegen ist, verbraucht die neue Version mehr Ressourcen. Das kann in Ordnung sein, wenn du freie Kapazitäten hast. Aber wenn der Datenverkehr später zunimmt, werden aus diesen 90 % 100 %, und die Anwendung wird langsamer oder stürzt ab.

Die Sättigung hilft auch bei der Kapazitätsplanung. Wenn ein Server konstant zu 80 % ausgelastet ist, solltest du wahrscheinlich einen weiteren Server hinzufügen, bevor der nächste Verkehrsspitze kommt. Die Überwachung der Sättigung nach dem Deployment zeigt dir, ob die neue Version das Ressourcenprofil deiner Anwendung verändert hat.

Logs: Was ist tatsächlich im Inneren passiert?

Nicht alles lässt sich als Zahl erfassen. Wenn die Fehlerrate in die Höhe schießt, musst du wissen, warum. Hier kommen Logs ins Spiel. Logs sind Aufzeichnungen von Ereignissen, die die Anwendung während des Betriebs schreibt.

Gute Logs haben Stufen: info für normale Abläufe, warning für ungewöhnliche, aber nicht kritische Ereignisse, error für Fehler. Sie haben auch Kontext: Zeitstempel, Request-ID, Funktionsname und relevante Daten. Ohne Kontext sind Logs nur Rauschen.

Wenn nach dem Deployment etwas schiefgeht, sind Logs der erste Ort, an dem du nachschaust. Ist eine bestimmte Ausnahme aufgetreten? Hat eine bestimmte Eingabe einen Absturz verursacht? Antwortet die Datenbank nicht? Logs erzählen die Geschichte, die Zahlen allein nicht können.

Fang klein an, bleib konsistent

Du musst nicht von Anfang an alle fünf Signale überwachen. Fang mit Verfügbarkeit und Fehlerrate an. Diese beiden fangen die meisten Probleme ab. Füge Latenz hinzu, wenn du die Leistung verstehen musst. Füge Sättigung hinzu, wenn du mit der Kapazitätsplanung beginnst. Füge Logs hinzu, wenn du tiefere Probleme debuggen musst.

Wichtig ist die Konsistenz. Jedes Deployment sollte auf die gleiche Weise gemessen werden. Verwende denselben Health-Check-Endpunkt. Sammle Fehlerraten aus derselben Quelle. Messe die Latenz mit denselben Tools. Nur dann kannst du Versionen ehrlich vergleichen: Ist die neue Version besser oder schlechter als die alte?

Diese fünf Signale liefern dir Daten statt Gefühle. Daten sagen dir, ob du fortfahren, zurückrollen oder weiter untersuchen solltest.

Kurz-Checkliste für das Monitoring nach dem Deployment

• Health-Check-Endpunkt antwortet
• Fehlerrate ist nicht signifikant höher als die Basislinie
• Durchschnittliche Latenz liegt im normalen Bereich
• CPU-, Arbeitsspeicher- und Festplattenauslastung sind nicht nahe der Kapazitätsgrenze
• Logs zeigen keine unerwarteten Fehler oder Ausnahmen

Was als Nächstes kommt

Diese Signale sagen dir, ob die Anwendung gesund ist, aber sie sagen dir nicht, ob die neue Funktion tatsächlich wie erwartet funktioniert. Eine Version kann perfekte Verfügbarkeit, niedrige Fehlerrate, schnelle Latenz haben und trotzdem das falsche Ergebnis liefern. Hier kommt die Verifikation ins Spiel.

Aber bevor du so weit bist, stelle sicher, dass diese fünf Signale vorhanden sind. Ohne sie fliegst du blind. Mit ihnen hast du eine Grundlage, um zu wissen, was nach jedem Deployment passiert.