🇫🇷 Version française plus bas
Overview
Our IP failover 62.210.31.127 used on the configuration of our hosting provider to redirect towards frontend server stopped working, resulting in a timeout. In other words, all services hosted on our frontend server were unreachable (Platforms, API, short links, Hubspot integration, documentation). All API requests made during the incident were lost. To solve this, we had to edit the smsfactor.com DNS zone A entry to point directly towards frontend server IP, meaning each user had to wait for the DNS propagation to be reflected.
Timeline (CET)
How did the issue unfold
- 10h00 - The IT team responded after seeing Slack monitoring channel alerts
- 10h01 - First investigation
- 10h07 - Incident created on status page
- 10h30 - First diagnostic about the IP failover at our hosting provider level
- 10h40 - Ticket created at our hosting provider
- 11h12 - Call to hosting provider so that we can escalate the ticket
- 11h30 - Decision to edit the DNS settings as an emergency solution for Platforms, API, Hubspot integration
- 12h00 - DNS change for our short-links domains as well
- 12h20 - DNS change for Reminder domains
- 13h00 - The situation seems to be stabilized
User facing impact
- Platform unavailable (timeout)
- API unavailable (timeout)
- Beta platform (data not loading)
Reminders (Impossible de manage subscriptions and calendars)
- NB : SMS from already configured calendars worked as expected
Hubspot integration unavailable (timeout)
Short links unavailable (timeout)
Mail2SMS unavailable (timeout)
How many customers were impacted?
- Absolutely all of them except for reminder users who already had their calendars set up
Did we lose any data (e.g simulations)?
- Since the API was unreachable during the event, no data could be created or modified whatsoever. Meaning all data sent to the API during the event is unavailable from our side.
Duration
- Start: 10h00
- Stop: Between 11h30 and several hours after depending on each user’s capability to flush DNS or acknowledge DNS propagation
- Downtime: Yes
- Downtime duration *: At least an hour and a half
- Customer impact: Yes
- Customer impact duration **: At least an hour and a half
Resolution
By changing the zone DNS A entry so that it points directly towards the frontend server and bypassing the IP failover.
NB: While this solution indeed solves the issue, this remains a temporary solution.
Follow-up action items
What actions should we take?
- We’re actively gonna look for solutions/alternatives when it comes to IP Failover and DNS (ex: multiple DNS A entries to provide multiple IPs in case one fails)
- We’re gonna consider IP failover and DNS zone as a serious SPOF
- We will rethink our infrastructure to make it more robust, redundant and resilient. We underestimated the probability of having an IP failover not working properly
‌
Aperçu
Notre IP failover 62.210.31.127 utilisée dans la configuration de notre hébergeur pour rediriger vers le serveur frontal a cessé de fonctionner, entraînant un timeout. En d'autres termes, tous les services hébergés sur notre serveur frontal étaient inaccessibles (Plateformes, API, liens courts, intégration Hubspot, documentation). Toutes les requêtes API effectuées pendant l'incident ont été perdues. Pour résoudre ce problème, nous avons dû modifier la zone DNS smsfactor.com pour pointer directement vers l'adresse IP du serveur frontal, ce qui signifie que chaque utilisateur était contraint d’attendre la propagation DNS.
Chronologie (CET)
Comment le problème s'est-il déroulé.
- 10h00 - L'équipe informatique a répondu après avoir vu les alertes du canal de surveillance de Slack
- 10h01 - Première enquête
- 10h07 - Incident créé sur la page de statut
- 10h30 - Premier diagnostic concernant l’IP failover au niveau de notre fournisseur d'hébergement
- 10h40 - Ticket créé auprès de notre fournisseur d'hébergement
- 11h12 - Appel au fournisseur d'hébergement afin que nous puissions escalader le ticket
- 11h30 - Décision de modifier les paramètres DNS comme solution d'urgence pour les plateformes, l'API et l'intégration Hubspot
- 12h00 - Modification DNS pour nos domaines de liens courts
- 12h20 - Modification DNS pour les domaines de Rappel de rendez-vous
- 13h00 - La situation semble être stabilisée
Impact pour l'utilisateur
- Plateforme indisponible (timeout)
- API indisponible (timeout)
- Plateforme bêta (données non chargées)
Rappels de rendez-vous (impossibilité de gérer les abonnements et les calendriers)
- NB : Les SMS provenant des calendriers déjà configurés ont fonctionné comme prévu
Intégration Hubspot indisponible (timeout)
Liens courts indisponibles (timeout)
Mail2SMS indisponible (timeout)
Combien de clients ont été impactés ?
- Absolument tous, à l'exception des utilisateurs de rappels qui avaient déjà configuré leurs calendriers
Avons-nous perdu des données ?
- Étant donné que l'API était inaccessible pendant l'événement, aucune donnée n'a pu être créée ou modifiée. Cela signifie que toutes les données envoyées à l'API pendant l'événement sont indisponibles de notre côté.
Durée
- Début : 10h00
- Fin : Entre 11h30 et plusieurs heures après en fonction de la capacité de chaque utilisateur à vider le cache DNS ou à reconnaître la propagation DNS
- Temps d'arrêt : Oui
- Durée de l'arrêt * : Au moins 1h30
- Impact sur le client : Oui
- Durée de l'impact sur le client ** : Au moins 1h30
Résolution
En modifiant l'entrée A de la zone DNS pour qu'elle pointe directement vers le serveur frontal et contourne l’IP failover.
NB : Bien que cette solution résolve effectivement le problème, il s'agit néanmoins d'une solution temporaire.
Actions de suivi
- Nous allons nous renseigner activement sur les solutions en matière d'IP failover et de DNS (par exemple, plusieurs entrées DNS type A pour fournir plusieurs adresses IP en cas de défaillance de l’une d’entre elles)
- Nous allons sérieusement considérer l’IP failover et la zone DNS comme un SPOF
- Nous allons repenser notre infrastructure afin de la rendre plus robuste, résiliente et redondante