Dois comandos drop simples que nosso teste simulado nunca cobriu

O trabalho era de rotina. Um processo em segundo plano vinha criando registros órfãos, ou seja, entradas deixadas para trás sem nada ligado a elas. Corrigimos o processo e limpamos os que já tinham se acumulado. A prática padrão para uma mudança dessas é escrever um plano pareado para desfazê-la, caso alguma coisa precise ser revertida mais tarde. Escrevemos um. Depois tentamos conferir esse plano antes de executá-lo de verdade.

A checagem que não estava checando

Queríamos confirmar que o plano de reversão estava escrito corretamente sem executá-lo, então ativamos um recurso feito exatamente para isso: olhar os passos, sem rodá-los. Rodamos contra o sistema em produção e tratamos a operação como totalmente inofensiva.

Não era. Esse recurso suprime a execução para um único tipo de passo. Todo o resto roda exatamente como se a checagem nunca tivesse sido ativada, e a maior parte de um plano de reversão é feita desse “resto”. Então a “checagem de segurança” executou o plano de verdade. A limpeza que tínhamos acabado de fazer voltou ao estado bagunçado, como se nada tivesse acontecido.

Por que isso não virou um incidente

Já estávamos rodando verificações como parte da mesma etapa, e elas apontaram o erro na hora. Não houve intervalo entre o erro e o momento em que o vimos. Restauramos tudo o que tinha sido desfeito, refizemos a limpeza e comparamos o estado final com o que ele deveria ser. Bateu.

Ao remontar tudo, encontramos um segundo problema no plano de reversão que ainda não tinha disparado, porque até então nada havia exigido a reversão de verdade. Um dos passos presumia que nada novo tinha sido adicionado desde que a mudança original rodou, e essa suposição já estava errada no mesmo dia. Corrigimos isso também, antes que fizesse diferença.

O que o nome prometia

Nós não pulamos uma etapa de segurança. Nós a adicionamos justamente para não executar algo arriscado antes de ter certeza de que estava certo. O que erramos foi confiar no que o nome do recurso sugeria, em vez de verificar o que ele cobre. “Não vai executar nada” parece uma promessa geral. Na verdade, é uma promessa sobre um caso específico e não diz nada sobre o resto, incluindo justamente o tipo de passo de que o nosso plano era feito na maior parte. Nunca confirmamos que ele cobria os dois comandos drop simples (comandos que apagam coisas de vez) que estavam nesse plano.

Num sistema de que pessoas de verdade dependem, é aí que o risco se escondia. Não estava no passo que adicionamos de propósito. Estava na linha desse passo que nunca testamos antes de confiar nele.

Antes de rodar um modo “simulação” ou “prévia” (Ler em inglês) em um sistema em produção, descubra exatamente o que ele suprime e teste primeiro em um ambiente que não seja o de produção. E mantenha verificações rodando junto com qualquer mudança em um sistema em produção, porque foram elas que pegaram este erro na hora.