 |
| Bellacosa Mainframe e a hidreletrica digital monitorando um mainframe |
☕ Um Café no Bellacosa Mainframe
🚀 A Hidrelétrica Digital — Quando o Agente J Entrou na Sala de Controle do z/OS e Descobriu que Cem Alertas Não Eram Cem Problemas
Ou: o mainframe não precisava de mais pares de olhos diante de dashboards; precisava de sensores, contexto, bons procedimentos e alguém que não apertasse o botão vermelho só porque Igor disse que a luz estava piscando
O Agente J, recém-saído de mais uma manhã tentando explicar ao público que alienígenas não usavam cartão de ponto, entrou no centro de operações e parou diante de uma parede de telas. Havia gráficos verdes, amarelos, vermelhos, mapas de aplicações, filas, porcentagens de CPU, mensagens de console, tickets e, em um canto suspeito, um operador olhando para o JES como quem esperava que ele revelasse o futuro nas entranhas de um SYSOUT.
— Então é aqui que vocês protegem o banco? — perguntou J.
— Em tese — respondeu o Agente K. — Em prática, às vezes protegemos o banco de 97 alertas que são a mesma coisa usando fantasias diferentes.
O colega apontou para a tela. A CPU estava alta. Uma fila MQ crescia. O Db2 apresentava espera. Uma transação CICS ficava lenta. Um job batch ultrapassara o horário previsto. A API móvel exibia aumento de timeout.
— São seis incidentes? — J perguntou.
K colocou os óculos escuros, porque alguma instituição provavelmente ainda não havia inventado um protocolo para isso.
— Talvez seja um só. Esse é o problema.
É aí que começa a conversa sobre Mainframe Operations inteligente. Não se trata de substituir o operador L1, o analista L2, o DBA, o especialista CICS ou aquela pessoa que conhece uma regra de negócio tão antiga que parece ter sido entregue junto com o primeiro cartão perfurado. Trata-se de parar de usar profissionais experientes como sensores biológicos de dashboard.
O mainframe continua sendo uma das salas de máquinas mais confiáveis do mundo. Mas confiável não significa simples. Ele conversa com aplicações web, mobile, APIs, nuvens, filas, parceiros, cartões, pagamentos, batches, sistemas de fraude e uma coleção de integrações que, em alguns bancos, já possui mais dependências do que a árvore genealógica dos Targaryen. Observar tudo isso apenas olhando telas é como operar uma hidrelétrica com uma lanterna e um caderninho.
A hidrelétrica que, por acaso, processa pagamentos
A melhor analogia para entender AIOps no mainframe é uma hidrelétrica moderna.
Uma usina possui centenas ou milhares de sinais: nível da água, vazão, pressão, vibração, temperatura, rotação da turbina, posição de comportas, tensão, frequência e estado de equipamentos. Um sensor isolado raramente conta a história inteira. Uma vibração levemente maior pode ser normal. Vibração crescente junto com temperatura elevada, perda de eficiência e alteração de pressão é outra conversa: alguém precisa investigar antes que a conversa vire notícia.
O ambiente z/OS tem seus próprios sensores:
CPU, memória, dispatching e metas de serviço do WLM;
I/O, canais, volumes e espaço de DASD;
jobs, initiators, spool e mensagens do JES2;
tempos de resposta e regiões do CICS;
locks, waits, pools e SQL no Db2;
filas, canais e consumidores no MQ;
transações IMS e conectividade TCP/IP;
logs, traces, mensagens do console e registros SMF;
latência de APIs, erros de aplicativos e experiência do cliente.
O cliente, no entanto, não vê nenhum desses itens. Ele vê uma pergunta de cinco segundos: “o PIX foi?”, “o pagamento entrou?”, “consigo consultar meu saldo?”, “a folha fechou?”.
Por isso, operação madura não monitora apenas componentes. Ela monitora serviços de negócio e usa os componentes para explicar o que aconteceu com eles.
CPU alta numa LPAR pode ser apenas o processamento esperado do fechamento. CPU alta, fila MQ crescendo, transação CICS acima do SLO e timeout no app bancário é uma tempestade se formando. A diferença não está no gráfico; está no contexto.
Antes da IA: alerta, evento, incidente, problema e mudança
Em operações, algumas palavras são tratadas como sinônimos até o dia em que deixam de ser. Vale colocá-las em ordem antes de dar uma pistola neuralizadora ao dashboard.
Um evento é qualquer ocorrência observável: uma mensagem no console, um job terminando, uma conexão caindo, uma alteração de estado. Um alerta é um evento que cruza uma regra de atenção: a fila passou de determinado tamanho, o tempo de resposta ultrapassou um limite, um recurso ficou indisponível.
Um incidente é quando um serviço está interrompido ou degradado. “Clientes não conseguem pagar” é incidente. Já um problema é a causa persistente ou subjacente que pode produzir vários incidentes: um plano SQL ruim, uma parametrização incorreta, um vazamento de recurso, um processo batch concorrendo de modo inadequado.
E há a mudança: o deploy, ajuste de parâmetro, manutenção ou alteração de configuração que pode ser a solução, a causa ou uma coincidência muito suspeita.
O erro clássico do monitoramento tradicional é transformar cada alerta em um incidente. Assim, uma única regressão após um deploy gera tickets separados para API, CICS, Db2, MQ, rede e storage. Cada equipe recebe seu fragmento do elefante e conclui que a culpa está em outra sala.
O objetivo da correlação é fazer o caminho oposto: agrupar os sintomas e apresentar um incidente operacional coerente.
Incidente: Pagamentos digitais degradados.
Impacto: clientes com timeout acima de três segundos.
Serviços envolvidos: API Payments → CICS PAYM → Db2 DBPAY → MQ.
Início: logo após a mudança CHG004321.
Hipótese: aumento de chamadas e regressão de plano SQL.
Próximo passo: coletar evidências e executar runbook aprovado.
Note a palavra importante: hipótese. Uma plataforma inteligente deve apresentar causa provável e nível de confiança, não posar de oráculo. Correlação temporal é valiosa; não é prova definitiva de causalidade.
O que as ferramentas trazem para a sala de controle
Ferramentas como IBM OMEGAMON, BMC AMI Ops e Broadcom SYSVIEW dão visibilidade profunda de z/OS e seus subsistemas. Elas ajudam a enxergar o que realmente acontece na LPAR, no CICS, no Db2, no MQ, no IMS, no JES e nos recursos que sustentam a carga. São os instrumentos de engenharia da usina.
IBM Z System Automation, NetView e soluções como OPS/MVS entram mais diretamente na parte de automação orientada a eventos, disponibilidade e ações controladas. Elas podem detectar estados, aplicar políticas e disparar procedimentos conhecidos.
No outro extremo da jornada, plataformas de observabilidade como Instana, Dynatrace e AppDynamics ajudam a costurar a visão de ponta a ponta: o clique no aplicativo, a API, o middleware, a transação no mainframe e o retorno ao cliente. Splunk e Elastic podem centralizar logs, eventos e análises, desde que os dados tenham qualidade, horário confiável e acesso devidamente protegido. ServiceNow organiza o processo: ticket, mudança, aprovação, SLA, escalonamento, CMDB e workflow.
O detalhe que slides de marketing omitem é este: nenhuma dessas ferramentas, isoladamente, é AIOps. A inteligência aparece na integração.
Um monitor detecta a anomalia. A topologia informa as dependências. A CMDB identifica o serviço e seu dono. O histórico aponta o comportamento esperado. O motor de correlação reduz o ruído. O ServiceNow abre um incidente já enriquecido. A automação executa uma ação de baixo risco. E a observabilidade confirma se o serviço voltou a funcionar.
Sem esse encadeamento, temos várias telas bonitas. Com ele, temos uma sala de controle.
Threshold estático: o velho porteiro ainda tem emprego
“Alerta quando CPU ultrapassar 90%.” É uma regra simples, útil e incompleta.
Às duas da manhã, no processamento mensal, 90% pode ser esperado. Às duas da tarde, numa LPAR que normalmente opera a 45%, 65% pode ser a primeira pista de algo muito estranho. É aqui que entram baseline, sazonalidade e detecção de anomalia.
Uma boa análise pergunta:
este comportamento é normal para este horário e este dia?
houve alteração abrupta, mesmo abaixo do limite absoluto?
quais métricas se moveram juntas?
qual serviço de negócio foi afetado?
houve mudança, deploy ou manutenção recente?
o impacto é crescente ou estável?
Mas não se deve jogar fora os limites rígidos. Espaço de DASD quase esgotado, fila aproximando-se de limite físico, certificado prestes a expirar e recurso indisponível não precisam aguardar uma tese de machine learning. O ambiente maduro combina limites determinísticos para riscos claros e anomalias estatísticas para padrões sutis.
O Agente J resumiria assim: “Se o reservatório está transbordando, não vamos montar um comitê para saber se a água parece incomumente molhada.”
Do alerta ao incidente: um caso de banco digital
Imagine que, às 10h05, clientes começam a relatar lentidão ao efetuar pagamentos.
No modo antigo, L1 abre o dashboard da aplicação e vê timeout. Depois consulta CICS e identifica transações com maior tempo de resposta. Abre Db2 e encontra waits. Vai ao SDSF verificar jobs. Olha MQ. Procura mensagens. Cria ticket. Escala para L2, DBA, middleware, infraestrutura e, por segurança, para a equipe que fez o último deploy. Todos começam a investigar ângulos diferentes.
No modelo inteligente, as informações chegam correlacionadas. A plataforma observa que:
a jornada “pagamento digital” ultrapassou seu SLO;
a API Payments aumentou o volume de requisições;
a transação CICS PAYM ficou lenta;
o Db2 mostrou aumento de waits e uma consulta específica mudou de comportamento;
a fila MQ começou a acumular mensagens;
tudo teve início minutos após uma mudança registrada.
O L1 não recebe seis sirenes. Recebe um incidente com impacto, dependências, evidências, possíveis responsáveis e runbook.
Isso não elimina a investigação técnica. Elimina a caça ao tesouro inicial — aquela meia hora em que cada pessoa tenta descobrir se o incêndio é real, onde começou e quem tem a chave do armário de mangueira.
Para um programador COBOL iniciante, existe uma lição excelente aí: seu PROGRAM-ID quase nunca vive sozinho. Uma rotina aparentemente inocente pode chamar Db2, publicar em MQ, ser acionada por CICS, expor dados por API e participar de um fluxo que movimenta dinheiro. Aprender a observar o caminho da transação é tão importante quanto acertar o PERFORM.
Self-healing sem transformar Igor em DBA de produção
Automação de recuperação é maravilhosa até alguém programar uma rotina para derrubar uma região CICS crítica por causa de um alerta mal calibrado. Por isso, “self-healing” precisa ser dividido por risco.
Há ações ótimas para automação total:
coletar logs, mensagens, dumps e métricas quando surge uma anomalia;
abrir e enriquecer incidentes;
executar health checks;
reiniciar um processo isolado e conhecido;
elevar temporariamente o nível de monitoramento;
pausar uma cadeia batch antes que um erro se propague;
fazer a notificação e o escalonamento corretos.
Outras ações devem ser assistidas ou requerer aprovação:
cancelar batch crítico;
alterar WLM;
modificar parâmetro Db2;
derrubar ou reciclar região compartilhada;
fazer failover;
alterar RACF, certificados, conectividade ou regras de segurança;
realizar rollback de aplicação.
A regra de ouro é simples: quanto maior o raio de explosão, maior a necessidade de aprovação humana, trilha de auditoria e rollback.
Uma hidrelétrica não permite que um algoritmo abra todas as comportas porque um sensor piscou. Ela trabalha por níveis: automático para ajustes seguros e reversíveis; assistido para recomendações que o operador aprova; manual para decisões críticas. A operação de mainframe deveria seguir exatamente essa filosofia.
Igor, naturalmente, propôs colocar CANCEL JOB(*) dentro de um botão verde chamado “cura automática”. O Agente K confiscou o teclado. Segurança também é uma forma de carinho.
L1 e L2: menos mensageiros, mais operadores de exceção
A evolução não diminui o valor de L1 e L2; ela muda o tipo de valor entregue.
L1 deixa de ser a pessoa que copia mensagens de console para um ticket e pode se tornar operador de exceções: valida impacto, executa runbooks aprovados, confirma se a correção funcionou, faz comunicação operacional e escalona com evidências.
L2 ganha espaço para trabalho que diminui as próximas madrugadas ruins: análise de causa raiz, ajuste de alertas, automações, gestão de capacidade, revisão de arquitetura, melhoria de runbooks e eliminação de falhas recorrentes.
Isso é próximo da cultura de SRE: não basta apagar incêndio com eficiência; é preciso descobrir por que o prédio continua tendo incêndios na mesma tomada.
A parte chata que salva o projeto: dados, nomes e procedimentos
Antes de contratar uma IA com nome de nave espacial, arrume a base.
Se a aplicação é chamada de PAGTO no mainframe, “Pix” pelo negócio, “Payments Hub” na CMDB e APP-347 no dashboard, a ferramenta não ganhou contexto; ganhou quatro identidades secretas para o mesmo serviço. Nem o MIB tem orçamento para isso.
Os obstáculos reais costumam ser:
alertas duplicados ou sem dono;
topologia e CMDB desatualizadas;
logs sem correlação, timestamp confiável ou padronização;
mudanças sem registro operacional;
runbooks velhos, incompletos ou guardados na cabeça de uma única pessoa;
ausência de SLOs e indicadores de impacto de negócio;
automações sem teste, validação ou rollback;
permissões excessivas em contas técnicas.
Lembre-se: IA alimentada por telemetria ruim apenas produz conclusões ruins com uma confiança irritantemente bem redigida.
Um roteiro possível para começar
Não tente modernizar todos os alertas do universo numa única change. Comece pequeno, mensurável e dolorosamente real.
Primeiro: reduza ruído. Revise alertas. Cada alerta deve ter dono, severidade, ação esperada e justificativa. Se ninguém sabe o que fazer quando ele dispara, provavelmente não é alerta; é decoração sonora.
Segundo: escolha jornadas críticas. Pagamento, PIX, cartão, fechamento, folha, faturamento, autorização. Comece por aquilo cuja indisponibilidade o negócio percebe em minutos.
Terceiro: mapeie dependências. Desenhe API, middleware, CICS/IMS, Db2, MQ, batch, rede, storage e terceiros. A pergunta é: “se isto falhar, quem sente?”
Quarto: escreva runbooks utilizáveis. Não um PDF de 200 páginas enterrado no SharePoint. Um procedimento que diga sintomas, verificações, comandos autorizados, evidências, critérios de parada, escalonamento e rollback.
Quinto: automatize a coleta antes da correção. Fazer a máquina montar um ticket excelente e reunir evidências já reduz muito MTTR. Automação de remediação vem depois, em ações reversíveis e testadas.
Sexto: correlacione casos recorrentes. Se três incidentes por mês começam com a mesma combinação de sinais, essa é uma ótima primeira regra. A automação deve nascer de dor repetida, não de entusiasmo em reunião.
Sétimo: valide o resultado. Uma ação só é recuperação se o serviço voltou ao SLO. Reiniciar uma tarefa e fechar o ticket porque o alerta sumiu é como desligar o alarme de incêndio e declarar que a fumaça foi embora.
O que medir para saber se a inteligência existe
Não conte telas, licenças ou gráficos com inteligência artificial desenhada no canto. Meça resultado:
quantidade de alertas por incidente real;
redução de ruído;
MTTA, o tempo até reconhecer o incidente;
MTTR, o tempo até restaurar o serviço;
percentual de incidentes detectados antes do cliente;
taxa de sucesso e falha das automações;
reincidência dos principais problemas;
percentual de tickets enriquecidos automaticamente;
cobertura de serviços críticos com SLO e dependências mapeadas.
O indicador mais honesto é simples: o operador passa menos tempo caçando pistas e mais tempo prevenindo a próxima falha?
Epílogo — Não é Skynet; é uma usina bem operada
Mainframe Operations inteligente não é dar autonomia ilimitada a um modelo e esperar que ele descubra o significado de IEC161I enquanto a produção queima. É criar uma operação que coleta sinais, entende dependências, relaciona tecnologia com negócio, aplica procedimentos seguros e mantém pessoas experientes no circuito.
O futuro não é “menos humanos”. É menos trabalho mecânico, menos escalonamento cego, menos alertas inúteis e mais inteligência aplicada ao que realmente importa.
Quando o Agente J saiu da sala, perguntou se poderia usar o neuralyzer para apagar da memória dos operadores todos os alertas duplicados.
K balançou a cabeça.
— Não. Primeiro precisamos corrigir a regra que os gera.
E aquele, para quem já enfrentou uma madrugada de console cheio e café frio, foi o momento mais sensato de toda a operação.
Easter egg para quem viveu o mainframe: se um dashboard declarar tudo verde enquanto o usuário reclama que nada funciona, desconfie. Talvez não seja uma invasão alienígena. Talvez alguém esteja monitorando o recurso certo… para o serviço errado.
