Fehlerkatalog Tiefenfinalisierung

Fehlerbild: Container startet nicht.

Wahrscheinliche Ursache: Docker Engine laeuft nicht, Image kann nicht gezogen werden oder Port ist bereits belegt.

Diagnose:

docker ps
docker compose ps
docker compose logs postgres --tail=80

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Docker starten, Portkonflikt loesen, Container neu erzeugen mit docker compose up -d --force-recreate.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Port 5432 ist belegt.

Wahrscheinliche Ursache: Lokale PostgreSQL Installation oder alter Container nutzt den Port.

Diagnose:

lsof -i :5432 || netstat -ano | findstr 5432
docker ps --format "table {{.Names}}	{{.Ports}}"

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Lokalen Dienst stoppen oder Portmapping im Compose anpassen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: PostgreSQL Login falsch.

Wahrscheinliche Ursache: Falscher Host, falscher Benutzer oder falsches Passwort in application.yml/.env.

Diagnose:

docker compose logs postgres --tail=50
psql -h localhost -U order_user -d orderdb

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Credentials aus .env.example uebernehmen und Container neu starten.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Flyway Migration schlaegt fehl.

Wahrscheinliche Ursache: SQL ist nicht idempotent, Tabelle existiert schon oder Schema fehlt.

Diagnose:

select * from flyway_schema_history order by installed_rank;
mvn -pl runtime spring-boot:run

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Migration nicht ueberschreiben, neue V-Version erstellen und Fehler sauber reparieren.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Outbox bleibt auf NEW.

Wahrscheinliche Ursache: Relay laeuft nicht, Scheduling ist deaktiviert oder RabbitMQ Publish scheitert.

Diagnose:

select event_id,event_type,status from outbox.events order by event_id desc;
docker compose logs rabbitmq --tail=80

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: OutboxRelayJob pruefen, RabbitMQ Verbindung pruefen, Relay Delay kontrollieren.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Outbox steht auf FAILED.

Wahrscheinliche Ursache: RabbitMQ nicht erreichbar oder Routing Key/Exchange falsch.

Diagnose:

select event_id,event_type,status from outbox.events where status = 'FAILED';
curl -u order_user:order_pass http://localhost:15672/api/exchanges/%2F/order.events

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Exchange/Queue/Binding aus definitions.json neu laden und App neu starten.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: RabbitMQ Queue bleibt leer.

Wahrscheinliche Ursache: Binding fehlt oder Publisher nutzt falschen Routing Key.

Diagnose:

curl -u order_user:order_pass http://localhost:15672/api/bindings
docker compose logs runtime --tail=100

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Routing Key order.accepted und Exchange order.events abgleichen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Billing Consumer reagiert nicht.

Wahrscheinliche Ursache: Listener-Queue falsch, Bean nicht geladen oder AMQP Starter fehlt.

Diagnose:

grep -R "@RabbitListener" -n maven-project
mvn -pl runtime dependency:tree | grep amqp

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: spring-boot-starter-amqp pruefen und Queue-Namen exakt vergleichen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: WireMock Payment liefert 404.

Wahrscheinliche Ursache: Mapping-Datei fehlt oder URL stimmt nicht.

Diagnose:

curl http://localhost:8089/__admin/mappings
curl -i -X POST http://localhost:8089/payment/authorize

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Mapping in containers/wiremock/mappings kontrollieren und Container neu starten.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Payment Timeout.

Wahrscheinliche Ursache: Provider reagiert langsam, Timeout zu kurz oder Resilience-Regel greift.

Diagnose:

curl -v http://localhost:8089/__admin/requests
grep -R "timeout" -n maven-project/runtime/src/main/resources

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Timeout bewusst konfigurieren und Retry/Circuit Breaker Metriken pruefen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Keycloak Token kann nicht geholt werden.

Wahrscheinliche Ursache: Realm import nicht fertig, Client-ID falsch oder Keycloak startet noch.

Diagnose:

curl http://localhost:8082/realms/order-platform/.well-known/openid-configuration
./scripts/security/get-keycloak-token.sh order-admin admin

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Keycloak Logs abwarten, Realm-Datei pruefen, Client order-runtime nutzen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: API liefert 401.

Wahrscheinliche Ursache: Kein Token, Token abgelaufen oder falscher Issuer.

Diagnose:

echo $TOKEN | cut -d. -f2 | base64 -d
curl -i http://localhost:8080/api/orders/ORD-1

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Token neu holen und issuer-uri mit Keycloak Realm abgleichen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: API liefert 403.

Wahrscheinliche Ursache: Token ist gueltig, aber Rolle fehlt.

Diagnose:

echo $TOKEN | cut -d. -f2 | base64 -d | jq .realm_access.roles
grep -R "hasRole" -n maven-project/runtime/src/main/java

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Benutzerrolle in Keycloak ergaenzen oder Endpoint-Regel korrigieren.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Prometheus findet Runtime nicht.

Wahrscheinliche Ursache: Runtime laeuft nicht, host.docker.internal fehlt oder Actuator nicht exponiert.

Diagnose:

curl http://localhost:8080/actuator/prometheus
curl http://localhost:9090/targets

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: management.endpoints exposure pruefen und target anpassen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Grafana zeigt keine Daten.

Wahrscheinliche Ursache: Datasource falsch oder Prometheus hat keine Targets.

Diagnose:

curl http://localhost:9090/api/v1/targets
docker compose logs grafana --tail=80

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Grafana Datasource URL http://prometheus:9090 pruefen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Maven Multi-Module Build bricht ab.

Wahrscheinliche Ursache: Modulabhaengigkeit falsch, Parent fehlt oder Version nicht konsistent.

Diagnose:

mvn -q -DskipTests package
mvn -pl runtime -am dependency:tree

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Parent POM und module Reihenfolge pruefen, keine zyklischen Abhaengigkeiten zulassen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Domain importiert Spring.

Wahrscheinliche Ursache: Architekturregel verletzt: Domain darf keine Framework-Klassen kennen.

Diagnose:

grep -R "org.springframework" maven-project/domain/src/main/java || true

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Import entfernen, Port im ports-Modul definieren und Adapter im adapters-Modul implementieren.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Docker Image baut nicht.

Wahrscheinliche Ursache: Jar fehlt, Dockerfile zeigt auf falschen Pfad oder Build vor Image fehlt.

Diagnose:

mvn -pl runtime -am package
docker build -f Dockerfile.runtime .

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Maven Build zuerst ausfuehren und COPY Pfad im Dockerfile pruefen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Kubernetes Pod startet nicht.

Wahrscheinliche Ursache: Env Vars, Image, DB URL oder Security Context falsch.

Diagnose:

kubectl describe pod <pod>
kubectl logs <pod> --tail=100

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: ConfigMap/Secret, readinessProbe und ImagePullPolicy pruefen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: OpenShift Route funktioniert nicht.

Wahrscheinliche Ursache: Service-Port oder Route-Ziel falsch.

Diagnose:

oc get route,svc,pod
oc describe route order-runtime

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Route auf richtigen Service-Port zeigen lassen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Backup ist unbrauchbar.

Wahrscheinliche Ursache: Dump wurde nicht verifiziert oder falsche DB gesichert.

Diagnose:

ls -lh backups/
pg_restore --list backup.dump | head

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Nach jedem Backup Restore-Probe oder mindestens Dump-Listing ausfuehren.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Restore ueberschreibt falsche Umgebung.

Wahrscheinliche Ursache: Zielkontext falsch oder DB Name verwechselt.

Diagnose:

echo $KUBECONFIG
kubectl config current-context
psql -c "select current_database();"

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Restore nur mit explizitem Kontext und Freigabe ausfuehren.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: Rate Limit blockiert Tests.

Wahrscheinliche Ursache: Test ruft Endpoint zu oft auf oder Filter ist fuer lokale Tests zu strikt.

Diagnose:

grep -R "RateLimitingFilter" -n maven-project/runtime/src/main/java
curl -i http://localhost:8080/actuator/health

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Testprofil mit hoeherem Limit nutzen oder Filter im Integrationstest gezielt konfigurieren.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.

Fehlerbild: PDF/HTML Link fuehrt ins Leere.

Wahrscheinliche Ursache: Datei wurde verschoben, aber Index nicht aktualisiert.

Diagnose:

python scripts/quality/check-links.py
grep -R "href=.*md" -n .

Erwartete Hinweise:
- Logs zeigen konkrete technische Ursache oder fehlende Verbindung.
- Statusseiten zeigen, ob Container, API oder Infrastruktur erreichbar sind.
- SQL- oder HTTP-Antworten helfen, zwischen Daten-, Broker-, Security- und Runtime-Problem zu trennen.

Loesung: Alle Markdown-Dateien zu HTML konvertieren und Links auf HTML zeigen lassen.

Warum das in echten Enterprise-Systemen passiert:
In verteilten Systemen liegt der Fehler selten nur an einer Klasse. Meist stimmen Umgebung, Konfiguration, Netzwerk, Schema, Token oder Betriebserwartung nicht zusammen. Deshalb ist Diagnose mit Befehlen wichtiger als reines Lesen von Code.

Praxis-Check:
1. Fehler absichtlich erzeugen.
2. Diagnosebefehle ausfuehren.
3. Ursache notieren.
4. Fix anwenden.
5. Gegenprobe ausfuehren.