Dix tickets de support en dix ans : voilà à quoi ressemble une infrastructure ennuyeuse.
Un éditeur de presse national fait tourner ses soirées électorales sur notre matériel. En dix ans, il a ouvert une dizaine de tickets de support. Voici ce qu'il a fallu pour le bâtir.
Dans cet article 5 sections
- Un éditeur de presse national est sur notre matériel depuis dix ans et a ouvert environ dix tickets de support sur cette période.
- Ses soirées électorales et ses finales de championnat tournent sur notre matériel. Rien ne sonne. Ce silence est le livrable, pas un heureux hasard.
- La stack est délibérément terne : du bare metal en cluster sur HPE ProLiant, un ensemble connu de briques, des ingénieurs qui répondent à votre ticket.
- Le même soin s'applique vers le bas. Une seule machine sérieuse fait tourner une chaîne de magasins de réparation sur exactement le même principe.
Une bonne infrastructure n'a pas d'histoire à raconter. La métrique que personne ne met sur une diapositive est celle qui compte le plus : combien de fois quelqu'un a-t-il dû y penser ? Pour l'éditeur, la réponse, sur dix ans d'actualité continue à fort trafic, est environ dix fois. Ce n'est pas un témoignage. C'est un décompte.
Ce dont ils avaient besoin
Le brief tenait en une phrase : quand il faut atteindre ses lecteurs, il n'y a pas de compromis avec l'interruption. Le pic d'un éditeur n'est pas une montée lente qu'on regarde sur un tableau de bord et pour laquelle on provisionne à l'avance. C'est un verdict qui tombe à 21h00, un but dans les arrêts de jeu, une démission que personne n'avait vue venir.
Ce que nous avons bâti
Nous n'avons rien bâti d'exotique. Nous avons bâti une chose connue, bien, sur du matériel dédié. Plus de 30 serveurs HPE ProLiant faisant tourner des charges de travail bare metal en cluster : HAProxy et Varnish en bordure, nginx et PHP, des clusters Percona XtraDB, Valkey et Elasticsearch en cluster, sur du stockage HPE 3PAR all-flash avec 3PAR Peer Persistence, avec un disaster recovery géographiquement distribué.
- CALCUL
- HPE ProLiant, bare metal, en cluster
- BASE DE DONNÉES
- Percona XtraDB Cluster (plusieurs, à 3 nœuds)
- RECHERCHE / CACHE
- Elasticsearch · Valkey · Varnish
- STOCKAGE
- HPE 3PAR all-flash, Peer Persistence
- DISASTER RECOVERY
- Disaster recovery géographiquement distribué
La partie la plus révélatrice de la construction est une partie que ses lecteurs n'ont jamais vue. La plateforme a été déplacée d'Amsterdam vers Digital Realty Athens il y a quelques mois, et la bascule est passée inaperçue de ses lecteurs.
Ce qui a changé
Désormais, les soirées électorales et les finales de championnat tournent, et le support n'entend rien.
Remarquez ce qui ne s'est pas passé. Nous n'avons pas vendu à l'éditeur un compteur plus gros ni un niveau de support premium pour survivre à ses pics. Nous avons dimensionné la machine au pic réel et mis la marge dans la boîte.
Le reçu
On peut discuter des adjectifs. On ne peut pas discuter d'un décompte de tickets. Voici celui de l'éditeur, face à une décennie du schéma de trafic le plus impitoyable de l'édition.
Les soirées électorales de l'éditeur ont lieu. Personne n'appelle. Le silence, dans ce métier, est tout le produit. Le reste est de l'emballage.
Pourquoi cela se généralise
Rien de ce qui a rendu la plateforme de l'éditeur ennuyeuse n'est propre à l'édition. Du matériel qui vous appartient sans compteur dessus, une stack connue au lieu d'un zoo de services à moitié compris, et des ingénieurs qui répondent à votre ticket avec un nom au lieu d'une file. Voilà les ingrédients, et ils n'exigent pas un lectorat national pour fonctionner. Nos cas clients montrent davantage de notre façon de travailler.
Le même soin descend jusqu'à une seule machine sérieuse. Une chaîne de magasins de réparation fait tourner ses magasins, ses techniciens et son ERP critique pour l'entreprise sur un seul serveur dédié. Taille différente, résultat identique : une infrastructure qui fait son travail puis s'efface.
Réponses directes
Comment savoir que cela s'applique à ma taille ?+
Parce que le principe ne porte pas sur la taille. Il porte sur le fait de posséder le matériel, de standardiser la stack, et d'avoir un ingénieur nommé sur votre ticket. Cela fonctionne sur une seule machine dédiée et sur un cluster privé complet. Le Sizing Desk vous dira quelle extrémité de cette gamme il vous faut vraiment, et il penche vers la réponse la plus petite.
Que comprend « managed » ?+
La migration de nos mains, l'exploitation quotidienne de la plateforme, et l'optimisation des performances et de la sécurité, tout de notre côté de la ligne. Nous le bâtissons, nous le faisons tourner, nous répondons quand quelque chose demande de l'attention. Pour l'éditeur, cela a voulu dire une dizaine d'occasions en dix ans.
Que se passe-t-il le soir de mon pic ?+
Vous débordez dans une marge qui est déjà dans la boîte, parce que c'est du matériel dédié et qu'il n'y a pas de compteur dessus. Nous dimensionnons cette marge sur votre pic réel dès le départ.
Et si tout un datacenter passe une mauvaise journée ?+
La plateforme de l'éditeur a un disaster recovery géographiquement distribué, donc un problème sur un site n'est pas un problème pour ses lecteurs.
Dimensionnez le cluster derrière une soirée électorale sans histoire
Répondez à quelques questions et le Sizing Desk propose une vraie architecture à partir de nos vraies briques. Il vous dira si vous avez besoin de moins que vous ne le pensez. C'est le cas de la plupart des gens.
Dimensionner votre clusterVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur