Uma mudança durante a noite trancou todos os clientes para fora. O telefone de ninguém tocou.

Ler o original em inglês

monitoringincident-responsefalse-positivealerting

Imagem de capa: Uma mudança durante a noite trancou todos os clientes para fora. O telefone de ninguém tocou.

Numa noite de outubro, uma única mudança tirou do ar o endereço próprio de todos os nossos clientes. Começou por volta das 21:00 e durou até umas 8:00 da manhã seguinte. São onze horas.

Tínhamos um monitor. Ele fazia uma verificação a cada cinco minutos. E nunca disparou.

O que aconteceu

Cada cliente nosso tem seu próprio endereço na web, como www.yourbusiness.example. Por trás dos panos, todos esses endereços entram por uma única porta. Uma porta, todos os clientes.

Um agente de programação com IA fez a mudança. Tínhamos pedido que ele adicionasse uma nova ferramenta interna no mesmo servidor. Enquanto refazia uma configuração pequena da própria ferramenta nova, ele executou uma instrução que deveria remover uma coisinha só. Ela estava solta demais e removeu a porta compartilhada.

Vamos ser francos sobre as provas. Sabemos que a porta sumiu naquele mesmo minuto, porque o servidor guarda um histórico. Não sabemos com certeza qual foi a instrução exata. Decidimos não recriá-la no sistema em produção para descobrir.

Os clientes que digitavam o endereço viam uma página de erro em branco. Os sites continuavam existindo. Só que ninguém conseguia entrar.

O monitor vigiava o portão da frente

Aqui está a parte que dói. Tínhamos configurado de propósito quatro endereços de teste, no lugar de clientes de verdade. E havia uma verificação neles.

Só que cada endereço tem duas etapas. A primeira é um pequeno portão da frente que só diz “vá para o site de verdade”. A segunda é a porta onde o site de verdade fica. Nossa verificação só batia no portão da frente. O portão ficou bem a noite toda, então a verificação marcou verde a noite toda. A porta por onde os clientes realmente passam era a que estava trancada, e nunca tentamos abri-la.

A verificação ainda tinha um nome que a fazia parecer completa. É fácil cair nisso e difícil perceber.

Verde queria dizer “terminou”, não “passou”

Depois piorou. Ao olhar mais a fundo, descobrimos que a página que nosso serviço externo de alertas acompanha tinha uma segunda falha. Ela dizia “tudo certo” sempre que a última verificação tinha terminado. Não quando tinha passado. Uma verificação que terminou com falha também contava.

Ou seja, mesmo uma verificação perfeita teria dito que algo estava errado, e a página teria informado ao serviço de alertas que estava tudo bem. Duas coisas precisaram falhar para que ninguém fosse acordado, e as duas falharam.

O telefone de ninguém tocou

Nosso serviço externo de alertas não ligou para ninguém, porque lhe disseram que estava tudo bem. Ninguém foi acordado.

A caixa de entrada era um alarme que ninguém estava ouvindo

Esta é a parte em que mais pensamos. Enquanto nosso monitor dizia que estava tudo bem, nossos clientes sabiam que não estava. Dezenas de e-mails de usuários preocupados chegaram durante a noite e ficaram parados na caixa de entrada. A primeira pessoa a nos procurar foi um membro da equipe, de manhã. Só então vimos os e-mails.

Seus clientes percebem horas antes das suas ferramentas, e os e-mails deles ficam numa caixa de entrada. Um aumento repentino de e-mails, tickets ou conversas de suporte é um aviso por si só. Ele deveria gerar um alerta, mesmo fora do horário comercial, para alguém que vá agir. É a rede de segurança para o dia em que seu monitor estiver olhando para a coisa errada. Ainda não construímos isso.

Uma mudança, todos os clientes

O formato do problema é claro. Uma porta atendia todo mundo, então um deslize derrubou todo mundo. Não vamos mudar esse desenho esta semana, porque ele também é o que mantém tudo simples. O que fizemos foi fazer essa porta “gritar”. Agora ela está marcada como “não mexer” na única página que lista tudo o que existe no servidor, e qualquer mudança no servidor passa por uma rotina de verificação. Essa rotina salva uma cópia antes, tira uma lista de tudo antes e depois, testa uma amostra de endereços de clientes e desfaz tudo sozinha se algo fora do alvo tiver mudado.

Essa cópia salva também é o motivo de a correção ter levado só alguns minutos. A porta foi recolocada exatamente como era, minutos depois do aviso, sem reiniciar nada.

O que corrigimos e o que ainda não está pronto

Agora verificamos a porta por onde os clientes passam, não só o portão da frente. A página de status agora diz “tudo certo” apenas quando a última verificação passou, e reclama se as verificações pararem de rodar.

Depois testamos de verdade. Avisamos a equipe, fizemos uma verificação falhar de propósito e acompanhamos a cadeia inteira. O serviço de alertas nos marcou como fora do ar, os e-mails saíram e um telefone tocou.

Já no ar: uma proteção nas nossas próprias ferramentas que recusa esse tipo de mudança vinda dos nossos agentes, a menos que ela passe pela rotina de verificação. Ainda não construído: o alerta para um aumento repentino de e-mails de suporte.

Aqui estão as seis redes de segurança lado a lado, com o que deu errado em cada uma e o que mudamos.

Tabela com seis redes de segurança: impedir o erro, perceber, o sinal de tudo certo, acordar alguém, responder e desfazer. Para cada uma, o que deu errado e o que mudamos. Uma instrução solta de um agente de IA removeu a única porta compartilhada, e agora as mudanças passam por uma rotina de verificação. A verificação batia no portão da frente e dezenas de e-mails de clientes ficaram sem leitura durante a noite, e agora a verificação testa a porta que os clientes usam, enquanto o alerta para um aumento de e-mails de suporte ainda não existe. Tudo certo queria dizer que a verificação tinha terminado, e agora quer dizer que passou e é recente. O telefone de ninguém tocou, e um teste proposital agora provou que um telefone toca. Um membro da equipe nos procurou de manhã, e agora uma página lista tudo. Uma cópia salva tornou a correção rápida, e a rotina agora desfaz as coisas automaticamente.

Seis perguntas para fazer a quem cuida do seu site

Você não precisa saber como nada disso funciona. Você pode perguntar.

  1. Vocês verificam o endereço que os clientes realmente digitam? Não só o site principal. Todos os caminhos pelos quais um cliente pode chegar até você.
  2. Alguém acompanha um aumento repentino de e-mails ou tickets de clientes, e quem recebe o alerta? Pergunte se ele chegaria a uma pessoa às 2:00 da manhã, porque muitas vezes os clientes percebem antes das ferramentas.
  3. “Verde” quer dizer que passou, ou só que rodou? Pergunte o que faria ficar vermelho.
  4. Quem é acordado, e vocês já testaram? Pergunte quando foi a última vez que alguém fez a verificação falhar de propósito e o telefone de uma pessoa de verdade tocou.
  5. Existe uma coisa que, se mudar, quebra todos os clientes de uma vez? Pergunte qual é e quem pode mexer nela.
  6. Em quanto tempo vocês desfazem uma mudança, e uma cópia é salva antes? Peça o tempo em minutos.

Se a resposta para qualquer uma delas for “não tenho certeza”, você encontrou o que corrigir primeiro.

Se você usa um assistente de IA

Abaixo, há uma versão curta dessas perguntas que você pode colar no assistente de IA que já usa. Ela só revisa como você está protegido. Não testa nada.

Uma porta compartilhada, uma verificação que só batia no portão da frente e dezenas de e-mails de clientes que ninguém estava vendo. Faça ao seu provedor as seis perguntas acima antes que uma noite tranquila as faça por você.

Relacionado

Receba a próxima história de IA no dia a dia

Histórias em linguagem simples sobre usar IA para facilitar o trabalho do dia a dia. Um e-mail curto quando sair uma nova, sem jargão.