Retour sur l’incident du 30 septembre 2016

TL;DR

À partir de 00h05 CEST le 30 septembre 2015, notre infrastructure a été coupée d’Internet : toutes les requêtes vers vos applications expiraient.
Le problème a été résolu à 01h40 CEST.
Il s’agissait d’un incident réseau externe, côté fournisseur d’infrastructure, et non d’un problème lié à notre plateforme.

Chronologie détaillée des événements

À 00h05 CEST, le téléphone de Léo (notre CTO) sonne. Pas une sonnerie classique, mais une alerte PagerDuty indiquant qu’un problème est survenu sur la plateforme.
Après une rapide analyse, il apparaît clairement qu’il s’agit d’un problème réseau, et non d’un souci lié à notre stack logicielle. Nous devons donc contacter le niveau inférieur : notre fournisseur d’infrastructure.

Ce n’est pas un secret : nous n’utilisons pas un cloud public comme Amazon Web Services ou Google Cloud (qui ne sont d’ailleurs pas exempts d’incidents non plus).
Nous avons fait le choix de nous appuyer sur un acteur français plus petit, disposant de deux datacenters à Paris et Strasbourg.
Ce choix nous permet de mieux maîtriser le rapport coût/performance, et aussi parce que nous connaissons bien cette équipe (oui, on leur répète régulièrement que leur site devrait aussi être en anglais 🙂).

À 00h10 CEST, nous contactons leur support — en réalité des ingénieurs, eux aussi réveillés en urgence.
Ils confirment que le problème est global et impacte plusieurs de leurs clients, et que leurs équipes sont en train d’intervenir. Très bien.

Commence alors une période « dans le noir ».
Un moment frustrant où nous sommes impuissants : impossible d’agir, simplement attendre que notre infrastructure retrouve l’accès réseau.
Comme aucun problème n’affectait notre propre infrastructure, les applications et bases de données continuaient de fonctionner normalement.
Relancer leur équipe n’aurait rien changé : le problème était identifié, et la pression était déjà maximale pour tout le monde.

À 00h30 CEST, nous recevons une première hypothèse : le problème pourrait provenir d’un routeur BGP bloquant le trafic, isolant ainsi notre infrastructure.
Mais aucune solution immédiate — et la tension monte.

À 01h00 CEST, nouvelle information : la cause réelle n’est finalement pas le routeur BGP, mais un pare-feu / load balancer situé juste après.
Une solution de contournement est en cours de mise en place pour rétablir le service au plus vite.

Ce n’est qu’autour de 01h40 CEST que nos serveurs retrouvent l’accès à Internet et que l’ensemble des applications et de la plateforme redevient accessible.
D’après les informations fournies par notre prestataire, l’incident provenait de leurs load balancers (situés en amont de notre infrastructure).
Ceux-ci ont été contournés temporairement afin de rétablir la connectivité, avant un retour à la configuration normale une fois le problème définitivement corrigé.

Qu'avons-nous appris

Tout d'abord, notre système de notification d'urgence fonctionne très bien, quelques minutes après que le problème se soit déclaré, quelqu'un était éveillé, prêt à prendre les choses en main. C'est un bon point, même si nous le testons, il est essentiel qu'une telle alarme fonctionne correctement dans des situations réelles.

Ensuite, dans le monde de l'hébergement, nous nous sommes positionnés dans le domaine de la Plateforme en tant que Service. Cela signifie que nous 'utilisons' un fournisseur d'infrastructure, installons notre pile logicielle et fournissons un service aux clients afin de faciliter leur vie, le choix de ce fournisseur d'infrastructure. À la question “travaillons-nous avec les bonnes personnes ?”, nous répondons oui. Le contrat que nous avons signé avec eux mentionnait ce qui suit :

• Aucun temps d'arrêt ne dépassera 4h

• Aucun temps d'arrêt ne dépassera 12h par an

Jusqu'à présent, ces deux conditions ont été respectées et nous n'avons jamais été proches d'elles. Aucun fournisseur d'infrastructure n'est exempt de problèmes, Google Cloud et Heroku ont eu un temps d'arrêt d'environ 1h ces dernières semaines, mais il est important pour nous d'expliquer cet échec ouvertement et rapidement.