Ce jeudi 9 novembre 2017 au matin, une panne géante a affecté l’hébergeur OVH avec pour conséquence la mise hors-service de nombreux sites web. Le service Jamespot – comme les services de nombreuses sociétés – a été impacté par cette panne, rendant l’accès aux plateformes indisponible. Le service a été rétabli au fur et à mesure de la journée, pour au final revenir à la normale aux alentours de 17h30. 

Nous sommes désolés pour la gène que cette panne aura occasionnée auprès de tous nos utilisateurs. Nous avons donc décidé de partager avec vous le film de la journée du point de vue de Paul Giraudon, notre directeur technique. 

Hier, à partir de 8h13, nous avons commencé à recevoir des alertes en provenance de nos systèmes de monitoring.

À 8h28 la situation était la suivante : à l’exception d’un serveur d’application et de 2 serveurs d’archives, tous les serveurs d’applications sont vus comme éteints. Les 2 serveurs d’archives de données sont chez Free, tous les autres sont chez OVH.

Dans cette situation, nous avons deux causes pouvant être à l’origine de cette situation :

  • Soit le monitoring est tombé en panne (c’est rare, mais ça reste le cas le plus fréquent heureusement) ;
  • Soit le problème vient d’OVH. 

Très rapidement, en vérifiant les accès nous validons la deuxième option : OVH subit une panne massive

Nous décidons donc d’attendre le rétablissement de la situation par OVH.

Dès lors, nous prévenons le support interne de Jamespot et nous préparons à répondre aux appels des clients qui ne manquent pas d’affluer.

Nous décidons ensuite de réunir toute l’équipe pour se préparer et agir au mieux dans ce contexte de crise. Ensemble, nous activons nos procédures de prévention des administrateurs des instances (plateformes) situées sur les serveurs d’applications en panne et plus généralement nous publions l’information sur notre Twitter officiel.

Pendant 2 heures, rien ne change côté OVH. C’est long… 

De notre côté, nous lançons une vérification manuelle des archives disponibles chez Free, avec un retour positif : nous disposons bien de copies valides de chaque plateforme effectuée vers 3 heures du matin sur les serveurs d’application.

En parallèle, nous améliorons nos procédures de prévention : la liste des administrateurs de plateformes était mise à jour de façon manuelle, et nos listes sont donc incomplètes. Il faut y ajouter manuellement les derniers administrateurs des dernières plateformes, qui ne sont pas encore déclarés. Du coup, nous en profitons pour automatiser la mise à jour de ces listes.

Le rétablissement est ensuite progressif dans les heures qui suivent : certains serveurs redeviennent à nouveau accessibles. Nous pouvons alors valider qu’ils n’ont pas été touchés par l’incident. Ils étaient « simplement » inaccessibles derrière les routeurs éteints d’OVH, et les plateformes sont de nouveau immédiatement opérationnelles.

En revanche, d’autres serveurs ont été coupés physiquement. Il faut alors rétablir le service qui ne s’est toujours remis correctement en place, ou reconnecter les interfaces réseaux qui n’étaient plus correctement reliées pour rétablir un service complet vers 17h30.

Une communication de fin d’incident est envoyée aux administrateurs et sur Twitter

Nous sommes désolés de la gène occasionnée pour ceux d’entre vous que cela a touché le plus longtemps. Cette panne est exceptionnelle et notre fournisseur OVH a pris la mesure de l’incident avec des réponses techniques et organisationnelles adaptées. Il garde toute notre confiance. Restant à ce jour l’opérateur le plus fiable et le plus compétitif.

Cet incident nous a permis d’améliorer un de nos process (celui de la gestion des alertes). Ce que nous essayions de faire à chaque fois pour s’adapter et progresser dans le service au quotidien.

Il nous reste maintenant à revenir vers les clients impactés pour appliquer les clauses du SLA.

En vous souhaitant à tous une meilleure journée que celle passée hier.

Paul GIRAUDON.