Antes de contratar mais MIPS, descubra o que seu mainframe executa à toa

Existe uma conversa que se repete em praticamente toda empresa que opera mainframe. O volume transacional cresce, o consumo acompanha, o contrato chega perto do teto e alguém precisa decidir entre ampliar capacidade ou segurar o crescimento do negócio.

A pergunta que quase ninguém faz antes dessa decisão é mais simples: quanto do que o ambiente processa hoje ainda serve para alguma coisa?

Na nossa experiência, a resposta costuma surpreender.

O desperdício não aparece no relatório de consumo

Relatórios de consumo mostram o quanto foi gasto. Não mostram o quanto foi gasto sem necessidade. Essa diferença é invisível justamente porque ninguém é dono dela.

Ambientes com décadas de operação acumulam rotinas que sobreviveram ao projeto que as criou, relatórios que ninguém mais lê, cargas que alimentam sistemas desligados há anos, jobs duplicados por contingências antigas que nunca foram revertidas. Cada um deles consome janela, CPU e atenção do time de sustentação.

Em um conjunto de iniciativas de saneamento conduzidas por Eduardo, especialista com mais de 30 anos em mainframe, cartões e adquirência, aproximadamente 15 mil processos obsoletos foram eliminados. Esse número é o resultado agregado de várias frentes ao longo do tempo, não de um único projeto — mas dá a ordem de grandeza do que costuma estar acumulado.

Desativar sem quebrar nada é uma disciplina, não um script

A parte difícil do saneamento não é encontrar candidatos. É decidir com segurança.

Uma rotina sem execução nos últimos seis meses parece morta. Pode ser o fechamento anual. Pode ser o plano de contingência que roda uma vez a cada três anos e, no dia em que rodar, precisa funcionar. Pode ser a exigência de um órgão regulador que só aparece em auditoria.

Por isso a desativação precisa considerar:

• Dependências reais, não apenas as documentadas.
• Calendários de execução, incluindo ciclos anuais e eventos raros.
• A função de negócio de cada processo, confirmada com quem responde por ela.
• Um caminho de reversão que possa ser acionado rápido.

Saneamento feito em ondas delimitadas, com aprovação de responsáveis e reversão possível, é lento o suficiente para ser seguro e rápido o suficiente para gerar resultado dentro do mesmo exercício.

Otimizar o que fica

Eliminar o desnecessário é metade do trabalho. A outra metade é fazer o que permanece consumir menos.

Em um case do portfólio da Bitwise, numa operação de pagamentos em que o crescimento transacional degradava a performance e atrasava janelas críticas, a intervenção combinou quatro frentes:

• Revisão lógica e otimização de programas COBOL críticos.
• Tuning de consultas e das estratégias de acesso ao DB2.
• Reestruturação de processos batch com gargalos de entrada e saída.
• Monitoramento contínuo de indicadores de CPU e consumo.

O resultado daquele ambiente foi uma redução de 30% no consumo de MIPS e de 40% no tempo de processamento das rotinas. São números históricos daquele case específico, sem garantia de repetição em outro ambiente, e não se referem ao saneamento descrito acima.

O efeito prático foi mais interessante que o percentual: rotinas essenciais passaram a terminar antes. Emissão de extratos, abertura do online, antecipação de recebíveis e geração de arquivos para bandeiras ganharam folga. E a capacidade liberada absorveu crescimento sem novo aporte em infraestrutura ou licenças.

O método importa mais que a ferramenta

Qualquer mudança em ambiente crítico precisa de justificativa, responsável e evidência. O caminho que seguimos tem cinco etapas:

Diagnosticar. Delimitar aplicações e cadeias batch. Reunir histórico de execução, consumo, falhas, contratos relevantes e calendário de negócio. A entrega é um inventário e uma linha de base — sem linha de base não existe ganho comprovável.

Priorizar. Relacionar desperdícios e gargalos ao impacto no negócio, classificando dependências e esforço. A entrega é um backlog priorizado e um plano de ondas.

Validar. Confirmar a necessidade de cada processo com seus responsáveis e definir testes, homologação, mudança e reversão. A entrega é um plano aprovado.

Executar. Desativar ou otimizar os itens aprovados, registrar alterações e acompanhar a produção. A entrega são evidências técnicas e um escopo estabilizado.

Medir. Comparar com a linha de base, ajustando a leitura por volume, sazonalidade e calendário. A entrega é um relatório de benefícios e as próximas oportunidades.

Esse último ponto costuma ser o mais negligenciado. Sem ajuste por volume e sazonalidade, qualquer comparação vira discussão. Com ajuste, o ganho para de ser opinião.

Quando essa conversa faz sentido

Vale olhar para o seu ambiente se:

• A janela batch se aproxima do limite e atrasa a abertura do online ou outras entregas críticas.
• Existem processos antigos sem dono claro e dúvida sobre o que pode ser desativado.
• O negócio precisa crescer e a área de tecnologia está sob pressão para ampliar capacidade ou contratos.
• Falhas recorrentes consomem o time de sustentação.

Modernizar não significa substituir tudo. Na maior parte dos casos, o caminho mais rápido para liberar orçamento não é migrar — é parar de pagar pelo que não serve mais.