Is there an Fasterize outage?
Fasterize status: Systems Active
Last checked: 9 minutes ago
Get notified about any outages, downtime or incidents for Fasterize and 1800+ other cloud vendors. Monitor 10 companies, for free.
Last checked: 9 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: This incident has been resolved.
Status: Resolved
Impact: Major | Started At: April 15, 2020, 8:04 a.m.
Description: This incident has been resolved by KeyCDN at 8:25.
Status: Resolved
Impact: Major | Started At: Feb. 25, 2020, 4:14 a.m.
Description: ## Description de l'incident Le mardi 28 janvier 2020, l’un de nos CDN partenaires KeyCDN a émis des erreurs 502 entre 13h40 à 15h05, suite à l’indisponibilité d’un des serveurs de leur POP à Paris. L’incident a concerné une petite partie du trafic, la majorité étant routée sur un autre CDN et seul un serveur étant en erreur. KeyCDN nous a bien confirmé l’incident chez eux par mail. Cela n’a pas impacté les clients ayant migré sur le CDN d’Amazon Cloudfront. ## Plan d'actions ### Court terme * Basculer au plus vite les derniers clients sur notre nouvelle infrastructure * Mettre à jour la liste de diffusion sur [status.fasterize.com](http://status.fasterize.com) pour ne pas avoir de clients qui ne soient pas notifiés ### Moyen terme * Pouvoir désactiver simplement un CDN globalement pour ne pas avoir à agir client par client \(config par config\) * Modifier automatiquement les messages / signatures du support pour signaler l’incident
Status: Postmortem
Impact: Major | Started At: Jan. 28, 2020, 1:43 p.m.
Description: # **Description de l'incident** Note : L’incident suivant est relatif au datacenter situé chez AWS \(euwest1\). Le mercredi 22 janvier 2020 entre 19h et 20h30, un problème de résolution DNS a été identifié sur l’ensemble des machines hébergées sur une de nos trois zones de disponibilité de Paris. Le système de supervision indique que pendant cette durée 6,24% des requêtes à l’origine ont échoué. Les machines présentes dans cette zone utilisant toutes le DNS interne d’AWS \(censé être hautement disponible / redondé\), elles ne pouvaient plus se connecter aux serveurs d’origine des clients. AWS a déclaré un problème de connectivité sur la zone incriminée sur sa page de status. Après identification de l’incident, nous avons modifié la configuration de nos machines pour utiliser un autre service public DNS afin de maintenir le service dans l’attente de la résolution de l’incident côte hébergeur. L’absence de résolution DNS ne permettait pas d’avoir une vision en temps réel et fiable de l’état du système \(logs et métriques\). A partir du moment où nous avons modifié les resolvers DNS, le système de supervision a commencé à rattraper le retard de logs et de métriques. Tant que ce retard n’était pas comblé, nous n’avions pas une vision temps réel des erreurs émises par la plateforme via nos système de logs et de collecte de métriques. En l’absence de supervision et de logs et suite à nos tests manuels, nous avons pensé à tort que la correction était suffisante. Il s'avère, après analyse, que les serveurs HTTP impactés n’ont pas correctement pris en compte le changement, utilisant leur propre configuration de resolver. La fin de l’incident correspond à la remise en état du service DNS par AWS. # Plan d'actions **Court terme :** * améliorer la disponibilité de notre système de résolution en évitant de dépendre d’un unique acteur * révision du système de métrique pour fiabiliser la vision temps réel de la plateforme **Moyen terme :** * amélioration de la prise en compte automatique d’une panne au niveau de la couche responsable de la communication avec les origines
Status: Postmortem
Impact: Major | Started At: Jan. 22, 2020, 6:49 p.m.
Description: # Plateforme indisponible Date du post mortem : 15/01/2020 Participants du post mortem : * David Rousselie * Mikael Robert * Nicolas Alabrune * Anthony Barré * Stéphane Rios # Description de l'incident Note : L’incident suivant est relatif au datacenter situé chez AWS \(euwest1\) suite à une attaque. Le 14/01/2020, à partir de 18h09, tous les proxys sont devenus indisponibles et les utilisateurs ont commencé à recevoir des erreurs 502. La bascule DNS s’est déclenchée automatiquement une première fois à 18h12, le trafic est revenu chez Fasterize de 18h17 à 18h21 puis a été basculé manuellement à 18h23. L’indisponibilité des proxys est due à une saturation du CPU. Les pings et le trafic sont fortement impactés \(erreur 502 et temps de réponse\) et les proxys sont perçus comme indisponibles par les frontaux. Dans ce cas là, le code d’erreur généré par les frontaux \(502\) n’est pas utilisé pour faire un failover \(ie. retry\) à l’origine, ceci pour ne pas faire un retry sur un 502 qui proviendrait de l’origine et qui pourrait aggraver un éventuel problème de l’origine. Après le débranchement de 18H23, nous constatons qu’il reste principalement un trafic suspicieux mélangeant diverses catégories d’attaques. Ces attaques échouent mais génèrent une consommation anormale sur les proxys. Nous tentons de désactiver et redémarrer les proxys : tant que le proxy ne reçoit pas le trafic, il reste stable. Après une désactivation, il reste chargé quelques minutes puis finit par retrouver un état stable \(signe qu’il n’y a pas un blocage permanent\). A 19h15, nous identifions une exception non catchée lors de l’accès au storage qui fait redémarrer les processus plantés et amplifie la consommation CPU lors du chargement des configurations clientes. Le blocage de l’attaquant sur le proxy résout le problème de charge : la consommation CPU se situe donc après le middleware de filtrage d’adresses IP. Afin d’éviter les exceptions de connexion au storage, nous désactivons l’accès au header store \(ie. Early Hints/preload\) en patchant le code \(pas de feature flag global\). La décision de rerouter le trafic sur Fasterize est prise lorsque l’attaque est clairement identifiée et mitigée. # Faits et Timeline **18h09**: premier pic d’erreurs 502 au niveau des proxys **18h10** : première alerte du système de supervision concernant l'indisponibilité des proxies **18h12** : bascule automatique vers les origines client **18h15** : l'équipe tech se réunit **18h17** : rebascule automatique vers Fasterize **18h19** : premier mail au support indiquant un problème de 502 **18h21** : bascule automatique vers les origines client **18h23** : l’ensemble des clients de la plateforme est débranché manuellement via le système de coupure d’urgence. **18h29 :** publication d’un message sur la page de status de la plateforme **18h36** : fin des erreurs 502 **18h40** : première suspicion d’attaque en constatant des URL forgées - mais difficile de lier ces URL à la consommation CPU des proxys **19h15** : identification d’une exception non catchée lors de l’accès au storage depuis les proxys => redémarrage automatique des processus plantés **19h18** : test de désactivation du storage - sans effet **19h44** : adresse IP de l’attaquant bloquée au niveau des proxys **19h45 :** nouveau message pour indiquer que nous avons identifié une saturation CPU des proxys **19h56** : envoi d’une requête d’abus à l’hébergeur de l’attaquant \(abuse@ovh\). **20h22 :** nouveau message pour indiquer que nous avons identifié la corrélation entre une attaque sur un client et la saturation CPU **20h20** : prise d’un échantillon des requêtes provenant de l’attaque pour analyse ultérieure **20h25** : mise en place d'une règle WAF au niveau CDN afin de bloquer les requêtes provenant de l’adresse IP de l’attaquant **20h29 :** nouveau message pour indiquer que le trafic est rerouté sur la plateforme. **20h50 :** fin des requêtes provenant de l’attaquant # Métriques * Niveaux de sévérité de l'incident : **Sévérité 1: arrêt du site non planifié qui affecte un nombre significatif d'utilisateurs.** * Temps de détection : 1 min * Temps de résolution : * 3 min pour être en mode dégradé, partiellement * 15 min pour être en mode dégradé \(routage à l’origine\) * 2h20 pour réactiver les optimisations # Impacts L’ensemble des clients a été impacté, une petite partie nous a contacté : tickets \(10\) \+ appels en direct \(1\) \+ SMS \(2\) Les pages et les objets cachés ont été servies normalement. Tout ce qui passait par le proxy a été impacté \(panier, fragments SmartCache\). # Contre mesures ## Actions pendant l’incident * blocage de l’attaquant * désactivation de l’accès au header store / early hints * bascule manuelle, routage du trafic à l’origine * réactivation des optimisations # Plan d'actions **Court terme :** * Identifier la ou les requêtes qui ont eu un impact sur les proxys et corriger le code du proxy. * Effectuer un failover sur l’origine depuis les fronts lors d’une erreur 502 * Distinguer les erreurs 502 provenant de l’origine vs l’infrastructure Fasterize \(erreurs 592\) * Implémenter un failover au niveau CDN **Moyen terme :** * Mise en place d’un WAF avec les règles de sécurité de base * Améliorer l’observabilité des processus proxy sur demande * Intégrer l’analyse de sécurité des dépendances * Mise en place du shuffle sharding sur les proxys
Status: Postmortem
Impact: Major | Started At: Jan. 14, 2020, 5:29 p.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.
