Eu tinha uma aplicação de ingestão que publicava um snapshot para consumo. O painel estava verde, tudo parecia correto, mas algo me incomodava: a quantidade de dados não crescia como deveria. Fui olhar. O serving estava parado havia 14,71 dias, e o alarme permanecera verde o tempo inteiro. O check de frescor tinha SLA de 26 horas e era rearmado a cada 19 minutos pelo próprio publish que não publicava nada.
O trigger do ETL disparava normalmente. Na hora do load, falhava. O Asset Check do Dagster rearmava mesmo assim, porque o sinal de monitoramento vinha do mesmo caminho que estava quebrado. Para o alarme soar, seriam necessários 82 ciclos consecutivos sem rearme impossível por construção. Nenhuma quantidade de sorte ruim faria aquele alarme tocar. E o defeito de fundo é pior que o silêncio: a falha que o vigia deveria reportar era a mesma coisa que o mantinha calado, o que inverte a função do instrumento quanto pior o estado do sistema, mais firme o sinal de saúde.
Se eu tenho um portão que garante a qualidade dos meus projetos e que, ao identificar uma aplicação com VETO ou BUGs, bloqueia o commit quando ela não passa pelo CI, esse portão precisa ser efetivamente uma barreira de proteção.
Se, por outro lado, é possível excluir um prefixo, uma regra ou qualquer outro ponto para contorná-lo, o problema não é simplesmente o bypass existir. A exclusão empurra a obrigação de garantir a qualidade para cada rota que está dentro daquele escopo, sem que essa responsabilidade tenha sido decidida ou assumida explicitamente. É aí que ocorre o mesmo erro: o portão continua reportando “passou”, mas “passou” passa a significar coisas diferentes dependendo de onde o commit caiu. Quem olha para o resultado não consegue distinguir entre “verificado e aprovado” e “fora do escopo”. A exclusão, portanto, não desliga o portão; ela faz o portão dizer “aprovado” sobre algo que ele nunca olhou.
Se foi realizada uma mudança no código, com uma nova implementação, porém a verificação de CI/CD ficou impedida de ser executada devido a limitações impostas pelo provedor de Git, como, por exemplo, o limite permitido pelo GitHub Actions, ou qualquer outro mecanismo de restrição da plataforma, não se pode considerar que houve uma validação de qualidade. A ausência dessa verificação compromete a garantia de integridade do projeto, especialmente quando o CI/CD é responsável por controlar a quantidade ou o tamanho de um arquivo e garantir que, caso essa medição seja ultrapassada após uma alteração, a aplicação não seja comprometida e a mudança seja bloqueada de forma atômica. O job não falhou. Ele não aconteceu. E não ter acontecido é indistinguível de ter passado para quem olha depois.
Há um caso complexo, semelhante ao de um romance em que um industrial terceiriza a decisão sobre a proteção de seu bem mais precioso: um metal que levou dez anos para desenvolver. Ao delegar a um operador em Washington essa escolha, permite que alguém fora de seu domínio determine o destino daquilo que levou uma década para construir, abrindo caminho para a ruína do projeto.
O ponto não é só ter delegado. É ter tomado o aval desse operador como se fosse a própria verificação. Sem conferir o resultado, recebeu a decisão de fora com a sensação de dever cumprido que só o exame direto daria. O carimbo ocupou o lugar da prova. É o mesmo verde dos outros casos, só que gerado por pessoa e não por máquina: o julgamento foi deslocado e tratado como se o fato já estivesse comprovado. Mudou a forma, não o erro: tomar por verificado o que nunca foi verificado.
A objeção mais forte contra tudo isso é outra.
O custo de verificar é real e imediato; o custo de não verificar é hipotético e adiado. Na maioria dos sistemas, ausência de verificação e verificação bem-sucedida produzem exatamente o mesmo resultado e produzem por anos. Se o painel verde falso não causou perda concreta, o problema não é o falso positivo: é você exigir rigor onde a criticidade não justifica. Verificação sem proporção à consequência é cerimônia, não engenharia.
De fato, nem todo sistema precisa de um check, e tudo bem remover aquilo que não se justifica. Mas existe uma diferença fundamental entre um sistema que está funcionando de fato, um sistema que não possui qualquer mecanismo de verificação e um sistema que produz um sinal de que está funcionando quando, na realidade, não está.
No primeiro caso, você tem rastreabilidade, segurança e monitoramento: se algo ocorrer, existe evidência de que o sistema estava sendo verificado e mecanismos para identificar o problema e restaurar a aplicação rapidamente. No segundo, você simplesmente não sabe. Pode estar funcionando ou não, mas não existe um mecanismo que permita afirmar isso. O terceiro é o pior dos casos: existe algo que atesta que está funcionando, você acredita nesse sinal e, justamente por acreditar nele, deixa de perceber o problema que está acontecendo. É como ter uma faca presa às costas sem sentir dor: você não sabe que existe um problema, mas ele continua lá.
Por isso, o Quality Assurance entra como mecanismo de reconciliação: não basta verificar continuamente; é necessário verificar se a própria verificação continua funcionando. A verificação anterior precisa ser confrontada com evidências reais de que aquilo que ela deveria detectar ainda pode ser detectado.
É nesse ponto que a aplicação de ingestão de dados se torna relevante. Se um fornecedor entregasse um sistema cujo sinal de saúde fosse produzido pelo próprio processo que deveria auditar, você aceitaria esse sistema como confiável?
E, no entanto, foi exatamente isso que aconteceu no meu próprio sistema: o painel permaneceu verde por dias, e eu continuei olhando para ele como evidência de que tudo estava funcionando. O problema não era apenas a ausência de uma verificação; era acreditar em uma verificação que nunca havia sido reconciliada com a realidade.
