Les opérations en production pour les API REST réussissent quand elles sont ennuyeuses : déploiements prévisibles, comportement observable, diagnostic rapide et récupération rapide. Ce guide vous fournit une liste de vérification pratique, étape par étape, que vous pouvez exécuter dans de vrais environnements. Il inclut des motifs de configuration concrets, des commandes de validation, des résultats attendus, des manuels d'intervention pour les modes de défaillance, et une routine d'opérations répétable du quotidien au mensuel. Toutes les valeurs, seuils et sorties de commandes dans cet article sont des exemples construits. Adaptez-les à vos charges de travail et à votre tolérance au risque. ## Inventaire des versions et de l'environnement Vous ne pouvez pas opérer ce que vous ne pouvez pas nommer. Avant tout changement, collectez les versions exactes, la topologie et les dépendances critiques de l'API. Stockez cet inventaire dans un emplacement versionné accessible aux opérations et aux développeurs.
| Élément | Valeur d'exemple (construite) | Comment vérifier |
|---|---|---|
| Runtime | Node.js v18.19.1 | node -v |
| Build API | v1.7.3 commit 3f2a9c1 | grep VERSION .env && git rev-parse --short HEAD |
| OS | Ubuntu 22.04 LTS | lsb_release -a ou cat /etc/os-release |
| TLS | Let's Encrypt, expire 2026-03-01 | openssl s_client -connect api.example.com:443 -servername api.example.com < /dev/null 2>/dev/null | openssl x509 -noout -dates |
| Moteur DB | MongoDB 6.0 primaire en région A | mongod --version && mongo --eval 'db.hello()' |
| Dépendances | express 4.18, mongoose 7.x | npm ls --prod --depth=0 |
| Tiers | Stripe, API OpenAI | Vérifier les clés d'intégration et les endpoints |
| Endpoints santé | /healthz, /readyz, /version | curl -fsS https://api.example.com/healthz |
| Sync temps | NTP actif | timedatectl status |
| Métrique | Cible (construite) | Alerte quand |
|---|---|---|
| Disponibilité (2xx, 3xx) | >= 99.9% glissant 30 jours | < 99.5% sur 1 heure |
| Latence p95 (GET) | <= 200 ms | > 400 ms pendant 15 min |
| Latence p95 (POST) | <= 500 ms | > 800 ms pendant 15 min |
| Taux d'erreur (5xx) | < 0.5% | > 2% pendant 10 min |
| Utilisation connexions DB | < 80% | > 90% pendant 5 min |
| Symptôme | Cause probable | Premières corrections | Vérifier la récupération |
|---|---|---|---|
| Pic de 5xx sur POST | Panne dépendance (paiements, API ML) | Activer circuit breaker ou file d'attente ; réduire timeout à 3 s avec 2 réessais ; servir 202 Accepted avec ID de job en file | Taux d'erreur sous 0.5% ; profondeur file se stabilise |
| Beaucoup de réponses 429 | Limite de taux agressive | Augmenter le bucket par clé pour clients de confiance ; ajouter capacité de burst ; communiquer les limites | Latence p95 stable ; ratio 2xx augmente sans saturation |
| Latence p95 lente | Contention DB ou index manquant | Ajouter index, augmenter pool DB pour correspondre CPU, revoir requêtes N+1 | p95 revient à la cible ; temps de verrou DB baisse |
| Croissance mémoire sur heures | Fuite ou caches non bornés | Plafonner taille cache, auditer corps de requêtes, redémarrer avec heap dump | Utilisation heap se stabilise ; pauses GC normales |
| Erreurs TLS chez clients | Certificat expiré ou chiffrements faibles | Renouveler cert ; forcer TLS 1.2+ ; corriger mismatch SNI | Handshakes réussis ; pas de nouvelles alertes TLS |
| Épuisement threads/sockets | Slowloris ou timeouts trop longs | Réduire headersTimeout ; définir maxRequestsPerSocket ; activer limites taille requête | Nouvelles connexions réussissent ; 5xx dus au timeout chutent |