O painel está verde. O sistema responde. Os usuários entram, as telas abrem, o tempo de resposta está dentro do acordado. E a operação está parada há semanas.

Não é contradição — é a diferença entre duas perguntas que quase todo mundo trata como uma só. Disponibilidade mede se o sistema responde. Resiliência operacional mede se o trabalho acontece. São coisas diferentes, e só a primeira costuma ter alarme.

Por que o monitor não vê

Todo monitoramento é construído sobre eventos. Alguma coisa acontece, alguma coisa é registrada, uma regra avalia o registro e decide se avisa. O modelo funciona bem para o que quebra.

Ele é cego para o que simplesmente não acontece. Um processo que deveria rodar e não rodou não gera evento nenhum. Não há linha no log, não há código de retorno, não há nada para uma regra avaliar. O silêncio é indistinguível de um dia tranquilo.

E o silêncio tem três formas, que valem separar porque se investigam de maneiras diferentes:

O que deveria ter começado e não começou. A fila existe, as mensagens entram, e não há ninguém consumindo do outro lado. Tudo se acumula, ordenadamente, sem erro.

O que começou e não terminou. O documento fica num estado intermediário — preparado, liberado, aguardando — e nunca avança. Cada registro individualmente parece normal; o problema só aparece no total.

O que terminou errado e ninguém comparou. O resultado saiu, é plausível, e está incorreto. Esse é o mais difícil, porque exige uma expectativa contra a qual comparar.

O número que denuncia: zero em erro

Num ambiente que atendemos, as notas fiscais pararam de sair. Nenhum erro na tela, nenhum registro, nenhum alerta.

A investigação virou quando alguém contou os documentos por estado, em vez de procurar falha:

• 250 documentos parados em preparação
• 7 liberados
• zero concluídos
• zero em erro

O último número é o achado. Nada tinha falhado. Nada tinha sequer tentado. A peça que distribui o trabalho apontava para um endereço inexistente, e havia mais de cem mil unidades represadas — parte delas fazia mais de um mês. O sistema passava em qualquer verificação de disponibilidade.

O caso inteiro, com a hipótese errada que custou dois dias, está em DANFE que não imprime: nenhum spool, nenhum erro, nenhum log.

A medição que falta: contar o esperado

A correção não é mais monitoramento. É outro tipo de monitoramento, que ninguém instala por padrão porque exige uma informação que a ferramenta não tem: o que deveria acontecer.

A pergunta muda de “o que falhou?” para “o que deveria ter acontecido e não aconteceu?“. E ela é respondível com contagem simples, por janela de tempo:

• documentos por estado — quantos entraram, quantos concluíram, quantos ficaram no meio;
• fila por consumidor — quantas unidades esperando, e há quanto tempo está a mais antiga;
• interface por período — quantas mensagens no mesmo intervalo de ontem, da semana passada, do mesmo dia do mês anterior;
• rotina por calendário — o que roda toda segunda rodou nesta segunda?

Nenhuma dessas contagens é sofisticada. O que elas exigem é a parte que costuma faltar: alguém precisa ter escrito o que se espera. Sem expectativa declarada, não existe ausência detectável — existe só um número sem referência.

Como montar em cima do que já existe

1. Liste os processos que produzem resultado contável. Emissão, integração, fechamento, carga, expedição. Se não dá para contar o resultado, não dá para detectar a ausência dele.

2. Escreva o esperado por janela. Não precisa ser preciso. “Entre 200 e 400 por dia útil” já é infinitamente melhor do que nada, porque zero fica visível na hora.

3. Alarme por ausência, não por erro. A regra que importa é “esperava-se N e vieram 0” — e ela é diferente de todas as regras que você já tem.

4. Dono por processo. Alarme sem destinatário vira ruído em duas semanas, e ruído desligado é pior do que alarme nenhum, porque dá sensação de cobertura.

O que dá errado, com nome

Usar disponibilidade como indicador de operação. Um sistema pode ficar meses com 99,9% de disponibilidade sem processar parte do trabalho. Os dois números são verdadeiros ao mesmo tempo, e só um deles chega ao negócio.

Monitorar o componente, não o resultado. Serviço no ar, processo parado. Vigiar a peça é necessário e não é suficiente — o que importa é o documento que sai do outro lado.

Tratar “ninguém reclamou” como evidência. No caso acima, o documento que gerou o chamado era menos de 0,1% do que estava represado. Ninguém tinha aberto chamado sobre o resto — e o resto era quase tudo.

Medir média em vez de contagem. Tempo médio de processamento continua ótimo quando nada está sendo processado. Média esconde ausência; contagem não.

Confiar no alarme que nunca tocou. Um alarme que nunca disparou tem duas explicações possíveis, e a maioria das operações só considera uma delas.

Em ambiente regulado, isso deixou de ser opcional

Resiliência operacional entrou no vocabulário das normas do setor financeiro, e o texto pede mais do que política escrita: pede demonstração. Declarar que existe controle e demonstrar que o controle funciona são exercícios diferentes — o segundo exige justamente a evidência de que o trabalho aconteceu.

É a mesma lógica de auditoria em qualquer setor regulado: não basta afirmar que o processo roda; é preciso poder mostrar quantas vezes rodou, quando, e o que saiu. Tratamos isso em TI para instituições financeiras.

O limite honesto

Contar o esperado exige saber o que se espera — e boa parte das operações não sabe. Descobrir isso é trabalho de negócio, não de infraestrutura, e é a parte que costuma travar. Quando ninguém consegue dizer quantos documentos um dia normal produz, o problema é anterior à monitoração.

Isso também não substitui o que já existe. Monitoramento de falha continua necessário — o que se propõe aqui é uma camada que ninguém instalou, não a troca de uma pela outra.

E há um limite de escopo: detectar a ausência encurta o tempo até descobrir, não o tempo até corrigir. No caso citado, a detecção teria economizado a maior parte de onze dias. A correção em si continuaria exigindo investigação — e coordenação, porque religar um distribuidor de trabalho com cem mil unidades represadas é um evento em si.

Se o ponto de partida é descobrir o que já está parado sem ninguém saber, é exatamente o que o diagnóstico de TI procura. Para sustentar isso no dia a dia, o caminho é observabilidade. E se a discussão é colocar processos automáticos nesse ambiente, vale antes entender o que a autonomia herda.

Perguntas frequentes