Chez Fasterize, la transparence est une valeur essentielle et c’est pourquoi nous voulions partager avec nos clients, partenaires et futurs clients notre post mortem suite à l’indisponibilité d’un de nos hébergeurs ce jeudi 04/07/2013.
Nous pensons que c’est un gage de confiance que de mettre à disposition de chacun ce que nous avons vécu, comment nous l’avons traité et ce que nous en avons tiré comme moyen d’amélioration.
Description de l’incident
L’indisponibilité du datacenter DC2 de Iliad / Online a rendu indisponible une partie de la plateforme Fasterize, rendant le service inopérant.
Cette indisponibilité est due à une coupure de courant dans le datacenter de DC2 de Illiad / Online (plus d’infos : https://twitter.com/online_fr/)
Faits et Timeline
Une coupure de courant est apparue a 11h22 au DC2 d’Online.
Il a été détecté à 11h22 par notre système de monitoring via des alertes d’indisponibilité d’une partie des machines (fronts, proxys, storage et graphing)
A 11h24 nous sommes alertés suite à la multiplication des alertes de notre système de monitoring.
La bascule DNS (assurée par Cedexis) a joué son rôle et redirigé l’ensemble du trafic vers les origines (modulo 3 clients mal configurés + le site Fasterize …) by-passant la plateforme Fasterize.
A 11h40, nous constatons qu’un de nos clients a aussi des serveurs hébergés dans le même datacenter. Cela explique pourquoi ce site géré par Fasterize est aussi en partie indisponible.
A 11h45, nous intégrons www.fasterize.com sur notre système de bascule DNS, comme les autres clients ; www.fasterize.com redevient disponible. Les cordonniers sont toujours les plus mal chaussés …
A 11h50, détection des noms de domaine secondaires qui ne sont pas gérés par la bascule DNS. A priori, aucun impact.
A 11h56, une partie des machines est revenue et le système de bascule DNS a donc renvoyé l’ensemble du trafic sur la plateforme. Seul un proxy fonctionne et notre storage restant indisponible, le service n’est pas complètement fonctionnel.
Vu que le service n’est pas complètement opérationnel, nous décidons de re-basculer l’ensemble du trafic sur les origines le temps que les machines encore impactées reviennent à la vie.
A 11h57, nous twittons sur la situation.
A 12h02, nous basculons manuellement le trafic vers les origines via le portail Cedexis.
Vers 13h10, la dernière machine down est de retour sur le réseau mais nous vérifions que tout est ok de notre côté avant de repartir.
Vers 14h, nous détectons que certains clients n’ont pas une bonne configuration DNS et font pointer leur nom de domaine sur la plateforme en direct.
A 14h05, nous redémarrons certains process de l’engine pour forcer la reconnexion au storage.
A 14h10, le trafic est redirigé sur la plateforme. Tout est revenu à la normale.
Quelques métriques
- Niveaux de sévérité de l’incident : 1 (arrêt du site non planifié qui affecte un nombre significatif d’utilisateurs)
- Time to detect : 2min
- Time to resolve : 2h48min
Impacts
Sur nos client (en terme d’usage et d’image)
Seuls 3 clients ont été impactés tout au long de l’incident car ils ne bénéficiaient pas de la bascule DNS automatique suite à une mauvaise configuration de leur DNS.
Sur Fasterize
Le site web www.fasterize.com a été indisponible jusqu’à 11h45 + propagation DNS. L’enregistrement DNS de www.fasterize.com lui aussi était mal configuré …
Un tweet a été envoyé à 12h15 : “Indisponibilité d’une partie de la plateforme. Bascule réalisée par @Cedexis en place. Les sites restent en ligne“.
Pas de retours clients et pas de retours publics via les réseaux sociaux, le système de failover général a bien fonctionné.
Sur l’équipe
4 heures passées pour réagir et faire le post mortem.
4 heures permettant aussi de constater que notre système de redirection DNS fonctionne plutôt bien mais que nous avons un élément de l’architecture qui reste un SPOF (avec des impacts assez limités tout de même).
Quelles contre mesures ?
- Nous avons mis en production le pilotage du système de bascule DNS depuis notre application (qui était prévue ce matin au moment de la coupure …)
- Nous avons contacté les clients mal configurés en leur demandant de corriger leurs enregistrement DNS et allons mettre en place un système pour détecter les prochains clients qui se tromperaient dans leurs enregistrements DNS
- Nous avons identifié un bug de reconnexion à notre système de storage après une coupure réseau et allons le corriger. Une suspicion existe aussi pour notre système de file de message distribué et nous allons également investiguer pour savoir s’il est impacté par une coupure réseau.
- Nous allons supprimer notre dernier point of failure (storage persistent servant à stocker certains objets optimisés).
Conclusion
A vrai dire, nous sommes assez fiers de tout ce que nous avons mis en place pour limiter l’impact de ce genre d’incident : même pas une minute de coupure ! Mais nous savons aussi que cela se reproduira et qu’il faut encore améliorer notre service dans ces cas là. Allez, au boulot !
Si vous avez des commentaires, si vous avez des questions, n’hésitez pas, toute l’équipe est à votre disposition pour y répondre.
[edit]
Le post mortem côté Illiad : http://forum.online.net/index.php?/topic/3332-coupure-salle-103-rapport-dincident/