Is there an Fasterize outage?
Fasterize status: Systems Active
Last checked: 6 minutes ago
Get notified about any outages, downtime or incidents for Fasterize and 1800+ other cloud vendors. Monitor 10 companies, for free.
Last checked: 6 minutes ago
Get notified about any outages, downtime or incidents for Fasterize and 1800+ other cloud vendors. Monitor 10 companies, for free.
Outage and incident data over the last 30 days for Fasterize.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage. It's completely free and takes less than 2 minutes!
Sign Up NowOutlogger tracks the status of these components for Xero:
| Component | Status |
|---|---|
| Acceleration | Active |
| API | Active |
| CDN | Active |
| Collect | Active |
| Dashboard | Active |
| Logs delivery | Active |
| Website | Active |
View the latest incidents for Fasterize and check for official updates:
Description: Le 08/01/2020, jour de l’ouverture des soldes d’hiver 2020, la plateforme a émis des erreurs 502 entre 8h05 et 10h25. Les erreurs ont été principalement émises sur 2 périodes : * 9h15 à 9h35 * 9h50 à 10h30 Notre couche de proxys a été saturée par le très fort trafic de la matinée, et par intermittence, plus aucun proxy ne répondait à nos fronts. Il s’agit de la première source d’erreurs 502. De la même manière, notre couche de frontaux a aussi été indisponible par intermittence. Le CDN a alors émis des erreurs 502. Il s’agit de la seconde source d’erreurs 502. Au plus fort des 2 pics d'erreurs, il y a eu jusqu'à 9% d'erreurs. À 9h30, un nouveau serveur proxy et un nouveau serveur front sont prêts à être ajoutés mais cela ne suffit pas pour soulager les autres serveurs. Tous les serveurs proxys et fronts sont alors upscalés un par un et les couches de front et de proxy sont de nouveau 100% disponible à 10h25. Il reste ensuite quelques erreurs 502 générées \(< 0.2%\) par le dernier serveur front ajouté qui n'a pas été déployé convenablement. Ce serveur est sorti du load balancer une fois identifié comme la cause de ces erreurs à 11h50. Contre mesures : * déjà appliqué : * notre infrastructure à été upscalée et peut absorber plus de 2 fois le trafic de la matinée. * le script de déploiement d'un nouveau serveur front a été corrigé * court terme : * le sizing des prochains événements sera plus pessimiste * des VM prêtes à l'emploi seront mises à disposition pour une augmentation de capacité plus rapide * correction de l'alerte de disponibilité de notre couche de front * correction des derniers cas qui génèrent des erreurs HTTP 502 au lieu de 592 pour faciliter l'identification de la source des erreurs et pour profiter de notre système de failover HTTP qui s'appuie sur le code 592. * moyen terme : * auto-scaling de la couche de workers * mise en place d'un système de failover HTTP au niveau du CDN en cas d'indisponibilité intermittente du moteur de Fasterize * long terme : * auto-scaling de nos couches de proxys et frontaux
Status: Postmortem
Impact: Major | Started At: Jan. 8, 2020, 8:53 a.m.
Description: We have found the root cause. Some customer configurations were not loaded correctly and stop the restart of some workers.
Status: Resolved
Impact: Major | Started At: Nov. 22, 2019, 8:36 a.m.
Description: Logs are now fully operational. We are sorry for logs lost during this incident.
Status: Resolved
Impact: Major | Started At: Nov. 18, 2019, 1:50 p.m.
Description: # Incident du 07/11/2019 Date du post mortem : 07/11/2019 Participants du post mortem : * David Rousselie * Mikael Robert * Nicolas Alabrune * Grégoire Lejeune * Anthony Barré * Jerome Lachaud * Stephane rios # Description de l'incident Le 07/11/2019, à partir de 05:40, des alertes sont reçues par l’astreinte avec pour objet un fort taux d’erreur sur les optimisations. Ces erreurs sont rapidement identifiées comme étant liées à la maintenance réseau effectuée plus tôt dans la nuit. L’objectif de ce déploiement était de basculer sur le réseau privé d’un de nos hébergeurs au lieu de notre VPN. Nous espérions une amélioration notable de la stabilité et des performances du réseau, il s’est avéré que ce réseau et notamment la communication entre les différentes version de ce réseau sont trop instables et trop peu performant quand le trafic est important, et l’effet obtenu fut inverse. # Timeline **22:00** : départ du déplacement / de la maintenance de réseau **03:15** : Fin du déplacement / de la maintenance réseau. Supervision et tests automatisés tous ok. La bascule a été longue à cause de la procédure mise en œuvre pour ne pas couper le service / la plateforme. **05h40** : Alerte “High optimization error rate detected” **05h50** : L'équipe identifie les problèmes de latence sur le réseau privé de notre hébergeur et décide d’effectuer un rollback vers l’ancien réseau privé virtuel avec un focus sur l’ensemble des composants du moteur \(workers/broker/proxys\) **07h30** : Les machines impactées par ce problème sont revenues sur notre ancien VPN. Plusieurs membres de l’équipe restent en supervision de la plateforme. **11h50** : Un premier ticket est reçu au support relatant des temps de latence plus élevée sur la page d’accueil d'un de nos clients. Suivent d’autres messages sur le support de trois autres clients. Nous avions déjà identifié un certain nombre de soucis réseaux restant et commencer à re-basculer les machines sur l’ancien réseau progressivement. La hausse progressive du trafic dans la matinée a amplifié les problèmes réseaux déjà détectés. **12h00** : L'équipe complète se mobilise afin d’effectuer un rollback complet et rapide de la configuration précédent la mise en production de la veille au soir. Certains sites clients sont débranchés afin de limiter l’impact de l'opération en cours. **14h20** : L’infrastructure et la configuration réseau est à nouveau dans l'état précédent la mise en production survenue la veille. # Analyse des causes de l’incident Suite à la [maintenance programmée](https://status.fasterize.com/incidents/18jthjfq9ftj) portant sur la migration de notre réseau privé virtuel vers le réseau privé d’un de nos hébergeurs, des instabilités réseaux et des latences sont apparues dans la communication entre les machines de l’infrastructure. Ces instabilités se sont manifestées par une augmentation des timeouts d’optimisation vus par les proxys. L’impact est également visible en comparant le speed index médian par rapport à la semaine précédente. Après analyse il s’avère que le réseau privé d’un de nos hébergeur est bien plus lent que notre ancien réseau virtuel privé, et qu’il y a des erreurs de connexion et routage assez régulièrement entre plusieurs machines. Les temps d’optimisation de ressource ont énormément augmenté et ne sont revenus à des seuils normaux qu’une fois l’infrastructure re-basculée sur l’ancien réseau. # Processus de rollback Lors du passage sur le nouveau réseau privé, les adresses IP du réseau virtuel sécurisé avaient été supprimées de nos firewalls. Et lors du rollback, les services se sont remis à échanger sur le réseau virtuel sécurisé mais bloqués par les firewalls. Le process de rollback a été long car nous n’avions pas prévu la cohabitation des deux réseaux en parallèle. Il a fallu mettre à jour l’ensemble de la plateforme. # Métriques \* Niveaux de sévérité de l'incident : Sévérité 2 : dégradation du site, problème de performance et/ou feature cassée avec difficulté de contourner impactant un nombre significatif d'utilisateur. \* Time to detect : 10 minutes \* Time to resolve : * mitigation : 1 heure 40 minutes * patch: 2 heures 20 minutes # Impacts * Des erreurs 502 se sont produits sur les frontaux, et vu par les clients \(la majorité est due aux moments où les machines ont basculé d’un réseau à l’autre pendant le rollback\). * La fonctionnalité de flush ne fonctionnait plus * Les métriques utilisateurs \(boomerang\) se sont dégradées. # Plan d'actions **Court terme** * Nous avons remis le réseau dans le même état qu’avant la mise en production prévue et en premier lieu sur les workers qui étaient les plus impactés. * Nous avons re-basculé le reste de l’infrastructure progressivement ensuite. **Moyen terme** * Abandon du projet d’utiliser le réseau privé de notre hébergeur \(migration en cours vers le nouvel hébergeur\) * Préparation d’un plan de rollback testé sur les environnements de staging pour éviter le flottement pendant rollback et surtout mise en place d’un déploiement progressif pour les opérations impactantes. * Retirer les adresses IP privées dans nos configurations pour les remplacer par des variables pour éviter une mise à jour forcée de l’ensemble des configurations. **Long terme** * Utiliser un DNS uniquement et plus d’adresses IP dans les configuration de services. * Trouver un moyen de pouvoir reproduire un trafic réel sur la plateforme, sans impacts sur les sites réels afin de valider ce type de migration potentiellement impactantes. * Mettre en place une métrique permettant de détecter les pertes et latence du réseau privé. * Mettre en place du blue-green déploiement et passage progressif du trafic d’un réseau à l’autre. * Meilleure formation de l’ensemble de l’équipe au premier secours sur la plateforme. Dans le cas des MEP, prévoir si possible une meilleure couverture des compétences.
Status: Postmortem
Impact: Major | Started At: Nov. 7, 2019, 11:54 a.m.
Description: _Note : les temps indiqués dans ce document sont au format UTC sauf indication contraire._ # Description de l'incident Le 23/10/2019, à partir de 09:39, les frontaux de l’environnement euwest1 ont commencé à devenir instable. Les premiers éléments montrent que les healthchecks entre le load balancer et les frontaux de euwest1 étaient négatifs de manière sporadique, ce qui entraînait la sortie alternative des frontaux de la ferme. Une pré-analyse montre que les frontaux subissaient une charge anormalement élevée lorsqu’ils recevaient du trafic. Une saturation au niveau de leur disques durs a été constatée. Le mécanisme de failover DNS a fonctionné. Le trafic a progressivement été rerouté vers les origines ou le second datacenter dc1. # Timeline **09h39** : Premier serveur sortant du loadbalancer. **09h45** : Une partie du trafic est remise sur dc1 et l’autre va directement à l’origine. **09h50** : L'équipe détecte le problème d'instabilité au niveau du load balancer. **10h50** : Après une analyse poussée, nous détectons l’origine de l’incident et effectuons une modification de la configuration du service web afin de mitiger le problème. **10h52** : le service est à nouveau disponible sur la région et les serveurs sont réintroduits dans le load balancer. **11h00** :Le trafic reprend progressivement sur la region euwest1. Durant le reste de la journée, une solution est déployée à plus petite échelle afin de la valider techniquement. **16h00** : la solution validée est déployée sur l’ensemble des frontaux et le service est à nouveau nominal. # Analyse des causes de l’incident et correction La charge des frontaux a commencé à augmenter de manière anormale. Lors de la première analyse, nous détectons que celle-ci est causée par des I/O wait, donc des latences d'accès disque des processus. Les processus posant problème concernent le cache placé devant l’origine pour limiter les accès à l’origine lors de la phase d’optimisations des ressources statiques. La mitigation a consisté dans un premier temps à couper le cache devant les origines. Puis, nous avons remplacer les disques durs par une gamme de disque SSD plus performante dédiée à ce cache. Nous avons enfin ré-activé le cache. # Métriques \* Niveaux de sévérité de l'incident : Sévérité 2 : dégradation du site, problème de performance et/ou feature cassée avec difficulté de contourner impactant un nombre significatif d'utilisateur. \* Time to detect : 10 minutes \* Time to resolve : * mitigation : 1 heure * patch: 5 heures # Impacts * Durant un instant, certains clients ont reçu des erreurs 5xx dû à la surcharge des serveurs. Cela représente 3% de taux d’erreurs \(nombre de MISS sur CloudFront et erreurs 50\{1..4\}\). * Une partie du trafic a été détourné vers la région dc1 afin de limiter l’impact du point de vue client. # Plan d'actions * Revoir le niveau d’alerte autour de la fonctionnalité du cache devant les origines * Prévoir la possibilité de rapidement couper les caches devant les origines
Status: Postmortem
Impact: Major | Started At: Oct. 23, 2019, 10:26 a.m.
Join OutLogger to be notified when any of your vendors or the components you use experience an outage or down time. Join for free - no credit card required.
