O Paradoxo da Automação de Cargas de Trabalho

A infraestrutura que corre tudo — e que ninguém audita.

Algures no seu edifício — ou, mais provavelmente, num centro de dados que nunca visitou — há um sistema que corre centenas, talvez milhares, de tarefas automatizadas todas as noites.

Move ficheiros entre sistemas. Despoleta processamento batch que reconcilia transações, gera relatórios, calcula saldos, alimenta aplicações a jusante. Orquestra a sequência em que as coisas acontecem — que job corre primeiro, qual espera pelo outro terminar, o que acontece quando algo falha às 3 da manhã.

Este sistema chama-se uma plataforma de automação de cargas de trabalho. Em muitas organizações, é o BMC Control-M. Noutras, é o IBM TWS, o Stonebranch, ou algo construído internamente com cron e shell scripts.

É, sem exagero, o sistema nervoso das suas operações.

E quase ninguém o audita.

O paradoxo

As TI empresariais auditam tudo. Os servidores são inventariados. As redes são monitorizadas. As bases de dados têm relatórios de capacidade. As aplicações têm SLAs. O código passa por revisão antes do deploy.

Mas a camada que orquestra tudo isto — a camada de automação de cargas de trabalho — fica num ponto cego de governação. Foi montada há anos. Funciona. Corre todas as noites. E porque funciona, ninguém a questiona.

Até que alguém faz as perguntas que deveriam ter sido feitas há anos.

O que encontrámos

Ao longo dos últimos anos, auditei ambientes de automação de cargas de trabalho em organizações de infraestrutura crítica, pagamentos e energia. Os ambientes variavam em dimensão, indústria e tecnologia. As conclusões não.

Eis o que um diagnóstico típico revela — e digo típico porque os números são compósitos, mas os padrões repetem-se com uma consistência incómoda.

38% dos jobs não têm responsável documentado. O job corre. Faz alguma coisa. Mas se perguntar «quem é responsável por este job?» — ninguém consegue responder. A pessoa que o criou saiu há anos. A equipa que o herdou trata-o como problema de outra pessoa. Existe numa zona de amnésia coletiva: demasiado arriscado para apagar, demasiado obscuro para compreender, demasiado aborrecido para investigar.

15% dos jobs ativos não servem qualquer processo de negócio atual. Foram criados para um projeto que terminou. Ou um sistema que foi desativado. Ou um requisito regulatório que mudou. Mas o job continua lá. Continua a correr. Continua a consumir recursos. Continua a gerar alertas que as equipas de operações reconhecem obedientemente todas as manhãs sem compreender porquê.

Os jobs mortos não são só desperdício. São geradores de ruído. Cada falso alerta treina a equipa de operações a ignorar alertas. E no dia em que um alerta real dispara — um job que de facto importa — afoga-se num mar de alertas que não significam nada há anos.

A janela de batch cresceu 40–50% em três anos, e ninguém reparou. Quando o ambiente foi desenhado, o batch noturno corria da meia-noite às 5 da manhã. Cinco horas. Margem confortável. Hoje, corre das 23h às 7 da manhã. Oito horas. E algumas noites transborda para o horário laboral, porque alguém acrescentou «só mais um job» a cada trimestre durante três anos.

Ninguém planeou isto. Ninguém o mediu. A janela de batch não explodiu — foi-se arrastando. Como uma rã em água a aquecer devagar. Quando alguém repara, a margem já desapareceu.

Zero procedimentos de recuperação foram testados nos últimos 24 meses. Os jobs têm tratamento de erros. Alguns têm lógica de retry. Uns quantos têm regras de notificação. Mas a pergunta «se o job #247 falha às 3 da manhã e ninguém está disponível, o que acontece?» não tem resposta testada.

Não quero dizer que não haja runbook. Pode haver. Quero dizer que ninguém verificou que o runbook de facto funciona com a infraestrutura atual. Porque a infraestrutura mudou — servidores foram migrados, caminhos de ficheiros foram atualizados, contas de serviço foram rodadas — mas os procedimentos de recuperação nunca foram retestados contra a nova realidade.

A cadeia de dependências que ninguém mapeou

Eis o que torna a automação de cargas de trabalho unicamente perigosa de deixar por auditar: as dependências.

O Job A despoleta o Job B. O Job B espera por um ficheiro do Sistema C. O Sistema C gera o ficheiro só depois de o Job D terminar. O Job D depende de uma extração de base de dados do Sistema E. O Sistema E é mantido por um terceiro que mudou a sua configuração de SFTP há seis meses sem avisar ninguém.

Esta cadeia existe. Corre todas as noites. Funciona — até um elo mudar.

E quando parte, ninguém lhe consegue dizer porquê, porque a cadeia nunca foi documentada. A pessoa que a construiu compreendia o quadro completo. Essa pessoa reformou-se. A equipa que a herdou compreende a sua peça — o Job A, ou o Job B — mas não a cadeia. Não as dependências. Não os constrangimentos de tempo.

A maioria das organizações descobre as suas cadeias de dependências durante um incidente. Às 3 da manhã. Com o negócio à espera.

Por que isto acontece

A automação de cargas de trabalho é infraestrutura que foi construída para ser invisível. Quando funciona, ninguém pensa nela. Quando parte, alguém a corrige e toda a gente volta a não pensar nela.

Não há revisão anual. Não há auditoria agendada. Não há requisito de conformidade — ainda — que mande especificamente governar a automação de cargas de trabalho. O DORA e a NIS2 estão a mudar isto, mas a maioria das organizações não ligou os requisitos regulatórios ao ambiente batch.

O resultado é uma camada de infraestrutura que cresce organicamente, acumula dívida em silêncio, e entrega risco que só se torna visível durante a falha.

É o exato oposto de todas as outras camadas nas TI empresariais, onde a visibilidade, a governação e a responsabilização são prática-padrão.

O custo de não olhar

Vi organizações passar meses a resolver falhas de batch recorrentes que poderiam ter sido evitadas por uma auditoria de 3 dias. Vi janelas de batch que consumiam tanto do tempo de processamento noturno que a organização teve de comprar capacidade adicional de servidor — não porque a carga de trabalho cresceu, mas porque o agendamento nunca foi otimizado.

Vi equipas de cinco pessoas a fazer prevenção noturna para um ambiente onde 80% dos alertas eram para jobs que não importavam há anos. Cinco salários. Subsídios de prevenção. Cobertura de fim de semana. Por ruído.

O custo de não auditar a sua automação de cargas de trabalho não é uma única falha catastrófica. É uma hemorragia lenta e contínua: capacidade desperdiçada, alertas desperdiçados, atenção humana desperdiçada, e uma vulnerabilidade crescente à única falha que de facto importa.

A pergunta

Todas as organizações com que trabalhei têm a mesma reação quando apresento estas conclusões: «Sabíamos parte disto. Só nunca tivemos os dados».

É esse o paradoxo. A informação está lá. O ambiente regista tudo. A plataforma guarda cada definição, cada dependência, cada histórico de execução. Os dados existem.

O que não existe é alguém que pare, olhe para o quadro completo, e faça as perguntas que as equipas de operações estão demasiado ocupadas — ou demasiado habituadas — para fazer.

Perguntas como:

Quantos dos seus jobs de batch têm um responsável documentado — e quantos são órfãos a correr por inércia institucional?

Quando foi a última vez que os seus procedimentos de recuperação foram testados contra a infraestrutura que existe hoje — não a infraestrutura que existia quando foram escritos?

Quanto da sua janela de batch é consumido por jobs que já não servem um propósito de negócio?

Se a pessoa que construiu a sua cadeia de batch mais crítica saísse amanhã, quem compreenderia o mapa completo de dependências?

Se consegue responder às quatro com confiança, está na minoria.

Se não consegue — isso não é uma falha. É um diagnóstico à espera de acontecer.