Três causas de falha por trás de um alerta que ninguém mais lia
Um bot cuja função era notar e corrigir pequenos problemas em uma ferramenta de engenharia ficava travando. Cada falha mandava o mesmo alerta: uma mensagem de erro e um horário, várias vezes seguidas, no instante em que acontecia. Depois de muitos desses, ninguém lê mais como lia o primeiro. Esse é o custo de um alerta que dispara sem ser útil. Ele ensina você a ignorar o próximo, inclusive o que importava.
Reservamos uma tarde e fomos atrás das causas reais, em vez de reagir ao sintoma a cada vez.
Três causas comuns em disfarces diferentes
A primeira causa era uma marca deixada por uma etapa anterior que morreu no meio do caminho e não limpou depois de si. Toda tentativa seguinte esbarrava na mesma marca e se recusava a continuar, de novo e de novo, até alguém entrar e limpar à mão.
A segunda era um conjunto de verificações internas de rotina que não paravam de falhar. Nada estava realmente quebrado. A máquina estava ocupada com outra coisa, sem relação, na hora em que cada verificação rodava. Uma verificação que falha uma vez sob carga normal e é tratada como falha definitiva gera um alerta dizendo “algo quebrou” quando o que aconteceu foi “o sistema estava ocupado”. Por isso essas verificações ganharam uma nova tentativa antes de poderem escalar o alerta.
A terceira era a mais simples e a menos interessante. O próprio processo às vezes morria e ficava morto até uma pessoa notar e reiniciar. Esse caso não pedia diagnóstico. Pedia que ele reiniciasse sozinho.
A correção que parecia pronta e não estava
A primeira correção, para a marca deixada para trás, estava bem construída no papel. Antes de limpar qualquer coisa, verificar se algo ainda a está usando agora, e limpar só se a verificação voltar claramente limpa. Nada de adivinhar.
Mesmo assim ela não disparou, em mais de uma ocasião, justamente nos casos que deveria proteger. Demorou para achar o motivo. A verificação que confirmava que nada usava a marca dependia de uma única consulta externa, e essa consulta estourava o tempo limite sob o mesmo tipo de carga que causa a marca deixada para trás. Quando a consulta estourava, a verificação se recusava a adivinhar e deixava tudo como estava, o que parece seguro isoladamente. Na prática, a rede de segurança da própria correção ficava cega no momento em que o problema original era mais provável. Uma verificação cautelosa que não consegue resposta sob carga real é inútil justamente quando mais se precisa dela.
A correção da correção acrescentou uma segunda forma, mais barata, de verificar quando a primeira não respondia. Também acrescentou uma regra mais estreita para quando as duas continuavam sem resposta: se a marca estava vazia e era antiga o bastante para que nada legítimo ainda a usasse, isso contava como outro tipo de evidência, não como um palpite.
Para onde vai a rotina agora
Além de consertar o mecanismo, a mudança maior foi decidir para onde vão os problemas de rotina que se resolvem sozinhos. Se o processo reinicia sozinho e volta limpo, se uma verificação falha uma vez e passa na nova tentativa, se uma marca deixada para trás é limpa automaticamente, nada disso interrompe ninguém. Fica registrado em log e entra num único resumo diário. O que ainda avisa na hora é só aquilo que a camada automática tentou e não conseguiu resolver, uma lista bem menor do que “tudo que pareceu errado em algum momento”.
O que o assistente fez e o que uma pessoa decide
Um assistente de IA foi útil no trabalho de agrupar: olhar uma pilha de alertas repetidos, separá-los pela causa real em vez do texto da mensagem e propor uma verificação de segurança que só age diante de uma resposta confirmada. Ele não deve ser quem decide que uma verificação travada ou inconclusiva é quase igual a uma limpa. Também não deve parar de avisar alguém sem que essa mudança fique visível em algum lugar onde uma pessoa possa ver.
Uma pessoa decide quais falhas são seguras para resolver automaticamente e registrar para depois, e quais devem sempre interromper alguém na hora, por mais rotineiras que pareçam. Isso é um julgamento sobre risco real, e não pertence ao sistema que está se consertando sozinho.
Pergunte se cada correção automática ainda responde sob carga, e decida de antemão quais falhas podem ser tratadas em silêncio e quais devem sempre avisar uma pessoa.