39 lines
1.4 KiB
Markdown
39 lines
1.4 KiB
Markdown
# 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
|