14 jours difficiles

14 jours difficiles

Il y a 1 mois, je publiais l’introduction de mon dossier « Les coulisses de mon entreprise » dans lequel je compte expliquer mes méthodes pour être serein professionnellement, rentable, en travaillant à peine 4 heures par jour.

Ironie du sort, quelques jours plus tard, j’ai été confronté à un problème serveur franchement vicieux qui m’a imposé de travailler comme un acharné une dizaine d’heures par jour (week-end inclus) pendant 2 semaines, soit environ 140 heures de travail 😅

Qui fait le malin tombe dans le ravin

Notez bien que je ne tire aucune fierté de cette « performance stakhanoviste ». De mon point de vue, devoir travailler énormément est avant tout la preuve qu’il y a des problèmes à résoudre ou des processus à améliorer. Bref, c’est rarement positif…

Jamais la résolution d’un problème n’avait nécessité une telle débauche de travail sur une période aussi longue. Même l’épisode du plagiat ou celui de l’incendie d’OVH me semblent peu de choses en comparaison !

Ce qui est vraiment paradoxal, c’est que quasiment personne ne s’en est rendu compte. En fait, les quelques observateurs l’auraient probablement vite oublié si je ne rédigeais pas cet article. Moi, je n’ai pas envie que cet épisode soit oublié car ça a été une vraie galère.

J’ai simplement envie de vous la raconter dans ce (long) article car ça fait aussi partie de ma vie d’entrepreneur.

Samedi 17 avril : quelques ralentissements

Depuis quelques jours, j’observe des ralentissement sur mon outil de gestion de mon entreprise dont je suis le développeur. Certaines listes, comme celles des clients ou des sites, sont particulièrement lentes à s’afficher. Ca ne m’étonne pas vraiment : j’ai commencé à développer cet outil il y a 7 ans, j’étais alors auto-entrepreneur et j’avais une dizaine de clients en base de données, une vingtaine de sites et quelques dizaines de factures. J’ai maintenant plus de 600 clients, 3 000 sites à gérer et 1 400 factures. Mon système est probablement sous-dimensionné par rapport à mes besoins actuels et, forcément, ça mouline un peu. Ca faisait déjà quelques temps que je me disais que ce serait pas mal d’optimiser tout ça. Visiblement ce n’est plus une option…

Je commence donc à optimiser mon outil :

  • Réduction du nombre de données à afficher.
  • Optimisation des requêtes et du code.
  • Accélération du moteur de la base de données, notamment via l’utilisation d’index (un truc technique).

Ce qui m’étonne un peu c’est que j’observe aussi des ralentissements sur des interfaces qui ne nécessitent pas de charger beaucoup de données. Etrange.

Au bout de quelques jours, le doute s’installe sérieusement : j’obtiens bien des améliorations des performances, mais il semble y avoir des périodes durant lesquelles les ralentissements persistent malgré tout. Et j’ai surtout l’impression que ces périodes sont de plus en plus longues et de plus en plus fréquentes.

Rien de grave mais c’est troublant car je n’ai jamais rencontré un souci de ce style auparavant 🤨

Autre point inquiétant, j’observe des ralentissements similaires sur Bulldoz (ma plateforme de rédaction), j’applique donc les optimisations effectuées sur mon outil pour accélérer aussi ce site.

Ce phénomène est franchement bizarre et je continue à optimiser les vitesses d’affichage de ces deux sites par différents moyens.

Jeudi 22 avril à 19h00 : alerte client

A 19h00, je reçois ce message de la part d’un client sur Skype :

je trouve que mes sites sont assez lents
genre quand j’ouvre 5 onglets en même temps de 5 sites
laisse tomber chrome il mets 15 secondes
(dsl j’en oublie mes politesse : j’espère que toi et tes proches êtes au top !

Un client qui souhaite rester anonyme 😉

Les doutes que j’avais depuis quelques jours se confirment, les problèmes de ralentissement ne sont pas liés à la performance du code, c’est plus général. A priori, ce serait un problème au niveau du serveur, probablement un paramétrage à affiner ou un processus qui pompe trop de ressources. Je demande donc à Yannick (mon administrateur système) de jeter un œil. Il va certainement résoudre ça en 5 minutes, comme d’habitude (sans oublier son traditionnel « bah, c’est juste ça », qui a l’art de m’énerver 😋) :

[Non urgent]
J’ai un client qui se plaint des perfs d’affichage des sites aujourd’hui. Perso, j’ai eu du mal à l’évaluer vu que ma connexion internet déconne depuis 2 jours…
Comment puis-je vérifier et quantifier la vitesse de réponse du serveur ?

A noter : j’ai eu pas mal de soucis avec ma connexion internet pendant cette période, ce qui n’a pas simplifié cette affaire…

A ce moment là, je ne le sais pas encore, mais ce message « [Non-urgent] » est le point de départ d’un marathon technique qui va durer 14 jours et dont la résolution va m’accaparer 140 heures de travail. Yannick passera aussi énormément de temps à m’aider.

Vendredi 23 avril

Yannick fait un diagnostique sur le serveur. Bizarrement, ça ne prend pas du tout 5 minutes comme je l’avais espéré (et l’insupportable « bah, c’est juste ça » ne vient pas non plus).

En attendant, la situation s’est largement dégradée : les sites sont parfois tellement lents que les navigateurs finissent par afficher des messages d’erreur (timeout). 2600 sites s’affichent plus qu’aléatoirement. Pour ce qui est de la « sérénité professionnelle », désolé, mais il faudra repasser un autre jour 😨

Yannick finit par trouver la source du problème : le disque dur du serveur rame. Yannick soupçonne que le souci provient du backup nocturne d’OVH qui ne se termine pas. Il envoie donc un ticket à OVH pour expliquer le souci et demander sa résolution. Le backup est rapidement stoppé par OVH (nous sommes tous les deux surpris par la vitesse de cette réponse, mais vu le niveau d’urgence ça tombe plutôt bien). Suite à cet arrêt et au redémarrage de divers processus, le serveur est à nouveau fonctionnel et les sites s’affichent à nouveau. Ouf !

Ce fut chaud 😅

Mais Yannick n’est pas optimiste du tout : le disque dur reste très lent, ce qui n’est pas normal. Pour le mesurer, il a mis en place un test très simple : il s’agit de copier 300 méga octects de données et de chronométrer en combien de temps cette copie est réalisée. En temps normal, ça devrait nécessiter moins de 1 seconde. A ce moment là, il a besoin de 9 secondes. Concrètement, à 9 secondes, les sites rament sérieusement. Si c’est plus, tous les sites plantent 😱

Quelques précisions sur les serveurs

Un serveur est simplement un gros ordinateur qui ne s’arrête jamais.

Le serveur que j’utilise pour héberger les 2600 sites est une « machine virtuelle », c’est à dire une simulation de serveur. En clair, ça signifie qu’OVH possède un (très très) gros serveur sur lequel il loue des « machines virtuelles » à différents clients. Le souci c’est que si plusieurs machines virtuelles consomment simultanément beaucoup de ressources, le gros serveur peut commencer à ramer, ce qui plombe les performances de toutes les machines virtuelles. Autre souci possible : si une pièce du gros serveur est défectueuse alors toutes les machines virtuelles subissent aussi la panne.

Avant l’incendie du datacenter OVH de Strasbourg, mes sites étaient dispatchés sur 5 machines virtuelles différentes, ce qui permettait de limiter ce type de risque. Suite à l’incendie, il a fallu transférer en urgence tous les sites sur le datacenter de Gravelines, dans le département du Nord (voir le détail de cette aventure ici). Comme le paramétrage d’une machine virtuelle est assez long à réaliser et qu’il fallait faire vite, nous avions placé tous les sites sur une seule machine virtuelle, ce qui les rendait plus vulnérables à un souci du gros serveur.

A noter : notre machine virtuelle était bien remplie (2600 sites), mais la configuration était largement suffisante pour assumer cette charge 🚀

Nos actions en attendant que le disque dur soit réparé par OVH (ce qui n’est jamais arrivé)

En attendant qu’OVH trouve une solution pour réparer le disque dur, nous avons tenté de limiter la consommation de ressources de cet élément par différents moyens. Je vais vous expliquer quelques pistes de travail que nous avons suivies.

➡️ Petit point technique : pour faire fonctionner un site avec WordPress, il y deux grandes parties :

  1. Les fichiers de programmation (PHP), qui contiennent le code source nécessaire pour faire fonctionner le site : afficher un article, les catégories, le menu… Ces fichiers sont lus par un « moteur » qui s’appelle Apache.
  2. Une base de données qui contient les informations du site, comme le texte des articles, le titre du site, les libellés du menu… Ce contenu est géré par un « moteur » qui s’appelle MySQL.

La désactivation des extensions WordPress défectueuses

C’est MySQL qui nécessite le plus de ressources de disque dur, nous avons donc cherché à voir si ce moteur ne consommait pas trop de ressources, notamment en lisant le « journal des erreurs » (les logs). En les analysant, nous nous sommes rendus compte que beaucoup d’erreurs étaient générées par des extensions WordPress défectueuses 😠

Les extensions sont de petits programmes que l’on peut ajouter à un site WordPress pour disposer de nouvelles fonctionnalités. C’est très facile à installer et ça peut rendre d’excellents services, c’est pourquoi certaines personnes en installent beaucoup, pour tout et n’importe quoi. Malheureusement, la qualité du codage n’est pas toujours au rendez-vous et certaines extensions génèrent des erreurs (ou entrent en conflit avec d’autres extensions).

N’oubliez jamais : chaque extension est un alien qui peut ravager votre WordPress. Installez-en le moins possible et supprimez-les dès que vous n’en avez plus besoin :

J’ai donc contacté les personnes concernées pour demander l’autorisation de désactiver les extensions défectueuses, ce que j’ai obtenu sans difficulté vu qu’elles n’étaient pas utilisées… Suite à cette expérience, la procédure sera désormais légèrement différente : si je détecte une extension défectueuse :

  1. Elle sera désactivée directement
  2. J’avertirai ensuite le propriétaire que son extension a été désactivée

Désolé, mais la sécurité du serveur est prioritaire sur l’utilisation d’extensions codées avec les pieds 💀

Réparation des bases de données endommagées

Nous continuons à détecter et corriger les problèmes générés par les extensions défectueuses. Le souci c’est que certaines extensions ont endommagé partiellement la base de données de leur site, ce qui génère des flots d’erreurs sur MySQL. Il faut donc les réparer. L’opération est rendue encore plus compliquée par le fait que le disque dur peut ramer à tout moment, ce qui bloque les processus de réparation et génère d’autres pannes : c’est « 2 pas en avant , 3 en arrière » 🤬

Franchement, c’est l’Enfer de travailler dans des conditions pareilles 🤪

Problèmes sur la sauvegarde OVH

La sauvegarde nocturne d’OVH continue de boguer complètement, ce qui n’est pas étonnant vu que ce type de processus a besoin que le disque dur fonctionne bien pour se dérouler. Je décide alors de désactiver ce système de sauvegarde. Il ne reste donc plus que le système de sauvegarde de Yannick (qui est moins gourmand en ressources) et les anciens backups pour restaurer le serveur en cas de très gros pépin (un incendie par exemple…). C’est moins rassurant, mais c’est suffisant techniquement.

Samedi 24 avril

La commande du serveur dédié

Yannick me recommande de disposer d’un « vrai » serveur dédié, c’est à dire un serveur qui n’est pas une machine virtuelle. Cela a plusieurs avantages : étant donné qu’il n’y a qu’un seul utilisateur sur ce serveur, il est beaucoup plus facile de détecter des problèmes de matériel. Aussi, il n’y a aucun risque qu’un autre locataire consomme toutes les ressources. Je passe donc la commande du serveur dédié, il devrait être livré dans 3 jours. Vu qu’on est samedi, je table sur une livraison mercredi 28 avril.

Au pire, nous devrions sortir de la panade dans quelques jours 🙂

Tentative de migration de la machine virtuelle complète

Après avoir passé la journée à tenter en vain d’améliorer les performances, je me rends compte que rien ne s’arrange, il faut quand même faire quelque chose car la situation empire de plus en plus. Je décide alors de tenter un « all-in » en copiant toute la machine virtuelle dans une nouvelle machine virtuelle. Avec un peu de chance, elle sera basée sur un autre « gros serveur » qui lui n’aura pas de problème de disque dur. L’opération va consommer beaucoup de ressources du disque dur pour faire la copie, mais ça se tente. Je lance donc la copie (un « snapshot ») pendant la nuit et je croise les doigts pour que ça fonctionne 🤞

Cette bonne blague de l’interface d’OVH nous a fait bien rigoler.

Dimanche 25 avril

Bonne surprise au réveil : la copie a bien fonctionné ! J’avoue que je n’y croyais pas trop 😮

Je lance donc la création d’une nouvelle machine virtuelle à partir de cette copie.

Petite contrainte : suite à la création de la machine virtuelle, je devais transférer toutes les IP de la machine virtuelle actuelle vers la nouvelle. Techniquement parlant, cette opération est très simple, il suffit de faire quelques clics dans l’interface d’OVH. Le souci c’est qu’il y en a plus de 250 à transférer, soit presque 3 heures de travail idiot et qui peut entrainer des erreurs de manipulation. Je passe donc la matinée à découvrir l’API d’OVH qui est un outil permettant d’automatiser cette tâche et à scripter ce processus 🧐

En début d’après-midi la nouvelle machine virtuelle est prête et je migre les IPs en quelques minutes via mon script. Tout semble fonctionner parfaitement, impeccable. La nouvelle machine virtuelle tourne beaucoup mieux, le disque dur réagit normalement et les sites fonctionnent à nouveau.

YES !

Lundi 26 avril

Tout fonctionne bien, c’est agréable de travailler à nouveau normalement. Je dois maintenant rattraper le retard accumulé au fil des jours précédents, mais vu que je retrouve ma productivité habituelle, c’est gérable 🥳

Vers 11h30, je prends un « timeout » sur mon outil de gestion d’entreprise, c’est mauvais signe. Je teste avec l’état du disque dur avec le petit script de Yannick : le disque dur est à 9 MégaOctets par seconde. Visiblement, on est toujours sur le même « gros serveur » !

En fait, on en est strictement au même point 😱

Pourquoi ? Pourquoi moi ?

Yannick, m’explique que le principal goulot d’étranglement dans la configuration actuelle reste le moteur de base de données : MySQL. En attendant que le serveur dédié soit livré (prévu pour dans 2 jours), il faudrait essayer de limiter au maximum son utilisation. Il me propose alors d’installer une extension WordPress de gestion de cache.

Le principe du cache est assez simple : lorsqu’on affiche une page d’un site WordPress, le programme va :

  1. Chercher de nombreuses informations en base de données (via MySQL), ce qui est relativement lourd.
  2. Générer une page sur laquelle ces informations seront affichées.

Une extension de cache enregistre la page générée sur le disque dur. La prochaine fois qu’un internaute voudra cette page, on affichera directement la version enregistrée plutôt que de reconstruire la page à partir de 0. C’est beaucoup plus rapide et ça limite énormément le nombre de requêtes sur le moteur de MySql.

J’ai donc installé et paramétré l’extension W3T sur l’un de mes sites WordPress en suivant les conseils de Yannick. Une fois que j’ai constaté que ça fonctionnait correctement, je l’ai installé sur les 560 sites WordPress qui m’appartiennent. L’air de rien, ce paramétrage m’a demandé quelques heures de travail et j’ai terminé une fois de plus vers minuit. Malheureusement, ça n’a pas vraiment eu d’impact visible sur la panne : lorsque le disque dur ne tournait pas, les sites ne fonctionnaient plus, peu importe le nombre de requêtes envoyées sur MySQL…

Mardi 27 avril

Les problèmes continuent sur le serveur. Sachant que le nouveau serveur dédié arrive demain, je laisse les choses en place, il n’y a pas grand chose à faire de plus. Je m’attelle donc à produire les sites de PBN que les clients m’ont commandés la semaine précédente, je ne sais pas ce qu’il s’est passé la semaine dernière, mais j’ai eu plus de 300 commandes de sites en 48 heures. Un record qui tombe pile poil au mauvais moment 😅

Au cours de la production de ces sites un nouveau type de souci fait son apparition : l’arrêt violent des processus (causé par l’arrêt du disque dur), génère des erreurs. Par exemple, si je suis en train de publier une cinquantaine de textes sur plusieurs sites simultanément (ce qui nécessite plusieurs minutes) et que le disque dur ne fonctionne pas pendant 1 minute, une partie des textes ne seront pas publiés (ou seulement partiellement). Lorsque le serveur fonctionne normalement, ce phénomène n’arrive quasiment jamais : disons 1 fois par mois sur 1 seul texte… Dans la configuration actuelle, la panne devient la norme. Je suis donc obligé de développer des nouveaux scripts pour m’adapter à cette nouvelle « normalité » :

  • Un script dont le rôle est de vérifier si tous les textes sont correctement publiés.
  • Un script dont le rôle est de réinitialiser les textes qui ont eu des erreurs.

J’ai du faire ceci pour chacun des processus nécessaires à la production des sites… Encore une grosse charge de travail supplémentaire 😓

Mercredi 28 avril

Le serveur dédié n’est toujours pas livré et le disque dur a toujours des coupures. On décide de checker le journal d’activités d’Apache (les « logs ») pour voir si il n’y aurait pas des processus qui consommeraient beaucoup trop de ressources. Petite surprise, je découvre qu’une trentaine de vieux « money-sites » génèrent beaucoup de requêtes SQL pour un bénéfice très faible. Je passe donc du temps à supprimer proprement ces requêtes.

En poursuivant l’étude du journal d’activités, nous détectons que certains sites affichent des pages qui ne sont visiblement pas issues d’un WordPress classique. En creusant ce point, je découvre qu’une dizaine de sites sont hackés ! Il sont tous à moi, sauf 2 qui appartiennent à un client. Ces hacks ne consomment pas spécialement de ressources, mais ils ne font pas non plus du bien au serveur. Quoi qu’il en soit, il faut les déloger.

Quelques précisions sur le hack des sites

A noter : je ne suis pas un spécialiste du piratage. Si vous avez des soucis à ce sujet inutile de me contacter, je ne suis pas le plus qualifié pour vous aider.

Un site est hacké lorsqu’un pirate injecte du code source pour lui faire faire des choses pour son compte. Dans ce cas précis, il s’agissait d’afficher des pages bidons pour générer des liens vers d’autres sites, c’était donc du netlinking DarkHat (sympas les collègues…). Plus le hack dure longtemps, plus il est rentable pour le pirate. Le but pour le pirate est donc :

  • de réussir à hacker le site.
  • de ne pas se faire détecter.
  • de ne pas se faire déloger si il est détecté.

Pour ne pas être détecté, le pirate va tenter de gêner le moins possible son « hôte ». En effet, si le site fonctionne mal à cause du hack, le propriétaire va rechercher la cause, découvrir le hack et tenter de s’en débarrasser.

Déloger un hack n’est pas facile car le pirate va cacher les fichiers de programmation un peu partout dans le code du WordPress. Le but du jeu est alors de découvrir tous les fichiers piratés et de les nettoyer. Vu qu’il y avait une dizaine de sites touchés, j’ai développé des scripts permettant de les détecter et de les nettoyer automatiquement.

Mon ressenti lorsque je chasse des fichiers hackés 😂

La suppression de ces hacks m’a demandé énormément de travail : si il reste un seul fichier hacké, c’est suffisant pour reconstituer l’ensemble du hack. Il faut donc s’assurer de supprimer tous les fichiers simultanément et d’en oublier aucun pour s’en débarrasser définitivement. Ce qui n’est pas du tout évident…

Ces différentes expériences sur le serveur me font prendre conscience qu’en acquérant plus de compétences sur Linux je serais apte à réagir beaucoup plus rapidement en cas de souci. J’ai donc commandé le livre « Linux Bible » (in english please) pour mieux maitriser l’aspect théorique.

Il ne me reste plus qu’à le lire 😅

Jusqu’au 3 mai

Je vais arrêter de décrire les tentatives techniques car cet article est déjà fort long et un lecteur non technicien risquerait de le trouver lassant 😉

Sachez simplement qu’à ce jour le serveur dédié n’est toujours pas livré (j’écris cette ligne le 23 mai…) et que jusqu’au 3 mai, Yannick et moi avons tenté d’optimiser tout ce qui était possible pour pouvoir faire tourner correctement une machine virtuelle basée sur un disque dur fonctionnant aléatoirement. Mais c’est impossible : autant essayer de gagner une course de Formule 1 avec une voiture dont le moteur s’arrête toutes les 10 minutes…

La situation devenait franchement insupportable et empirait chaque jour :

Si le site n’est pas accessible alors la bande est rouge 😡

De guerre lasse, j’ai pris la décision (assez extrême) de migrer tous les sites vers mes anciennes machines virtuelles de Strasbourg, c’est à dire celles qui avaient brûlé 2 mois plus tôt ! Elles ont été réactivées par OVH 2 semaines après l’incendie et depuis je les conservais en stock (en cas de besoin).

Une migration de ce style ne s’improvise pas, Yannick et moi avons fait un premier test en migrant 15 sites vers Strasbourg et nous avons surveillé leur activité durant 24h, tout semblait fonctionner parfaitement.

Le lendemain au réveil, j’ai donc pris la décision de migrer tous les autres sites à Strasbourg. Malheureusement, il ne suffit pas de faire un simple copier-coller pour que ça fonctionne, Yannick a du reparamétrer chaque machine virtuelle pour qu’elles soient prêtes à recevoir les 2600 sites. Nous avons scripté l’intégralité de la migration pour dispatcher les sites correctement. A la fin de la journée tout était prêt et nous avons pu démarrer la migration en fin de soirée.

Jeudi 6 mai : la libération

Le lendemain, tout était au vert : ça a fonctionné 🥳

Evidemment, il a fallu gérer quelques exceptions, mais 99% des sites ont migré sans souci. J’avoue que j’étais assez fier de cette performance 😉

Voici maintenant à quoi ressemble mon tableau de bord UptimeRobot :

C’est beaucoup mieux comme ça 👍

C’était alors la fin d’un marathon de 14 jours, quel soulagement !

J’avoue que j’ai passé les 3 jours suivants à dormir et/ou à comater devant Netflix 😅

Rattrapage du retard

Evidemment, un incident de ce genre m’a fait prendre du retard sur différents sujets (ce sont surtout les projets personnels qui ont été impactés) et il a fallu tout rattraper. Vu qu’en temps normal je travaille 4 heures par jour, ça n’a pas été très difficile de trouver du temps supplémentaire. Ceci est d’autant plus vrai que désormais mes processus sont plus rapides (vu qu’il y a eu 3 semaines d’optimisations intenses). Ils sont aussi super résistants aux différentes formes de pannes (c’est l’avantage d’avoir travaillé longtemps dans un environnement instable).

Et les clients ?

Ca me paraît assez incroyable, mais sur les 84 clients qui hébergent des sites sur mes serveurs, seulement 5 clients m’ont fait part d’un souci. De ce fait, la gestion de la relation client a été assez rapide : j’expliquais la situation en toute transparence et les actions en cours pour résoudre le problème. Les clients semblaient satisfaits de ce retour rapide.

Je les remercie vraiment pour leur patience et pour leur confiance 👍

Paradoxalement, ça a été la crises la plus complexe et la plus longue à gérer de ma carrière… Pourtant presque personne ne s’en est vraiment rendu compte. C’était très bizarre comme sensation : un peu comme si il y a avait une alarme assourdissante au milieu d’une foule et que vous étiez le seul à l’entendre.

Conclusion

Je suis entrepreneur, je suis donc optimiste par nature. Je vais donc conclure positivement cet article 🙂

  • J’ai mis en place des processus avancés de surveillance de sites et de serveurs.
  • J’en sais beaucoup plus sur l’optimisation d’Apache, de MySQL et de WordPress.
  • La console de Linux est devenue un véritable terrain de jeu pour moi (vous savez, l’écran noir qui fait peur).
  • J’ai beaucoup appris sur le fonctionnement des disques durs et des différents composants des serveurs.
  • Je sais maintenant détecter et déloger des hacks (ça reste néanmoins un exercice difficile, mais passionnant).
  • Mes processus de production sont plus rapides, plus sûrs et plus résistants aux pannes.
  • Je scripte désormais systématiquement mes processus de détection de panne, de diagnostique et de réparation.
  • Ce stress test géant m’a poussé à découvrir de nouveaux outils pour gérer la situation comme l’API d’OVH, les logs MySQL, l’outil « Monitor Apache »…

Merci d’avoir lu cet article jusqu’au bout 🙂

Vous prendrez bien quelques prestations ?

Sachez que je propose des prestations de SEO :

Vous pouvez suivre mon actualité via Twitter, LinkedIn ou ma newsletter 🙂

Si vous avez des questions, n’hésitez pas à utiliser les commentaires 📝

12 Replies to “14 jours difficiles”

  1. Belle galère effectivement, que connaissent parfois les entrepreneurs et que ne soupçonnent jamais les clients ou les tiers. Déjà connu ce genre de situation pour d’autres problématiques, le plus dur à supporter est le « yaka » ou le « taltan » qu’on entend dans ces moments là.
    Merci de ce retour d’expérience.
    A bientôt

    1. J’ai eu de la chance, je n’ai pas eu trop de retour de ce style, c’était plutôt à base de « Ok, je te fais confiance, tu vas gérer ». L’air de rien ces encouragements aident beaucoup lorsque la situation est compliquée 🙂

  2. J’ai l’impression d’avoir vécu une telle expérience mais bien sur à mon niveau .
    Merci François au top ce retour d’expérience surtout l’optimisation et les hacks…
    À bientôt

    1. Tous les entrepreneurs traversent des galères, mais c’est toujours plus confortable de parler des succès. Je crois que c’est important de dire que tout n’est pas toujours génial et que parfois il faut se travailler fort et longtemps pour que le système fonctionne 🙂

  3. Effectivement, la confiance est importante dans ces cas là. Personnellement tu as la mienne et je savais que tu trouverais 😉 Au final j’étais surtout content de ne pas être à ta place lol.

  4. Bonjour, juste pour info, et histoire que vous ne fassiez pas la route pour rien, Gravelines n’est pas dans le département de la Manche 🙂

  5. Passionnante histoire que la vôtre et pleine de suspense ! Je me posais une question au sujet du nombre d’ip dont vous disposez chez OVH, quel est le produit/service qui permet d’en avoir autant ?

    1. Merci 🙂
      J’ai un peu plus de 1000 IP chez OVH
      C’est le service « IP failover » qui permet de les avoir, mais je crois que le nombre maximal est maintenant assez restreint (je l’ai commandé il y a plusieurs années).