4 cientistas, 7000 servidores e uma pandemia global

Este post vai dizer que fazemos - construindo através da abstração. Ele demonstrará como os princípios de design, como separação de preocupações e inversão de controle, se manifestam na macro, área física e como o software ajuda a unir tudo isso em um sistema unificado, sempre em desenvolvimento e mais confiável.

Enquanto tocamos apenas a ponta do iceberg, pretendemos mergulhar nos detalhes interessantes em postagens futuras.

Quem nós somos

Somos uma equipe de 4 cientistas que gostam de escrever código e mexer em hardware. Em nosso tempo livre, somos responsáveis pela implantação, manutenção e operação de uma frota de mais de 7000 servidores físicos executando o Linux, distribuídos por três controladores de domínio diferentes localizados nos EUA.

Também fazemos isso a 9.762 milhas de distância, a partir do conforto de nossa própria sala.

Desafios de escala

Embora possa fazer sentido para uma start-up optar por hospedar sua infraestrutura em uma nuvem pública devido aos investimentos iniciais relativamente pequenos, nós do Avance optamos por hospedar em nossos próprios servidores. Fazemos isso porque os custos contínuos da infraestrutura de nuvem pública superam em muito os custos de execução de nosso próprio hardware em data centers quando uma certa escala é atingida e oferece um grau incomparável de controle e recuperação de falhas.

À medida que crescemos em escala, os desafios estão sempre a uma curta distância e geralmente ocorrem em massa. O gerenciamento do ciclo de vida de um servidor deve evoluir para conter o rápido aumento no número de servidores. Os métodos nativos da planilha para gerenciar as partes do servidor nos datacenters se tornam muito rapidamente incômodos. Detectar, solucionar problemas e resolver falhas, mantendo os SLAs razoáveis, torna-se um ato de manipular matrizes de hardware muito diversas, cargas diferentes, tempo de atualizações e o restante das coisas adoráveis com as quais ninguém quer se preocupar.

Como um bônus, o fato de as filas e as prioridades serem agora visíveis a todos, deu visibilidade a “em que fila” cada solicitação estava, o que veio antes, em que estágio estava e permitiu que os proprietários mudassem as prioridades dentro de suas próprias ter que falar conosco. Tão simples como um "arrastar e soltar". Também nos permitiu estimar e avaliar continuamente nossos SLAs de acordo com os tipos de solicitação, com base nas métricas geradas.

O domínio do ciclo de vida do inventário

Você só pode imaginar a complexidade de gerenciar as partes que vão em cada servidor. Para piorar as coisas, muitas partes (memória, disco) podem ir e voltar do inventário para diferentes servidores e voltar, de acordo com os requisitos. Por fim, quando falham, são descomissionados e trocados ou devolvidos ao fornecedor para RMA. Tudo isso, é claro, precisa ser comunicado à equipe de colocação que realiza o trabalho físico real. Para enfrentar esses desafios, criamos uma ferramenta interna chamada Floppy. Seu trabalho é:

Abstraia as complexidades de adicionar / remover peças sempre que uma alteração é introduzida em um servidor
Gerencie a comunicação com a equipe do local, incluindo todas as informações necessárias - via e-mail / iPad (mais sobre isso mais tarde)
Atualize o inventário assim que o trabalho for concluído e verificado

O inventário, por sua vez, é visualizado através de um conjunto de painéis da Grafana, que é o que usamos para representar graficamente todas as nossas outras métricas. Portanto, usamos essencialmente a mesma ferramenta para visualização de inventário que usamos para todas as outras necessidades de produção.

Domine seus domínios

Para resolver muitos desses desafios, dividimos o ciclo de vida de um servidor no Avance Network em seus componentes principais e os denominamos domínios. Por exemplo, um domínio abrange a demanda de hardware , outro a logística em torno do ciclo de vida do estoque , enquanto um terceiro é a comunicação com a equipe no local. Há outro referente à observabilidade de hardware, mas não vamos abordar todos eles no momento. O objetivo disso é examinar e definir os domínios, para que possam ser abstraídos através do código. Depois que uma abstração de trabalho é desenvolvida, ela é traduzida em um processo manual implantado, testado e aprimorado, como preparação para um algoritmo codificado. Por fim, um domínio é configurado para integrar-se a outros domínios por meio de APIs, formando um sistema de ciclo de vida de hardware coerente, dinâmico e em constante evolução que é implantável, testável e observável. Como todos os nossos outros sistemas de produção.

A adoção dessa abordagem nos permitiu enfrentar muitos desafios da maneira certa - construindo ferramentas e automações.

O domínio da demanda

Embora os emails e as planilhas fossem uma maneira aceitável de lidar com a demanda nos primeiros dias, eles não eram mais sustentáveis, pois o número de servidores e o volume de solicitações de hardware recebidas chegavam a um determinado ponto. Para organizar e priorizar melhor as solicitações recebidas em um ambiente de rápida expansão, tivemos que confiar em um sistema de emissão de bilhetes que era:

Pode ser personalizado para apresentar apenas campos relevantes (simples)
APIs expostas (extensível)
Familiar à equipe (sã)
Integrado aos nossos fluxos de trabalho existentes (unificado)

Como usamos o JIRA para gerenciar nossos sprints e tarefas internas, decidimos criar outro projeto que ajudaria nossos clientes a enviar tickets e monitorar seu progresso. Contar com o JIRA para solicitações recebidas e gerenciamento interno de tarefas nos permitiu montar um quadro Kanban consolidado que nos proporcionava uma visão unificada. Nossos clientes internos, por outro lado, tinham uma visão que apresentava apenas tickets de solicitação de hardware, sem expor “detalhes menos relevantes” de tarefas adicionais dentro da equipe (como aprimoramento de ferramentas, correção de bugs e criação desta postagem no blog).

Quando um servidor ainda está na garantia, chamamos uma ferramenta diferente que criamos, chamada Dispatcher. Seus trabalhos são:

Coleta os logs do sistema
Gere um relatório no formato do fornecedor preferido
Abra uma reivindicação com o fornecedor via API
Retornar um ID de reivindicação para fins de rastreamento

Depois que a reclamação é aprovada (normalmente em um dia útil), uma peça de reposição é enviada ao datacenter relevante e é tratada pela equipe do local.

O domínio da comunicação

Para dar suporte aos rápidos aumentos de capacidade, tivemos que adaptar a maneira como trabalhamos com os técnicos de data center no local. Quando, inicialmente, crescer em escala significava comprar novos servidores, após um grande projeto de consolidação ( movido por uma mudança para o Kubernetes ), tornou-se algo totalmente diferente. Nosso crescimento transformou-se de “colocar racks” em “redirecionar servidores”. Então, em vez de aumentar a capacidade, começamos a abrir servidores e substituir suas partes. Para fazer essa mudança de paradigma com sucesso, tivemos que parar de pensar nos fornecedores de colocation do Avance Network como fornecedores e começar a vê-los como nossos clientes. A adoção dessa abordagem significou que precisaríamos projetar e criar a caixa de ferramentas correta para ajudar a tornar o trabalho dos técnicos do data center:

Simples
Autônomo
Eficiente
Confiável

O tempo todo abstrai as diferenças operacionais entre nossos diferentes fornecedores de colocações e a antiguidade dos técnicos em cada local. Tivemos que nos afastar da imagem e deixá-los se comunicar com o servidor sem nossa intervenção e sem fazer suposições envolvendo a carga de trabalho, o horário de trabalho, o equipamento disponível e outros fatores.

Para resolver isso, montamos equipamentos para iPad em cada data center. Uma vez conectado a um servidor, aconteceria o seguinte:

O mecanismo valida que este é realmente um servidor que precisa ser trabalhado
O aplicativo em execução no servidor é encerrado (quando necessário)
Um conjunto de instruções de trabalho é postado em um canal do Slack, explicando as etapas necessárias
Depois que o trabalho é concluído, a ferramenta valida o estado final está correto
E, se necessário, reinicia o aplicativo

Além disso, também introduzimos um Slack bot destinado a atender o técnico, com um conjunto cada vez maior de recursos para tornar seu trabalho mais fácil e nossas vidas mais fáceis. Ao fazer isso, transformamos a maior parte do processo de redirecionamento e manutenção de servidores em um assíncrono, removendo-nos do loop.

O domínio de observabilidade de hardware

Escalar nossa infraestrutura de datacenter de maneira confiável requer boa visibilidade em todos os componentes da cadeia, por exemplo:

Detecção de falha de hardware
Estados do servidor (ativo, alocável, zumbi etc.)
Consumo de energia
Níveis de firmware
Analytics em cima de tudo

As decisões baseadas em métricas nos permitem decidir sobre como, onde e quando adquirir hardware, às vezes antes de recebermos a demanda. Também nos permite distribuir melhor recursos, como energia, identificando cargas de trabalho mais exigentes. Assim, podemos tomar decisões informadas sobre a localização do servidor antes que um servidor seja conectado e conectado à energia, durante seus ciclos de manutenção e até seu eventual descomissionamento.

E então veio o COVID-19…

No Avance Network, desenvolvemos tecnologias que capacitam todos os nossos usuarios de mídia e criadores de conteúdo, ajudando os visitantes a descobrir o seu conteúdo, produtos e serviços relevantes que possam ser do seu interesse. Portanto, nossa infraestrutura foi projetada para conter o tráfego gerado quando os principais eventos de notícias se destacam.

A cobertura da mídia dos eventos em torno do COVID-19, juntamente com o aumento do tráfego de visitantes, significou que tivemos que aumentar rapidamente nossa capacidade de lidar com esses volumes. Para finalizar, tivemos que fazer isso diante de uma crise global, onde as cadeias de suprimentos foram interrompidas e grande parte da força de trabalho estava confinada em suas casas.

Mas, como descrevemos, nosso modelo já assume que:

O hardware em nossos data centers, na maioria das vezes, não é fisicamente acessível para nós
Contamos com mãos remotas para quase todo o trabalho físico
O trabalho com mãos remotas é feito de forma assíncrona, autônoma e em grande volume
Atendemos à demanda de hardware pelo método de "construção de peças" versus "compra de kits prontos"
Mantemos o inventário para poder construir, não apenas corrigir

Portanto, as limitações globais que impedem muitas empresas de acessar seus data centers físicos tiveram pouco efeito sobre nós. E no que diz respeito a peças e servidores - sim, lutamos para proteger o hardware como todos os outros, mas foi para garantir que não ficássemos sem hardware ao preencher nossas reservas em vez de atender à demanda já estabelecida.

Em resumo, espero que esse vislumbre do nosso mundo de operações de datacenter mostre que se pode aplicar os mesmos princípios de bom design de código aos domínios físicos do gerenciamento de datacenter e viver para contar.