Que fait le cybermarché Thortful pour se préparer à la Saint Valentin ?

Les cartes de vœux sont une activité saisonnière. La Saint Valentin, la fête des Mères et la fête des Pères sont de très grosses journées chez Thortful. Nous avons des milliers d'utilisateurs sur notre site en même temps et le nombre de recherches par minute est multiplié par 30. 

En tant que cybermarché du segment entreprise-consommateur, avec de petits paniers, la fidélité des clients est fondamentale à notre réussite. Le site web doit apporter une bonne expérience pour que les clients reviennent. Il est vital de trouver les problèmes et de les résoudre rapidement ; il nous faut comprendre où, comment et pourquoi les clients sont impactés. Et nous faisons tout ce que nous pouvons du côté technologique pour que cela soit possible.

Nous vous présentons ici certaines stratégies que nous suivons pour assurer les performances de la plateforme et une expérience client sans accroc pendant les pics de trafic.

Monitoring des métriques clés pour l'expérience client

Je ne veux pas que ce soit les clients qui nous signalent les problèmes. Je veux être le premier à en être informé. Dans ce but, nous faisons tout évoluer préventivement pour les pics de trafic. Nous observons proactivement tout ce que nous pouvons suivre : le taux de conversion et les temps de réponse de l'application web aux API. Ces métriques m'indiquent si nous respectons nos promesses. Nous suivons scrupuleusement le nombre de passages à la caisse par seconde dans les jours précédant le grand jour de la Saint Valentin.

L'un des avantages du cloud avec Amazon Web Services (AWS) c'est vraiment la grande facilité avec laquelle on peut passer à l'échelle supérieure (clusters, modèles autoscale), de telle sorte que lorsque le trafic augmente, tout évolue avec lui. Du point de vue numérique, nous pouvons grandir ou rapetisser autant que nous le voulons. Tout ce qu'utilisent les consommateurs qui viennent sur le site doit avoir un temps de réponse de moins de 100 millisecondes. Nous faisons le suivi à la milliseconde près — et tout mouvement en millisecondes aide les conversions. Techniquement, nous sommes aussi bons que le dernier passage à la caisse.

L'observabilité a été un élément important de la croissance de notre stratégie de mise sur le marché. Il y a cinq ans, nous étions trop petits pour effectuer des tests de charge ou de performance. Chaque année, nous apprenions sur le tas. Cela nous a rendus très prudents en ce qui concerne les produits, car nous ne savions jamais ce qui allait casser. New Relic est très fort pour nous aider à résoudre les problèmes en plein vol. Nous pouvons les localiser dans le système grâce au tracing distribué, qui permet à notre équipe de capturer, visualiser et analyser facilement les traces des différents services qui font partie de notre architecture.

Test de nouveaux médias et utilisation des données pour comprendre le RSI

Le défi des campagnes de marketing (surtout quand on commence avec un tout nouveau canal, ou que l'on fait de la télévision ou de la radio) vient du fait qu'en quelques secondes, nous avons un afflux de trafic. Cela met de la pression sur le stack. Pour le suivi de l'entonnoir, nous utilisons des outils tels que Google Analytics pour suivre la conversion du secteur d'une page à l'autre. Tout ce que nous faisons en termes d'expérimentation sur site et de tests publicitaires passe par ce type d'outil de suivi. 

En ce qui concerne la technologie pure, notre fonctionnalité de recherche est une métrique clé que nous surveillons. En règle générale, chaque personne qui arrive sur notre site effectue au moins une recherche. C'est essentiel pour la conversion et la réussite du panier. Les passages à la caisse sont également importants. Nous passons d'un passage à la caisse par seconde à 30 par seconde les jours de forte affluence. Même si la valeur de chaque panier est faible, si on multiplie cela par 20 chaque seconde, cela revient à 1 200 paniers par minute. Le résultat est important. Il nous faut une vision suffisamment granulaire pour savoir que chaque composant fait son travail et donne le meilleur de lui-même. Ces informations ont été essentielles à notre évolution, et chaque année, nous avons obtenu une croissance record. Nous monitorons toutes ses métriques dans New Relic.

Automatisation des alertes avec les données

Je suis un fervent partisan de l'automatisation. En tant qu'ingénieurs, nous devons être le plus paresseux possible lorsqu'il s'agit de tâches répétitives. Si l'on fait quelque chose plus de deux fois, il faut envisager l'automatisation. Nous avons automatisé des alertes et des notifications textuelles pour nous avertir en cas de problème avec nos lignes de base, comme le temps de réponse. Un ingénieur de premier contact s'en charge, puis, selon la complexité de l'incident, il passe du frontend au backend et aux ingénieurs principaux, si nécessaire. Une fois que nous sommes alertés, nous nous concentrons sur l'incident et analysons le temps de réponse pour voir quel service est affecté. Les logs en contexte nous permettent de voir la ligne de log exacte où se situe le problème, mais aussi de faire la corrélation avec d'autres points de données pertinents. Il n'est plus nécessaire de changer d'écrans ou d'outils pour consulter les journaux en cas de problème.

Dès que nous sommes dans le vert pour une métrique, nous plaçons une alerte. Nous utilisons les alertes pour tout surveiller, des clusters de bases de données aux serveurs web. Nous suivons toutes les références de base, y compris Core Web Vitals, avec les dashboards de New Relic. Nous les utilisons comme seule source factuelle pour visualiser les tendances et prendre le pouls de notre activité. Nous donnons à notre équipe une vue réelle sur le fonctionnement de ses systèmes. On ne peut pas faire mieux. 

Nous sommes arrivés à un point où nous savons ce qu'il faut faire évoluer. Avec les microservices, nous commençons à faire évoluer nos capacités de recherche ou celles qui sont plus anciennes à différents endroits et niveaux. Si nous perdons une minute de disponibilité sur le site web, c'est énorme. Nous voulons limiter les risques le plus possible. 

Amélioration des temps de réponse des bases de données

Nous avons eu des problèmes avec nos bases de données qui ne renvoyaient pas les réponses aux requêtes à temps. Nous nous sommes concentrés sur la requête et New Relic a aidé nos ingénieurs à l'optimiser dans l'APM avec Java. 

Nous pouvons désormais creuser dans ce qui se passe et voir le point de terminaison grâce au tracing distribué. Si nous avons un problème dans notre stack, il est très utile de tout avoir dans un seul système et de voir les dépendances de service de bout en bout, puis d'évaluer si cela peut impacter nos clients. Nos logs reviennent avec l'intelligence qu'il nous faut, comme un outil d'analyse des causes racines, de telle sorte que je peux réellement tout regarder. Il arrive parfois que nous trouvions que le problème est ailleurs ou qu'il faut que nous changions notre façon de faire. À d'autres moments, nous nous rendons compte que l'emplacement du logging des erreurs n'est pas optimal. 

Nous utilisons aussi New Relic pour effectuer des tests techniques. Nous avons un ensemble de points de terminaison sur notre chemin critique. Si l'un d'eux n'est plus disponible, nous savons que quelque chose ne va pas. Nous exécutons deux ou trois scripts synthétiques différents qui observent l'utilisateur final et son interaction avec le site et nos API. Il est important pour nous de voir ces éléments techniques du point de vue de l'utilisateur, nous pouvons même voir les vulnérabilités de sécurité de tout notre stack juste à côté des performances du système, au même endroit. New Relic nous aide à nous concentrer sur les métriques qu'il faut pour assurer l'expérience positive de nos clients.