Rapport d'incident - 29 Mars 2018

Incident du : 28 Mars 2018 - 19:52 CEST (+02:00 UTC)

au: 29 Mars 2018 - 09:38 CEST (+02:00 UTC)

Bonjour,
 
Malgré tous nos efforts pour que de tels évènements n’arrivent pas, nous avons eu un incident majeur apparu dans la soirée d’hier, le 28 mars 2018 à 19h52 CEST (+02:00 UTC) qui n’a pu être résolu avant ce matin à 09h38 CEST (+02:00 UTC).
 
Sachez que nous comprenons parfaitement que cela a dû être très difficile de réaliser certaines de vos opérations et nous vous prions d’accepter toutes nos excuses pour tous les désagréments que cela a engendrés pour vous et pour vos équipes.
 
Nous souhaitions en toute transparence, revenir sur ce problème, vous l’expliquer dans le détail et vous dire ce que nous avons engagé pour qu’un tel problème n’arrive plus. 
 
Ce qui s’est passé : 
  • Microsoft Azure a « recyclé », comme c’est son droit, un ensemble de serveurs dont ceux assurant le routage de nos services.
  • Lors de cette opération et cette fois-ci spécifiquement, la configuration du serveur a été modifiée dans un sens qui n’était pas prévue.
  • Cette reconfiguration a rendu le service Java installé sur les serveurs portant les routeurs instables. 
  • Le résultat a été qu’aucun des serveurs pourtant redondants portant le service de routage n’a pu démarrer car ils ont été tous recyclés avec la même procédure.
  • Finalement tous les serveurs portant réellement nos applications cloud étaient fonctionnels, mais le service de routage qui permet d’accéder à nos services ne l’était pas.
  • Malheureusement ce problème s’est aggravé car la première alarme qui a été levée à ce moment-là par notre système de monitoring de notre cloud, l’a été sur un service secondaire au lieu de le faire sur le service de routage. 
  • Cette alarme a masqué pendant un temps bien trop long l’alarme principale qui aurait dû être traitée.
  • Même après la prise en charge du problème principal, les procédures existantes de redémarrage et de redéploiement des services n’ont pas fonctionné.
  • Il nous a fallu recréer un nouveau service de routage complet. Cette opération fut terminée ce matin à 09h38 CEST (+02:00 UTC).
 
Après une analyse du problème rencontré, nous avons décidé de :
  • Reconstruire une configuration du service de routage qui nous assurera que le service Windows déployé par Azure ne puisse plus influer sur le service Java nécessaire au service.
  • Reconfigurer notre système d’alarmes pour qu’une alarme majeure sur un service subalterne ne puisse plus nous empêcher de recevoir une alarme majeure sur notre service de routage.
  • Documenter une procédure de reconstruction du service pour qu’elle puisse éventuellement être exécutée dans un temps qui sera inférieur à 15 minutes, en cas d’une autre erreur amenant au même type d’indisponibilité du service de routage.  
 
Nous sommes sûrs que ces mesures permettront de ne pas reproduire une telle forme d’incident.
 
De plus et dans le but de vérifier si nous ne pouvons pas faire encore mieux que les premières mesures prises, nous avons aussi décidé de lancer plusieurs études pour voir si nous ne pouvions pas ajouter d’autres formes de redondances et de sécurité sur ce service de routage.
 
Nous sommes vraiment désolés de l’impact qu’a pu avoir pour vous cette panne d’un système pourtant assez simple et basique mais qui se trouve en frontal de toutes nos applications. Nous pouvons vous assurer que toutes nos équipes solutions, support, développement, qualité et production au-delà de bien évidement faire que des erreurs du même type ne puissent plus arriver, sont focalisées à faire tout leur possible pour que de tel évènements ne se produisent pas.

Bien cordialement, 

Patrick CHAUVEL
Chief Customer Officer

Retour à l'accueil