20 avril 2019

Hébergement sur mesure. Mesurer pour décider et choisir la solution la plus adaptée.

Une approche technique et stratégique pour concevoir des solutions d'hébergement véritablement personnalisées, en commençant par l'analyse des données et les besoins réels du projet.

Hébergement personnalisé

L'une des questions les plus absurdes que l'on a l'habitude de lire sur le net est : "Est-ce que quelqu'un me recommande un hébergement WordPress performant et pas cher ?", suite au festival des réponses des sociétés d'accueil, chacune élevée au gré d'expériences personnelles directes ou indirectes.

Le problème est que nous parlons de cas et de situations absolument différents qu'il est impossible d'évaluer sans une analyse appropriée des exigences et des besoins.

Que répondriez-vous à ceux qui vous ont demandé :

Michael Jordan ou Diego Armando Maradona étaient-ils plus forts ?

Du point de vue de l'hébergement, la question sonne plus ou moins la même. Il n'a pas de réponse, mais il en mérite certainement une.

La raison est facile à dire, l'informatique est une science presque exact et donc il faut mesurer puis décider. Cette étape est vitale car une mauvaise évaluation fait perdre de l'argent au client.
Cela leur fait perdre essentiellement pour deux raisons, la première parce que le site risquerait d'être lent voire de planter sous le poids d'une charge importante, l'autre raison est qu'il pourrait être poussé à acheter un plan d'hébergement très surdimensionné pour des besoins réels et donc peut-être jeter des dizaines de milliers d'euros par an alors qu'il aurait suffi de simplement évaluer la situation avec calme et compétence puis de l'orienter vers la meilleure solution matérielle et logicielle afin de répondre aux besoins techniques sans aller surdimensionner le matériel et connexes des coûts qui dans certains cas avec certains de nos clients pourraient même atteindre 12 mille euros par mois.

Alors voici ce qu'est un bon hébergement un bon ingénieur système devrait demander avant de référer un client ou un prospect à une solution d'hébergement, qu'il s'agisse d'un un hébergement mutualisé, un VPS, un Cloud ou un Serveur Dédié :

  1. Quel est le site ?
  2. Quel CMS utilisez-vous ?
  3. Quelle technologie matérielle utilisez-vous actuellement ?
  4. Quels sont les pics de trafic ?
  5. Les utilisateurs se contentent-ils de lire ou doivent-ils/peuvent-ils se connecter ?
  6. De quel type de continuité d'activité avez-vous besoin ?
  7. De quel budget disposez-vous ?

Essayons de comprendre l'importance de ces 8 questions et pourquoi tout bon ingénieur système, surtout si un ingénieur système Linux doit vous les poser.

1 - Qu'est-ce que le site ?

En connaissant simplement le nom du site, un ingénieur système expert est en mesure d'obtenir des données importantes pour dimensionner le matériel nécessaire et choisir le meilleur logiciel.

Grâce à des outils en ligne tels que SimiliarWeb, Weppalizer et BuildWith en fait, nous pouvons connaître en quelques secondes le nombre de visites mensuelles qu'il effectue et les technologies côté serveur qui actuellement, ainsi que via SEOZoom comprendre la tendance à la croissance ou à la baisse et donc peser le choix non seulement dans le présent immédiat, mais également dans un avenir proche.

Pour faire simple : cela nous permet d'avoir une vision approximative de notre futur client.

2 - Quel CMS utilisez-vous ?

Répondre à cette question nous fait immédiatement prendre conscience de la configuration côté logiciel que nous pourrions utiliser et des problèmes à résoudre. Utilisez-vous Joomla ? Utilisez-vous WordPress ? Utilisez-vous Magento, WooCommerce ou Prestashop ? Par exemple, on pourrait évaluer les marges d'amélioration et d'optimisation, sachant que normalement WooCommerce ne permet des améliorations décidément significatives qu'en intervenant sur la configuration logicielle alors que Prestashop fonctionne généralement déjà à son rythme et donc les marges d'amélioration que l'on peut obtenir à partir d'un bon les réglages sont minimes et vous devez nécessairement évaluer le matériel et le dimensionner de manière appropriée si les performances actuelles ne nous satisfont pas.

Logo CMS

Mais surtout, utilisez-vous un CMS ou un site personnalisé ?

Prendre conscience de l'utilisation d'un système personnalisé peut-être écrit ad-hoc qui n'utilise aucun CMS nous prévient immédiatement d'un terrain inconnu, dont on ne sait pas quels peuvent être les points faibles, la possibilité d'utiliser un cache statique et dynamique sans bouleverser le code, d'éventuels problèmes d'inefficacité et de lenteur excessive sur la base de données, des requêtes lentes, l'utilisation d'index, les optimisations associées etc.

3 - Quelle technologie matérielle utilisez-vous actuellement ?

Répondre à cette question signifie clarifier laarchitecture matérielle qui héberge actuellement le site Web ou l'infrastructure WebIl s’agit d’informations cruciales car elles nous permettent de comprendre immédiatement les limites, le potentiel et les problèmes critiques potentiels du système utilisé.

Si le client nous répond que le site est hébergé sur un hébergement partagé (hébergement mutualisé)Ces données à elles seules dressent un tableau assez clair : partage intensif des ressources, risques de survente, performances souvent instables et limitations opérationnelles dictées par un environnement rigide conçu pour des scénarios à faible coût plutôt que pour la performance ou l'évolutivité. Les grands fournisseurs ont tendance à vendre ces services en mettant l'accent sur le prix et la simplicité, mais souvent au détriment de la qualité technique réelle.

La situation est différente si le client utilise un VPS, environnement Cloud ou serveur dédiéDans ces cas-là, il est essentiel d'entrer dans les détails. Il faut savoir :

  • Nombre de cœurs de processeur réellement disponibles

  • Quantité et type de RAM installée

  • Vitesse de connexion réseau (liaison montante)

  • Type et vitesse du disque (HDD, SSD, NVMe, RAID si applicable)

  • Fournisseur d'hébergement ou d'infrastructure (par exemple, Hetzner, OVH, AWS, etc.)

Ces éléments nous permettent de évaluer correctement les performances réelles de l'environnement actuelPar exemple, il est courant de trouver des VPS avec de nombreux cœurs et beaucoup de RAM, mais pénalisés par des E/S disque extrêmement lentes, ou, à l'inverse, des environnements avec des disques NVMe ultra-rapides, mais des CPU sous-alimentés pour une utilisation réelle, comme dans le cas d'un site eCommerce WordPress avec un grand nombre de plugins et de trafic.

Cette analyse initiale nous permet non seulement de mettre en évidence d’éventuels goulots d’étranglement ou problèmes structurels, mais également de faites des choix plus intelligents lors de la conception de votre nouvel environnement:nous pourrions décider d'augmenter le nombre de cœurs ou de RAM, ou – si l'environnement actuel est surdimensionné par rapport à l'utilisation réelle – d'optimiser et de réduire les ressources, obtenant ainsi des économies économiques sans sacrifier les performances.

Dans une approche technique rigoureuse, où Mesurer avant d'agir est essentielConnaître votre matériel actuel nous permet de prendre des décisions éclairées et fiables, en construisant une nouvelle infrastructure sur des bases solides et sans conjectures inutiles.

4 - Quels sont les pics de trafic ?

Bien qu'en regardant le premier point de cette liste à travers les outils d'analyse susmentionnés, nous puissions connaître assez précisément le trafic mensuel, ce que nous ne pouvons pas connaître, ce sont les pics de trafic qu'un site peut recevoir.

Par exemple, si un journal publie la nouvelle d'un tremblement de terre, plutôt que celle d'un attentat à la bombe contre un bureau politique, combien de visiteurs peut-il faire ?

Trafic Google Analytics

On a eu le cas d'un article de presse partagé sur le mur Facebook et Twitter de l'actuel Premier ministre Salvini, qui a conduit le site en question à bien marquer 5 millions de visites en une seule journée, dont les deux premiers millions en deux heures. Évidemment, un tel cas peut être considéré comme un cas exceptionnel, peu probable mais pas impossible.

Une réponse de mémoire

5 - Les utilisateurs se contentent-ils de lire ou doivent-ils/peuvent-ils se connecter ?

Cette question est d'une importance vitale surtout lorsqu'il s'agit de systèmes interactifs tels que les forums, le commerce électronique ou les zones restreintes. S'il est vrai que de pitoyables performances natives peuvent être habilement masquées par l'utilisation de caches statiques tels que Vernis SuperCache ou des solutions similaires, il est également vrai qu'un utilisateur connecté en tant que tel ne peut pas bénéficier de cet avantage car le cache est contourné pour des raisons évidentes.

Dans ce cas, il est bon de connaître la nature de l'application et de prévoir le nombre d'utilisateurs connectés et non connectés et de mesurer la charge afin de dimensionner ultérieurement le matériel à choisir.

6 - De quel type de continuité d'activité avez-vous besoin ?

Cette question peut sembler évidente puisque tout le monde répondrait à 100% bien sûr, mais en fait nous savons qu'un vrai 100% signifie en fait avoir une telle redondance géographique qui nécessite un double DNS, une double instance géographiquement redondante peut-être sur Amazon AWS qui n'est pas vraiment bon marché. La différence entre 99,9 % et 100 % alors qu'elle n'est que de 0,1 % en termes de disponibilité de l'infrastructure matérielle et logicielle signifie dépenser environ 10 fois plus.

Pour être clair, dépensez-vous 300 euros par mois pour avoir 99,9% de disponibilité ? Soyez prêt à dépenser AU MOINS 3000 si vous voulez avoir 100% de disponibilité.

Est-ce que ça a du sens ? Ça dépend. 

Avec l'aide de Calculateur de disponibilité en fait, nous pouvons déterminer combien de temps de disponibilité de 99,9% est mensuel, ou mieux encore un combien est le temps d'arrêt.

Comme on peut le voir sur le site, 99,9% correspond à 43 minutes d'indisponibilité mensuelle. Il faut dire que généralement avec une garantie de 99.9%, le double du temps des procédures de reprise après sinistre est toujours calculé en cas de problème.

Par conséquent, imaginons que votre entreprise reste immobile pendant 2 heures deux fois par an, pour un total de 2 heures par an. Ces 4 heures d'arrêt peuvent-elles justifier une dépense hypothétique de 4 mille euros de plus par an pour atteindre un hypothétique 30%, contre une dépense de 100 euros par an pour avoir 3600% ?

Cela dépend de l'activité que vous faites et de ce que rapporte votre site, soit en termes d'image, soit en termes de revenus ou de revenus. La réalité est également assez différente, dans le sens où les pannes sont encore rares (un couple par an) durant entre 5 à 15 minutes et en fait même dans les solutions redondantes avec 100% de disponibilité elles peuvent avoir des problèmes de nature logicielle qui conduisent toujours à problèmes. C'est également arrivé à de grands acteurs tels que Ebay, Amazon, Spotify, Netflix qui sont restés inactifs pendant plus de 4 heures. ( Le rapport d'échec original d'Amazon S3 ici ) et il est donc incontesté de dire qu'une baisse de quelques minutes par an peut être là.

Cet aspect doit donc être très bien évalué, en tenant compte en fait si vous préférez risquer d'avoir 1 heure d'arrêt mais une économie considérable sur les coûts d'infrastructure (une économie moyenne indicative de 500 % jusqu'à plus de 1000%) ou s'il est de importance vitale, atteindre 100 % et donc ne ménager aucune dépense.

Le choix dans ces cas dépend souvent d'une logique métier pas trop intelligente mais tout de même légitime surtout de la part des grands groupes d'édition et des grandes entreprises habitués à stipuler des contrats de service entre managers sans savoir le moins du monde de quoi ils parlent, exiger le meilleur du marché dans le seul but de protéger leur position de travail face à d'éventuels problèmes, en justifiant leur position comme celle de celui qui a fait le choix du marché.

7 - De quel budget disposez-vous ?

C'est peut-être la question la plus délicate à poser, et elle l'est encore plus en Italie. Parler ouvertement d'argent est souvent perçu comme de mauvais goût, presque comme un tabou culturel. Contrairement à d'autres pays où les discussions budgétaires font partie intégrante et transparente de toute négociation, dans notre contexte, cela semble presque intrusif et insensible. Et pourtant, aussi provocateur ou prématuré que cela puisse paraître, c'est… l'une des questions les plus importantes à poser au début d'un projet, et pas à la fin.

Connaître le budget disponible ne signifie pas vouloir « presser » le client, mais au contraire cela permet de définir un périmètre réaliste dès le départ, en évitant les propositions trop ambitieuses ou, au contraire, excessivement restrictives. Sans ces informations, toute discussion sur le matériel, les logiciels, l'architecture et les performances risque d'être vague, théorique et souvent déconnectée de la réalité opérationnelle.

Budget d'hébergement de sites Web

En outre, travailler « à moindre coût » alors que le budget permettrait une infrastructure plus performante C'est une erreur qui finit toujours par payer. Il est inutile (et contreproductif) de concevoir sur du matériel aux limites de ses capacités si l'on dispose des moyens financiers nécessaires pour opter pour des solutions plus stables, évolutives et durables. Un budget équilibré permet de mettre de côté les compromis inutiles, réduire les risques de goulots d’étranglement et assurer une plus grande tranquillité d’esprit dans la gestion quotidienne du projet.

En bref : la question budgétaire est non seulement légitime, mais fondamentale. Y répondre honnêtement permet à ceux qui conçoivent les infrastructures de construire quelque chose de cohérent, solide et durable, évitant ainsi le gaspillage et la frustration. C'est la première étape pour transformer une idée en une solution concrète et dimensionnée.

conclusion

En conclusion, nous pouvons dire que si vous ne savez pas comment choisir un hébergement ou comment choisir un serveur dédié vous devez au moins connaître ces données ci-dessus et être en mesure de répondre à ces sept questions. Si vous avez des doutes, vous souhaitez essayer de comprendre quelle est la solution la plus adaptée à vos besoins et connaître tous les avantages et inconvénients, n'hésitez pas à nous contacter.

Nous avons une expérience vraiment vaste avec de nombreuses études de cas allant de l'amateur aux portails et journaux et sites sectoriels avec plus de 50 millions de visiteurs mensuels par mois.

Vous avez des doutes ? Vous ne savez pas par où commencer ? Contactez-nous !

Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

AVIS DE NON-RESPONSABILITÉ, Mentions légales et droits d'auteur. Red Hat, Inc. détient les droits sur Red Hat®, RHEL®, RedHat Linux® et CentOS® ; AlmaLinux™ est une marque commerciale de la AlmaLinux OS Foundation ; Rocky Linux® est une marque déposée de la Rocky Linux Foundation ; SUSE® est une marque déposée de SUSE LLC ; Canonical Ltd. détient les droits sur Ubuntu® ; Software in the Public Interest, Inc. détient les droits sur Debian® ; Linus Torvalds détient les droits sur Linux® ; FreeBSD® est une marque déposée de la Fondation FreeBSD ; NetBSD® est une marque déposée de la Fondation NetBSD ; OpenBSD® est une marque déposée de Theo de Raadt ; Oracle Corporation détient les droits sur Oracle®, MySQL®, MyRocks®, VirtualBox® et ZFS® ; Percona® est une marque déposée de Percona LLC ; MariaDB® est une marque déposée de MariaDB Corporation Ab ; PostgreSQL® est une marque déposée de PostgreSQL Global Development Group ; SQLite® est une marque déposée de Hipp, Wyrick & Company, Inc. ; KeyDB® est une marque déposée d'EQ Alpha Technology Ltd. ; Typesense® est une marque déposée de Typesense Inc. ; REDIS® est une marque déposée de Redis Labs Ltd ; F5 Networks, Inc. détient les droits sur NGINX® et NGINX Plus® ; Varnish® est une marque déposée de Varnish Software AB ; HAProxy® est une marque déposée de HAProxy Technologies LLC ; Traefik® est une marque déposée de Traefik Labs ; Envoy® est une marque déposée de CNCF ; Adobe Inc. détient les droits sur Magento® ; PrestaShop® est une marque déposée de PrestaShop SA ; OpenCart® est une marque déposée d'OpenCart Limited ; Automattic Inc. détient les droits sur WordPress®, WooCommerce® et JetPack® ; Open Source Matters, Inc. détient les droits sur Joomla® ; Dries Buytaert détient les droits sur Drupal® ; Shopify® est une marque déposée de Shopify Inc. ; BigCommerce® est une marque déposée de BigCommerce Pty. Ltd.; TYPO3® est une marque déposée de la TYPO3 Association; Ghost® est une marque déposée de la Ghost Foundation; Amazon Web Services, Inc. détient les droits sur AWS® et Amazon SES® ; Google LLC détient les droits sur Google Cloud™, Chrome™ et Google Kubernetes Engine™ ; Alibaba Cloud® est une marque déposée d'Alibaba Group Holding Limited ; DigitalOcean® est une marque déposée de DigitalOcean, LLC ; Linode® est une marque déposée de Linode, LLC ; Vultr® est une marque déposée de The Constant Company, LLC ; Akamai® est une marque déposée d'Akamai Technologies, Inc. ; Fastly® est une marque déposée de Fastly, Inc. ; Let's Encrypt® est une marque déposée d'Internet Security Research Group ; Microsoft Corporation détient les droits sur Microsoft®, Azure®, Windows®, Office® et Internet Explorer® ; Mozilla Foundation détient les droits sur Firefox® ; Apache® est une marque déposée de The Apache Software Foundation ; Apache Tomcat® est une marque déposée de The Apache Software Foundation ; PHP® est une marque déposée de PHP Group ; Docker® est une marque déposée de Docker, Inc. Kubernetes® est une marque déposée de The Linux Foundation ; OpenShift® est une marque déposée de Red Hat, Inc. ; Podman® est une marque déposée de Red Hat, Inc. ; Proxmox® est une marque déposée de Proxmox Server Solutions GmbH ; VMware® est une marque déposée de Broadcom Inc. ; CloudFlare® est une marque déposée de Cloudflare, Inc. ; NETSCOUT® est une marque déposée de NETSCOUT Systems Inc. ; ElasticSearch®, LogStash® et Kibana® sont des marques déposées d'Elastic NV ; Grafana® est une marque déposée de Grafana Labs ; Prometheus® est une marque déposée de The Linux Foundation ; Zabbix® est une marque déposée de Zabbix LLC ; Datadog® est une marque déposée de Datadog, Inc. ; Ceph® est une marque déposée de Red Hat, Inc. ; MinIO® est une marque déposée de MinIO, Inc. ; Mailgun® est une marque déposée de Mailgun Technologies, Inc. ; SendGrid® est une marque déposée de Twilio Inc. Postmark® est une marque déposée d'ActiveCampaign, LLC ; cPanel®, LLC détient les droits sur cPanel® ; Plesk® est une marque déposée de Plesk International GmbH ; Hetzner® est une marque déposée de Hetzner Online GmbH ; OVHcloud® est une marque déposée d'OVH Groupe SAS ; Terraform® est une marque déposée de HashiCorp, Inc. ; Ansible® est une marque déposée de Red Hat, Inc. ; cURL® est une marque déposée de Daniel Stenberg ; Facebook®, Inc. détient les droits sur Facebook®, Messenger® et Instagram®. Ce site n'est pas affilié, sponsorisé ou autrement associé à l'une des entités mentionnées ci-dessus et ne représente aucune de ces entités de quelque manière que ce soit. Tous les droits sur les marques et noms de produits mentionnés sont la propriété de leurs titulaires respectifs des droits d'auteur. Toutes les autres marques mentionnées sont la propriété de leurs titulaires respectifs. MANAGED SERVER® est une marque déposée européenne de MANAGED SERVER SRL, dont le siège social est situé Via Flavio Gioia, 6, 62012 Civitanova Marche (MC), Italie et le siège opérationnel Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italie.

JUSTE UN MOMENT !

Vous êtes-vous déjà demandé si votre hébergement était nul ?

Découvrez dès maintenant si votre hébergeur vous pénalise avec un site web lent digne des années 1990 ! Résultats immédiats.

Fermer le CTA
Retour en haut de page