Version 4 · Migration
Observability und Runbooks
Migration endet nicht beim Starten des Pods. Wichtig sind Health Checks, Logs, Metriken, Tracing, Alarme und klare Betriebsanweisungen.
Migration endet nicht beim Starten des Pods. Wichtig sind Health Checks, Logs, Metriken, Tracing, Alarme und klare Betriebsanweisungen.
Betriebliches Minimalziel
Ein migriertes System muss erklären können, ob es lebt, bereit ist, welche Abhängigkeit gestört ist, welche fachliche Nachricht betroffen ist und wie der Betrieb reagieren soll.
Health-Endpunkte
Readiness und Liveness als fachliche Betriebsgrenze
@Path("/q/health")
public class HealthResource {
@GET
@Path("/ready")
public Response ready() {
// Bereit erst, wenn DB, MQ und Legacy-Gateway erreichbar oder bewusst degraded sind.
HealthStatus status = healthCheckService.readiness();
return status.ready() ? Response.ok(status).build()
: Response.status(503).entity(status).build();
}
@GET
@Path("/live")
public Response live() {
return Response.ok(Map.of("status", "UP")).build();
}
}
Runbook-Struktur
| Abschnitt | Inhalt |
|---|---|
| Symptom | Route antwortet 503 |
| Sofortcheck | Pod Events, Readiness, ConfigMap/Secret, DB/MQ-Erreichbarkeit |
| Fachcheck | Sind Rechnungen blockiert? Gibt es Outbox-Rückstand? |
| Rollback | Traffic auf Legacy Route zurücknehmen, moderne Verarbeitung stoppen. |
| Nachweis | Incident-ID, betroffene Kunden/Rechnungen, Korrekturlauf dokumentieren. |
Observability-Kette
| Signal | Zweck |
|---|---|
| Correlation ID | Von Portal über API, MQ, DB und Batch durchreichen. |
| Business Metrics | Anzahl erstellter Rechnungen, Fehlerklassen, Retry-Rückstand. |
| Technical Metrics | CPU, Memory, GC, Threadpool, Connection Pool, Queue Lag. |
| Tracing | Langsame externe Aufrufe und Kaskadenfehler sichtbar machen. |