Depuis 11h35, les environnements du groupe 8 sont inaccessibles. Nous recherchons la cause du problème.
]]>Depuis 16h55, les environnements du groupe 8 sont inaccessibles. Nous recherchons l'origine du problème, tout semble opérationnel d'après les premiers contrôles.
]]>Nous avons remis en route le système applicatif à 15h, tout était disponible à 15h03.
Nous regardons
Nos applications VSA, VSP et VSE sont indisponibles depuis 19h25 heure de Paris, nous cherchons la cause du problème.
]]>Les environnements du groupe 8 sont inaccessibles depuis 14h20 heure de Paris, nous cherchons la cause.
]]>Vendredi 21h15, nous coupons la plateforme de secours pour basculer sur un tout nouvel ensemble technique qui ne posera plus de soucis.
Mise à jour à 7h30 heure de Paris, malgré une réinstallation complète du cluster dans la nuit, le système est à nouveau tombé et nous avons rebasculé sur l'équipement de secours. Comme hier, supprimez le cookie de session si vous avez un message d'erreur disant que l'application est indisponible.
Mise à jour à 1h30 heure de Paris, nous avons remis en route le cluster de production. Nous avons pu également remonter la réplication VSDB.
Ce soir, à partir de 21h, nous couperons tous les environnements du groupe 7 pour revenir sur le cluster de base de données de production. Depuis 10h, le service VSDB du groupe 7 est toujours accessible mais n'est plus répliqué en temps réel. La réplication sera remise en route demain en matinée une fois que la plateforme de productions sera à nouveau opérationnelle.
Mise à jour à 10h25 heure de Paris, nous avons du basculer sur la plateforme de secours. Si vous n'arrivez pas à vous connecter, supprimez vos cookies sur l'adresse de votre environnement. Nous allons chercher une solution au problème de cluster de production. Une fois le problème résolu, nous devrons couper pendant la nuit tous les environnements du groupe 7 pour remettre en route la plateforme de production.
Mise à jour à 9h50 heure de Paris, le cluster est toujours instable dès que nous laissons des connexions passer. Nous tentons un dernier test et si ce n'est pas concluant nous engageons une basculer vers un système de secours.
A 8h20 heure de Paris, le cluster semble à nouveau être tombé, nous regardons ce qu'il se passe.
Mise à jour à 7h55 heure de Paris, le cluster de base de données a été intégralement redémarré et fonctionne normalement. La synchronisation de tous les noeuds était bloquée. Nous cherchons la cause.
Depuis 7h15 heure de Paris, les environnements du groupe 7 sont inaccessibles, nous cherchons la cause du problème.
]]>Mise à jour à 10h heure de Paris. Le load balancer était dysfonctionnel, il a été remis en route. Néanmoins un serveur du cluster n'était pas accessible, nous cherchons la cause.
Depuis 9h30 heure de Paris, les environnements du groupe 8 sont inaccessibles. Le cluster de base de données semble opérationnel, cela semble venir du répartiteur de charge qui se situe entre les serveurs applicatifs et le cluster de base de données.
]]>Suite à l'incident de ce matin qui concerne les environnements du groupe 8, la réplication VSDB n'est plus active, uniquement pour le groupe 8. Dès que nous aurons récupéré le serveur qui n'est plus opérationnel, nous pourrons relancer la réplication.
]]>Le cluster est complètement reparti. La synchronisation VSDB sera remise en route dans la matinée du 10 janvier.
Les environnements sont accessibles, le serveur fonctionne sur 2 noeuds, nous remettrons en route le 3ème noeud dans la nuit. La plateforme VSDB est encore accessible mais n'est plus répliquée. Tout sera revenu à la normale d'ici demain matin.
Depuis 14h07 heure de Paris, tous les environnements du groupe 6 sont indisponibles. 2 noeuds du cluster de base de données se sont arrêtés, nous cherchons à redémarrer le cluster.
]]>Le système d'indexation full text est indisponible depuis la coupure du serveur de cache hier dimanche 7 janvier 2024 à 12h50, le bascule réalisée n'a pas été effective sur la partie indexation. Nous cherchons une solution.
]]>Mise à jour à 12h50 heure de Paris, le problème vient d'un serveur de cache qui est inaccessible, nous avons du faire une bascule manuelle car la bascule automatique n'a pas fonctionné. Nous faisons le nécessaire pour tout remettre en route.
Bonjour, depuis 12h40 heure de Paris, tous les environnements sont inaccessibles, nos 3 load balances remontent une indisponibilité totale. Nous cherchons la cause du problème.
]]>La plateforme VSDB des environnements du groupe 4 est inaccessible depuis 9h00 heure de Paris. Nous cherchons la cause du problème.
Vous pouvez accéder à la plateforme sous MySQL 8.0, qui est parfaitement fonctionnelle en changeant l'adresse du serveur : vsdb04-mysql8.veryswing.com en attendant que nous solutionnions le problème.
]]>Vous pouvez tester MySQL 8.0 avec vos identifiants actuels avant la bascule :
Mise à jour à 17h30 heure de Paris, le plateforme doit être changée. Nous devons déployer sur une autre plateforme qui sera obligatoirement sous MySQL 8.0, cela devrait être disponible dans la soirée.
Le vendredi 22 décembre à 16h heure de Paris, la plateforme VSDB des environnements du groupe 1 s'est arrêtée de fonctionner. Nous recherchons la cause.
]]>Pour rappel, vous pouvez tester MySQL sur votre connexion VSDB avant la bascule :\
Pour rappel, vous pouvez tester MySQL sur votre connexion VSDB avant la bascule :\
Nous avons basculé sur un serveur de secours car nous rencontrons des problèmes réseaux sur une partie de notre infrastructure. Il s'agit d'une base de données sous MySQL 8.0. Cela nous laisse le temps de trouver une solution et de remonter proprement la plateforme VSDB pour le groupe 3.
Nous rencontrons des difficultés technique à remonter une plateforme. Nous envisager de basculer sur la futur plateforme sous MySQL 8.0 pour remettre le service en route plus rapidement. Nous nous excusons pour la gêne occasionnée.
Nous devons remonter une plateforme pour le groupe 3, nous vous tenons informé dès que c'est prêt.
L'accès VSDB des environnements du groupe 3 est inaccessible. Le problème semble être au niveau du réseau, nous cherchons une solution.
]]>Depuis 15h40 heure de Paris, tous les environnements du groupe 9 sont à l'arrêt. Nous cherchons à remettre en route le cluster de base de données.
]]>Bonjour, depuis ce matin 5h30 heure de Paris, VSDB du groupe 3 n'est plus répliqué suite à un problème d'enregistrement qui ne s'est pas copié à cause d'une restriction de sécurité un peu trop forte sur un proxy. Nous allons couper le service sur le groupe 3 à 10h heure de Paris pour recharger une sauvegarde et relancer la réplication. Il faut compter 2 à 3 heures d'indisponibilité.
]]>A 14h heure de Paris, le cluster de base de données est reparti. Les environnements sont accessibles normalement. Nous finirons les opérations techniques dans la nuit prochaine. VSDB est accessible mais la synchronisation en temps réel est arrêtée jusqu'à demain.
A 11h30 heure de Paris, la synchronisation s'est achevée mais le noeud n'est pas reparti correctement et l'ensemble du cluster s'est arrêté. Nous devons rendre indisponible GRP3 pendant 2 à 3 heures pour la remettre en route correctement. Aucune donnée n'a été perdue. VSDB peut toujours être consulté.
Depuis ce matin 9h30 heure de Paris, un des serveurs du groupe 53 a été redémarré suite à un problème technique. L'état de la base de données nécessite une synchronisation complète qui est en cours.
Cela peut impacter les performances des environnements sur ce groupe.
La réplication VSDB n'est pas impactée.
Depuis le jeudi 29 juin 21h30 heure de Paris, la réplication VSDB des environnements du groupe 5 est interrompue. Des problèmes réseau ont coupé la réplication. Tout sera en route dans la nuit du 30 juin eu 1er juillet. En attendant le serveur VSDB sur le groupe 5 est fonctionnel.
]]>Mise à jour à 12h30 heure de Paris : Nous avons pu relancer le cluster du groupe 1. Il semble que le problème vienne du stockage des fichiers de logs qui a été rempli en l'espace d'une heure. Nous prévoyons une coupure pour maintenance, ce soir le samedi 17 juin à 21h heure de Paris pour resynchroniser les données de tous les noeuds. Il faudra prévoir entre 2 et 3 heures de coupure.
Depuis 12h heure de Paris, tous les environnements du groupe 1 sont inaccessibles, nous cherchons à identifier la cause du problème.
]]>Vendredi 16 juin à 9h05 heure de Paris, un des serveurs du cluster de base de données du groupe 4 est tombé à cause d'un problème de synchronisation de données. Nous allons devoir lancer une synchronisation des données au moment de la pause déjeuner pour limiter l'impact sur la production.
]]>Après analyse, il semble que le problème vienne de notre réseau privé. Scaleway a ouvert plusieurs incidents sur le sujet et il semble que nous soyons impactés.
Nous avons solutionné le problème le 15 juin vers 10h30 heure de Paris en changeant le système de répartition de charge de notre cluster de base de données.
]]>Mise à jour à 14h00 heure de Paris : le cluster est à nouveau complètement opérationnel. Le service n'a pas été interrompu, seules quelques lenteurs ont pu être constatées en fin de matinée. Nous allons resynchroniser l'environnement de secours et le service VSDB pour relancer la réplication.
Mise à jour à 11h40 heure de Paris : nous avons récupéré le serveur, la mémoire était saturée. Après un reboot, nous avons lancé une resynchronisation des données.
Bonjour, ce matin à 10h25 heure de Paris, nous avons perdu la connexion avec un serveur de base de données du groupe 5. Pas d'impact pour le moment sur l'utilisation des environnements applicatifs. Nous cherchons à récupérer le serveur et à le remettre dans le cluster.
VSDB pour le groupe 5 est toujours disponible, mais la réplication en temps réel n'est pas en fonctionnement.
]]>La réplication de la plateforme VSDB du groupe 2 est à l'arrêt suite à un problème réseau. Nous allons couper la plateforme et resynchroniser les données. L'opération va prendre entre 2 et 3 heures.
]]>Le 7 juin 2023 à 11h00 heure de Paris : le répartiteur de charge du cluster de base de données de GRP5 a été complètement redémarré. Le problème semblait venir de ce composant, nous avons pu trouver des traces d'erreur dans les logs de ce dernier.
Le 7 juin 2023 à 10h00 heure de Paris : des utilisateurs nous remontent des problèmes de connexion par intermittence. Nous analysons pour comprendre le problème.
Le 6 juin 2023 de 8h55 à 9h05 et de 15h25 à 15h35 heures de Paris, les environnements du groupe 5 ont été indisponibles.
Il s'agit vraisemblablement d'un problème sur notre réseau privé, le cluster de base de données n'était pas joignable. Aucune donnée n'a été perdue pendant les 2 coupures.
Tout fonctionne normalement actuellement.
Le service VSDB des environnements GRP5 est indisponible. Nous cherchons la cause du problème.
]]>Mise à jour à 22h30 heure de Paris : Scaleway a pu débloquer le problème réseau, nous tentons de réintroduire les serveurs dans le réseau privé adapté.
Mise à jour à 14h50 heure de Paris : tous les environnements confirmés ont été migrés sur d'autres groupes et sont maintenant accessibles. Nous attendons toujours une solution de la part de notre hébergeur pour remettre en route le groupe 8.
Mise à jour 13h20 heure de Paris : sans solution de Scaleway, nous décidons de basculer les environnements de GRP8 vers un autre groupe, nous mettrons à jour l'incident quand la migration sera terminée.
Mise à jour à 12h30 heure de Paris : la situation est bloquée, une partie de nos serveurs ne sont plus accessibles via notre réseau privé. Nous attendons que Scaleway revienne vers nous avec une solution.
Les serveurs de base de données du groupe 8 sont indisponibles à cause d'un problème de configuration réseau. Nous faisons le nécessaire pour les serveurs soient à nouveau disponibles rapidement.
]]>28/03/2023 - Le serveur a été relancé ce matin pour ouvrir l'accès au service VS-DB. Le support Scaleway cherche une solution. Si aucun problème n'est trouvé dans l'après-midi, nous organiserons la bascule vers une autre instance.
27/03/2023 - 15h10 heure de Paris. Le support m'indique que le problème va être escaladé. Le serveur est coupé depuis 14h00 heure de Paris.
La plateforme VS-DB du groupe 2 est instable et perd sa connexion réseau utilisée pour la réplication en temps réel. Nous allons demander au support Scaleway d'intervenir, il est possible que le serveur soit coupé et la connexion impossible à utiliser dans la journée.
]]>Notre connexion internet ne permet pas de gérer la téléphonie sur IP du support. Les appels avec le support sont très saccadés et l'audio est parfois inaudible. Nous coupons le système de téléphonie le temps de revenir à la normale.
Vous pouvez toujours contacter le support par le système de ticket écrit.
La ligne du support sera à nouveau ouverte le jeudi 23 mars.
Merci de votre compréhension
]]>Les environnements du groupe 7 sont inaccessibles depuis 12h05 heure de Paris. Nous cherchons la cause.
]]>Nous nous excusions pour la gêne occasionnée.
]]>Le service VSDB du groupe 1 va être coupé pendant 1h30 environ pour remettre en route la réplication en temps réel qui est arrêté depuis l'incident avec le cluster de base de données d'hier.
]]>Mercredi 18 janvier 2023 à 21h45 heure de Paris, la synchronisation se poursuit sur la dernière node.
Mercredi 18 janvier 2023 à 18h heure de Paris, le cluster est tombé pendant la synchronisation. Nous avons du arrêter toutes les nodes. Les environnements GRP1 seront inaccessibles pendant plusieurs heures le temps que nous remontions correctement le cluster. Merci de votre compréhension. Aucune données n'a été perdue.
Mercredi 18 janvier 2023 à 16h00 heure de Paris, le trafic est redirigé vers un noeud disponible du cluster, la synchronisation continue. Les environnements sont utilisables à nouveau normalement.
Mercredi 18 janvier 2023 à 15h45 heure de Paris, un serveur du cluster de base de données du groupe 1 est tombé. Il est reparti et une synchronisation complète s'est lancée rendant le cluster très lent voire indisponible.
Nous allons rapidement envoyer le trafic sur un nœud disponible pour rendre le groupe utilisable.
]]>Le cluster GRP1 est à nouveau tombé, le système de ticketing ne pas utilisable, nous allons nous focaliser sur la remise en route de la base de données de production des environnements VSA/VSP/VSE.
Le système de ticketing est à nouveau utilisable.
Mercredi 18 janvier 2023 à 15h45 - Notre système de ticketing utilisé par le support est hors service, il est impacté par l'incident survenu sur le cluster de base de données du groupe 1. Nous allons rediriger le trafic vers un noeud disponible rapidement.
]]>Mardi 17 janvier 2023 à 23h heure de Paris - Le cluster GRP4 est migré et en fonctionnement normal, y compris les réplications de secours et VSDB. GRP1 quant a lui est toujours en cours de migration, nous avons rencontré un problème sur un des serveurs et une synchronisation est nécessaire, cela rallonge sensiblement le temps nécessaire à toute l'opération. GRP1 devrait être à nouveau disponible vers 0h30 heure de Paris.
Mardi 17 janvier 2023 à 20h38 heure de Paris - Nous allons très vite couper les environnements de GRP1 et GRP4 et commencer la migration.
Le mardi 17 janvier 2023 à 20h30 heure de Paris, les environnements sur GRP1 et GRP4 seront coupés pour une durée de 3h environ. Nous effectuons une montée de version du logiciel de base de données utilisé.
Pour connaître votre groupe, vous pouvez ouvrir le popup "A propos de l'application" après avoir cliqué en haut à droite sur la photo de votre utilisateur depuis l'application.
Le service VSDB associé à GRP1 et GRP4 sera encore disponible mais la réplication en temps réel sera coupée et ne reprendra que le lendemain, mercredi 18 janvier 2023 dans la matinée.
]]>Depuis hier jeudi 5 janvier 2022, nos serveurs MX sont sur la blacklist ZapBL https://zapbl.net .
En réalité beaucoup d'adresses IP de notre hébergeur Scaleway sont listées à cause d'un seul serveur mal configuré, serveur qui n'a rien à voir avec Veryswing. Scaleway a été prévenu et leur équipe trust & safety est en communication avec ZapBL pour délister les adresses IP.
Cela peut impacter l'envoi des emails de nos applications, certains serveurs SMTP utilisant des systèmes antispam se basant sur plusieurs blacklist comme ZapBL.
]]>Le problème de disque a été corrigé mais le serveur ne démarre pas. Une réinstallation va peut-être être nécessaire. Nous faisons le nécessaire.
Dimanche 25 décembre à 22H heure de Paris, nous avons du couper le service VSDB du groupe 5 car le RAID ne fonctionnait plus correctement sur la partition de stockage des données. Le support Scaleway intervient en ce moment et cherche la cause, il s'agit probablement d'un disque dur hors service.
]]>La carte réseau a été changée, le serveur est à nouveau accessible. Nous le réintégrerons dans la nuit au système de cache. Normalement aucune coupure n'est à prévoir pendant cette opération.
Ce matin à 5h du matin, heure de Paris, un de nos serveurs de cache a perdu sa connexion à son réseau privé. L'accès à la plateforme était alors impossible, le système de cache étant inopérant. À 7h20 heure de Paris, nous avons pu remettre en route le système de cache en limitant l'accès aux serveurs encore accessibles.
Nous avons analysé le dysfonctionnement et il semble qu'une carte réseau hors service soit la cause de la perte de l'accès au réseau. Nous avons demandé à notre hébergeur de remplacer la carte réseau défectueuse. Nous mettrons à jour cet incident en fonction de l'avancement.
]]>Le problème a eu un impact pendant 10 minutes sur d'autres groupes car notre load balancer a mal détecté l'anomalie. Une fois le serveur de base de données en cause coupé, toute la plateforme a été de nouveau accessible avec le groupe 5 sur 2 serveurs de base de données mais parfaitement fonctionnel.\
A 20h30 heure de Paris, le serveur en cause a été relancé et le groupe 5 a retrouvé son état normal.\
Nous analysons ce qui a pu provoquer l'accroissement des fichiers temporaires afin de comprendre et d'éviter que le problème se reproduise.
]]>Les environnements ont été réouverts à 23h20 heure de Paris. Nous avons rencontré un problème sur la troisième node du cluster, un problème de réseau, le support Scaleway est en train de regarder. La troisième node a été migrée, mais n'a pas encore rejoint le cluster.
Il est 21h heure de Paris, nous démarrons la maintenance, les environnements du groupe 3 ne seront pas accessible pendant environ 2 heures.
Le jeudi 15 décembre à 21h heure de Paris, les environnements sur GRP3 seront coupés pour une durée de 2h30 environ. Nous effectuons une montée de version du logiciel de base de données utilisé.
Pour connaître votre groupe, vous pouvez ouvrir le popup "A propos de l'application" après avoir cliqué en haut à droite sur la photo de votre utilisateur depuis l'application.
Le service VSDB associé à GRP3 sera encore disponible mais la réplication en temps réel sera coupée et ne reprendra que le lendemain, vendredi 16 décembre 2022 dans la matinée.
A 11h, heure de Paris, nous coupons le service VSDB sur GRP1 pour y intégrer la sauvegarde de la veille et remettre en place la réplication.\
La réplication VSDB pour GRP1 est arrêtée à cause d'un problème de disque qui a eu lieu lundi 14 novembre 2022 à 21h30 heure de Paris.
Les données sont accessibles mais ne sont plus mises à jour.\
Pour remettre en route la réplication, nous allons devoir couper le service pour GRP1 dans la matinée pendant environ 1 heure.\
Nous mettrons à jour l'incident dès que nous commencerons les opérations de remise en route.
]]>Vendredi 7 octobre à 15h49 heure de Paris, un serveur de base de données du groupe 4 s'est arrêté.
Au redémarrage, une synchronisation totale des données s'est lancée. Nous avons redirigé le trafic vers le noeud du cluster qui n'est pas occupé dans le cadre de cette synchronisation.
Nous fermerons l'incident quand la synchronisation du noeud en démarrage sera complète.
]]>Le serveur en cause a été purgé et redémarré. Il a été réintégré au pool de cache.
Nous prévoyons plusieurs changements pour éviter qu'une telle situation se reproduise :
Un de nos serveurs de cache était en cause, nous l'avons manuellement enlevé du pool. Nous cherchons la cause du problème.
Nos serveurs d'applications sont en erreur. Il semble que ce soit l'accès à nos serveurs de cache qui soit en cause. Nous recherchons la cause exacte et une solution.
]]>Une version corrigée de HAProxy vient d'être publiée, après un test concluant, nous déployons sur nos Load Balancer de production cette nouvelle version qui corrige le problème avec Android et MyVS en HTTP2.
Nous testons de désactiver le protocole HTTP 2 sur nos load balancer et les terminaux Android arrivent à nouveau à passer des requêtes HTTP avec succès. Nous déployons ce changement de configuration.
L'étape suivante, c'est de comprendre ce qui provoque un problème entre notre load balancer, le protocole HTTP 2 et les terminaux Android.
Après avoir passé en revue tous nos composants, nous constatons que l'API utilisée par MyVS est fonctionnelle, mais les requêtes HTTP envoyées par les terminaux Android ne sont pas traitées correctement et reçoivent une erreur HTTP 500 en réponse. Techniquement, tout est ok pourtant.
Notre équipe support nous indique qu'il est impossible de se connecter à l'application MyVS depuis n'importe quel terminal sous Android.
]]>Les données sont synchronisées, le cluster est au complet avec ces 3 nœuds. Le load balancer du groupe ne rencontre plus de difficulté à servir les demandes. Nous allons analyser la cause du problème au niveau du nœud qui subit un problème technique en début d'après-midi.
Nous allons également travailler à l'amélioration de la répartition de charge pendant une resynchronisation des données, un seul nœud pouvant accueillir correctement les demandes, l'autre étant occupé à fournir les données au nœud qui redémarre.
Nous avons réussi à forcer le trafic vers le noeud du cluster qui n'est pas occupé à effectuer la réplication, les environnements sont à nouveau accessibles normalement.
un des serveurs du cluster de base de données du groupe 4 a subi un problème de synchronisation de données. Nous avons déclenché une resynchronisation des données vers 13h50 heure de Paris, néanmoins nous observons des erreurs de connexion aléatoires depuis que nous avons lancé cette synchronisation.
Plus de la moitié des données a été synchronisée.
À la fin de la synchronisation, tout rentrera dans l'ordre.
Nous nous excusons pour la gêne occasionnée.
]]>Bonjour, nous faisons un retour suite à l'incident d'hier pour vous détailler ce qu'il s'est passé et comment nous avons réussi à fournir un accès à nos clients.
Le 7 avril 2022 à 15h35 heure de Paris exactement, notre load balancer principal, le point d'entrée quand on utilise nos services, n'a plus reçu aucun trafic public (d'internet). Pour cette situation précise, nous avons une procédure, basculer les adresses IP vers un autre load balancer, celui de secours, qui attend sagement. Nous lançons la bascule, mais l'opération reste en statut "Mise à jour en cours", normalement, c'est une opération qui prend quelques dizaines de secondes, mais la au bout de 5 minutes, rien ne se passe. Les IP pointent toujours vers le load balancer principal qui n'est pas accessible.
Nous avions déjà ouvert un ticket à l'assistance Scaleway pour leur indiquer que notre load balancer était inaccessible depuis l'extérieur. Nous ouvrons un second ticket en mode urgent pour indiquer que la bascule de nos adresses IP flottantes, celle qui reçoivent tout le flux entrant de nos services, ne basculent pas. Réponse de l'assistance : nous avons un switch hors service dans la baie de votre load balancer principal et les bascules d'adresses IP flottantes sont bloquées tant que le switch ne sera pas remplacé, il va falloir être patient. Nous commençons donc à attendre, en espérant que le remplacement du switch aille vite.
A 16h30 toujours pas d'information sur l'incident chez Scaleway. Remplacer un switch, ça peut être long, au-delà de l'opération physique, il faut recharger la configuration et ce n'est pas forcément simple. Nous sentons que ça va être long. Nous décidons de monter un 3ème load balancer avec de nouvelles adresses IP pour nous services. Nous trouvons une stratégie pour modifier les enregistrements DNS en masse pour pointer vers les nouvelles adresses IP et à 17h, le nouveau load balancer commence a recevoir du trafic.
Nous avons donc appris que l'utilisation d'adresses ip flottantes pouvait être un point bloquant et nous intégrons dans nos procédures l'utilisation d'adresses IP de secours pour gérer ce genre de situation.
La bascule d'adresse IP est restée bloquée jusqu'à 22h30 heure de Paris et Scaleway a subi un autre problème de switch dans la nuit qui a paralysé cette fois-ci notre load balancer de secours. Nous sommes donc encore sur le load balancer monté hier spécialement pour cet incident. Nous prévoyons de basculer sur le load balancer principal ce week-end et nous gardons ce troisième load balancer en cas d'incident similaire.
Mise à jour à 17h heure de Paris. Les équipes de Scaleway sont sur le problème. Nous avons décidé de mettre en route un troisième load balancer qui n'est pas impacté par le problème réseau de Scaleway. Le DNS est en cours de mise à jour.
Bonjour,
Depuis 15h35 heure de Paris, nos 2 load balancers sont injoignables depuis internet. Toute la plateforme VSA / VSP / VSE est fonctionnelle au travers de nos réseaux privés, mais inaccessible depuis l'extérieur. Nous nous rapprochons actuellement de notre hébergeur pour savoir ce qu'il en est.
]]>La plateforme qui héberge les environnements PP ne fonctionne plus depuis hier mardi 15 février 2022 16h heure de Paris. Notre hébergeur cherche une solution. Si à 12h heure de Paris la situation ne s'est pas améliorée, nous basculerons sur une autre plateforme.
]]>Depuis dimanche 26 décembre 12h heure de Paris, le service VSDB sur les environnements du groupe 5 sont indisponibles. Le système rencontre des problèmes de disques. Notre hébergeur doit faire le nécessaire dans la journée. Nous revenons vers vous dès que c'est corrigé.
]]>Depuis 22h heure de Paris, les environnements du groupe 5 sont inaccessibles. Le cluster de base de données était complètement bloqué, nous tentons de le remettre en route.
]]>Scaleway, notre hébergeur, réalise une maintenance importante sur des équipements réseaux qui impactent notre réseau privé et nous sommes dans l'obligation de couper le service de production mercredi 15 décembre 2021 entre 8h et 9h heure de Paris.
]]>Depuis 16h30 heure de Paris, l'ensemble des environnements du groupe 1 ne sont plus accessibles. Nous recherchons la cause du problème.
]]>Ce soir à 22h20 heure de Paris, nous avons constaté des erreurs anormales de notre système de centralisation des logs. Devant la quantité d'erreur remontées, nous avons décidé de couper le service VSActivity le temps de comprendre ce qu'il se passe. Nos équipes sont actuellement en train de faire une analyse complète. Dès que nous en savons plus, nous mettrons à jour cet incident. Merci
]]>Ce soir à 22h20 heure de Paris, nous avons constaté des erreurs anormales de notre système de centralisation des logs. Devant la quantité d'erreur remontées, nous avons décidé de couper le service VSPortage le temps de comprendre ce qu'il se passe. Nos équipes sont actuellement en train de faire une analyse complète. Dès que nous en savons plus, nous mettrons à jour cet incident. Merci
]]>Mise à jour à 9h30 heure de Paris, le serveur a été relancé électriquement et tout fonctionne à nouveau.
]]>Ces erreurs étaient dues à un bug de notre load balancer suite à une montée de version qui corrigeait des failles de sécurité. Cette anomalie n'avait pas été constatée lors de notre test de montée de version.
Un correctif du load balancer a été publié le matin du 23 août vers 9 h45. Celui-ci a été installé et nos tests ont confirmé que l'anomalie a été corrigée.
]]>Jeudi 6 mai 2021 à 17h30 heure de Paris : La copie est terminée, les environnements GRP1 sont ouverts. La réplication du dernier noeud est en cours. VSDB des bases du groupe 1 n'est plus mis à jour depuis l'incident, la réplication sera remise en route demain matin après la sauvegarde de la nuit. Le service VSDB est néanmoins fonctionnel.
Jeudi 6 mai 2021 à 16h55 heure de Paris : nous sommes à 90% copie du premier noeud.
Jeudi 6 mai 2021 à 16h00 heure de Paris : la réplication a ralenti, il y a un peu de la moitié des données qui sont synchronisées. Nous pouvons imaginer que la copie sera complète vers 17h30, c'est une estimation. Nous ferons une mise à jour du statut à 16h45.
Jeudi 6 mai 2021 à 14h59 heure de Paris : nous sommes contraints de resynchroniser les 2 noeuds arrêtés. La synchronisation du premier noeud a commencé, quand elle sera terminée (estimation 16h heure de Paris), nous pourrons réouvrir les environnements et lancer la seconde synchronisation.
Jeudi 6 mai 2021 à 14h25 heure de Paris : 2 noeuds de notre cluster de base de données du groupe 1 se sont arrêtés. Le service est inaccessible pour ces environnements, le cluster ne fonctionne pas avec seulement 1 noeud en route. Nos équipes travaillent à les redémarrer le plus rapidement possible.
]]>Depuis 7h18 heure de Paris, le service VSDB pour le groupe 5 est indisponible. L'environnement technique s'est arrêté de fonctionner à cause d'un problème matériel. Notre hébergeur a été prévenu et travaille sur le problème.
]]>Le dimanche 21 mars 2021 à 9h15 heure de Paris, nous avons constaté un problème réseau sur notre système de stockage de fichier. Notre hébergeur a été prévenu et cherche la cause du problème. Cela impacte le service pour ce qui concerne la lecture et la sauvegarde de fichier sur toute la plateforme : VSActivity, VSPortage et MyVS.
]]>Le dimanche 21 mars 2021 à 9h15 heure de Paris, nous avons constaté un problème réseau sur notre système de stockage de fichier. Notre hébergeur a été prévenu et cherche la cause du problème. Cela impacte le service pour ce qui concerne la lecture et la sauvegarde de fichier sur toute la plateforme : VSActivity, VSPortage et MyVS.
]]>Tout est revenu à la normale à 14h30 heure de Paris.
-- Mercredi 10 février , depuis 12 h, heure de Paris, certains utilisateurs nous signalent que la connexion est impossible. Après une première analyse, il semble que cela vienne de notre répartiteur de charge qui dirige mal les connexions. Nous cherchons une solution.
En attendant qu'une solution soit trouvée, si vous êtes bloqué, 2 solutions vous permettent à nouveau de vous connecter :
Nous avons réduit un paramètre afin de ne plus avoir ce problème.
]]>Le service VSDB du groupe 5 est fonctionnel mais n'est plus répliqué en temps réel. La remise en route de la réplication est prévue dans la nuit.
Mercredi 28 octobre 10h30 heure de Paris : le cluster de base de données du groupe 5 s'est arrêté. Il semble qu'un problème réseau entre les serveurs du cluster en soit la cause. Nous recherchons à démarrer le cluster.
]]>Jeudi 22 octobre 2020 à 17h15 heure de Paris. Le cluster de base de données des environnements du groupe 1 n'accepte plus les modifications. Ce problème bloque complètement l'usage de ces environnements. Nous cherchons l'origine du blocage.
]]>Nous nous excusons pour la gêne que cela a pu engendrer ce matin pour les utilisateurs qui ont tenté de mettre à jour des données avec présence de la gestion des territoire et pour la déconnexion brutale subie vers 11 h.
Depuis la mise en production de la nuit dernière, nous rencontrons un problème technique au niveau de la gestion des territoires : régions, états, province, etc. Tous les formulaires qui font appel à cette notion ne s'affichent pas. Seulement la production est impactée, toutes nos autres plateformes fonctionnent correctement.
Nos tests de montée de version n'ont pas montré ce problème, c'est pour cela que nous découvrons tardivement le souci.
Actuellement, nous cherchons la cause du problème.
]]>Nous nous excusons pour la gêne que cela a pu engendrer ce matin pour les utilisateurs qui ont tenté de mettre à jour des données avec présence de la gestion des territoire et pour la déconnexion brutale subie vers 11 h.
Depuis la mise en production de la nuit dernière, nous rencontrons un problème technique au niveau de la gestion des territoires : régions, états, province, etc. Tous les formulaires qui font appel à cette notion ne s'affichent pas. Seulement la production est impactée, toutes nos autres plateformes fonctionnent correctement.
Nos tests de montée de version n'ont pas montré ce problème, c'est pour cela que nous découvrons tardivement le souci.
Actuellement, nous cherchons la cause du problème.
]]>-- Le service d'analyse sémantique n'est plus fonctionnelle, nous avons contacté le support du service pour avoir des informations.
]]>-- Mise à jour à 8h50 heure de Paris. Nous avons identifié la cause du problème, le protocole http/2.0 empêche le chargement des fichiers JS et CSS sur les navigateurs, nous l'avons désactivé pour le moment.
L'application fonctionne à nouveau correctement, aucun impact à prévoir pour les utilisateurs.
Nous cherchons la cause du problème pour réactiver le protocole http/2.0.
-- Depuis ce matin 8h20 heure de Paris, nous constatons des problèmes de chargement de certains fichiers javascript et CSS dans l'application VSActivity. Cela rend l'utilisation de l'application impossible. Nous cherchons actuellement la cause de ce dysfonctionnement.
]]>Le problème s'était stabilisé dans la journée du 11 mai sans coupure après 10h heure de Paris.
Le problème a été complètement résolu dans la nuit du 11 au 12 mai.
--
Nous rencontrons des problèmes avec les répartiteurs de charge du cluster de base de données du groupe 5.
L'adresse IP virtuelle utilisée par les 2 répartiteurs de charge se retrouve inaccessible ce qui oblige à redémarrer les services concernés sur les 2 équipements.
Nous cherchons la cause du problème.
]]>Raison :
Le traitement concerné est en cours d'identification afin que cela soit traité à l'avenir et que cela ne se reproduise plus.
Groupe 1 mis sous surveillance par notre équipe Système.
]]>Raison :
Le traitement concerné est en cours d'identification afin que cela soit traité à l'avenir et que cela ne se reproduise plus.
Groupe 1 mis sous surveillance par notre équipe Système.
]]>Le redémarrage de notre service de cache s'est bien passé, mais une partie des données qui sont remontées en cache étaient incomplètes. Nous n'avions pas de sonde au niveau de nos outils de surveillance pour détecter une telle anomalie.
Cela a entrainé des problèmes de paramètres au niveau de la moitié des environnements VSA et VSP, paramètres qui étaient mal initialisés.
Ce matin, le 6 septembre à 9h15 heure de Paris, l'équipe support a alerté l'équipe système de ces dysfonctionnements. A 9h30 heure de Paris, l'équipe système a forcé une purge de notre système de cache afin de remettre les bons paramétrages dans celui-ci. Cette action a résolu les incidents remontés par nos clients.
Depuis cet incident, l'équipe système fait le nécessaire pour mettre en place une sonde au niveaux de nos outils de surveillances afin de détecter ce type d'anomalie. Notre procédure de redémarrage du système de cache va également être mise à jour pour contrôler que les données sont bien remontées une fois celui-ci redémarré. Notez que dès qu'un incident se produit, nous cherchons systématiquement à améliorer nos procédures pour que l'incident en question ne se reproduise pas, mais également pour que nos outils de surveillances détectent l'incident afin de pouvoir réagir rapidement.
]]>Corrigé et donc l'analyse est maintenant débloquée.
]]>--
Nous rencontrons un problème avec les services VSDB pour GRP1 et GRP4. La base de données est arrêtée suite à un problème sur un serveur. Nous devons désynchroniser les services VSDB avec les données de production. La service sera à nouveau disponible dans la soirée.
]]>--
En raison de très fortes chaleurs prévues les 24 et 25 juillet, notre hébergeur Scaleway (Online) nous informe qu'il met tout en oeuvre pour maintenir ses services en fonctionnement. Néanmoins, la situation est assez exceptionnelle, et il n'est pas exclu que des coupures des services VSA et VSP soient nécessaires pour éviter d'endommager du matériel si la température dans les datacenters n'arrivait pas à être maintenue de la manière satisfaisante.
Chez Veryswing, nous nous tenons prêt à réagir et nous suivons avec attention la situation.
Les périodes les plus critiques sont celles-ci :
Nous communiquerons au travers de ce site de statut pour vous informer de la situation.
]]>--
Mise à jour le 08/07/2019 à 17h45 heure de Paris : le service VSDB a été migré vers un serveur de secours. L'opération a été plus longue que prévue car nous avons rencontré un problème de disque sur l'environnement de secours. Nous vous présentons toutes nos excuses pour le délai de rétablissement du services. Nous clôturerons cet incident quand le service sera revenu sur le serveur de production.
Mise à jour le 08/07/2019 à 14h heure de Paris : le serveur ne redémarre, il semble qu'une mise à jour du microcode intel soit la cause du problème. Nous entamons la bascule sur une machine de secours. Le service devrait revenir à la normale avant la fin de journée.
Le serveur VSDB qui réplique GRP1 est KO depuis 10h15 heure de Paris ce lundi 8 juillet 2019. Notre hébergeur a été prévenu nous attendons son retour pour savoir si le serveur peut redémarrer ou si nous devons basculer sur un autre système. Nous revenons vers vous dès que nous avons plus d'informations.
]]>-- Le service est revenu à la normale le 8 mars en soirée. Notre prestataire a rencontré des soucis lors de la mise à jour de son certificat SSL.
]]>Mise à jour à 11h15 heure de Paris : le serveur est arrêté suite à un problème matériel, notre hébergeur examine le problème et cherche une solution.
-- L'instance MySQL VSDB sur groupe 2 ne répond plus, nous analysons le problème.
]]>-- Mise à jour à 14h heure de Paris : Il s'agit d'un problème de DNS, la situation est en cours de résolution, la situation va revenir à la normale dans la journée.
-- Depuis 10h heure de Paris, le service d'analyse sémantique que nous utilisons n'est plus disponible. Nous avons ouvert un ticket au support du service pour avoir des informations sur les causes et l'heure de retour à la normale.
]]>19/10/2018 à 10h03 heure de Paris : Suspension temporaire de nos services.
]]>19/10/2018 à 10h03 heure de Paris : Suspension temporaire de nos services.
]]>Mise à jour le 11/10/2018 à 16h57 heure de Paris : Un des serveurs de base de données est tombé, la resynchronisation s'est bien lancée, le serveur restant était disponible mais un problème réseau empêchait son accès. Le problème réseau a du être résolu, la synchronisation des serveurs va se terminer dans les minutes qui suivent, tout reviendra à la normale avant 18h heure de Paris.
Message original : Les environnements du groupe 1 sont indisponibles. Cela semble venir du cluster de base de données. Nous cherchons la cause de la panne.
Les autres groupes d'environnements ne sont pas impactés.
]]>Le serveur VSDB du groupe 1 a du être coupé suite à un problème réseau qui bloque la réplication des données avec la production.
]]>Nous rencontrons un problème de synchronisation de la base VSDB pour le groupe 1. Il semblerait que l'interface réseau utilisée pour la synchronisation soit défaillante. Notre hébergeur doit procéder à des vérifications et nous devons arrêter le service.
Merci de votre compréhension
]]>10h05 : problème corrigé - Microsoft a fait une mise à jour Office 365 et le message de retour suite à une authentification était modifié, nous avons traité le sujet. Cela remarche correctement maintenant.
]]>10h05 : problème corrigé - Microsoft a fait une mise à jour Office 365 et le message de retour suite à une authentification était modifié, nous avons traité le sujet. Cela remarche correctement maintenant.
]]>Le service d'analyse sémantique ne fonctionne plus depuis 9h30 heure de Paris le lundi 18 juin. Le système de vérification des licenses semble hors service. Le support a été prévenu, nous attendons leur retour pour avoir une idée du temps de rétablissement.
]]>Le système a été à nouveau fonctionnel le 8 mai 2018 vers 16h heure de Paris.
]]>Mise à jour le 03/04/2018 à 21h30 : Nous lançons la restauration de la base pour retrouver une instance synchronisée.
L'instance VSDB du groupe 1 n'est plus synchronisée avec la production. L'instance est toujours accessible. Un arrêt de 2 heures sera nécessaire pour remettre la synchronisation en route. Nous réfléchissons au meilleur créneau horaire pour effectuer cette opération.
]]>Le service de parsing de CV de la société Eptica Lingway rencontre des difficultés de fonctionnement ce matin. En conséquence, l'analyse sémantique des CV dans VSA/VSP ne fonctionne plus. L'incident est en cours de résolution chez eux. Tout devrait être rentré dans l'ordre à 11h30.
]]>13h15: Le groupe GRP1 est hors service actuellement. Notre équipe technique travaille à la reprise des services pour nos clients ayant leur environnement sur ce groupe.
]]>Dans les jours qui viennent nous allons progressivement mettre à niveau nos serveurs pour que notre infrastructure technique ne soit pas vulnérable aux problèmes de sécurité mis en avant dans les médias sous le nom de Meltdown et Spectre.
Nos serveurs sont tous en architecture Intel sous Linux Debian. Notre hébergeur principal, Online.net, tient à jour une page sur la mise à disposition des mises à jour pour les micrologiciels des serveurs : https://blog.online.net/2018/01/03/important-note-about-the-security-flaw-impacting-arm-intel-hardware/ Debian a porté un correctif pour Meltdown (KPTI patch) que nous avons déjà commencé à déployer. Aucun correctif pour spectre n'est disponible pour le moment, nous attendons qu'un patch soit disponible pour les serveurs et Linux.
L'application de ces mises à jour nécessite des redémarrages de nos serveurs. Normalement aucune coupure n'est à prévoir car tous nos systèmes sont en haute disponibilité. Si des coupures sont à prévoir, nous vous le ferons savoir sur notre site de statut.
Cordialement
Antoine Fougnies et Nicolas Saillet
]]>Nous vous présentons toutes nos excuses pour la gène occasionnée.
7h30 : Nos services sont temporairement suspendus. Nos équipes sont en lien avec celles de notre hébergeur (Online.net) et travaillent à un redémarrage le plus rapidement possible. Nous avons bien en tête que nous sommes le premier jour du mois de décembre et qu'aujourd'hui, plus qu'un autre, VSA et VSP sont fortement sollicités. Soyez assurés de notre engagement et de notre implication à traiter ce sujet !
]]>