Aqui está uma história que mudou para sempre minha abordagem ao trabalho de DevOps. Já nos tempos antes da COVID, muito antes dela, quando eu e os caras estávamos apenas pensando em nosso negócio e freelancer em pedidos aleatórios, uma proposta chegou para mim no Telegram.
A empresa que a escreveu lidava com análise de dados. Diariamente, ela processava milhares de solicitações. Eles chegaram até nós dizendo: pessoal, temos ClickHouse e queremos automatizar sua configuração e instalação. Queremos Ansible, Terraform, Docker e que tudo isso seja armazenado no Git. Queremos um cluster de quatro nós com duas réplicas em cada um.
Um pedido padrão, como dezenas de outros, e precisamos de uma solução tão boa quanto as normais. Dissemos 'ok', e em 2-3 semanas estava tudo pronto. Eles aceitaram o trabalho e começaram a migrar para o novo cluster do ClickHouse com a ajuda da nossa ferramenta.
Ninguém ali queria ou sabia lidar com ClickHouse. Naquela época, achávamos que esse era o principal problema deles, e por isso o CTO da empresa simplesmente deu sinal à minha equipe para automatizar ao máximo o trabalho, para que nunca mais tivessem que mexer lá.
Apoíamos a migração, surgiram outras tarefas — configurar backups e monitoramento. Nesse mesmo momento, o CTO da empresa foi para outro projeto, deixando um de seus caras — Leonid — como nosso comandante. Lёnia não era um cara muito talentoso. Um simples desenvolvedor que de repente foi promovido a chefe do ClickHouse. Parece que essa foi sua primeira designação para liderar algo, e com a honra que caiu sobre ele, desenvolveu um certo estrelismo.
Juntos, começamos a trabalhar nos backups. Eu sugeri fazer backup dos dados brutos imediatamente. Apenas pegar, compactar e elegantemente enviar para algum S3. Dados brutos são ouro. Havia também outra opção — fazer backup das tabelas no ClickHouse, através de congelamento e cópia. Mas Lёnia teve uma solução alternativa.
Ele anunciou que precisávamos de um segundo cluster do ClickHouse. E a partir de agora, iríamos escrever dados em dois clusters — principal e de backup. Eu disse a ele que, Lёnia, isso não será um backup, mas sim uma réplica ativa. E se os dados começarem a se perder em produção, o seu backup terá o mesmo problema.
Mas Lёnia agarrou firme o leme e se recusou a ouvir meus argumentos. Tivemos uma longa discussão no chat, mas não havia o que fazer — Lёnia estava no controle do projeto, éramos apenas os caras contratados da rua.
Estávamos monitorando o estado do cluster e cobramos apenas pelo trabalho dos administradores. Administração pura do ClickHouse sem interferir nos dados. O cluster estava acessível, os discos normais e os nós em ordem.
Ainda não suspeitávamos que tinhamos recebido esse pedido devido a um terrível mal-entendido dentro da equipe deles.
O gerente estava insatisfeito porque o ClickHouse estava lento e, às vezes, os dados estavam perdendo-se. Ele encarregou seu CTO de investigar. Ele fez o que pôde e concluiu que precisava apenas automatizar o ClickHouse — e pronto. Mas, como logo se descobriu, eles precisavam de uma equipe totalmente diferente de DevOps.
Tudo isso se revelou de forma muito, muito dolorosa. E o mais frustrante é que foi no meu aniversário.
Sexta-feira à noite. Reservei uma mesa no meu bar de vinhos favorito e chamei os amigos.
Quase na hora de sair, recebemos a tarefa de fazer um alter, executamos, tudo certo. O alter passou, o ClickHouse confirmou. Já estávamos prontos para ir ao bar, e nos disseram que faltavam dados. Contamos — parecia estar tudo certo. E fomos celebrar.
O restaurante estava barulhento, típico de sexta-feira. Pedimos bebidas, comida, e nos acomodamos nos sofás. Durante todo esse tempo, meu Slack estava sendo inundado por mensagens. Estavam falando sobre falta de dados. Pensei — a manhã traz sabedoria. Especialmente a de hoje.
Perto das onze, começaram a ligar. Era o gerente da empresa... 'Provavelmente, ele decidiu me parabenizar', pensei com insegurança e atendi o telefone.
E ouvi algo como: 'Vocês perderam nossos dados! Eu estou pagando a vocês, mas nada funciona! Vocês eram responsáveis pelos backups e não fizeram nada! Vamos resolver isso!' — e ainda mais rude.
— Sabe de uma coisa, vai se danar! Hoje é meu aniversário e agora vou me divertir, não ficar lidando com suas gambiarras de novatos!
Foi assim que eu não disse. Em vez disso, peguei o laptop e comecei a trabalhar.
Não, eu estava furioso, estava intensamente furioso! Enviando mensagens sarcásticas no chat dizendo 'eu avisei' — porque o backup, que não era realmente um backup, não salvou nada, claro.
Nós, os caras, decidimos como interromper a gravação manualmente e verificar tudo. Realmente nos certificamos de que parte dos dados não estava sendo escrita.
Paramos a gravação, contabilizamos o número de eventos acumulados ao longo do dia. Adicionamos mais dados, dos quais apenas um terço não foi registrado. Três shards com duas réplicas. Você insere 100.000 linhas — 33.000 não são gravadas.
Aconteceu uma verdadeira confusão. Todos estavam se atacando mutuamente: primeiro foi o Leônidas, seguido por mim e pelo fundador da empresa. Apenas o CTO recém-chegado tentava manter nossas chamadas e conversas focadas na busca por uma solução para o problema.
Ninguém entendia o que estava acontecendo de fato.
Ficamos espantados quando percebemos que um terço de todos os dados não apenas não estava sendo gravado — estava se perdendo! Descobrimos que a ordem na empresa era a seguinte: após a inserção, os dados eram deletados permanentemente, e os eventos se perdiam em pacotes. Eu imaginei como o Sergey converteria tudo isso em reais não recebidos.
Meu aniversário também foi jogado no lixo. Estávamos em um bar gerando ideias, tentando desvendar o enigma apresentado. A razão da queda do ClickHouse não era óbvia. Talvez fosse a rede, talvez as configurações do Linux. Qualquer coisa, uma variedade de hipóteses foi levantada.
Não fiz um juramento de desenvolvedor, mas abandonar os caras do outro lado da linha era desonroso — mesmo que eles nos culpassem por tudo. Eu estava 99% certo de que o problema não estava nas nossas soluções, não do nosso lado. Essa chance de 1% de que nós nos tínhamos atrapalhado queimava em minha mente. Mas não importava de que lado a desgraça estivesse — era necessário consertar. Deixar os clientes, sejam eles quem forem, com um vazamento de dados tão grave — isso era cruel demais.
Trabalhamos até às três da manhã na mesa de um restaurante. Adicionamos eventos, insert select — e seguimos preenchendo as lacunas. Quando você perde dados, faz o seguinte: pega a média dos dados dos dias anteriores e insere no que se perdeu.
Depois das três da manhã, eu e meu amigo fomos para a minha casa, pedimos uma cerveja de um mercado. Eu estava sentado com o laptop e os problemas do ClickHouse, enquanto meu amigo me contava algo. No final, após uma hora, ele ficou chateado por eu estar trabalhando em vez de tomar cerveja com ele, e foi embora. Clássico — passei um tempo como amigo do DevOps.
Às 6 da manhã, recriei a tabela do zero, e os dados começaram a ser carregados. Tudo funcionou sem perdas.
Depois disso, ficou difícil. Todos começaram a se culpar pela perda de dados. Se surgisse um novo bug, aposto que começaria uma retaliação.
Nessas brigas, finalmente começamos a entender — na empresa pensavam que éramos as pessoas que trabalham com dados e cuidam da estrutura das tabelas. Eles confundiram os administradores com os DBAs. E vieram perguntar a nós de maneira que não era adequada para administradores.
A principal reclamação deles era: que diabos, vocês eram responsáveis pelos backups e não os fizeram corretamente, perderam os dados. E tudo isso com xingamentos e palavrões.
Eu queria justiça. Eu desenterrei a troca de mensagens e anexei todos os screenshots, onde Leonid insistia com toda a força para fazer um backup como o que foi feito. O CTO deles ficou do nosso lado após minha ligação. Depois, Leonid também reconheceu sua culpa.
O chefe da empresa, por sua vez, não queria culpar os seus. Screenshots e palavras não o afetavam. Ele acreditava que, já que éramos os especialistas, deveríamos ter convencido a todos e insistido na nossa decisão. Evidentemente, nossa tarefa era ensinar Leonid e, além disso, contornar ele, que foi designado como líder do projeto, para chegar ao principal e despejar todas as nossas dúvidas sobre o conceito dos backups.
O chat transbordava ódio, agressão oculta e não oculta. Eu não sabia o que fazer. Tudo havia chegado a um impasse. E então me sugeriram o jeito mais simples — escrever em particular para o líder e combinar uma reunião com ele. Vasya, as pessoas na vida não são tão audaciosas quanto no chat. Na minha mensagem, o chefe respondeu: venha, sem problemas.
Foi a reunião mais estranha da minha carreira. Meu aliado do cliente — o CTO — não conseguiu encontrar tempo. Eu estava indo para a reunião com o chefe e Leonid.
Repetidamente, eu revisitava em minha mente nosso possível diálogo. Consegui chegar muito antes, meia hora antes. Comecei a ficar nervoso, fumei 10 cigarros. Eu sabia que tudo — eu estava completamente sozinho. Eu não conseguiria convencê-los. E entrei no elevador.
Enquanto subia, acendi o isqueiro tanto que acabei quebrando-o.
No final, Leonid não estava na reunião. E tivemos uma ótima conversa com o chefe! Sergey me contou sobre sua dor. Ele não queria "automatizar o Clickhouse" — ele queria que "as consultas funcionassem".
Eu não vi um vilão, mas um bom cara, preocupado com seu negócio, imerso no trabalho 24/7. O chat frequentemente nos retrata vilões, canalhas e idiotas. Mas na vida, são pessoas como você.
Sergey não precisava de apenas alguns devops contratados. O problema que eles enfrentavam era muito maior.
Eu disse que podia resolver os problemas dele — só que isso é um trabalho completamente diferente, e eu tenho um DBA conhecido para isso. Se soubéssemos desde o início que este projeto era para eles, teríamos evitado muita coisa. Foi tarde, mas entendemos que o problema estava em um trabalho ruim com os dados, e não na infraestrutura.
Nós apertamos as mãos, o pagamento foi aumentado em duas vezes e meia, mas com a condição — eu assumi toda a dor de cabeça com os dados e o ClickHouse. No elevador, entrei em contato com aquele DBA, Max, e o convidei para trabalhar. Foi necessário mexer em todo o cluster.
Havia uma quantidade enorme de lixo no projeto aceito. Começando com o mencionado 'backup'. Aconteceu que esse 'cluster de backup' não era isolado. Estavam testando tudo nele, às vezes até colocavam em produção.
Os desenvolvedores internos criaram seu próprio 'inseridor' de dados. Ele funcionava assim: agrupava arquivos, executava um script e despejava dados em uma tabela. Mas o principal problema era que uma quantidade enorme de dados era necessária para uma única consulta simples. A consulta unia dados a cada segundo. Tudo por causa de um único número — a soma do dia.
Os desenvolvedores internos usaram incorretamente a ferramenta de análise. Eles acessavam o Grafana, escreviam sua consulta real. Isso extraía dados de 2 semanas. O gráfico ficava bonito. Mas na prática, a consulta de dados era feita a cada 10 segundos. Tudo isso se acumulava na fila, pois o ClickHouse simplesmente não conseguia processá-lo. Aqui residia a verdadeira razão. No Grafana, nada funcionava, as consultas estavam na fila, sempre chegavam dados antigos e não relevantes.
Reconfiguramos o cluster, refezemos a inserção. Os desenvolvedores internos reescreveram seu 'inseridor', e ele começou a shardear os dados corretamente.
Max fez uma auditoria completa da infraestrutura. Ele delineou um plano de transição para um backend completo. Mas isso não satisfez a empresa. Eles esperavam do Max um segredo mágico que permitisse operar da maneira antiga, mas de forma eficiente. O projeto ainda estava sob responsabilidade do Lёnya, que não aprendeu nada. De tudo o que foi proposto, ele escolheu sua alternativa novamente. Como sempre, foi a decisão mais seletiva... ousada. Lёnya acreditava que sua empresa teve um caminho especial. Difícil e cheio de icebergs.
Na verdade, foi assim que nos separamos — fizemos o que pudemos.
Com várias experiências e aprendizados, começamos nosso negócio e estabelecemos alguns princípios para nós mesmos. Agora, nunca começamos um trabalho da mesma maneira que naquela época.
O desenvolvedor Max se juntou a nós após este projeto, e até hoje trabalhamos muito bem juntos. O caso com ClickHouse nos ensinou a realizar uma auditoria completa e minuciosa da infraestrutura antes de começar a trabalhar. Nós investigamos como tudo funciona e só então aceitamos as tarefas. E se antes nós íamos direto para cuidar da infraestrutura, agora primeiro fazemos um projeto único que ajuda a entender como colocá-la em funcionamento.
E sim, evitamos projetos com infraestrutura ruim. Mesmo que seja por muito dinheiro, mesmo que seja por amizade. Trabalhar em projetos problemáticos não é benéfico. Essa compreensão nos ajudou a crescer. Ou fazemos um projeto único para organizar a infraestrutura e então firmamos um contrato de manutenção, ou simplesmente deixamos passar. Passamos por mais um iceberg.
P.S. Portanto, se você tem perguntas sobre sua infraestrutura, .
Temos 2 auditorias gratuitas por mês, talvez o seu projeto esteja entre elas.
Fonte: habr.com
