chore(release): v0.961 — Playbook (runbooks déploiement, rollback, incident)

This commit is contained in:
senke 2026-03-02 19:09:46 +01:00
parent 65375a61aa
commit f692ebfd26
5 changed files with 189 additions and 0 deletions

View file

@ -0,0 +1,50 @@
# Runbook — Déploiement
## Prérequis
- Accès au registry Docker
- Variables d'environnement configurées (voir `.env.example`)
- Base de données migrée
## Étapes
### 1. Build images
```bash
docker build -t veza/backend-api:${VERSION} -f veza-backend-api/Dockerfile .
docker build -t veza/stream-server:${VERSION} -f veza-stream-server/Dockerfile .
docker build -t veza/web:${VERSION} -f apps/web/Dockerfile .
```
### 2. Push images
```bash
docker push veza/backend-api:${VERSION}
docker push veza/stream-server:${VERSION}
docker push veza/web:${VERSION}
```
### 3. Migrations
```bash
cd veza-backend-api
DATABASE_URL=postgres://... make migrate
```
### 4. Deploy
Suivant l'orchestrateur (Kubernetes, Docker Compose, etc.) :
- Mettre à jour les images dans les manifests
- Appliquer : `kubectl apply -f k8s/` ou `docker-compose up -d`
### 5. Vérification
```bash
curl -s https://api.example.com/health | jq
curl -s https://api.example.com/health/deep | jq
```
### 6. Rollback
En cas de problème : voir [ROLLBACK.md](ROLLBACK.md).

View file

@ -0,0 +1,27 @@
# Runbook — Graceful Degradation
## Comportement quand Redis est down
| Fonctionnalité | Comportement |
|---------------------|---------------------------------------|
| Rate limiting | Fallback in-memory (par instance) |
| CSRF | Désactivé ou 503 si strict |
| Sessions | Échec login / refresh |
| Cache | Cache miss systématique |
LAPI reste opérationnelle pour les requêtes qui ne dépendent pas de Redis. Les routes protégées peuvent échouer si les sessions sont en Redis.
## Comportement quand RabbitMQ est down
- Les jobs asynchrones (transcode, notifications, etc.) ne sont pas traités
- Les requêtes synchrones restent fonctionnelles
## Comportement quand S3/MinIO est down
- Upload de fichiers : échec
- Lecture de fichiers stockés : échec
- Le reste de lAPI fonctionne
## Health /health/deep
Le endpoint `/health/deep` indique létat de chaque dépendance (DB, Redis, RabbitMQ, S3, disk). Utiliser ce diagnostic pour identifier la dégradation.

View file

@ -0,0 +1,39 @@
# 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
- LAPI 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** : lAPI renvoie 503
1. Vérifier la connexion PostgreSQL
2. Consulter les logs Postgres
3. Vérifier lespace 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 lURL 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

35
docs/runbooks/ROLLBACK.md Normal file
View file

@ -0,0 +1,35 @@
# Runbook — Rollback
## Rollback image
### Kubernetes
```bash
kubectl rollout undo deployment/veza-backend-api
kubectl rollout undo deployment/veza-stream-server
kubectl rollout undo deployment/veza-web
```
### Docker Compose
```bash
docker-compose down
# Éditer docker-compose.yml : utiliser l'image de la version précédente
docker-compose up -d
```
## Rollback base de données
**Attention** : Les migrations down ne sont pas systématiques. Voir `docs/MIGRATION_CONSOLIDATION.md`.
Pour une migration récente, si un fichier `*_down.sql` existe :
```bash
psql $DATABASE_URL -f veza-backend-api/migrations/XXX_migration_down.sql
# Retirer la ligne correspondante de schema_migrations
psql $DATABASE_URL -c "DELETE FROM schema_migrations WHERE version = 'XXX_migration.sql';"
```
## Switch de trafic
Avec load balancer / ingress : pointer vers la version précédente des pods/containers avant rollback complet.

View file

@ -0,0 +1,38 @@
# Runbook — Rotation des secrets
## JWT_SECRET
1. Générer un nouveau secret : `openssl rand -base64 32`
2. Déployer avec lancien et le nouveau (dual-secret) si lapp le supporte
3. Sinon : maintenance window
- Mettre à jour `JWT_SECRET` dans le déploiement
- Redémarrer lAPI
- Tous les tokens existants sont invalidés (re-login requis)
## CHAT_JWT_SECRET
Même procédure que JWT_SECRET. Doit être synchronisé entre backend et chat/stream si partagé.
## OAUTH_ENCRYPTION_KEY
Utilisé pour chiffrer les tokens OAuth en DB. Rotation complexe :
1. Ne pas supprimer lancienne clé tant que des tokens chiffrés existent
2. Ajouter la nouvelle clé dans la config
3. Les nouveaux tokens utilisent la nouvelle clé
4. Après expiration des anciens tokens, retirer lancienne clé
## STREAM_SERVER_INTERNAL_API_KEY / INTERNAL_API_KEY
Doivent correspondre entre backend et stream server.
1. Générer : `openssl rand -hex 32`
2. Mettre à jour les deux côtés quasi-simultanément
3. Redémarrer backend et stream server
## DATABASE_URL
1. Créer un nouvel utilisateur avec un nouveau mot de passe en DB
2. Mettre à jour `DATABASE_URL` dans le déploiement
3. Redémarrer lAPI
4. Révoquer lancien utilisateur après validation