# Runbook — Incident Response

## API down

1. Vérifier `GET /health` et `GET /health/deep`
2. Consulter les logs : `kubectl logs -l app=veza-backend-api --tail=200`
3. Vérifier DB, Redis, RabbitMQ (voir health/deep)
4. Redémarrer les pods si crash loop : `kubectl rollout restart deployment/veza-backend-api`
5. Rollback image si régression récente : [ROLLBACK.md](ROLLBACK.md)

## Redis down

- L’API peut fonctionner en mode dégradé (voir [GRACEFUL_DEGRADATION.md](GRACEFUL_DEGRADATION.md))
- Vérifier : `redis-cli ping`
- Redémarrer le service Redis ou le pod
- Vérifier la persistance (AOF/RDB) si perte de données

## DB down

- **Critique** : l’API renvoie 503
1. Vérifier la connexion PostgreSQL
2. Consulter les logs Postgres
3. Vérifier l’espace disque
4. Redémarrer Postgres si nécessaire
5. Pas de rollback migration automatique sans procédure validée

## Webhook failed

1. Consulter les logs du service appelant (ex. Stream server callbacks)
2. Vérifier `X-Internal-API-Key` et `STREAM_SERVER_INTERNAL_API_KEY`
3. Vérifier que l’URL du webhook est correcte
4. Réessayer manuellement si idempotent

## DDoS / trafic anormal

1. Activer le rate limiting (Redis requis pour distribué)
2. Vérifier les règles WAF / Cloudflare si applicable
3. Scaler horizontalement si charge légitime
4. Bloquer les IP abusives au niveau load balancer / firewall