VCSTS choisit, configure, migre et exploite les bases qui font fonctionner vos applications.
Étudier ma base de donnéesUn point antérieur à l’erreur permet de préparer une base restaurée, de la contrôler puis de reconnecter l’application, selon les possibilités du service.
Connexions de l’application
Pool selon le moteur
Comptes et droits
Trois regards sur votre base
Commandes, dossiers, comptes utilisateurs, informations métier : vos données doivent répondre aux applications qui les utilisent. Nous organisons aussi ce qui permet de les protéger, de les restaurer et de les faire évoluer.
Nous partons de votre application et de votre organisation. Vous pouvez nous confier une intervention précise ou un accompagnement allant du choix de la configuration à son exploitation.
Préparer la base, ses accès et son raccordement avec l’équipe qui développe ou intègre le service.
Une configuration prête pour les essais applicatifs.
Examiner le moteur, les dépendances et les conditions de transfert pour organiser la migration et la prise en charge.
Un état de départ et une séquence de reprise.
Étudier les ressources, les connexions et les points de ralentissement pour choisir les évolutions utiles.
Des priorités et des opérations définies.
PostgreSQL et MySQL sont deux moteurs de bases de données relationnelles. Le choix dépend de ce que votre application utilise, de ses contraintes et de ce qui doit rester compatible. D’autres besoins, notamment documentaires ou de cache, s’étudient avec leur fonctionnement propre.
Conserver le moteur peut faciliter une reprise. En changer demande d’examiner le modèle de données, les requêtes et les adaptations de l’application. Le transfert ne se résume alors pas à copier des tables.
Moteur, version et fonctions sont retenus ensemble dans la proposition. Le choix reste celui de votre application.
Application web, traitements automatiques, outils d’administration : une même base reçoit des connexions de plusieurs origines. Leur nombre, leur durée et leurs droits font partie du dimensionnement.
Lorsque c’est adapté, réutiliser un ensemble de connexions évite d’en ouvrir une nouvelle à chaque opération. Ce mécanisme, appelé pooling, se vérifie avec les fonctions réellement utilisées par l’application.
Comptes, droits, échanges chiffrés, restrictions réseau et gestion des identifiants sont organisés selon les usages. Production, tests et administration disposent des accès qui leur correspondent.
Les essais couvrent aussi une connexion interrompue. Avec vos développeurs ou votre éditeur, nous vérifions les nouvelles tentatives et la reprise des opérations applicatives.
Une panne du service et une erreur dans les données appellent des réponses différentes. Nous préparons la continuité et la récupération selon ce que votre activité doit pouvoir reprendre.
Une instance de secours peut permettre de reprendre le service. Son fonctionnement, les conditions de bascule et le raccordement de l’application dépendent de l’architecture choisie.
À préparer : bascule, capacité restante et reconnexion.
Une suppression ou une modification indésirable peut aussi se répliquer. Les sauvegardes et l’historique nécessaires permettent de préparer une restauration à un instant choisi, lorsqu’elle est disponible dans le service retenu.
À préparer : état récupérable, vérifications et remise en service.
Restaurer demande de vérifier les données récupérées et les parcours importants de l’application. Nous définissons les essais et les personnes qui constatent que le service peut reprendre.
Le plan précise ce qui est conservé, pendant combien de temps, où se trouvent les copies et qui peut déclencher une restauration. Les objectifs de perte de données et de délai de reprise sont définis avec votre activité.
Préparer la reprise de l’ensemble de l’activitéLa migration se prépare avec les personnes qui connaissent l’application. Nous identifions les dépendances, les parcours à essayer et les moments où une intervention est possible.
Moteur, version, données, droits et services connectés composent l’état de départ. Nous identifions les écarts à traiter avant le transfert.
Un inventaire et des critères de réception.
Une copie permet de vérifier la reprise et les principaux parcours applicatifs. Les accès et les contrôles sont définis ensemble.
Des essais avant la bascule.
Le calendrier précise la reprise des dernières écritures, les changements de connexion et, si nécessaire, une période de gel ou d’interruption.
Une séquence d’intervention connue.
Après le passage, les données et les parcours convenus sont vérifiés. Les critères de poursuite ou de retour sont préparés avant l’intervention.
Une réception et un passage en exploitation.
Elles font partie du plan. Si un retour devient nécessaire, l’ancienne base peut déjà ne plus être à jour. Les possibilités de resynchronisation, les opérations nécessaires et leurs limites sont donc préparées avant le changement.
Un service managé automatise une partie des opérations techniques. La bonne marche de votre application demande aussi des réglages, des contrôles et des décisions.
Organiser et exploiter
Nous préparons le service, coordonnons la migration et réalisons les opérations confiées. Le suivi peut couvrir l’état de la base, les accès, les sauvegardes, les ressources et la maintenance. Les interventions et les suites à donner sont documentées.
Porter l’application et le métier
Vous précisez les priorités, les parcours importants et les contraintes de calendrier. Nous travaillons avec vos développeurs ou votre éditeur pour les changements qui touchent le code, les requêtes et le modèle de données.
Fournir le service retenu
L’hébergement et les fonctions managées relèvent des conditions du prestataire choisi. VCSTS coordonne les interventions qui entrent dans le périmètre de votre prise en charge.
L’analyse des requêtes, des index et des paramètres peut rejoindre la mission. Les adaptations de l’application sont identifiées dans la proposition pour que chacun sache ce qui sera réalisé.
Les alertes ont un destinataire et un circuit de traitement. Plages d’intervention, canaux de contact et engagements applicables sont définis au contrat.
Confier aussi l’exploitation de votre environnementUne augmentation de capacité, une nouvelle version ou une modification d’accès se prépare selon ses effets sur le service. Nous examinons les dépendances et les essais nécessaires avant les fenêtres d’intervention convenues.
Certaines opérations peuvent demander une interruption. Ses conditions sont préparées avec vous, ainsi que les vérifications après intervention. Ajouter des ressources est une possibilité ; revoir une requête, un index ou l’usage des connexions peut aussi faire partie du travail.
Un dossier utilisable par les personnes qui font vivre votre application, adapté au périmètre confié.
La proposition distingue la mise en place, les ressources du service et l’exploitation récurrente. Vous savez ce qui démarre avec le projet et ce qui se poursuit ensuite.
Formats d’export, accès, dépendances propres au moteur ou au service, éléments à transmettre et contrôles de reprise : nous préparons les conditions de récupération dès le départ. Les opérations et frais éventuels de transition sont précisés.
Oui. Nous organisons le projet avec les personnes qui connaissent votre application. La reprise peut conserver le moteur et une partie de l’environnement ; les compatibilités et les responsabilités se vérifient au départ.
Non. Le nom de votre application, ce qu’elle doit faire et votre situation actuelle permettent d’engager l’échange. Nous précisons ensuite le moteur, la version et les fonctions nécessaires.
Oui. Nous pouvons configurer, migrer et exploiter des bases PostgreSQL et MySQL. Nous vérifions les versions, extensions et fonctions utilisées par votre application ; la proposition précise la configuration, l’hébergement et les opérations retenues selon les possibilités du service choisi.
La méthode dépend de la base, de l’application et des moyens de synchronisation disponibles. Les essais permettent de préparer la bascule et d’en préciser les effets sur votre activité, y compris un éventuel gel des écritures.
Non. Elle suit l’évolution de la base et peut suivre une erreur. Les sauvegardes et l’historique de restauration servent à retrouver un état antérieur, dans les limites du dispositif retenu.
Oui. Nous examinons le service en place, les droits accessibles, les opérations automatisées et les responsabilités actuelles pour définir ce que vous souhaitez nous confier.
Une base incluse dans un hébergement accompagne les besoins du site. Ici, la base constitue un service autonome, choisi et exploité autour de vos applications. Nous examinons l’intérêt de la séparer selon votre usage.
Présentez votre situation actuelle et ce que vous souhaitez nous confier. Si vous les connaissez, indiquez le moteur, le volume de données et l’échéance du projet. Nous définirons avec vous la configuration et la prise en charge adaptées.
Un premier échange pour qualifier le besoin, puis une proposition adaptée. Aucun mot de passe ni export de données n’est nécessaire.