Description du projet
TraduitNous gérons un catalogue en ligne qui a grandi pendant six ans, et il a enfin dépassé la machine sur laquelle il se trouve. Les pages de catégorie prennent environ cinq secondes à s'ouvrir, la recherche dans le catalogue est pire, et aux heures de pointe, tout le site semble bloqué. La base de données est toujours sur l'ancien serveur, tandis que le nouveau est déjà payé et préparé. Je cherche quelqu'un qui déplacera les données avec le moins de temps d'arrêt possible — par un plan écrit, avec une répétition et une fenêtre de basculement convenue, pas en débranchant un vendredi soir en espérant.
La seconde moitié du travail est tout aussi importante, car payer pour une machine plus rapide et garder les mêmes requêtes lentes n'a aucun sens. Veuillez lire le journal des requêtes lentes dans son intégralité, dites-nous honnêtement ce qui prend vraiment du temps, ajoutez les index manquants, réécrivez les sélections lourdes, et remplacez les pages qui récupèrent toute la table et la découpent dans le code par une véritable pagination. Ce que les gens demandent le plus souvent devrait être mis en cache, et le cache doit se rafraîchir plutôt que de servir les prix d'hier. Après le déménagement, j'attends un passage de vérification sur l'ensemble du site — sections, formulaires, recherche, comptes utilisateurs — plus une courte instruction en langage clair que nos propres administrateurs peuvent réellement suivre.
Les mesures avant et après font partie du travail, pas un bonus : je veux des chiffres, pas des impressions.
Conditions sur lesquelles je ne céderai pas :
— la migration est répétée sur une copie, et la base de données de production n'est pas touchée tant que cette copie n'a pas été vérifiée ;
— chaque changement de schéma est précédé d'une sauvegarde dont la restauration a été testée, pas simplement créée ;
— rien n'est changé en direct pendant les heures de pointe — toutes les étapes risquées se déroulent dans la fenêtre calme convenue ;
— chaque index et chaque requête réécrite vient avec son propre timing avant et après ;
— le rapport de clôture indique ce qui a été changé, pourquoi cela a été changé, et comment le restaurer.
La seconde moitié du travail est tout aussi importante, car payer pour une machine plus rapide et garder les mêmes requêtes lentes n'a aucun sens. Veuillez lire le journal des requêtes lentes dans son intégralité, dites-nous honnêtement ce qui prend vraiment du temps, ajoutez les index manquants, réécrivez les sélections lourdes, et remplacez les pages qui récupèrent toute la table et la découpent dans le code par une véritable pagination. Ce que les gens demandent le plus souvent devrait être mis en cache, et le cache doit se rafraîchir plutôt que de servir les prix d'hier. Après le déménagement, j'attends un passage de vérification sur l'ensemble du site — sections, formulaires, recherche, comptes utilisateurs — plus une courte instruction en langage clair que nos propres administrateurs peuvent réellement suivre.
Les mesures avant et après font partie du travail, pas un bonus : je veux des chiffres, pas des impressions.
Conditions sur lesquelles je ne céderai pas :
— la migration est répétée sur une copie, et la base de données de production n'est pas touchée tant que cette copie n'a pas été vérifiée ;
— chaque changement de schéma est précédé d'une sauvegarde dont la restauration a été testée, pas simplement créée ;
— rien n'est changé en direct pendant les heures de pointe — toutes les étapes risquées se déroulent dans la fenêtre calme convenue ;
— chaque index et chaque requête réécrite vient avec son propre timing avant et après ;
— le rapport de clôture indique ce qui a été changé, pourquoi cela a été changé, et comment le restaurer.
Développement de logiciels Espèces, Virement bancaire
