Was nach einem Deployment zu prüfen ist, hängt davon ab, was Sie deployed haben

Sie haben gerade eine neue Version in die Produktion gebracht. Die Pipeline ist grün. Das Deployment war fehlerfrei. Und jetzt?

Die meisten Teams starren auf ein Dashboard und hoffen, dass nichts kaputtgeht. Doch die entscheidenden Signale hängen vollständig davon ab, was Sie deployed haben. Wenn Sie für eine Anwendung, eine Datenbank und eine Infrastrukturänderung dieselben Metriken prüfen, übersehen Sie die wahren Probleme. Jeder Deployment-Typ hat seine eigenen Fehlermodi, und Sie müssen die richtigen Signale für jeden einzelnen überwachen.

Anwendungen: Beobachten Sie, wie Requests verarbeitet werden

Wenn Sie eine neue Version einer Anwendung deployen, ist das Wichtigste zu wissen, ob sie Benutzeranfragen korrekt verarbeitet. Zwei Metriken geben Ihnen diese Antwort schneller als alles andere: Fehlerrate und Latenz.

Die Fehlerrate zeigt Ihnen, wie viele Anfragen fehlschlagen. Steigt die Fehlerrate direkt nach einem Deployment an, stimmt etwas nicht. Die Ursache kann ein Bug im neuen Code, ein Konfigurationskonflikt oder eine Inkompatibilität mit der Produktionsumgebung sein. Was auch immer der Grund ist – Benutzer stoßen auf Fehler, und Sie müssen sofort Bescheid wissen.

Die Latenz gibt an, wie lange die Anwendung braucht, um auf Anfragen zu antworten. Ein plötzlicher Anstieg der Latenz bedeutet, dass die neue Version langsamer ist. Sie verbraucht möglicherweise mehr Ressourcen, stößt an einen Engpass oder ruft ineffizient nachgelagerte Dienste auf. Benutzer sehen vielleicht keine Fehler, aber sie werden die Langsamkeit spüren – und das ist genauso schädlich.

Der Durchsatz ist ein weiteres nützliches Signal, insbesondere für Anwendungen mit vielen Benutzern. Der Durchsatz misst, wie viele Anfragen die Anwendung pro Zeiteinheit verarbeiten kann. Sinkt der Durchsatz, während die Anzahl der Benutzer gleich bleibt, ist die neue Version weniger effizient. Etwas im Code bremst die Dinge aus, selbst wenn Fehlerrate und Latenz normal aussehen.

Diese drei Signale sind das Erste, was Sie nach einem Anwendungs-Deployment prüfen sollten. Sie spiegeln wider, was Benutzer tatsächlich erleben. Verlassen Sie sich nicht darauf, ob der Prozess noch läuft oder der Container hoch ist. Das sagt Ihnen nur, dass die Anwendung lebt, aber nicht, ob sie korrekt arbeitet.

Das folgende Flussdiagramm fasst zusammen, welche Metriken Sie je nach Deployment-Typ zuerst prüfen sollten:

flowchart TD Start([Deployment abgeschlossen]) --> Typ{Deployment-Typ?} Typ -->|Anwendung| App[Anwendungsmetriken prüfen] Typ -->|Datenbank| DB[Datenbankmetriken prüfen] Typ -->|Infrastruktur| Infra[Infrastrukturmetriken prüfen] App --> App1[Fehlerrate] App --> App2[Latenz] App --> App3[Durchsatz] DB --> DB1[Replikationsverzögerung] DB --> DB2[Abfrageleistung] DB --> DB3[Verbindungsanzahl] DB --> DB4[Transaktionslog-Größe] Infra --> Infra1[Node-Health] Infra --> Infra2[CPU & Arbeitsspeicher] Infra --> Infra3[Festplattenspeicher] Infra --> Infra4[Netzwerklatenz]

Datenbanken: Prüfen Sie Replikation, Abfragen und Verbindungen

Datenbanken bedienen keine Anfragen direkt wie Anwendungen. Sie stellen Daten für Anwendungen bereit. Daher sind die zu überwachenden Signale andere.

Der Replikationsstatus ist entscheidend. Die meisten Produktionsdatenbanken verwenden Replikate zum Lesen von Daten. Wenn die Replikation nach einem Deployment zurückfällt oder abbricht, könnten Anwendungen veraltete oder inkonsistente Daten lesen. Dies ist besonders gefährlich nach Schemaänderungen oder Datenmigrationen. Ein paar Sekunden Replikationsverzögerung mögen akzeptabel sein, aber Minuten bedeuten, dass etwas nicht stimmt.

Die Abfrageleistung ist das Nächste, was Sie überwachen sollten. Nach einem Deployment, das das Schema ändert, Indizes hinzufügt oder die Art und Weise verändert, wie die Anwendung Daten schreibt, können einige Abfragen plötzlich langsam werden. Achten Sie auf Abfragen, die länger als üblich dauern oder beginnen, Timeouts zu verursachen. Eine einzige langsame Abfrage kann die gesamte Anwendung ausbremsen.

Auch die Verbindungsanzahl ist wichtig. Datenbanken haben eine begrenzte Anzahl von Verbindungen. Wenn ein Deployment dazu führt, dass Verbindungen sich stapeln oder hängen bleiben, kann die Datenbank keine neuen Verbindungen mehr zulassen. Neue Anfragen schlagen fehl, und die Anwendung wirkt kaputt, obwohl die Datenbank selbst gesund ist.

Die Größe des Transaktionslogs ist ein weniger offensichtliches, aber wichtiges Signal. Datenbanken schreiben Logs für jede Änderung. Wenn ein Deployment die Art und Weise ändert, wie die Anwendung Daten schreibt, kann das Log schneller als üblich wachsen. Ohne ordnungsgemäße Bereinigung kann das Log die Festplatte füllen und die Datenbank zum Stillstand bringen. Datenbankteams haben normalerweise einen sicheren Schwellenwert für die Log-Größe. Wird dieser überschritten, ist Handeln erforderlich.

Infrastruktur: Beginnen Sie mit dem Node-Health

Infrastruktur-Deployments umfassen Änderungen an Servern, Containern, Netzwerken oder Cloud-Ressourcen. Das erste zu prüfende Signal ist der Node-Health. Ist der Server oder Container noch am Leben? Liegen CPU- und Speicherauslastung im normalen Bereich? Füllt sich die Festplatte?

Eine gesunde Infrastruktur ist die Voraussetzung dafür, dass Anwendungen und Datenbanken korrekt laufen. Wenn ein Node ständig neu startet oder ihm die Ressourcen ausgehen, leidet alles, was darauf läuft. Der Node-Health ist die Basis. Ist diese kaputt, ist alles andere egal.

Netzwerksignale sind ebenfalls wichtig, insbesondere nach Änderungen an Firewall-Regeln, Load-Balancern oder Service Meshes. Achten Sie auf erhöhte Latenz zwischen Nodes, Paketverluste oder abgebrochene Verbindungen. Diese Probleme zeigen sich oft nicht direkt in den Anwendungsmetriken, verursachen aber mysteriöse Fehler, die schwer zu debuggen sind.

Signale hängen zusammen, aber beginnen Sie mit einem

Signale von Anwendungen, Datenbanken und Infrastruktur existieren nicht isoliert. Eine langsame Anwendung kann durch eine langsame Datenbank verursacht werden. Eine langsame Datenbank kann durch einen Infrastruktur-Node verursacht werden, dem der Arbeitsspeicher ausgeht. Um das vollständige Bild zu erhalten, müssen Sie Signale aus allen drei Schichten gemeinsam lesen.

Aber wenn Sie nach einem Deployment eine schnelle Entscheidung treffen müssen, hat jedes Team normalerweise ein primäres Signal, das es beobachtet. Anwendungsteams achten auf Fehlerrate und Latenz. Datenbankteams achten auf Replikation und Abfrageleistung. Infrastrukturteams achten auf den Node-Health. Beginnen Sie dort. Wenn etwas falsch aussieht, graben Sie in den anderen Schichten, um die Ursache zu finden.

Praxis-Checkliste für die Überprüfung nach dem Deployment

  • Für Anwendungs-Deployments: Prüfen Sie innerhalb der ersten fünf Minuten Fehlerrate, Latenz und Durchsatz.
  • Für Datenbank-Deployments: Prüfen Sie Replikationsverzögerung, langsame Abfragen, Verbindungsanzahl und Transaktionslog-Größe.
  • Für Infrastruktur-Deployments: Prüfen Sie Node-Health, CPU- und Speicherauslastung, Festplattenspeicher und Netzwerklatenz.
  • Wenn ein Signal abnormal erscheint, prüfen Sie die zugehörigen Signale in den anderen Schichten, um die wahre Ursache zu finden.

Das Fazit

Verwenden Sie nicht für jedes Deployment dasselbe Dashboard. Die Signale, die zählen, hängen davon ab, was Sie gerade geändert haben. Anwendungen benötigen Metriken auf Anfrageebene. Datenbanken benötigen Metriken auf Datenebene. Infrastruktur benötigt Ressourcen- und Netzwerkmetriken. Wissen Sie, welche Signale Sie für jeden Deployment-Typ überwachen müssen, und Sie werden Probleme erkennen, bevor Ihre Benutzer es tun.