Dez tickets de suporte em dez anos é o aspeto da infraestrutura aborrecida.
Um editor de notícias nacional corre as noites eleitorais no nosso hardware. Em dez anos abriu cerca de dez tickets de suporte. Eis o que foi preciso para construir isso.
Neste artigo 5 secções
- Um editor de notícias nacional está no nosso hardware há dez anos e abriu cerca de dez tickets de suporte nesse tempo.
- As suas noites eleitorais e finais de campeonato correm no nosso hardware. Nada toca. Esse silêncio é o resultado entregue, não um acaso feliz.
- A stack é deliberadamente aborrecida: bare metal em cluster sobre HPE ProLiant, um conjunto conhecido de blocos de construção, engenheiros que respondem ao seu ticket.
- O mesmo cuidado escala para baixo. Uma única máquina a sério corre uma cadeia de lojas de reparação exatamente com o mesmo princípio.
A boa infraestrutura não tem história para contar. A métrica que ninguém põe num slide é a que mais importa: quantas vezes alguém teve de pensar nela? Para o editor, a resposta, ao longo de dez anos de notícias contínuas de tráfego elevado, é cerca de dez vezes. Isso não é um testemunho. É uma contagem.
O que precisavam
O briefing era uma frase: quando é preciso chegar aos leitores, não há compromisso com o downtime. O pico de um editor não é uma subida lenta que se observa num dashboard e para a qual se provisiona. É um veredicto que cai às 21:00, um golo nos descontos, uma demissão que ninguém viu chegar.
O que construímos
Não construímos nada de exótico. Construímos uma coisa conhecida, bem, em hardware dedicado. Mais de 30 servidores HPE ProLiant a correr cargas bare metal em cluster: HAProxy e Varnish no edge, nginx e PHP, clusters Percona XtraDB, Valkey e Elasticsearch em cluster, sobre storage HPE 3PAR all-flash com 3PAR Peer Persistence, com disaster recovery geograficamente distribuído.
- COMPUTAÇÃO
- HPE ProLiant, bare metal, em cluster
- BASE DE DADOS
- Percona XtraDB Cluster (vários, de 3 nós)
- PESQUISA / CACHE
- Elasticsearch · Valkey · Varnish
- STORAGE
- HPE 3PAR all-flash, Peer Persistence
- DISASTER RECOVERY
- Disaster recovery geograficamente distribuído
A parte mais reveladora da construção é uma que os seus leitores nunca viram. A plataforma mudou de Amesterdão para o Digital Realty Athens há meses, e o cutover passou despercebido aos leitores.
O que mudou
Agora as noites eleitorais e as finais de campeonato correm, e o suporte não ouve nada.
Repare no que não aconteceu. Não vendemos ao editor um contador maior nem um nível de suporte premium para sobreviver aos picos. Dimensionámos a máquina para o pico real e pusemos a margem dentro da caixa.
O balanço
Com adjetivos pode-se discutir. Com uma contagem de tickets não. Eis a do editor, contra uma década do padrão de tráfego mais implacável do setor editorial.
As noites eleitorais do editor acontecem. Ninguém liga. O silêncio, neste ofício, é o produto inteiro. Tudo o resto é embalagem.
Porque é que isto se generaliza
Nada do que tornou a plataforma do editor aborrecida é específico do setor editorial. Hardware próprio sem contador em cima, uma stack conhecida em vez de um jardim zoológico de serviços meio compreendidos, e engenheiros que respondem ao seu ticket com um nome em vez de uma fila. Esses são os ingredientes, e não precisam de um público nacional para funcionar. As nossas histórias de clientes mostram mais sobre como trabalhamos.
O mesmo cuidado escala até lá abaixo, até uma única máquina a sério. Uma cadeia de lojas de reparação corre as suas lojas, os seus técnicos e o seu ERP crítico para o negócio num único dedicated server. Tamanho diferente, resultado idêntico: infraestrutura que faz o seu trabalho e depois sai do caminho.

Respostas diretas
Como sei que isto se aplica ao meu tamanho?+
Porque o princípio não é sobre tamanho. É sobre ser dono do hardware, normalizar a stack e ter um engenheiro com nome no seu ticket. Isso funciona numa máquina dedicada e num cluster privado completo. O Sizing Desk diz-lhe qual das pontas desse intervalo realmente precisa, e inclina-se para a resposta mais pequena.
O que inclui o «managed»?+
Migração feita pelos nossos engenheiros, operação diária da plataforma, e otimização de desempenho e segurança, tudo do nosso lado da linha. Nós construímos, nós operamos, nós respondemos quando algo precisa de atenção. Para o editor, isso significou cerca de dez ocasiões em dez anos.
O que acontece na minha noite de pico?+
Transborda para uma margem que já está dentro da caixa, porque é hardware dedicado e não há contador em cima dele. Dimensionamos essa margem para o seu pico real desde o início.
O que acontece se um datacenter inteiro tiver um mau dia?+
A plataforma do editor tem disaster recovery geograficamente distribuído, pelo que um problema num site não é um problema para os leitores.
Dimensione o cluster por trás de uma noite eleitoral sem sobressaltos
Responda a algumas perguntas e o Sizing Desk propõe uma arquitetura real a partir dos nossos blocos de construção reais. Diz-lhe se precisa de menos do que pensa. A maioria precisa.
Dimensione o seu clusterChegou ao fim.
Ponha a leitura em prática
O que executa?
Fale-nos da carga de trabalho, do tráfego e dos requisitos de recuperação. Comece pelo configurador de servidores ou discuta os detalhes com um engenheiro.
Escrito pelos engenheiros que constroem e operam a infraestrutura que descreve.Fale com um engenheiro
