Bonjour,
Comme convenu sur nos posts sur les réseaux sociaux Linkedin et Facebook, nous allons revenir sur le sinistre de Strasbourg dans cette lettre d'information ainsi que faire un point sur les évolutions du service TW entreprises depuis ainsi que les impacts sur les entrées de gamme (forfaits STARTER et HA/L1).
1/ Sinistre de Strasbourg : crash test réussi pour les infrastructures HA TOUCHWEB
Le 10 Mars 2021 restera gravé à tout jamais dans le marbre pour les professionnels du Web, l'Europe s'est réveillée sous le choc : l'un des plus importants centre de données du continent était en flamme engendrant la destruction irrémédiable de plusieurs milliers d'ordinateurs (serveurs) et par effet de bord, la mise hors service de plusieurs dizaines de milliers d'applications Web et de sites Internet.
Le retour dans le réel a été violent pour certains : oui le Web n'a rien de surnaturel, rien d'immatériel : les données digitales constitutives des systèmes d'information et permettant aux applications Web / site E-Commerce de fonctionner sont bel et bien physiquement stockées sur du matériel réel et physique - susceptible d'être détruit.
Vous avez tous lu beaucoup de choses à propos de ce sinistre sur le Web dont un volume certain coécrit par des incompétents cherchant à se déresponsabiliser d'avoir vendu des sauvegardes low cost (mono site ou mono zone géographique) ou encore des infrastructures sans aucune tolérance de panne, sans l'assumer auprès de leurs clients.
Que cela soit formellement dit : nous considérons qu'OVH n'a aucune responsabilité dans ce sinistre et qu'OVH a parfaitement su répondre à ce désastre, un constat partagé par tous les professionnels du secteur vendant des PRA (plan de reprise de l'activité incluant de la sauvegarde multi-site et multi-hébergeur) rigoureusement maîtrisés et rôdés.
Autrement dit des professionnels qui assurent une résilience optimale des services de leurs clients (applications et sites Web), gérant tous types de scénarios incluant donc une destruction irrémédiable du matériel stockant les données digitales nécessaire au fonctionnement des applications et sites Web.
Tous les acteurs de l'hébergement, absolument tous, ont un passif de dysfonctionnement plus ou moins sévère, incluant des incidents d'envergure mondiale (Amazon en novembre 2020, Google en février 2021).
On sait tous que la question n'est pas "quand va t'il y avoir un problème", il va évidemment y avoir des problèmes, la question a toujours été : "comment les gère t'on le mieux possible ?"
Nos PRA avaient déjà été éprouvés aux doubles incidents de novembre 2017, cette fois-ci ils ont été éprouvés dans le pire des scénarios raisonnablement imaginables avec succès (hors guerre).
Aucun client consommant des infrastructures haute-disponibilité n'a perdu de données.
2/ Aucune infogérance professionnelle ne vend de la "sauvegarde" - On vend des PRA et de la portabilité inter-serveur contractuellement garantie
On vous l'a tous déjà au moins dit une fois, aucun professionnel qualifié ne vend de la "sauvegarde", ce mot clé n'ayant que peu de sens "seul" ou le cas échéant, invisibilise souvent (si ce n'est toujours) une technique précaire et donc dangereuse.
Il est essentiel de préciser si les sauvegardes sont copiées/collées sur plusieurs ordinateurs (serveurs) distincts sur plusieurs zones géographiques distinctes ou non, autrement dit si ce sont des sauvegardes mono-site ou des sauvegardes multisite, et si possible multisite ET multi-hébergeur (ce que TOUCHWEB vous vend)
Cependant, le fait d'avoir une sauvegarde multisite et multi-hébergeur ne répond en aucune manière exhaustivement au besoin de reprise de l'activité.
Un enseignement qui n'a toujours pas été compris vu ce qu'on peut lire sur la toile à ce propos : une sauvegarde exploitable n'est qu'un fragment d'un PRA (plan de reprise de l'activité), critique et indispensable pour jouer un PRA, mais qu'un fragment.
Vous devriez avoir tous déjà au moins une fois dans votre vie formaté (ou fait formater) votre ordinateur, vous avez probablement "sauvegardé" vos données (comptabilité / image / vidéo / etc).
Vous avez dû constater qu'entre la fin du formatage de votre ordinateur, et le moment ou vous avez récupéré une productivité optimale, c'est à dire quand vous avez fini de réinstaller tous les logiciels nécessaires à vos activités professionnelles (Photoshop / Sage / Ciel / etc), il s'est écoulé plusieurs heures, et parfois plusieurs jours suivant la complexité de réinstallation des suites logicielles dont vous avez besoin et de leurs re-paramétrages (comme par exemple, reconfigurer tous les raccourcis sur tous vos logiciels).
Un PRA (plan de reprise de l'activité) répond de manière opérationnelle à ce besoin précis, il détaille donc avec soin et rigueur tout ce qui est nécessaire de faire pour restaurer votre activité dans son état originel, vous permettant ainsi de récupérer une productivité optimale.
Si sur votre ordinateur il est souvent question de quelques dizaines - au pire centaines de configurations à restaurer, sur vos serveurs, nous parlons de plusieurs milliers de configurations à ajuster/contrôler.
Notre superviseur système est capable de restaurer à l'identique vos serveurs en cas de formatage (sans machine virtuelle ni container donc hautement résistant à des piratages), c'est grâce à cela qu'il n'y a eu aucune dégradation de service chez aucun de nos clients consommant des infrastructures haute disponibilité.
Dans l'intérêt des tiers et compte tenu des bêtises qu'on a pu lire et continue de lire sur Internet, il est essentiel que tout le monde communique à ce propos : ce n'est pas de la sauvegarde dont les tiers ont besoin, ce sont des PRA professionnels.
La plupart d'entre vous ont des réseaux informatiques dans leurs locaux, si vous ne l'avez pas déjà fait, nous vous suggérons vivement de vous poser avec votre prestataire de maintenance informatique pour discuter du PRA de votre réseau local informatique.
En 2021, votre PRA doit aussi répondre aux problématiques de piratage (ransomware).
3/ Suppression définitive des dépendances des infrastructures de service TOUCHWEB à OVH
La suite va être relativement technique et est difficilement "vulgarisable", elle est à destination de nos partenaires à l'ingénierie logicielle ainsi qu'à nos clients ayant une fibre technique.
Même si nos PRA prenaient parfaitement en charge le risque de destruction de serveurs, incluant mécaniquement une destruction d'envergure d'infrastructure (25% de l'infrastructure impactée), des optimisations possibles ont été découvertes.
Pour répondre à un ensemble d'incidents, incluant entre autres choses, les incidents de serveur de noms empêchant les superviseurs de momentanément dialoguer avec l'hyperviseur, il avait été convenu en 2017 qu'il était nécessaire de "coder en dur" l'adresse IP Failover du load-balancer du collecteur maître de l'hyperviseur dans les codes sources du superviseur. Cela a engendré des difficultés le 10 Mars entre 3h30 du matin et 5h30 du matin vu que les API OVH étaient totalement congestionnées. On a été contraint de mettre à jour en urgence sur la période quelques 250 serveurs pour récupérer une visibilité complète sur l'infrastructure.
Il est apparu obligatoire de supprimer définitivement nos dépendances aux adresses IP Failover et donc au Manager OVH pour améliorer nos temps de réponse en cas de désastre.
On s'est inspiré de ce que Cisco a mis en place sur le projet ClamAV pour distribuer les mises à jour anti-virales pour distribuer nos pointages d'adresse IP pour les services critiques/sensibles (bastion / déploiement / hyperviseur), via un réseau privé multi point et multi hébergeur de serveurs DNS - chaque point étant autonome vis à vis des autres, l'autorité étant donné à celui ayant la zone DNS la plus récente.
Grâce à cela, même en cas de désastre, on pourra récupérer une visibilité totale sur l'infrastructure dans les 5 minutes (au lieu d'une heure et demie à 2 heures avant en cas de paralysie totale des adresses IP Failover).
Il a par ailleurs été décidé que toutes les infrastructures critiques (incluant le réseau multi point des bastions et de déploiement) devaient être consolidées, ces infrastructures sont donc maintenant composées de 5 à 7 serveurs au lieu de 3 à 4, et toutes les infrastructures sensibles devaient être triplées, les infrastructures de l'hyperviseur, des dépôts Debian privés TOUCHWEB, des serveurs de noms et des Gitlab sont donc maintenant composées de 3 serveurs au lieu de 2.
Cela fait presque 3 mois que l'on travaille d'arrache-pied sur ces améliorations, les derniers jalons ont été déployés sur l'infrastructure mardi 22 juin. Si ce type de désastre arrive de nouveau un jour, on sera encore plus réactif.
A tous nos clients jouant le jeu des forfaits par CA : tout cela est permis grâce à vous, merci infiniment. On met tout en œuvre pour vous le rendre et continuer de consolider le service - votre service.
Un grand merci à vous de nous avoir soutenu pendant ce désastre.
4/ Location à perte de 14 000€ HT / an de serveur pour atténuer les effets de bord de la pénurie de stock
Dans la continuité du sinistre de Strasbourg, ayant engendré une pénurie européenne de stock chez les hébergeurs adaptés au marché des TPE ET ayant plusieurs centres de données, donc seuls à être en capacité de louer des infrastructures haute-disponibilité, il a été décidé de constituer un stock permanent de serveurs à destination de nos clients.
C'était la deuxième itération en 14 ans d'une pénurie de serveurs d'envergure. La première datant de l'Automne 2011, générée par effet de bord des inondations en Thaïlande qui avait contraint des constructeurs majeurs (dont Western Digital et Toshiba) d'arrêter les lignes de fabrication de disque dur, ce qui, toujours par effet domino avait engendré une pénurie mondiale de disque dur et donc une incapacité des hébergeurs à livrer des serveurs pendant plusieurs semaines / mois.
La pénurie de 2021 possède un risque modéré de durer plusieurs mois, on n'attend aucun retour à la normale avant Q3 2021. Pourquoi ?
Tout d'abord, les stocks des hébergeurs ont été mobilisés pour reconstruire les 15 000 serveurs détruits dans l'incendie qui a ravagé les centres de données SBG1 et SBG2 de Strasbourg.
Ensuite, les gens qui n'avaient pas encore saisi l'importance de bénéficier de deux serveurs de production répartis dans deux centres de données géographiquement distants, l'ont dorénavant parfaitement saisi (pour ceux qui n'ont pas tout perdu). Mécaniquement cela a amplifié la demande.
Et pour finir, tout cela sur fond de pénurie mondiale de semi-conducteur aggravant fortement la congestion.
Ce stock est en rotation constante et permet d'atténuer les effets de bord du livrable en dent de scie sur les gammes usuelles de notre clientèle (RISE 1 | 450Go NVME / ADV 2 | 500Go NVME) représentant 95% du parc type BAREMETAL sous infogérance TW.
Vous pouvez suivre cela en toute transparence sur le Manager TW : menu Global > Infrastructure > Stock.
Nous attirons également votre attention sur le fait que cela ne couvre "que" 95% des besoins de nos clients, on ne peut raisonnablement pas constituer un stock sur toutes les gammes OVH disponibles.
ATTENTION : Si vous prévoyez une élévation forte de trafic et/ou de volumétrie de données nécessitant expressément un changement de serveurs, nous vous invitons à veiller à nous prévenir AU MOINS 45 jours à l'avance. Nous nous tenons à votre disposition pour en discuter le cas échéant.
5/ Oblitération de la rentabilité des entrées de gamme (forfaits Starter et HA/L1) TOUCHWEB - 40 000€ HT de préjudice
On en avait longuement parlé dans une précédente lettre d'information - que nous vous invitons à lire si vous ne l'avez pas lue : https://www.touchweb.fr/lettre-information-20081 (point 2) - le nivellement par le haut du service TOUCHWEB, en ce sens où se sont les GRANDS COMPTES qui fixent la norme de tous les points de contrôle et donc des interventions à réaliser a engendré par effet domino un risque élevé de travail à perte - toujours avéré en cas de déphasage entre le forfait retenu et le CA réalisé.
Cela nous avait déjà contraint à durcir le ton l'année passée sur les écarts abusifs entre le CA réalisé et le forfait consommé.
Compte tenu des remaniements d'infrastructure offerts - contraint sur les nouvelles gammes OVH, seuls serveurs que l'on pouvait acheter - le sinistre de Strasbourg a engendré un manque à gagner net d'environ 40 000€ HT, ce qui a oblitéré la rentabilité des entrées de gamme (forfaits Starter et HA/L1) de TOUCHWEB pour plusieurs années.
Nous travaillons donc officiellement à perte sur ces entrées de gamme jusqu'en 2023 - personne ne nous dédommagera.
La question d'arrêter définitivement ces gammes s'est sérieusement posée et après de longues discussions avec le réseau TW, il a été décidé de les maintenir mais de revoir le staging pour compenser le travail à perte.
Dans la continuité de la lettre d'information de Janvier 2021 - que nous vous invitons également à lire si vous ne l'avez pas lue : https://www.touchweb.fr/lettre-information-21011 - point 3, le travail à perte généré par les forfaits Starter était compensé par leur statut de Bêta testeur niveau 2 et l'on partait du principe que les forfaits HA/L3 et les forfaits Starter formaient un tout indissociable, le rentabilité des uns compensant le travail à perte des autres.
Les GRANDS COMPTES ayant expressément besoin de bêta testeur niveau 2 pour garantir une qualité irréprochable de service et en contrepartie les bêta testeur niveau 2 bénéficiant gratuitement de tous les outils conçus pour les GRANDS COMPTES incluant leurs mécaniques de cyber-défense avancées et des PRA professionnels.
Cette synergie vertueuse avait été actée avec le réseau TW courant 2020, les effets de bord du statut de Bêta testeur niveau 2 (tout comme le niveau 1) étant très limités compte tenu des processus hautement qualitatif de validation sur les préproductions TOUCHWEB.
A date, et ce depuis 4 ans, aucun bêta-testeur, qu'il soit niveau 1 ou niveau 2 n'a subi de dysfonctionnement préjudiciable ni de perte de données.
Pour neutraliser le travail à perte des forfaits HA/L1, on est donc contraint de les considérer comme formant un tout avec les contrats GC au même titre que les forfaits STARTER.
Voici donc le nouveau staging allant rentrer en application à compter des renouvellements de contrat (changement uniquement sur les forfaits STARTER et HA/L1) :
- Mise à jour sur les serveurs de préproduction TOUCHWEB
- Mise à jour sur les serveurs des bêta-testeurs niveau 1 (forfait à 30€ HT / serveur / mois - forfait STARTER)
- Mise à jour sur les serveurs des bêta-testeurs niveau 2 (forfait à 50€ HT / serveur / mois - forfait HA/L1)
- Mise à jour sur les serveurs des clients MC (forfait à moins de 100€ HT / serveur / mois - forfait HA/L2)
- Mise à jour sur les serveurs des clients GC (forfait à moins de 200€ HT / serveur / mois - forfait HA/L3)
- Mise à jour sur les serveurs des clients TGC (forfait à plus de 200€ HT / serveur / mois ou forfait à plus de 1 000€ HT / mois)
On a conscience de la perfectibilité de cette décision, maintenant, c'était soit cela, soit l'arrêt définitif des entrées de gamme - ce qui était exclu.
6/ A nos clients ne jouant pas le jeu du forfait / CA : arrêt définitif des tolérances contre les comportements jugés abusifs
Compte tenu de la neutralisation de la rentabilité des entrées de gamme, nous vous informons que tous les contrats ayant des écarts que nous jugeons abusifs entre le forfait consommé et le CA dépendant à la disponibilité des applications métiers (Prestashop / Magento / NodeJS / etc) installées sur vos serveurs sous infogérance TW seront cassés à leurs échéances.
Nous avions déjà remanié en profondeur nos contrats pour lutter contre ces pratiques abusives, via des remises type "FORFAIT ADAPTE" permettant à nos clients respectueux de bénéficier d'une continuité tarifaire et nous permettant de partiellement neutraliser le travail à perte sur les autres CLIENTS, non respectueux.
Si vous êtes concernés, vous avez déjà reçu un email à ce propos (d'arrêt de contrat en cas d'écart abusif OU d'application des pénalités financières pour obsolescence aggravée de vos applicatifs en cas d'écart élevé - l'accès aux dépôts Debian privés TOUCHWEB vous étant interdits).
Cette décision est dans la continuité.
Toujours aux concernés : qu'il soit écrit que cela vous a été notifié au moins 6 mois avant pour que vous ayez le temps nécessaire et suffisant pour vous retourner dans le respect de votre projet professionnel.
Par ailleurs, nous vous informons aussi qu'il n'y aura plus aucune tolérance sur les fermetures d'infrastructure imposées par votre hébergeur du fait d'un éventuel refus de votre part de mettre en place un moyen de paiement fiable par prélèvement bancaire. Cela va faire quatre ans que c'est la première cause d'incident majeur des serveurs sous infogérance TW, cela doit cesser.
Cela fait 2 ans qu'on a introduit les pénalités financières pour la gestion - sans jamais les appliquer. Ces pénalités seront maintenant appliquées, pour rappel et comme prévu par les contrats des éventuels concernés : 75€ HT à 150€ HT de pénalité PAR gestion d'incident pour cause d'impayé chez l'hébergeur ayant engendré une fermeture totale de l'infrastructure imposée par l'hébergeur.
7/ Evolution de la construction des infrastructures
Pour nos clients concernés, on vous a tous contacté individuellement à ce propos et fait évoluer en l'accord les infrastructures. Voici une liste des changements opérés :
- Pour les forfaits HA/L1 (CA inférieur à 250K€ HT / an) et si vous êtes à plus de 100K€ HT / an, il est devenu strictement interdit de ne pas avoir deux serveurs de production rigoureusement identiques - toutes les réplications ont été mises à jour en l'accord. On conserve les tolérances sur les CA inférieurs à 100K€ HT / an tout en vous rappelant que les économies que vous réalisez côté hébergeur seront partiellement neutralisées par nos interventions - facturées à hauteur de 200€ HT à chaque permutation de production maître vu que cela nous contraint à deux fois plus de travail.
- Pour les forfaits HA/L3 (CA inférieur à 2M€ HT / an), la gamme ADV2 devient vivement conseillée pour bénéficier des niveaux de service OVH relatifs (cela avait été mis en place courant 2020 pour les CA > 1M€ HT / an, on le généralise à toute la tranche de CA supérieure à 500K€ HT / an)
- Pour les forfaits HA/PME (spécifiquement sur les CA supérieurs à 4M€ HT / an), il est obligatoire de tripler les infrastructures de production dans un contexte multi-hébergeur (double serveur préservé chez OVH pour conserver la mobilité en 120 secondes des adresses IP Failover - clés de voûte des infrastructures haute disponibilité et un serveur chez Online) - ce que certains confrères qualifient de "MULTI CLOUD"
8/ A nos clients ayant des forfaits adaptés à leurs CA et ayant des serveurs sous Debian 9 (Stretch) : les pénalités financières prévues par vos contrats pour obsolescence ne seront pas appliquées au 1° Janvier 2022 mais au 1° Janvier 2023 (et vous ne devriez pas les subir pour 99% d'entre vous)
La communauté Debian est sur le final du nouveau système d'exploitation Debian 11 (nom de code Bullseye), dont la dernière phase de "gel" est prévue pour dans quelques semaines.
Comme tous les deux ans, c'est un chantier d'envergure qui nous attend et qui va nous occuper tout le deuxième semestre 2021 (stack de complexité faible à moyenne - Prestashop / Drupal / Wordpress / NodeJS / Magento 1), et probablement une partie du premier trimestre 2022 (stack de complexité forte - Magento 2 / Akeneo / Marello)
On fait le maximum pour finaliser la prise en charge Q4 2021 ou à défaut Q1 2022 pour pouvoir mettre à niveau les infrastructures de nos clients sous Debian 9 vers Debian 11.
On évalue l'investissement financier de la prise en charge à environ 90 000€ HT de R&D compte tenu des changements à opérer sur nos outils (incluant un remaniement complet de certaines mécaniques sensibles de cyber-sécurité dont le firewall)
L'arrivée des dépôts Debian privés et autogérés par TOUCHWEB vous a octroyé une grâce supplémentaire de 4 ans malgré l'éventuelle obsolescence aggravée de votre applicatif métier (Prestashop 1.7.7-, Magento 1.9, Wordpress 4, Symfony 3, etc).
Dans la continuité des précédentes lettres d'information, et avec le concours de Freexian SARL et d'Ondrej Surý, grâce à ces dépôts privés Raphael Hertzog nous a assuré qu'on aurait un support PHP 5.6 à PHP 8.X pour Bullseye - au moins pour le démarrage (on sera prévenu formellement par Ondrej en cas de changements ce qui nous permettra de photographier les dépôts et de vous distribuer les photographies pour préserver vos PRA)
L'objectif sur S1 2022, va donc être de migrer toutes les Debian 9 en voie rapide d'obsolescence vers Debian 11 grâce aux dépôts privés Debian gérés par TOUCHWEB propulsés avec le concours de Freexian SARL : https://php.freexian.com/
Nous vous tiendrons informés de l'avancement dans les prochaines lettres d'information.
Nous vous souhaitons une agréable fin de semaine
L'équipe TW - Votre spécialiste en infogérance serveur dédié