Índice do artigofaltam 5 min de leitura
Minutos depois de o Pokémon GO entrar no ar na Austrália e na Nova Zelândia, o número de jogadores já tinha passado do que a Niantic, a empresa que fez o jogo, esperava. Ela ligou para o Google, em cujas máquinas o jogo rodava, e pediu reforço. Vieram 50 vezes mais jogadores do que a previsão, e o lançamento nos Estados Unidos estava marcado para o dia seguinte.
Quem conta é Luke Stone, o diretor do Google que atendeu a Niantic naquelas semanas, num relato que o Google publicou em 2016. A história interessa a quem vai lançar um produto ou fazer uma campanha grande e precisa saber se o sistema aguenta caso dê certo.
O pior cenário testado ficou muito abaixo do real
A Niantic não foi descuidada. Para um sistema, sucesso demais é o pior cenário: a equipe se preparou para até 5 vezes a previsão de jogadores, que já era a mais otimista. O real ficou dez vezes acima disso.
O jogo era difícil de sustentar por natureza. Todos os jogadores de uma mesma região veem o mesmo mundo e agem sobre ele, e o que um faz precisa aparecer para os outros quase na hora. Por isso não dava para dividir os jogadores em vários sistemas pequenos e independentes. Se o seu sistema mostra o mesmo estoque ou a mesma agenda para todo mundo ao mesmo tempo, ele enfrenta a mesma dificuldade.
O jogo rodava sobre o Kubernetes, o sistema que decide em que máquina cada parte do programa roda e liga mais cópias quando os acessos sobem. Não era aposta isolada: em 2020, o Gartner, consultoria que acompanha o mercado de tecnologia, já previa que até 2022 a maior parte das organizações rodaria sistemas assim. Mesmo assim, o jogo ficou instável no lançamento, e os engenheiros das duas empresas foram atacando um problema de cada vez.
- Os jogadores passam da previsão em minutos
A Niantic liga para o Google e pede reforço.
- O jogo fica instável
As equipes atacam um problema de cada vez.
- Trocam a porta de entrada
A troca parece tranquila.
- Aparecem os acessos que ninguém contava
Banco de dados, servidores e porta passam do limite, um atrás do outro.
- Triplo de cadastros, sem incidente
Entrada limitada, aplicativo corrigido e capacidade ampliada com o jogo no ar.
O que a medição não mostrava
O episódio que mais ensina está no livro em que o Google ensina como mantém os próprios sistemas no ar. Antes, a porta de entrada, que recebe todos os acessos e reparte entre os servidores, tinha duas camadas: um serviço do Google na frente e, atrás dele, a porta de entrada da própria Niantic. A da Niantic recebia tantos acessos que recusava parte, e quem era recusado não aparecia em número nenhum. As equipes contavam só quem tinha passado e achavam que aquele era o total, como o gerente que conta quem entrou na loja enquanto o segurança barra metade da fila na calçada.
Entre o lançamento nos Estados Unidos e o do Japão, trocaram essa porta por outra, mais capaz, também do Google, numa hora de poucos acessos. Quando o pico voltou, a porta nova deixou passar todos os acessos, e eles bateram de uma vez no banco de dados e nos servidores do jogo. Os dois passaram do limite, e depois a própria porta. Em vez de recusar acessos, os servidores ficaram lentíssimos, e o jogador ficava esperando uma resposta que não vinha.
O próprio aplicativo piorou o quadro, porque tentava de novo sozinho a cada erro, sempre depois do mesmo tempo de espera. Quando todos os celulares esperam o mesmo tempo para tentar de novo, voltam juntos e derrubam o sistema outra vez, e as tentativas chegavam em ondas, todas no mesmo segundo.
Para estancar, o Google separou uma porta de entrada só para o jogo, aumentou a capacidade dela e, com o aval da Niantic, passou a deixar entrar só uma parte dos jogadores por vez. Com os acessos contidos, a Niantic recolocou o jogo em operação normal e voltou a ampliar a capacidade.
Os consertos de verdade vieram em seguida. O primeiro mudou o jeito de o aplicativo tentar de novo:
No lançamento
Todos tentam de novo juntos- Espera sempre o mesmo tempo
- Todo celular espera igual
- As tentativas chegam em ondas
Depois do conserto
Cada celular espera a sua vez- A espera cresce a cada falha
- Cada celular espera um tempo diferente
- As tentativas se espalham
O segundo foi sobre a medição, e as duas empresas tiraram dele uma regra que serve para qualquer sistema: conte quantas pessoas tentaram entrar, não só quantas conseguiram, porque o painel que só mostra quem foi atendido esconde quem desistiu. Na preparação para o Japão, a equipe também aumentou o tamanho máximo que o sistema podia ter, com o jogo funcionando.
E no seu lançamento?
A sua empresa não precisa de um fenômeno mundial para passar pelo mesmo aperto. Basta um dia em que os acessos saem do padrão: a campanha que vai para a TV, a Black Friday, o cliente grande que entra com todos os funcionários de uma vez, o prazo legal que empurra todo mundo para o último dia.
Nesses dias, o que a Niantic viveu se repete em tamanho menor. Alguém fez uma previsão, o sistema foi preparado para ela, e ninguém sabe o que acontece se a previsão estiver errada. O teste da Niantic parou no pior cenário que ela imaginou. Um teste de carga pode ir além: aumenta os acessos até o sistema quebrar, mostra em que número ele quebra e o que o cliente vê nessa hora.
Se você nunca pediu um teste desses, o nosso texto sobre teste de carga de sistema explica o que ele é, que tipos existem e o que exigir no contrato de quem vai fazer. Com esse número medido, dá para decidir com calma o que o cliente vê quando o limite chega, antes da data marcada.
As perguntas para levar a quem cuida do seu sistema
Servem para a sua equipe ou para a empresa contratada, e as respostas não exigem conhecimento técnico.
- Qual é o limite medido do sistema, em clientes ao mesmo tempo, e quando ele foi medido?
- O que o cliente vê quando esse limite chega: uma fila, um aviso ou uma tela travada?
- Quando dá erro, o aplicativo tenta de novo sozinho? De quanto em quanto tempo?
- O painel conta quem tentou entrar ou só quem conseguiu?
- Se o sistema cair num sábado à noite, quem fica sabendo e quem age?
Gente a postos no portal da UNICEF
O que pôs o jogo de pé de novo foi limitar a entrada e ter gente pronta para agir na hora. A segunda parte é o trabalho de todo dia da X-Apps, a empresa de software que escreve este blog, no portal da UNICEF, que ela mantém no ar e faz evoluir. A comparação para aí: o portal não passou por um pico como o do jogo.
O portal é vigiado 24 horas, com alerta para incidente crítico, e cada mudança no que foi combinado passa por um pedido formal. A disponibilidade operacional, a parcela do tempo em que o portal está no ar e funcionando, é de 99,7%.
A página do case conta um dia em que isso foi posto à prova. Saiu a correção de duas falhas graves numa tecnologia que o portal usa, e no mesmo dia a X-Apps verificou o portal, confirmou que ele precisava dela e aplicou a correção, com o plano para desfazê-la pronto antes de ela ir ao ar. A UNICEF acompanhou sem parar o próprio trabalho.
Se as respostas àquelas perguntas vierem vagas e a data já estiver marcada, a X-Apps mede o limite do seu sistema e combina com você o que ele faz quando esse limite chegar.
Fontes: relato de Luke Stone, diretor do Google, no blog do Google Cloud (29/09/2016); The Site Reliability Workbook, livro de engenharia de confiabilidade do Google, capítulo 11 (2018). Leitura em 13/11/2026.
