Introduction
L'infrastructure technique d'Eventmaker est décrite dans ce document. Il explique notamment les différentes stratégies mises en place pour la redondance des systèmes vitaux de la plateforme Eventmaker. Il détaille aussi la politique et la fréquence des sauvegardes effectuées sur la base de données. Enfin il décrit les différents mécanismes de sécurité.
Le plan de continuité d'activité permet de présenter brièvement la gestion de la continuité d’activité en cas de perturbation ou sinistre chez Eventmaker. Plusieurs éléments sont présentés ici : L’infrastructure technique, Les différentes stratégies mises en place pour la redondance des systèmes vitaux de la plateforme Eventmaker et du système d’information, La politique et la fréquence des sauvegardes effectuées sur la base de données, Les différents mécanismes de sécurité.
Les différents enjeux et objectifs de ce document sont de : Préserver les données clients, Préserver la disponibilité des services d’Eventmaker, Garantir une rapide reprise des processus prioritaires et essentiels en cas de perturbation/sinistre, Répondre efficacement en cas de perturbation/sinistre.
Le document est revu a minima une fois par an ou en cas de changement majeur du système d’information. Le plan de continuité d’activité fera également l’objet de test une fois par an, ce qui engendrera une potentielle revue du document si certains processus doivent être modifiés suite aux résultats du test.
Personnes clés et information de contact
Prénom Nom | Rôle | Email
Ivan Maireaux | CTO| ivan.maireaux@eventmaker.io
Wilfried Deluche | Partner Solution Manager | wilfried.deluche@eventmaker.io
Tristan Verdier | Managing Director | damien.schmitz@infopro-digital.com
Risques identifiés
Introduction d’une défaillance dans le code de l’application web
Description
L’application web Eventmaker est développée en suivant le principe de continuous delivery. Par conséquent, les nouvelles versions de l’application sont déployées en production régulièrement et parfois plusieurs fois par jour. Une nouvelle version peut introduire une défaillance de l’application.
Analyse de l’impact
L’impact de l’introduction d’une défaillance peut avoir des conséquences diverses en fonction de la criticité de cette dernière et de la partie du système qu’elle touche. Le pire scénario est une défaillance qui rend l’application inutilisable.
L’impact varie donc d’une défaillance sans réelle implication sur l’utilisation du système à une défaillance rendant le système non utilisable.
Méthodes de détection
L’introduction d’une défaillance en production peut-être detecté de trois manières.
Dans le cas où la défaillance est une erreur dans le code qui introduit une interruption anormale de l’exécution du code, l’erreur est remonté dans un système de traçage d’erreur : sentry.io. L’intégralité de l’équipe de développement est avertie par email qu’une erreur s’est produite.
Dans le cas où l’application n’est plus du tout accessible, un système de surveillance de continuité de service, pingdom, avertit par email l’équipe de développement ainsi que le CEO.
Dans le cas où la défaillance est fonctionnelle, c’est à dire que le code ne suit pas la bonne logique et ne permet donc pas de délivrer une fonctionnalité, celle-ci est détecté humainement et consigné dans notre outil de gestion de projet Basecamp afin que l’équipe de développement soit notifiée par email. En fonction de la criticité, le dysfonctionnement peut aussi être communiqué directement à l’oral ou via un message instantané à l’équipe de développement.
Méthodes de préventions
Afin de prévenir au maximum les défaillances, Eventmaker respecte les bonnes pratiques de développement :
utilisation de git comme outil de système de gestion de version du code
utilisation de Github et du Github flow : revue de code systématiques
tests unitaires et tests d’intégration (couverture du code testé : 79.14%)
continuous integration : les tests unitaires sont exécutées automatiquement, un linter de code, rubocop, est aussi exécuté afin d’assurer la lisibilité du code
Aussi, les nouvelles versions potentiellement critiques sont testées en interne sur un environnement de pré-production.
Lors du déploiement d’une nouvelle version, celle-ci devient la version principale uniquement quand elle répond positivement à une sonde de démarrage, qui évite la mise en ligne d’une version avec une défaillance critique qui empêcherait l’application de démarrer ou de traiter des requêtes HTTP par exemple.
Enfin, les processus qui arrêtent de fonctionner de manière anormale sont automatiquement redémarrés par Kubernetes notre système de gestion de conteneur Linux.
Méthodes curatives
Quand une défaillance est détectée, celle-ci est évaluée directement par l’équipe de développement. S’il est évalué que la défaillance doit-être traitée directement, les développeurs habilité à déployer l’application peuvent procéder à un rollback, c’est à dire remplacer la version de production par une version précédente. La durée de rollback est d’environ 2 minutes.
Panne du cluster applicatif
Description
Le cluster applicatif est l'ensemble des serveurs qui exécutent l'application web Eventmaker. Celui-ci est situé dans le Cloud d’Amazon AWS (plus d’information dans ce document). Les pannes peuvent provenir de différentes sources : une machine virtuelle cesse de fonctionner, des problèmes de réseaux à l’intérieur du VPC, ou tout autre panne que peut subir AWS.
Analyse de l’impact
L’impact est l’indisponibilité totale de l’application web.
Méthodes de détection
Les serveurs sont tous monitoré par Newrelic Infrastructure. Quand un serveur ne répond plus, un email est envoyé à Robin Monjo et Ivan Maireaux.
En cas d’indisponibilité totale de l’application web, l’équipe de développement est aussi avertie par un email de pingdom.
Méthodes préventives
Afin d’être robuste aux potentiels pannes d’AWS, l’application Eventmaker est déployée sur au moins 4 serveurs répartis sur 3 zones différentes.
Les serveurs sont gérés par un auto-scaling group qui est en charge de s’assurer que le nombre de serveur souhaités est bien respecté.
Kubernetes s’assure de distribuer l’application sur les différents serveurs disponibles.
Les serveurs sont exposés à l’extérieur via un équilibreur de charge.
Méthodes curatives
Dans le scénario ou toutes les zones de la région eu-west-1 de Amazon se trouvaient impactées par une panne majeure, un re-déploiement de l’infrastructure serait nécessaire.
Eventmaker utilise Terraform un outil d'Infrastructure as Code pour déployer son infrastructure de manière automatisée. Cela permet un re-déploiement automatique de l’infrastructure dans une autre région d’AWS.
La durée de remise en service dans ce scénario est d’environ 8 heures. Les personnes impliquées dans cette procédure sont Robin Monjo, Ivan Maireaux et Wilfried Deluche.
Panne du cluster de base de données
Description
Le cluster de base de données est l'ensemble des serveurs utilisés pour le système de gestion de base de données MongoDB géré par Atlas (plus d’informations dans ce document). Comme le cluster applicatif, il est hébergé sur le Cloud d’Amazon AWS. Les pannes qui peuvent survenir sont les mêmes que celles pour le cluster applicatif, bien que le cluster de base de données est isolé dans son propre VPC.
Analyse de l’impact
Une panne sur le cluster de base de données peut entraîner une impossibilité de l’application web à communiquer avec la base de donnée. Dans cette situation, on peut considérer que l’application est inutilisable.
Autre impact possible, la perte de données.
Méthodes de détection
Comme les serveurs applicatifs, les serveurs de base de données sont monitorés par Newrelic Infrastructure. En cas de défaillance d’un serveur, un email est envoyé à Robin Monjo et Ivan Maireaux.
Le logiciel MongoDB est aussi monitoré par MongoDB Cloud Manager. Celui-ci permet d’alerter sur des comportements anormaux de MongoDB comme par exemple, la disparition d’un noeud dans le replica set. Les alertes sont des emails envoyés à Robin Monjo et Ivan Maireaux.
Méthodes préventives
Composant critique du système Eventmaker, la base de donnée est répliquée en temps réel sur 3 serveurs via le système de replica set fourni par MongoDB. Les 3 serveurs sont isolés dans leur propre VPS est répartis sur 3 les 3 zones de la région eu-west-1 d’AWS.
Méthodes curatives
Si moins de 2 serveurs sont impactés en même temps, aucune interruption de service n’est constatée grâce au système de réplication. Une intervention humaine est malgré tout nécessaire afin de rétablir la réplication à 100% :
si la panne provient du serveur : il faut re-déployer un serveur (toujours en utilisant Terraform) puis ajouter le nouveau serveur au replica set depuis l’interface de MongoDB Cloud Manager. Durée de l’opération : 30 minutes
si la panne provient de MongoDB : il faut diagnostiquer et rétablir le ou les noeuds impactés pour qu’ils rejoignent le replica set. L’outil à utiliser ici MongoDB Cloud Manager. Durée de l’opération : 20 minutes
Dans le cas ou les 3 serveurs subissent une panne au même moment, on constate une interruption de service. La durée de remise en service dépend du scénario :
les données ne sont pas impactées (si les disques durs des serveurs n’a pas été endommagé par la panne)
les données ont été perdues suite à la panne
Dans le premier scénario, les serveurs sont re-déployés via Terraform en utilisant les disque dures existants. Le replica set est par la suite recréé via MongoDB Cloud Manager. Durée de l’opération : 2 heures.
Dans le deuxième scénario, en plus de recréer les serveurs et le replica set, il est nécessaire de restaurer la dernière sauvegarde de la base de données. La politique et la fréquence de sauvegarde de la base de données est détaillée dans ce document.
La restauration d’une sauvegarde prend aujourd’hui environ 2 heures. La durée de remise en service pour ce scénario est donc d’environ 4 heures. La restauration d’une sauvegarde se fait directement via l’outil MongoDB Cloud Manager.
Les personnes impliquées sur ces procédures sont Robin Monjo et Ivan Maireaux.
Attaque par déni de service
Description
Une attaque par déni de service vise à requêter massivement un service afin de le rendre indisponible pour les utilisateurs légitime.
Analyse de l’impact
Une telle attaque peut provoquer des lenteurs et une indisponibilité de la plateforme.
Méthodes de détection
Les serveurs d’Eventmaker sont monitorés par Newrelic Infrastructure. L’application web Eventmaker est monitoré par Newrelic APM.
Une attaque par déni de service provoque une surconsommation des ressources du cluster applicatif (CPU et mémoire). Une alerte est envoyée par email à Robin Monjo et Ivan Maireaux quand un serveur utilise plus de 80% de CPU ou de mémoire pendant plus de 5 minutes.
Confirmer une attaque par déni de service est ensuite possible en consultant les données recoltées par Newrelic APM qui nous indiquent entre autre le nombre de requêtes par minutes sur la plateforme.
Méthodes préventives
Pour mitiger les effets d’une attaque par déni de service l’infrastructure d’Eventmaker est conçue pour permettre rapidement un passage à l’échelle horizontale. La procédure est la suivante :
ajout de serveurs dans le cluster Kubernetes pour le groupe de serveur dédiés à Eventmaker
ajout de processus de type web via notre Plateforme As A Service Hephy
La durée de l’opération est d’environ 2 minutes pour chaque serveur ajouté. Cette procédure peut-être réalisée par Robin Monjo et Ivan Maireaux.
Méthodes curatives
En cas d’attaque par déni de service prolongée qui ne peut pas être suffisamment mitigée par un passage à l’échelle, la procédure est de mettre en place AWS Shield sur l’équilibreur de charge victime de l’attaque. Cette procédure peut-être réalisé par Robin Monjo et/ou Ivan Maireaux, sa mise en place est d’environ 2 heures.
Panne de notre prestataire d’emailing
Description
L’envoi d’email est un système vitale de la plateforme Eventmaker. Le service utilisé pour envoyer des emails est Mailjet.
Analyse de l’impact
L’impossibilité d’envoyer des emails peut impacter grandement le service Eventmaker. En effet envoyer des emails de confirmation d’inscription ou des campagnes d’emailing est une fonctionnalité majeure.
Méthodes de détection
Eventmaker communique avec Mailjet via leur API REST. Dans le cas ou une requête HTTP vers Mailjet, une exception est générée et envoyée au service de traçage d’erreur : sentry.io. Un email d’alerte est alors envoyé à chaque personne de l’équipe de développement.
Aussi, les emails sont envoyés de manière asynchrone via un système de queues. Quand l’une des tâches d’envoi d’email génère une exception, le job est considéré comme échoué et est gardé en mémoire dans une queue spéciale dédiée à stocker les tâches qui ont échoué. Le système de surveillance de continuité de service pingdom monitor cette queue et alerte par email l’équipe de développement quand celle-ci n’est pas vide.
Méthodes préventives
Quand Eventmaker utilise l’API de Mailjet, la requête est réessayée jusqu’à 3 fois si la réponse de l’API est une réponse d’erreur, ou si la requête n’a pas pu aboutir. Cela permet de mitiger les erreurs temporaires de Mailjet.
Méthodes curatives
Si l’envoie échoue plus de 3 fois de suite, celui-ci peut être ré-essayé directement dans l’interface du système de queues.
En cas de panne prolongée de Mailjet, la procédure est de changer de service et de migrer sur le service d’Amazon SES. La durée de la migration est d’environ 5 heures, les personnes impliquées sont l’équipe de développements incluant Robin Monjo ou Ivan Maireaux pour la mise en place du service SES. Il s’agira d’un mode dégradé qui permettra d’envoyer des emails, mais ne permettra pas le suivi statistique.
Panne de nos autres prestataires
Description
Eventmaker s'appuie sur d'autres services tierces en plus de AWS et Mailjet :
Esendex pour l’envoi de SMS
Crisp pour le support et la documentation
Heroku qui héberge une application qui sert les thèmes de l’outil de création de site web ainsi que les thèmes de l’outil de création d’emails d’Eventmaker
Amazon S3 qui est utilisé pour les thèmes de l’outil de création de site web d’Eventmaker
Analyse de l’impact
Service et Impact
Esendex | Impossibilité de la plateforme d’envoyer des SMS. Les SMS sont utilisés pour les notifications VIP, l’envoi de code temporaire pour l’authentification multi-facteur ainsi que les campagnes de SMS
Crisp | Impossibilité aux utilisateurs (organisateurs d’événement) de solliciter l’aide de l’équipe d’Eventmaker via le tchat de la plateforme. Indisponibilté de la documentation help.eventmaker.io
Heroku | Impossibilité de configurer un nouveau site web ou un nouvel email sur la plateforme Eventmaker. Note : la duplication reste possible et les sites web ou emails existants ne sont pas impactés
Amazon S3 | Les pages d’un site web nécessitant du Javascript s’affichent mais ne se comportent pas comme prévue car la code Javascript n’a pas pu être chargé
Méthodes de détection
Service & Détection Esendex | Comme pour les emails, l’erreur de communication avec l’API de Esendex génère une exception qui est ensuite remonté sur sentry.io.
Zoho Invoice | Détection humaine
Crisp | Détection humaine
Heroku | Détection humaine
Amazon S3 | Détection humaine
Méthodes préventives
Service & Détection
Esendex | Comme pour les emails, en cas d’erreur la requête à l’API de Esendex est réessayée jusqu’à 3 fois afin de mitiger les erreurs temporaires
Crisp | Aucune
Heroku | Aucune
Amazon S3 | Aucune
Méthodes curatives
Service | Détection
Esendex | Aucune. Le système d’envoi de SMS n’empêche pas à Eventmaker de délivrer sa valeur ajouté. Des interventions humaines au cas par cas peuvent-être envisagée pour débloquer un utilisateur qui ne peut plus accéder à son compte car il ne peut pas recevoir son code d’authentification par SMS.
Crisp | Aucune
Heroku | Déploiement de l’application sur le cluster applicatif interne d’Eventmaker. Cette procédure peut-être menée par Robin Monjo et prend environ 1 heure
Amazon S3 | Aucune