Ce matin certains d'entre vous ont eu des ralentissements dans certaines pages du backoffice entre 10h00 / 10h15 et entre 11h00 / 11h15.
En fait nous avons procédé à des tests sur l'architecture pour identifier un bug que nous avons rencontré à 2 ou 3 reprises ces 12 derniers mois.
En fait nous avons procédé à des tests sur l'architecture pour identifier un bug que nous avons rencontré à 2 ou 3 reprises ces 12 derniers mois.
De quoi s'agit-il exactement ?
Lorsqu'un serveur plantait, les temps d'accès au back office s'envolait alors que tout est prévu pour que cela n puisse pas les impacter.
Lorsqu'un serveur plante, il est automatiquement retiré de la liste des serveurs disponibles. C'est identique pour les services, en fait pour les services qu'il fait tourner. Si un service plante nous sommes notifié, bien sur, et le service retiré automatiquement de la liste des services disponibles.
Lorsqu'un serveur plante, il est automatiquement retiré de la liste des serveurs disponibles. C'est identique pour les services, en fait pour les services qu'il fait tourner. Si un service plante nous sommes notifié, bien sur, et le service retiré automatiquement de la liste des services disponibles.
Alors pourquoi ?
Le backoffice fonctionne pareil, il utilise une liste de serveurs dispo mise à jour en temps réel mais également une liste de services également mise en temps réel.
C'est cette dernière qui n'était pas correctement implémenté pour un des nombreux services utilisés. Le problème était sournois car lorsque le service était éteint cela fonctionnait correctement. il fallait que la machine soit "plantée" pour constater ce bug et pour corser le tout, il n'était pas reproductible mais aléatoire...
C'est cette dernière qui n'était pas correctement implémenté pour un des nombreux services utilisés. Le problème était sournois car lorsque le service était éteint cela fonctionnait correctement. il fallait que la machine soit "plantée" pour constater ce bug et pour corser le tout, il n'était pas reproductible mais aléatoire...