Page "Etat du service ATRIUM" - Introduction

Bienvenue sur la page "État du service ATRIUM".

Vous trouverez ci-dessous des informations actualisées régulièrement concernant l'état du service ATRIUM. L'objectif est de vous tenir informés des actions en cours lorsque le service est perturbé, qu'il s'agisse d'opération de maintenance prévues ou d'incidents inopinés.


 

État du service ATRIUM

Bonjour,

Ce mercredi 7 juillet vers 7h00, nous avons connu un dysfonctionnement sur l'un des serveurs hébergeant les bases de données Atrium.
Le traitement de l'incident a débuté dès 7h30 pour rendre la base de données principale d'Atrium disponible à 10h00, par contre ses performances ont rendu l'application inexploitable jusqu’à 23h00.

Depuis ce mercredi 7 juillet 23h00, le service Atrium fonctionne de façon nominale.

La source de l'incident est identifiée. Les causes du temps de rétablissement anormalement long du service sont en cours d’analyse (les différentes procédures auraient dû permettre de rétablir de service en moins de 2 heures)
Les actions préventives et correctrices nécessaires seront mis en place dans le cadre d'Atrium 2.

Nous sommes conscient de la gêne occasionnée et mettons tout en œuvre pour offrir un service de qualité.

L'équipe ATRIUM
La nouvelle version 1.22.5 d'ATRIUM a pu être correctement installée le 09 octobre 2020 entre 16h et 18h.
Voir la note de version.
Quand : Mardi 08/12/2020 entre 9h et 10h

Nature de l'incident : Surcharge ponctuelle de la base de données qui a causé un engorgement sur la plateforme.
Vous avez pu constater de ralentissements et erreurs inopinées durant cette période.

Cause de l'incident : Nous avons réaliser une importante collecte de statistiques sur le serveur de base de données dans le cadre d'un audit visant à augmenter ses capacités. Nous avons volontairement réaliser cette opération en production, sur une période de forte affluence, pour être en conditions réelles.
La charge générée par la production des traces nécessaires à la production de ses statistiques a été trop importante pour le serveur, ce qui a ralenti ses temps de réponse.

Nous disposons désormais de nombreuses informations qui vont pouvoir être analysées.

Statut : Cet incident est clos.
Nous avions réagi en urgence la semaine dernière en bloquant le trafic émis depuis l'étranger sur ATRIUM pour stopper de multiples connexions visant à fragiliser le service.
Nous avons pu depuis affiner la configuration des firewalls (notamment les systèmes anti-DDOS) pour bloquer plus spécifiquement les connexions anormales et ainsi réouvrir le trafic émis hors de France.

Nous n'avons plus constaté de perturbation sur la plateforme depuis.
Quand : Mardi 01/12/2020 entre 18h50 et 19h20

Nature de l'incident : Nous avons subi une attaque de type "slow loris" de plus grande ampleur que celle suspectée ce matin.
Les adresses IP impliquées proviennent de l'étranger.

Intervention réalisée : Afin de rétablir le service en urgence nous avons bloqué à l'accès à toutes les adresses IP provenant de l'étranger en attendant d'être en mesure de déployer un blocage plus ciblé.
Quand : Lundi 1er décembre 2020 entre 9h et 14h30

Nature de l'incident :
Le service a été fortement perturbé entre 9h et 14h30 aujourd'hui.
L'équipe technique a pu identifier cette fois-ci une activité anormalement importante depuis quelques adresses IP laissant penser à une possible attaque visant à déstabiliser la plateforme.

Interventions réalisées :
  • des actions manuelles ont été réalisées pour interdire l'activité des adresses identifiées ;
  • la configuration du mécanisme de protection contre les attaques DDOS du firewall a été revue ; 
  • une expérimentation avec un nouveau firewall applicatif a été lancée sur les environnements de pré-production pour valider que celui-ci n'interfère pas avec les usages attendus d'ATRIUM ; si l'expérimentation est positive le dispositif sera déployé en production.

Statut de l'incident : sous surveillance.
L'activité identifiée nous semble clairement anormale, mais il est trop tôt pour dire si elle peut expliquer à elle seule les perturbations que nous connaissons ces derniers temps. Nous poursuivons la surveillance et les travaux en cours pour sécuriser le service.

Remarque : le service a été à nouveau perturbé entre 16h25 et 16h45. Il s'agit d'une erreur humaine de notre part liée à une des interventions sur la plateforme et non à une nouvelle occurence du problème connu ces derniers temps.
Point de situation sur les ralentissements et coupures de service :
  • De Jeudi 19 novembre à Dimanche 22 novembre, nous n'avons pas constaté de problème de disponibilité ou de temps de réponse (vous pouvez constater très ponctuellement des lenteurs, mais dans l'ensemble les indicateurs de la plateforme sont bons)
  • Lundi 23 novembre nous avons subi une coupure du service de 16h à 17h
  • Ce jour, Mardi 24 novembre, nous avons subi plusieurs perturbations :
    • de 9h à 9h12 le service a été interrompu (il s'agit d'un évènement isolé lié à un défaut de redémarrage des serveurs)
    • de forts ralentissements entre 10h et 11h30, suivi d'une interruption du service jusqu'à 12h10
    • une nouvelle interruption de service entre 13h45 et 14h45
    • la situation est revenue à la normale à 14h45 et aucun nouvel incident n'a été constaté depuis (ce billet étant rédigé à 19h15)

Actions en cours :
  • L'analyse des données déjà disponibles est effectuée en continue. Nous ne sommes pas parvenus à ce stade à identifier le composant qui déclenche le problème. Nous observons une charge tout à fait acceptable sur l'ensemble des composants avant une explosion soudaine de la charge qui déclenche la coupure de service ; il n'est donc pas évident à ce stade que ce soit un problème de surchage lié au volume d'utilisation. De plus, la survenue des incidents ne correspond pas aux pics d'utilisation.
  • L'installation des nouveaux outils de monitoring sur les infrastructures de production se poursuit
  • Un audit du serveur de base de données par une équipe d'experts va être programmée très prochainement.

Statut de l'incident : en cours.



 
Quand : 
  • Le 17/11/2020 17h30
  • Le 18/11/2020 11h00

Nature de l'incident : Panne du portail ATRIUM. 
La navigation a pu être fortement perturbée et ralentie avant que le portail ne soit plus accessible.
Le serveur d'authentification n'ayant pas été affecté, l'authentification directe sur les services tiers restait possible.

Interventions réalisées :
  • Lors de chacun des 2 arrêts de service, le redémarrage des serveurs a permis de rétablir le service.
  • Les données d'usages et les métriques des différents serveurs sont en cours d'analyse pour déterminer la cause du problème.
  • Modernisation des outils de supervision de l'infrastructure pour disposer d'informations plus complètes sur l'activité des serveurs, ce qui devrait nous permettre de diagnostiquer plus rapidement les causes des incidents (ce chantier a été entrepris il y a plusieurs mois ; nous accélérons la mise en oeuvre des nouveaux outils pour nous aider dans le rétablissement de la qualité du service ).

Statut de l'incident : en cours.

Lors des deux évènements nous avons constaté un ralentissement de la plateforme qui déclenche très rapidement une réaction en chaîne (les requêtes utilisateurs étant traitées moins rapidement, elles s'accumulent, augmentant la charge des serveurs, ce qui ralentit le traitement des requêtes...).
Nous constatons également depuis la rentrée des vacances de la Toussaint une forte augmentation des usages sur ATRIUM ; il est trop tôt pour dire si cette augmentation du trafic est la cause directe des coupures de service.
Quand : Entre le 09/11/2020 et le 16/11/2020 

Nature de l'incident : le serveur d'authentification (serveur CAS) d'ATRIUM a cessé de fonctionner à plusieurs reprises durant cette période.
Lorsque le serveur n'était pas disponible, les utilisateurs n'avaient plus la possibilité de s'authentifier sur ATRIUM (un message d'erreur apparait sur la mire d'authentification) ; de plus le surcroit d'activité lié aux tentatives de connexion en erreur perturbait également l'activité des utilisateurs déjà connectés.

Interventions réalisées :
  • Le serveur a été systématiquement redémarré manuellement pour rétablir le service en parallèle des recherches de la cause du problème
  • Une fuite mémoire sur le serveur, probablement liée à l'augmentation du nombre d'authentifications, causait une saturation de la mémoire et donc le crash du serveur. Le 16/11/2020 la configuration mémoire du serveur a été revue ; nous n'avons plus constaté de dysfonctionnement de ce composant depuis.

Statut de l'incident : nous espérons avoir résolu cet incident ; l'activité du serveur d'authentification va rester en observation pendant les jours à venir pour confirmer le retour à la normale.

Affichage des résultats 1 - 9 parmi 9.