Encontrei um bug analítico em nosso próprio produto analítico.
O pipeline do evento funcionou. Sites reais enviaram eventos reais. Um booleano interno ainda dizia que o script de rastreamento não estava instalado.
Essa contradição foi importante porque a bandeira foi o primeiro marco na nossa pontuação de ativação. Se permanecesse falso, um local de trabalho poderia permanecer no segmento frio mesmo após a chegada dos dados.
Em 21 de julho, a produção contava com 36 locais. Vinte e um receberam um primeiro evento. Apenas dois tinham script_installed definido como verdadeiro.
Dezenove instalações em funcionamento foram descritas como inativas.
O problema não era uma fila atrasada ou uma falha no rastreador. Havíamos criado uma transição de estado que nenhum caminho de produção jamais realizou.
O valor estava correto na criação
Quando um cliente criava um site, script_installed começava como falso. Isso era razoável. Naquele momento, Zenovay não havia recebido provas de que o script estava sendo executado.
A parte que faltava veio depois.
Nosso sistema registrou o carimbo de data/hora do primeiro evento quando os dados chegaram, mas nada alterou o sinalizador de instalação. O sinalizador tinha um gravador para o valor falso inicial e nenhum gravador para o valor verdadeiro posterior.
Os testes tornaram o erro fácil de ignorar. Eles forneceram fixtures onde script_installed já era verdadeiro e depois verificaram se a pontuação de ativação tratava o valor corretamente.
A função de pontuação foi testada. A transição que criou sua entrada não foi.
Dois campos descreveram um fato
Já tínhamos um sinal mais forte: first_event_at.
Esse carimbo de data/hora só existe depois que o caminho de ingestão aceita um evento analítico real para o site. É uma evidência de algo que aconteceu. O booleano era apenas uma descrição dessa evidência.
Uma vez que ambos os campos existissem, eles poderiam discordar:
select count(*)
from websites
where first_event_at is not null
and script_installed is distinct from true;
A consulta retornou 19.
Este é o risco de estado duplicado. Cada campo pode parecer válido isoladamente. A contradição só aparece quando a relação entre eles é verificada.
Por que o dano permaneceu interno
A verificação de instalação voltada para o cliente utilizou uma condição mais segura. Ele só avisava quando o sinalizador era falso e não existia nenhum primeiro evento. Os clientes com dados reais não foram informados incorretamente para reinstalar o rastreador.
O cron de ativação também foi somente leitura. Ele gravou telemetria e não enviou e-mails de ciclo de vida.
Isso limitava o raio da explosão, mas não tornava o inseto inofensivo. O relatório de ativação interna classificava as equipes de trabalho incorretamente. Qualquer decisão baseada nesse segmento partiria de evidências falsas.
O reparo
Anexamos a transição que faltava ao evento que comprova a instalação.
Quando o primeiro evento de visitante chega, o mesmo gatilho de banco de dados que registra o primeiro evento agora define script_installed como verdadeiro e registra quando o script foi visto pela primeira vez.
A atualização é protegida. Ele é executado apenas enquanto a verificação está pendente ou o sinalizador de instalação ainda não é verdadeiro. As visualizações de página posteriores não reescrevem a mesma linha do site nem produzem uma nova entrada de auditoria para cada evento.
Em seguida, preenchemos as 19 linhas inconsistentes a partir da evidência existente do primeiro evento.
Após o reparo, o estado histórico de produção contava com 21 locais com primeiro evento e 21 com bandeira de instalação definida. A contagem de incompatibilidade foi zero.
Uma nova verificação de produção em 20 de agosto ainda retornou zero sites com eventos, mas um sinalizador de instalação falso, e zero sites com um sinalizador verdadeiro, mas nenhum primeiro evento.
O que mudamos no processo de revisão
A correção do código foi pequena. A mudança de revisão é mais útil.
Primeiro, os marcos de ativação precisam de um evento observável. “O script está instalado” é um rótulo. “O primeiro evento foi aceito neste momento” é uma prova.
Segundo, os testes precisam cobrir a transição que produz o estado. Um teste unitário perfeito para a função de pontuação não poderia revelar que a produção nunca forneceu o valor verdadeiro.
Terceiro, os fatos duplicados precisam de um invariante. Se for esperado que dois campos concordem, execute a consulta de contradição continuamente. Não espere por uma auditoria manual.
Quarto, a análise interna merece o mesmo ceticismo que a análise do cliente. Um funil polido ainda pode medir a ficção quando um marco deriva de um estado obsoleto.
A pergunta que usamos agora
Não perguntamos mais apenas se o sinalizador de instalação é verdadeiro.
Perguntamos qual evento irreversível prova que o marco aconteceu.
Para instalação do rastreador, esse evento é simples: o primeiro evento chegou.
Qual status do seu produto é tratado como fato mesmo que nenhum evento de produção seja responsável por alterá-lo?
