Une opération de resynchronisation du cluster MySQL GRP7 est prévue ce vendredi 20 mars à partir de 21h heure de Paris.
Des interruptions de service sont donc à prévoir pendant cette fenêtre.
]]>A 11h00 heure de Paris, les environnements sont accessibles. Le cluster n'a pas pu être redémarré rapidement. Pour ne pas trop perturber le service, un seul noeud a été redémarré en mode autonome. La remise en route complète du cluster aura lieu dans la soirée/nuit à partir de 21h, les environnements ne sont pas accessibles pendant environ 3 heures. Nous analysons plus en détail le problème, une incohérence dans les données semble être la cause de l'arrêt, le cluster s'arrête, c'est une sécurité.
Les environnements du groupe 7 sont actuellement inaccessibles depuis 10h45 heure de Paris.
Le cluster de base de données s’est arrêté, entraînant cette interruption de service. Les équipes sont en cours d’investigation afin d’identifier la cause et de rétablir l’accès dans les meilleurs délais.
Nous vous tiendrons informés de l’évolution de la situation.
]]>Depuis 17h30 heure de Paris, la réplication de la plateforme VSDB des environnements du groupe 3 est bloquée. Après une rapide analyse a permis de déterminer qu'une restauration était nécessaire. Nous venons de lancer la restauration, le service sera coupé pendant 1 heure environ.
]]>Un incident impacte actuellement uniquement l’envoi et la réception des factures via le réseau Peppol belge
Les autres modes d’envoi et de réception ne sont pas impactés. Nos équipes travaillent au rétablissement du service dans les meilleurs délais.
]]>Pendant cette période, le service d'émission et de réception de facturation électronique belge sera indisponible, ce qui entraînera les impacts suivants :
Nous vous recommandons, si possible, d’anticiper vos envois en dehors de cette plage horaire.
]]>Suite à l'incident de ce matin, nous allons arrêter le cluster des environnements du groupe 7 pendant 1 heure environ de 22h à 23h heure de Paris pour remettre en route le cluster en mode normal.
]]>Mise à jour 8h55 heure de Paris : nous rouvrons les services à nos utilisateurs avec une partie de l'infrastructure basculée sur l'environnement de secours. Les environnements du groupe 7 ne sont pas encore accessible, nous devons déporter tout le cluster de base de données, quelques minutes sont encore nécessaires.
La maintenance Scaleway planifiée ce matin de 6h à 8h heure de Paris est terminée mais a engendré un problème technique de leur coté qui bloque le redémarrage de certains de nos services. Nous attendons une mise à jour du statut de l'incident de leur coté pour savoir quoi faire. Si cela dure trop, nous enclencherons nos scénarios de continuité d'activité.
]]>Mise à jour à 7h40 heure de Paris : la maintenance Scaleway est très longue. Il faudra plusieurs minutes pour relancer nos services une fois la maintenance terminée. Une fin au delà de 8h heure de Paris est à prévoir.
Mise à jour à 7h20 heure de Paris : La maintenance est toujours en cours, nos services sont arrêtés pour ne pas créer de dysfonctionnements qui bloqueraient un redémarrage correct.
La maintenance est en cours, les coupures réseau perturbent nos services en cluster. Nous avons préféré couper nos services web en attendant un retour à la normal.
Scaleway effectue une maintenance programmée sur certains routeurs des réseaux privés de notre plateforme SaaS, planifiée le 14 janvier de 06:00 à 07:00 heure de Paris. Pendant cette intervention, le trafic interne de nos serveurs peut subir des perturbations ou des interruptions temporaires.
Le trafic public (internet) ne devrait pas être impacté.
L’impact réel pourrait durer jusqu’à 08:00 si l’intervention est prolongée.
Recommandation aux utilisateurs
S'il vous plait, reportez les opérations sensibles en dehors de cette plage horaire.
Cette version introduit une interface revisitée, que nous espérons plus agréable et intuitive à utiliser. N’hésitez pas à nous faire part de vos retours.
Merci pour votre patience.
Une opération de maintenance planifiée aura lieu ce soir à 21h30 (heure de Paris).
Cette intervention vise à déployer la version 26.0.0 de l’application, qui introduit une interface entièrement revisitée ainsi que plusieurs améliorations internes.
Aucune interruption de service n’est normalement à prévoir durant la maintenance.
Nous vous tiendrons informés en cas d’évolution de la situation.
Merci de votre compréhension.
]]>Mise à jour à 10h58 heure de Paris : la synchronisation est à plus de 50% sur le cluster des environnements du groupe 2.
Mise à jour à 10h18 heure de Paris : le cluster des environnements du groupe 2 va mettre 1h environ à se synchroniser, les accès devraient ouvrir vers 11h30 heure de Paris.
Mise à jour à 10h10 heure de Paris : l'accès a tous les groupes est revenu à la normale sauf pour les environnements du groupe 2. La cluster du groupe 2 est bloqué. Les load balancer ont bien détecté le problème mais ont coupé l'accès global à la plateforme. Cet accès a été rétabli pour tous les groupes sauf le 2 dont le cluster est en train de redémarrer.
Bonjour, depuis 9h50 heure de Paris, l'ensemble des environnements est inaccessible. Nous analysons la situation pour vous permettre de retrouver un accès rapidement.
]]>Une première intervention a eu lieu à 18h20 afin de rétablir l’accès aux fichiers. L’opérateur en charge a estimé que cela suffirait à relancer automatiquement le traitement des tâches, ce qui n’a malheureusement pas été le cas. À 21h45, constatant la persistance des alertes, une seconde intervention a été réalisée pour relancer explicitement le système de traitement. Cette opération a permis le retour à la normale.
Nous avons depuis ajusté nos procédures internes afin de renforcer les contrôles et d’éviter qu’une telle situation ne se reproduise. Il est à noter que l’incident s’est produit un samedi, ce qui a contribué au délai de résolution, malgré une première intervention rapide mais insuffisante.
Nous présentons nos excuses à nos clients pour la gêne occasionnée et vous remercions pour votre compréhension.
]]>Depuis hier jeudi 6 novembre 19h heure de Paris, la réplication VSDB des clients qui sont sur le groupe 4 ne fonctionne plus. VSDB est néanmoins accessible mais les données ne sont pas mises à jour. Nous travaillons au rétablissement du service, cela risque de prendre du temps et nous allons devoir attendre d'être en dehors des heures d'activité pour relancer certaines synchronisation de données pour ne pas impacter les utilisateurs.
]]>Depuis 14h16 heure de Paris, nous constatons un ralentissement du traitement des tâches asynchrones. Après analyse, il semble que ce soit l'ajout de nouveaux environnements qui soit à l'origine du problème. Une première relance du système de traitement des tâches asynchrone a semblé corriger le problème à 16h10 heure de Paris. Mais après quelques minutes, le nombre de tâches à traité était encore très important malgré une baisse importante les premières minutes.
Une seconde relance après resynchronisation de tous les fichiers semble corriger cette fois le problème. Second redémarrage à 16h50 heure de Paris. Le nombre de tâches en attente a significativement diminué et va revenir à la normale dans l'heure qui vient.
]]>Merci de votre compréhension.
]]>Bonjour, depuis une semaine la synchronisation des environnements VS-DB des environnements SANDBOX est à l'arrêt. Après plusieurs tentative de relance en échec, nous devons arrêter tout le service VS-DB SANDBOX pour refaire une synchronisation totale. L'arrêt va durée toute la journée du lundi 8 septembre.
Veuillez nous excuser pour la gêne occasionnée.
]]>Les environnements du groupe 5 sont actuellement inaccessibles en raison d’un incident sur le cluster de base de données, qui est à l’arrêt et ne redémarre pas. Nos équipes techniques sont mobilisées pour rétablir le service dans les plus brefs délais.
Nous vous tiendrons informés de l’évolution de la situation.
Merci de votre compréhension.
]]>Depuis 08h07 (heure de Paris), les environnements du Groupe 1 sont inaccessibles. Nos premières analyses indiquent un incident sur le cluster de base de données.
Nos équipes techniques sont actuellement mobilisées pour identifier la cause exacte et rétablir l’accès au plus vite.
Nous vous tiendrons informés de l’évolution de la situation. Merci de votre patience et de votre compréhension.
]]>Un problème affecte actuellement le cluster de l'environnement du groupe 5, ce qui impacte la réplication VSDB, qui est temporairement arrêtée. Nous tenons à préciser que le service VSDB reste pleinement opérationnel malgré l’arrêt de la réplication. Nous travaillons à rétablir la réplication et prévoyons de la remettre en route dans la nuit d’aujourd’hui à demain. Merci pour votre compréhension.
L’équipe système
]]>La réplication VSDB des environnements du groupe 11 est actuellement arrêtée suite à une mauvaise manipulation de l'équipe système. Nous nous excusons pour la gêne occasionnée.
La reprise de la réplication est prévue demain matin, après la sauvegarde de la nuit.
Merci pour votre compréhension. ????
]]>Depuis 11h50 (heure de Paris), la synchronisation VSDB des environnements du groupe 11 est interrompue en raison d'un incident sur un nœud du cluster de production.
Nos équipes travaillent actuellement à la résolution du problème. La synchronisation sera rétablie demain matin après la récupération de la sauvegarde nocturne.
Nous vous remercions pour votre patience et vous tiendrons informés de l'évolution de la situation.
]]>A 17h30 heure de Paris, nous avons déterminé que la dernière mise à jour des règles du pare-feu applicatif était en cause et nous avons isolé les serveurs en cause.
Depuis 14h45 heure de Paris, vous pouvez rencontrer des difficultés d’accès à votre environnement ainsi que des affichages incorrects. En attendant la résolution de l’incident, nous vous recommandons d’utiliser un autre navigateur, comme Firefox.
Nos équipes sont pleinement mobilisées pour rétablir la situation au plus vite. Nous nous excusons pour la gêne occasionnée et vous remercions pour votre patience.
]]>Nous rencontrons actuellement un problème avec le cluster de base de données du groupe 3, entraînant une interruption de la réplication VSDB. Cependant, le service VSDB reste pleinement fonctionnel.
Nos équipes sont mobilisées pour résoudre l’incident dans les meilleurs délais. Nous nous excusons pour la gêne occasionnée et vous remercions pour votre patience.
Nous vous tiendrons informés des évolutions de la situation.
]]>Les environnements du groupe 10 sont actuellement indisponibles en raison d’un blocage au niveau du cluster.
Nos équipes travaillent activement à résoudre le problème dans les plus brefs délais.
Nous vous présentons toutes nos excuses pour la gêne occasionnée et vous remercions pour votre compréhension.
Nous vous tiendrons informés de l’évolution de la situation.
]]>La réplication avec GRP5 est opérationnelle mais sur GRP4 nous rencontrons des difficultés. Une copie de fichiers est en cours, la réplication devrait être de retour avant 12h aujourd'hui heure de Paris.
Un problème affecte actuellement le cluster des environnements des groupes 4 et 5, ce qui impacte la réplication VSDB, qui est temporairement arrêtée. Nous tenons à préciser que le service VSDB reste pleinement opérationnel malgré l’arrêt de la réplication.
Nous travaillons à rétablir la réplication et prévoyons de la remettre en route dans la nuit d’aujourd’hui à demain. Merci pour votre compréhension.
L’équipe système
]]>Depuis 16h25 heure de Paris, les environnements du groupe 5 sont indisponibles. Nous rencontrons des problèmes de mémoire au niveau du cluster de base de données.
]]>Depuis 14h21 heure de Paris, les environnents du groupe 5 sont inaccessibles. Cela semble venir de la base de données.
]]>L’analyse indique qu’une importante consommation de mémoire est à l’origine de cet arrêt.
Nous vous présentons nos excuses pour la gêne occasionnée et restons vigilants pour prévenir toute récurrence de ce type d’incident.
Merci pour votre compréhension.
Nous rencontrons actuellement une indisponibilité des environnements hébergés sur le Groupe 5 en raison d’un problème technique.
Notre équipe système est mobilisée et analyse activement la situation afin de rétablir le service dans les meilleurs délais.
Nous vous tiendrons informés de l’évolution dès que de nouvelles informations seront disponibles.
Merci pour votre compréhension et votre patience.
]]>Nous rencontrons actuellement un problème de connectivité réseau entre deux de nos datacenters, ce qui impacte la gestion des fichiers attachés dans nos environnements. Cela peut entraîner des latences importantes lors de l'upload ou de la récupération de fichiers.
Nous avons identifié que cet incident est lié à un problème général signalé par notre fournisseur d'infrastructure, Scaleway, en cours depuis le 21 novembre. Cependant, cet impact semble nous toucher plus spécifiquement depuis peu.
Actions en cours :
Nous vous tiendrons informés de l’évolution du problème et nous excusons pour la gêne occasionnée.
Merci de votre patience et de votre compréhension.
]]>De plus, la fonctionnalité de récupération de base de données DB ON DEMAND ne sera pas opérationnelle demain, le temps que nos équipes mettent en place une résolution complète.
Nous vous tiendrons informés des avancées dans les plus brefs délais. Merci de votre compréhension et de votre patience.
]]>Depuis 9h45 heure de Paris, nous constatons un important ralentissement des traitements asynchrones de l'application, nous travaillons à remettre le système en route normalement.
Ce problème va impacter les délais de mise à jour des données de reporting, de génération des pré-factures, de traitement de certains actions de masse et certains traitements RH.
]]>Suite au passage en production d'une nouvelle fonctionnalité, la gestion des affaires est en erreur avec des possibles écrans blancs. Une modification de base de données semble être la cause du problème. Nous préparons un script de modification de base de données pour corriger le problème le plus rapidement possible. Nous vous présentons nos excuses pour la gêne occasionnée.
]]>Depuis 21h00 heure de Paris, les environnements des groupes 2, 3, 4, 6 et 7 sont inaccessibles. Nos cherchons la cause mais vraissemblement cela doit être un problème réseau chez notre hébergeur car cela touche beaucoup trop de groupes pour être sur un composant isolé chez nous. Nous recherchons la cause.
]]>Le cluster de base de données était à l'arrêt. Nous avons réussi à le remettre en route. La synchronisation VSDB est à l'arrêt, celle-ci devrait repartir ce soir.
Depuis 17h35 heure de Paris, les environnements du groupe 5 sont inaccessibles. Nous cherchons la cause.
]]>Les environnements du groupe 11 sont inaccessibles, le cluster de base de données semble être en cause. Nous sommes en train d'analyser la situation.
]]>L'accès était complétement rétabli à 13h40 heure de Paris. A 13h55 heure de Paris, le noeud arrêté avait été redémarré. Tout fonctionne normalement maintenant.
]]>La plateforme est hors service, l'hébergeur n'a pas réussi à remettre en route le système. Nous sommes en attente d'une nouvelle plateforme technique pour redéployer la solution de réplication.
]]>Mise à jour à 22h40 heure de Paris, le cluster a eu un problème de synchronisation et s'est complètement bloqué. La resynchronisation complète est en cours, les environnement seront disponibles d'ici 23h20.
Depuis 21h50 heure de Paris, les environnements du groupe 7 sont hors service, nous cherchons la cause.
]]>Depuis 9h56 heure de Paris, les environnements PP sont inaccessibles. Nous cherchons la cause.
La plateforme VS-DB des environnements PP est opérationnelle mais n'est plus synchronisée.
]]>Le problème a été corrigé. Un incident de sécurité a été ouvert afin d'améliorer nos procédures et de détecter ce type de problème plus rapidement.
]]>La plateforme VSDB de réplication des environnements PP est inaccessible. Nous avons un problème matériel vraisemblablement. Nous nous rapprochons du support Scaleway.
]]>Les environnements PP sont indisponibles, nous cherchons la cause.
]]>Nous nous excusions pour la gêne occasionnée.
Nous constatons que des utilisateurs ont des soucis pour se connecter sur certains environnements. Nous cherchons la cause de ce dysfonctionnement.
]]>Mise à jour le 17 juillet à 10h18. L'ensemble des environnements s'est encore bloqué ce matin à 9h10 heure de Paris. La coupure a duré quelques minutes.
Hier nous avons compris d'ou venait le problème, un cumul d'opérations techniques engendre un blocage d'un groupe d'environnement et notre load balancer considère que l'ensemble de la plateforme est hors service, coupant ainsi l'accès à tous les utilisateurs. Nous mettons en place une solution pour que cela ne se reproduise pas demain matin.
Nous nous excusons pour la gène occasionnée.
Aujourd'hui entre 8h30 et 8h40 heure de Paris, l'ensemble des environnements s'est retrouvé inaccessible.
Un cluster de base de données s'est bloqué comme hier matin ce qui a déclenché un blocage complet au niveau du load balancer qui a considéré que l'ensemble des environnements étaient inaccessibles. Il semble que la fin de la sauvegarde cumulée avec plusieurs traitements ont provoqué ce blocage.
Nous cherchons une solution pour que cet incident ne se produise plus.
]]>Depuis 7h35 heure de Paris, les environnements du groupe 3 sont inaccessibles. Nous cherchons la cause.
]]>Mise à jour vendredi 5 juillet à 14h heure de Paris. Un problème matériel bloque le bon fonctionnement, nous cherchons une solution, une remise en route le samedi 6 juillet est à prévoir.
Depuis 11h10 heure de Paris, la plateforme VSDB du groupe 7 est indisponible, le service de base de données est arrêté et ne redémarre pas. Nous cherchons la cause.
]]>Depuis 16h45 heure de Paris, les environnements du groupe 4 peuvent être bloqués, nous cherchons une solution.
]]>Bonjour, depuis 5h30 heure de Paris, les environnements du groupe 9 sont inaccessibles. Le cluster de base de données ne répond plus correctement, nous cherchons la cause.
]]>Si vous rencontrez ces difficultés, nous vous proposons d'utiliser le navigateur Firefox (ou Safari sur Mac) en attendant la résolution de cet incident.
Nos équipes sont mobilisées pour apporter une solution au plus vite.
Nous vous présentons nos excuses pour la gêne occasionnée.
]]>Bonjour, depuis quelques jours, certains utilisateurs nous remontent un problème au lancement de l'application sur Android. L'application reste figée sur l'écran de démarrage. Nous cherchons activement un correctif, la cause du problème a été identifiée, les données stockées de manière cryptée ne sont plus décryptées correctement et cela provoque un plantage, l'application reste figée sur l'écran de démarrage.
En vidant les données de l'application sur le téléphone, l'application fonctionne correctement. Une déinstallation/réinstallation ne suffit pas. Pour vider les données, rester appuyez sur l'icône MyVS, puis appuyez sur "Infos sur l'appli". Ensuite, appuyez sur "Données utilisateur", puis "Vider l'espace de stockage", et enfin confirmez la suppression.
Au prochain lancement, tout doit rentrer dans l'ordre.
]]>Bonjour,
Nous devons effectuer une tâche de maintenance avec une resynchronisation totale du cluster de base de données du groupe 1. Cela va engendrer une coupure de ces environnements le jeudi 9 mai 2024 entre 21h et minuit heure de Paris.
]]>La plateforme VSDB est fonctionnelle et synchronisée.
Depuis 15h30 heure de Paris les environnements du groupe 1 sont inaccessibles. Nous recherchons la cause.
]]>Tous les environnements du groupe 1 sont inaccessibles depuis 13h15 heure de Paris. Le cluster de base de données semble en cause, nous recherchons des éléments.
]]>Le samedi 20 avril 2024 heure de Paris, nous organisons un test de continuité d'activité. Les environnements du groupe 5 seront inaccessibles de 10h à 12h heure de Paris.
]]>Depuis 11h heure de Paris, la plateforme qui héberge les environnements PP ne répond plus, nous cherchons la cause du problème.
]]>À 13h40 heure de Paris, nous avons dû relancer la synchronisation sur un second nœud pour prévenir des problèmes techniques potentiels chez notre hébergeur qui risqueraient de couper l'accès dans l'après-midi. La synchronisation va durer 30 à 40 minutes, nous sommes vraiment désolés pour la gêne occasionnée.
Le cluster de base de données s'est arrêté. Il a été redémarré sur un seul noeud pour redonner l'accès rapidement aux utilisateurs. Les opérations de synchronisation des autres noeuds auront lieu en soirée. VSDB est ouvert mais les données ne sont pas rafraichies.
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 !
]]>