Le marketing lance une campagne vendredi qui pourrait amener vingt fois le trafic normal. Comment vous préparez-vous ?

Faites un test de charge sur un modèle réaliste du trafic de la campagne pour trouver le vrai goulot d'étranglement, qui est en général la base de données ou une dépendance tierce plutôt que la couche applicative. Augmentez la capacité et les quotas de compte à l'avance, puisque l'autoscaling réagit trop lentement pour un pic, préchauffez les caches et les pools de connexions, et mettez en place de la limitation de débit et de la dégradation gracieuse pour que la surcharge délestre au lieu de s'effondrer. Décidez d'avance ce que vous couperez si ça tourne mal.

D'abord je veux la forme, pas seulement le multiplicateur. Vingt fois étalé sur une journée, c'est un problème complètement différent de vingt fois qui arrivent en quatre-vingt-dix secondes quand un e-mail part. Ensuite je fais un test de charge avec un mélange réaliste de requêtes sur un environnement dimensionné comme la production, parce que le goulot n'est presque jamais la couche web, ce sont les connexions à la base, un verrou sur une ligne très sollicitée, ou une API tierce avec sa propre limite de débit qu'on ne contrôle pas. Ce que le test fait ressortir est corrigé ou reçoit de la capacité. Avant l'événement je monte en charge manuellement plutôt que de faire confiance à l'autoscaling, parce que la mise à l'échelle réagit avec plusieurs minutes de retard et le pic sera passé ou le site sera tombé d'ici là, et je vérifie les quotas au niveau du compte parce que c'est un mur classique au pire moment. Les caches et les pools de connexions sont préchauffés. Puis le plan de dégradation : limitation de débit par client, les fonctionnalités non essentielles comme les recommandations échouent en douceur, et on décide d'avance ce qu'on coupe pour protéger le paiement. Et quelqu'un surveille en direct, avec le chemin de retour arrière déjà validé.