O backend da venda de ingressos

Sua mesa: A tabela que não cabe na janela

Esta noite, das 1h às 3h, o site sai do ar para migrar o banco para o servidor novo. Cada tabela migra em paralelo, numa máquina própria, na velocidade que o teste de sexta mediu. Às 3h o site tem que voltar: às 10h abre a venda da turnê.

Duas horas são 7.200 segundos. O plano está na sua tela.

Ache a tabela que não termina de migrar dentro das duas horas. É essa. pedidos_itens: 180 milhões de linhas a 20 mil por segundo são 9.000 segundos, duas horas e meia. O site voltaria às 3h30 sem os itens dos pedidos, ou não voltaria. A maior tabela do banco, a de logs, cabe. Essa, que ninguém olhou, não. Cada tentativa errada custa 6 minutos.

O que acontece conforme a hora em que você chega

• Antes das 12h: Você achou antes do meio-dia. Deu tempo de começar a copiar a parte antiga de pedidos_itens à tarde, com o site no ar. À noite, só os pedidos da última semana precisaram migrar. O site voltou às 2h40.
• Entre 12h e 16h: Você achou depois do meio-dia. A cópia antecipada começou tarde e terminou só a metade. A janela foi esticada até as 4h, com aviso no site. Voltou às 3h50, com o coração na mão.
• Depois das 16h: O plano ficou para depois das 16h. A migração começou à 1h com o plano do jeito que estava. O que quer que tenha sido ajustado depois, às 3h o painel ainda mostrava pedidos_itens pela metade, e o plantão da madrugada acordou o CTO.

Central de atendimento: Cobrado duas vezes

Desde o deploy de ontem à noite, 2% das compras saem cobradas duas vezes no cartão. A central de atendimento tem 340 chamados abertos e a fila cresce. O deploy trouxe também o pagamento por Pix parcelado, que o marketing anunciou para a venda de amanhã.

Você já sabe onde está o erro. Corrigir direito leva umas quatro horas, com revisão e testes.

• Reverter o deploy agora. Você reverte. Em dez minutos, as cobranças voltam ao normal. O Pix parcelado some do site, e o marketing descobre pelo próprio site. A correção com o Pix de volta vai para amanhã cedo, a duas horas da venda.
• Corrigir em cima, sem reverter. Você corrige com o deploy no ar. Em quatro horas, a correção sobe, revisada e testada. Nesse tempo, mais 1.800 compras saem cobradas duas vezes. O Pix parcelado fica no ar para amanhã. O financeiro passa a semana estornando.

O que acontece conforme a hora em que você chega

• Antes das 10h30: Você foi à central antes das 10h30. Eram 340 chamados. Qualquer que fosse a decisão, a central conseguiu responder a cada cliente no mesmo dia.
• Entre 10h30 e 13h: Você foi à central depois das 10h30. Os chamados tinham passado de mil, e o caso já estava num site de reclamações com print da fatura. Você decidiu com a central inteira olhando.
• Depois das 13h: A central ficou para depois das 13h. A coordenadora da central escalou direto ao CTO. O que quer que tenha sido feito depois, a primeira decisão sobre o incidente foi tomada sem quem conhecia o código.

Ilha do produto: Duzentos mil ou cem mil

A Bruna, PM da venda de amanhã, quer subir o limite da fila virtual: 200 mil pessoas comprando ao mesmo tempo, em vez de 100 mil. "Da última vez a fila demorou uma hora e virou piada nas redes."

No teste de carga de sexta, o sistema começou a falhar com 120 mil. Dá para pôr mais servidores, mas ninguém testou com eles.

• Subir para 200 mil e reforçar os servidores. Você sobe o limite e dobra os servidores. Às 10h04 de amanhã, com 180 mil pessoas dentro, o banco começa a demorar. A fila anda rápido até a página de pagamento, que trava por onze minutos. A venda se recupera. O vídeo da tela travada roda o dia inteiro.
• Manter 100 mil, com a fila mais longa. Você mantém o limite e escreve com a Bruna um aviso honesto na fila: o tempo de espera estimado. Amanhã, a fila passa de uma hora de novo. O sistema não cai. As redes fazem piada com a espera, e ninguém fala de pagamento travado.

O que acontece conforme a hora em que você chega

• Antes das 11h: Você foi à ilha do produto antes das 11h. A Bruna ainda não tinha prometido nada ao marketing. A conversa foi sobre o que o sistema aguenta, não sobre o que já tinha sido anunciado.
• Entre 11h e 15h: Você foi à ilha do produto depois das 11h. O marketing já tinha preparado o post "fila duas vezes mais rápida". Qualquer decisão agora confirmava ou derrubava um post pronto.
• Depois das 15h: A ilha do produto ficou para depois das 15h. A Bruna levou a pergunta ao CTO sem você. O que quer que tenha sido decidido depois, o número já estava no post agendado para as 9h de amanhã.

Sala de reunião: Trocar um número na URL

Um pesquisador de segurança mandou um e-mail educado: trocando o número do pedido na URL da API, dá para ver o nome e o e-mail de quem comprou outro pedido. Você confirma em cinco minutos. A falha existe há oito meses. Nos registros, alguém além dele usou isso três vezes, em julho.

O CTO, Marcelo, está na sala de reunião. A correção é simples. A pergunta é o que fazer com o que já aconteceu.

• Corrigir e avisar os clientes afetados e a autoridade de dados. A correção sobe em uma hora. O jurídico manda o comunicado à autoridade de proteção de dados e um e-mail aos 2.400 clientes cujos dados podem ter sido vistos. Um site de tecnologia publica a história à noite. O CTO agradece ao pesquisador em público.
• Corrigir e investigar antes de avisar alguém. A correção sobe em uma hora. Você abre uma investigação para entender os acessos de julho antes de decidir se avisa. O pesquisador pergunta, dois dias depois, se a empresa vai comunicar. O prazo da lei para avisar começa a contar do dia em que vocês souberam.

O que acontece conforme a hora em que você chega

• Antes das 10h: Você foi à sala de reunião antes das 10h. O pesquisador ainda não tinha mandado o segundo e-mail. A empresa respondeu antes de ser cobrada.
• Entre 10h e 14h: Você foi à sala de reunião depois das 10h. O pesquisador já tinha mandado um segundo e-mail, com prazo de 90 dias para publicar a falha. Você decidiu com esse prazo na tela.
• Depois das 14h: A sala de reunião ficou para depois das 14h. O CTO passou a manhã esperando a confirmação técnica e acionou o jurídico sozinho. O que quer que tenha sido decidido depois, a falha ficou aberta até a tarde, na véspera da maior venda do ano.

Copa: Café, e o backend visto de fora

Duas pessoas do marketing estão na máquina de café.

“…backend é aquela parte que ninguém vê. Se funciona, ninguém lembra que existe.”

É verdade, e é o objetivo. O problema é que, quando ninguém lembra que existe, ninguém lembra de pedir tempo para cuidar dele. Quinze minutos depois, você volta para a mesa com essa frase na cabeça.

O que se ouve de passagem

Atravessar a empresa não é só deslocamento. No corredor as pessoas continuam falando, e o que elas dizem depende da hora e do que você ainda não resolveu. Nada disso custa tempo nem muda o dia.

• …o pessoal de infra tá dizendo que a migração de hoje é a maior que a empresa já fez.
• …a central tá lotada de gente cobrada duas vezes desde ontem.
• …o marketing quer anunciar fila duas vezes mais rápida amanhã.
• …o Marcelo tá trancado na sala de reunião desde cedo. Parece que chegou um e-mail sério.

O que vem depois das escolhas

• Se você escolheu “Reverter o deploy agora” e “Corrigir e avisar os clientes afetados e a autoridade de dados”: Você reverteu o deploy e avisou os clientes da falha de segurança. Na véspera da venda, o site perdeu o Pix parcelado e ganhou uma notícia. As duas coisas estavam certas. O marketing passou a noite reescrevendo o anúncio.
• Se você escolheu “Corrigir em cima, sem reverter” e “Subir para 200 mil e reforçar os servidores”: Você corrigiu a cobrança sem reverter e subiu a fila para 200 mil. A venda abriu com código novo, servidor novo e limite nunca testado. Às 10h04, ninguém sabia qual dos três estava fazendo a página de pagamento travar.
• Se você escolheu “Corrigir e investigar antes de avisar alguém” e “Manter 100 mil, com a fila mais longa”: Você segurou a fila em 100 mil e segurou o aviso da falha até investigar. Duas vezes no mesmo dia, escolheu o lado que não faz barulho. A venda de amanhã vai ser tranquila. A investigação ainda está aberta.
• Se você escolheu “Reverter o deploy agora” e “Manter 100 mil, com a fila mais longa”: Você tirou o Pix parcelado do ar e segurou a fila em 100 mil. A Bruna perdeu duas coisas que tinha prometido para amanhã. Ela entendeu as duas. Disse que gostaria de ter sabido antes do marketing.

Como o dia termina

As quatro portas do Backend

Backend não é uma profissão só, são várias, e elas se separam pelo tipo de problema, não pela linguagem.

• Banco de dados e infraestrutura. Fazer o dado mudar de lugar sem ninguém perceber que ele saiu.
• Confiabilidade e incidentes. Decidir rápido quando o sistema está errando com gente de verdade.
• Performance e escala. Saber quanto o sistema aguenta antes de todo mundo chegar ao mesmo tempo.
• Segurança de aplicações. Achar a porta aberta antes dos outros, e decidir o que fazer quando alguém achou primeiro.