Liste de contrôle des meilleures pratiques pour les tests de charge

# Test de charge selon la mentalité d'un ingénieur fiabilité orienté performance - Commencez chaque test de charge par un objectif écrit, comme une latence p95 sous 300 ms à 500 requêtes par seconde, plutôt que par un vague "voir ce qui casse". - Écrivez les tests de charge sous forme de code avec k6, Gatling ou Locust et conservez-les dans le même dépôt que le service. - Modélisez un trafic réaliste à partir des journaux de production : le mélange des endpoints, les tailles de charge utile et le temps de réflexion entre les requêtes. - Utilisez un modèle de charge de travail ouvert avec un taux d'arrivée fixe lors du test des services exposés à Internet, car les modèles fermés masquent les délais de file d'attente. - Exécutez délibérément des types de tests distincts : test de fumée, test de charge au pic attendu, test de surcharge au-delà du pic, test de pointe, et un long test de trempage pour les fuites de mémoire. - Rapportez la latence en percentiles, au moins p50, p95 et p99, et ne vous fiez jamais à la seule moyenne. - Définissez des seuils de réussite ou d'échec dans le script de test afin que l'intégration continue puisse faire échouer le build automatiquement. - Exécutez les tests de charge contre un environnement semblable à la production avec les mêmes tailles d'instance, le même volume de données et la même configuration. - Préparez des données de test qui correspondent à la cardinalité de la production, car une base de données minuscule rend chaque requête rapide. - Chauffez les caches et les pools de connexions avant de mesurer, et excluez la période de chauffage des résultats. - Générez la charge à partir de machines avec suffisamment de marge CPU et réseau, et surveillez les propres métriques du générateur de charge. - Corrélez les résultats de test avec les métriques, traces et journaux côté serveur pour trouver le véritable goulot d'étranglement au lieu de deviner. - Suivez le taux d'erreur et les délais d'attente en plus de la latence ; une réponse rapide qui renvoie une erreur n'est pas un succès. - Modifiez une variable par exécution et enregistrez le commit, la configuration et l'environnement avec chaque résultat. - Exécutez un court test de fumée de performance à chaque merge sur main et la suite complète avant les versions majeures. - Comparez les résultats avec une référence stockée et signalez les régressions supérieures à un pourcentage convenu. - Simulez ou mettez en bac à sable les API tierces qui facturent par appel ou imposent des limites de débit, mais testez réellement vos propres dépendances. - Trouvez le point de rupture et documentez comment le système échoue : un rejet gracieux avec 429 ou 503 est mieux qu'un effondrement. - Vérifiez que l'autoscaling réagit à temps en augmentant la charge progressivement et en mesurant combien de temps prend la nouvelle capacité pour aider. - Annoncez les tests de charge à l'équipe et aux ingénieurs d'astreinte, et ne les pointez jamais vers des systèmes de production partagés sans approbation. - Transformez les résultats en plans de capacité avec des objectifs de marge clairs, comme fonctionner à au plus 60 pour cent de la limite testée.