IBM Storage Insights 2Q26 Muito Além do Monitoramento: A Nova Era da Observabilidade para IBM Storage

 

Bellacosa Mainframe a nova era do ibm storage

---

☕ Um Café no Bellacosa Mainframe

IBM Storage Insights 2Q26

Muito Além do Monitoramento: A Nova Era da Observabilidade para IBM Storage

"Durante muitos anos administradores de storage olhavam para discos, controladoras e portas Fibre Channel. Hoje observam tendências, saúde operacional e inteligência analítica. A diferença parece pequena. Na prática, muda completamente a forma de operar um datacenter."

---

O Storage deixou de ser invisível

Durante décadas, armazenamento era considerado infraestrutura.

Funcionava?
Ótimo.

Não funcionava?
Chamavam o especialista de storage.

Hoje isso mudou.

Em um ambiente moderno existem:

• IBM Z

• LinuxONE

• VMware

• Kubernetes

• OpenShift

• Cloud híbrida

• IA

• Data Lakes

• Storage Scale

• FlashSystem

• DS8000

Tudo depende do storage.

Um pequeno problema em uma porta Fibre Channel pode afetar milhares de aplicações.

É justamente esse cenário que o IBM Storage Insights procura resolver.

---

O foco da versão 2Q26

Ao analisar todas as novidades percebe-se um padrão.

A IBM investiu em cinco pilares:

• observabilidade

• experiência do operador

• análise inteligente

• integração

• automação

Não há novos equipamentos.

Não há novo hardware.

Há inteligência operacional.

E isso vale muito mais.

---

1. Fleet Performance Analysis

Até agora a análise era muito centrada em um storage específico.

Agora passa a existir uma visão da frota inteira.

Imagine um banco com:

• 15 DS8900F

• 8 FlashSystem

• 6 SAN Directors

• dezenas de switches Fibre Channel

Antes era necessário analisar equipamento por equipamento.

Agora é possível observar tendências globais.

Isso permite responder perguntas como:

• Qual storage ficou mais lento?

• Qual começou a aumentar a latência?

• Em qual região ocorreu maior utilização?

• Existe um comportamento anormal em todo o ambiente?

Esse tipo de análise aproxima o Storage Insights das plataformas modernas de observabilidade.

---

2. Upgrade guiado para o Pro

Parece um detalhe.

Não é.

A IBM percebeu que muitos clientes utilizavam apenas a versão Free porque o processo de migração não era claro.

Agora existe um assistente mostrando:

• licença atual

• recursos disponíveis

• diferenças entre versões

• caminho de atualização

Resultado:

menos dúvidas.

Menos chamados.

Menor tempo para adoção.

---

3. Novo NOC Dashboard

O dashboard ganhou uma filosofia muito diferente.

Antes havia muitas telas.

Agora existem cartões inteligentes.

Entre os novos recursos:

✔ Saúde

✔ Capacidade

✔ Performance

✔ Desvios

✔ Tendências

✔ Intervalo de tempo flexível

Além disso surgiu um widget extremamente interessante.

O novo Performance Widget identifica automaticamente quais sistemas merecem atenção.

Ou seja:

não é mais o operador procurando problemas.

É o dashboard chamando o operador.

Esse é um conceito típico de plataformas modernas de observabilidade.

---

4. Monitoramento óptico da SAN

Na minha opinião, esta é uma das novidades mais importantes.

Até hoje muitos problemas em Fibre Channel eram diagnosticados apenas quando os erros apareciam.

Agora passam a existir três métricas fundamentais:

SFP Temperature

Temperatura do transceiver óptico.

Temperatura elevada normalmente indica:

• degradação

• ventilação inadequada

• desgaste

---

SFP Tx Power

Potência óptica transmitida.

Quando começa a cair pode indicar:

• envelhecimento do laser

• problemas no transmissor

---

SFP Rx Power

Potência óptica recebida.

Permite detectar:

• fibras sujas

• conectores danificados

• curvatura excessiva

• atenuação

• perda óptica

Isso muda completamente o modelo de suporte.

Antes:

"O link caiu."

Agora:

"O nível óptico vem degradando há três semanas."

É manutenção preditiva.

---

Bellacosa Mainframe espiona o DS8000

5. Capacity Insights para DS8000

Quem administra DS8000 sabe como planejamento de capacidade pode ser complexo.

A IBM agora separa claramente:

• capacidade IBM Z

• Open Systems

• Thin Provisioning

• Compression

• Non Compression

• economia obtida

• eficiência geral

Isso facilita responder perguntas clássicas da diretoria:

"Precisamos comprar mais discos?"

Ou:

"A compressão está realmente gerando economia?"

---

6. IBM Storage Scale na nova interface

Outro passo importante.

O IBM Storage Scale passa a aparecer na interface moderna.

Nesta primeira fase (Technology Preview), o foco é:

• inventário

• configuração

• hardware

• software

No futuro deverão chegar métricas completas de desempenho.

A tendência é consolidar toda a infraestrutura IBM Storage em uma única interface.

---

7. REST API Version 2

Toda plataforma moderna precisa ser automatizada.

A nova API V2 simplifica integrações com ferramentas como:

• Ansible

• Terraform

• Grafana

• ServiceNow

• Red Hat Ansible Automation Platform

• IBM Concert

• IBM Turbonomic

O detalhe interessante é que a IBM manteve compatibilidade com a versão anterior.

Ou seja:

não quebra integrações existentes.

É uma evolução segura.

---

O que isso significa para ambientes IBM Z?

Embora o IBM Storage Insights não substitua ferramentas tradicionais de administração do z/OS, ele complementa a visão operacional do ambiente.

Em um datacenter IBM Z, ele pode fornecer visibilidade sobre:

• DS8000

• FlashSystem

• SAN Fibre Channel

• Storage Scale

• eficiência de compressão

• crescimento de capacidade

• tendências de desempenho

• saúde da infraestrutura de armazenamento

Isso ajuda equipes de infraestrutura a identificar gargalos antes que impactem workloads críticos executados no IBM Z.

---

Minha avaliação

A IBM claramente está posicionando o Storage Insights como uma plataforma de observabilidade para armazenamento, e não apenas como um console de monitoramento.

As novidades mais relevantes desta versão são:

⭐ Fleet-Level Performance Analysis — visão consolidada do ambiente.

⭐ Monitoramento óptico de SAN — manutenção preditiva para Fibre Channel.

⭐ Capacity Insights para DS8000 — planejamento de capacidade mais preciso.

⭐ IBM Storage Scale na interface moderna — unificação da administração.

⭐ REST API v2 — integrações mais simples e preparadas para automação.

⭐ Novo NOC Dashboard — operação orientada por eventos e indicadores.

Para organizações que operam ambientes críticos — bancos, seguradoras, governos e grandes empresas — esses recursos reduzem o tempo gasto em diagnóstico, aumentam a visibilidade da infraestrutura e fortalecem uma abordagem proativa na gestão do armazenamento, em vez de apenas reagir a incidentes quando eles já ocorreram.

O Caso dos Oito Segundos Perdidos : Quando um Programador COBOL Descobre que o Verdadeiro Vilão Nunca Foi o CICS...

 

Bellacosa Mainframe e o caso dos 8 segundos perdidos

☕ Um Café no Bellacosa Mainframe

O Caso dos Oito Segundos Perdidos

Quando um Programador COBOL Descobre que o Verdadeiro Vilão Nunca Foi o CICS... Mas um Gargalo Escondido nas Sombras

"Naquela manhã chuvosa, os operadores juravam que o CICS estava lento. O gerente culpava o banco de dados. O DBA apontava para a CPU. O pessoal de infraestrutura acusava o storage. O Sysprog olhava silenciosamente para os gráficos do RMF. E, em algum lugar escondido entre milhões de linhas de COBOL, um único SQL aguardava para ser descoberto..."

---

Prólogo – O Mistério da Lentidão

Se você perguntar para um programador COBOL iniciante:

"O que faz um sistema ficar lento?"

Provavelmente ouvirá:

"A CPU está cheia."

É uma resposta compreensível.

Mas quase sempre...

Está errada.

Uma das maiores lições que um profissional IBM Mainframe aprende ao longo da carreira é que lentidão é um sintoma, não um diagnóstico.

Performance Tuning é praticamente um trabalho de detetive.

Cada métrica é uma pista.

Cada relatório é um depoimento.

Cada gráfico conta uma parte da história.

E, como todo bom romance policial dos anos 1950, o culpado quase nunca é quem parecia ser no primeiro capítulo.

Hoje vamos abrir os arquivos confidenciais do CPD para investigar um dos casos mais fascinantes do universo CICS.

Prepare seu bloco de notas.

A investigação começou.

---

Capítulo 1 – O CICS é uma Cidade que Nunca Dorme

Imagine uma enorme cidade.

Milhões de pessoas entram e saem todos os dias.

Existem:

• bancos

• hospitais

• aeroportos

• repartições públicas

• supermercados

Tudo funcionando ao mesmo tempo.

Essa cidade chama-se CICS.

Cada cidadão é uma transação.

Cada rua representa um recurso do sistema.

Cada cruzamento é um ponto onde pode surgir congestionamento.

Enquanto você dorme...

Essa cidade continua trabalhando.

Ela processa:

• PIX

• cartões

• seguros

• folha de pagamento

• bolsas de valores

• companhias aéreas

• telecomunicações

Em alguns ambientes...

Mais de 100 milhões de transações por dia.

E tudo isso precisa acontecer em poucos milissegundos.

---

Capítulo 2 – O Relógio Nunca Mente

O primeiro suspeito sempre atende pelo nome de:

Response Time

Ele representa o tempo entre:

ENTER

↓

Processamento

↓

Resposta

Parece simples.

Mas esse número esconde dezenas de acontecimentos.

Enquanto o usuário observa apenas uma tela parada...

O CICS está fazendo centenas de operações invisíveis.

---

O Iceberg da Performance

O usuário vê apenas isto:

Resposta em 8 segundos

O analista enxerga:

CPU

↓

Dispatcher

↓

Storage

↓

Task

↓

DB2

↓

VSAM

↓

MQ

↓

TCP/IP

↓

Locks

↓

I/O

↓

Rede

↓

WLM

↓

Cache

↓

Buffers

↓

SMF

↓

RMF

Cada bloco acrescenta alguns milissegundos.

Somados...

Transformam-se em segundos.

---

Capítulo 3 – O Detetive Nunca Acusa Sem Evidências

Um erro clássico dos iniciantes é fazer isto:

"O sistema está lento."

Então começam a alterar parâmetros.

Isso é como trocar o motor do carro porque um pneu furou.

Os profissionais experientes seguem uma regra sagrada:

Nunca modifique aquilo que você ainda não mediu.

Primeiro mede.

Depois entende.

Só então modifica.

---

A Regra de Ouro do Performance Tuning

Existe um mantra repetido por analistas veteranos:

Measure

↓

Analyze

↓

Identify

↓

Optimize

↓

Validate

Ou em português:

Medir

↓

Analisar

↓

Identificar

↓

Otimizar

↓

Validar

Perceba que "otimizar" aparece apenas no quarto passo.

Muitos iniciantes começam justamente por ele.

---

Capítulo 4 – O Julgamento da CPU

Sempre que algo fica lento...

Alguém diz:

"A CPU está em 95%."

Fim da discussão.

Mas espere.

CPU alta significa culpa?

Não.

CPU alta pode ser consequência.

Imagine um caixa eletrônico tentando consultar um cliente.

O SQL demora.

Enquanto espera...

A CPU continua trabalhando em outras tarefas.

Quando finalmente recebe os dados...

Executa um enorme processamento COBOL.

Resultado:

CPU sobe.

Mas ela não foi o problema inicial.

Ela apenas trabalhou mais porque outra peça atrasou todo o restante.

---

Curiosidade Noir

Os analistas antigos costumavam dizer:

"CPU é como febre. Ela mostra que existe um problema, mas quase nunca diz qual."

---

Capítulo 5 – O Sombrio Reino do Db2

Se existe um lugar onde muitos mistérios começam...

É o banco de dados.

Um SQL aparentemente inocente pode esconder um verdadeiro desastre.

Veja:

SELECT *
FROM CLIENTES

Parece simples.

Mas imagine uma tabela com:

120 milhões de registros.

Sem índice.

O Db2 inicia um Table Space Scan.

Milhões de páginas são lidas.

Buffers começam a encher.

Discos trabalham.

CPU cresce.

O usuário espera.

E o gerente conclui:

"CICS está lento."

Na verdade...

Era apenas um SQL mal escrito.

---

O EXPLAIN é a Lupa de Sherlock Holmes

Nenhum DBA sério trabalha sem EXPLAIN.

Ele responde perguntas como:

• Qual índice será utilizado?

• Haverá Table Scan?

• Quantos registros serão lidos?

• Qual Join será escolhido?

• Quantas páginas serão acessadas?

É literalmente a autópsia do SQL antes da execução.

---

Easter Egg nº 1

Se você encontrar um programa COBOL com:

SELECT *

Sem WHERE...

Você acabou de descobrir o equivalente mainframe de deixar a porta da geladeira aberta o dia inteiro.

---

Capítulo 6 – Os Arquivos VSAM Também Contam Segredos

Muito antes do Db2 dominar os grandes sistemas...

O VSAM já guardava milhões de registros.

E continua fazendo isso.

Os tipos mais comuns:

• KSDS

• ESDS

• RRDS

• LDS

Cada um possui comportamento diferente.

Um KSDS muito fragmentado pode sofrer:

• CI Split

• CA Split

Resultado?

Mais I/O.

Mais espera.

Mais tempo de resposta.

---

O Mistério dos Buffers

Imagine procurar um livro.

Você pode:

Ir até a biblioteca toda vez.

Ou deixá-lo sobre a mesa.

Os buffers fazem exatamente isso.

Quanto melhores os buffers...

Menos viagens ao disco.

Mais velocidade.

---

Capítulo 7 – A Memória Invisível

Poucos iniciantes estudam Storage.

Mas deveriam.

No CICS existem áreas famosas:

• DSA

• EDSA

• CDSA

• UDSA

• SDSA

Quando alguma delas fica cheia...

Começam acontecimentos estranhos.

Transações recusadas.

Lentidão.

Abends.

Filas.

Até surgir uma sigla temida:

SOS

Short On Storage.

Veteranos arrepiam só de ouvir esse nome.

---

Easter Egg nº 2

No universo CICS, "SOS" não significa "Save Our Souls".

Significa:

"Prepare o café... hoje ninguém vai embora cedo."

---

Capítulo 8 – O Engarrafamento Invisível

Nem toda lentidão significa problema técnico.

Imagine um banco às 10 horas da manhã.

Milhares de clientes.

Todos chegam ao mesmo tempo.

Os caixas são limitados.

Forma-se uma fila.

No CICS acontece igual.

500 usuários

↓

1000 transações

↓

200 Tasks disponíveis

As demais esperam.

Não existe erro.

Existe congestionamento.

Esse fenômeno chama-se:

Transaction Queuing.

---

Capítulo 9 – Throughput: O Herói Esquecido

Todo mundo fala em velocidade.

Poucos falam em capacidade.

Imagine dois carros.

Primeiro:

200 km/h

Transporta 2 pessoas.

Segundo:

80 km/h

Transporta 70 passageiros.

Qual leva mais gente?

O segundo.

O mesmo vale para o Mainframe.

Às vezes uma transação demora um pouco mais.

Mas o sistema atende milhares simultaneamente.

Isso é Throughput.

---

Capítulo 10 – Os Relatórios Nunca Mentem

Quando surge um incidente...

Entram em cena os investigadores.

Cada ferramenta possui uma especialidade.

SMF

É o diário secreto do z/OS.

Tudo fica registrado.

Cada evento.

Cada consumo.

Cada erro.

---

RMF

É o cardiologista do sistema.

Mede:

CPU

Disco

Canal

Memória

LPAR

WLM

---

CICS Performance Analyzer

Mostra tendências.

Permite descobrir:

Quando começou a degradação?

Ela piora em determinados horários?

Existe sazonalidade?

---

Db2 Performance Monitor

Mostra:

Locks.

Buffer Pools.

Getpages.

Elapsed.

CPU.

SQL.

É praticamente uma câmera de segurança do banco de dados.

---

O Método CSI Mainframe

Imagine uma investigação.

A transação SALD demora oito segundos.

O analista segue o roteiro:

Cena do crime.

↓

Coleta evidências.

↓

Analisa SMF.

↓

Consulta RMF.

↓

Verifica WLM.

↓

Observa CPU.

↓

Analisa SQL.

↓

Examina VSAM.

↓

Confere Storage.

↓

Encontra o gargalo.

Nenhuma hipótese é descartada sem provas.

---

Curiosidade Histórica

Na década de 1980 muitos problemas eram resolvidos observando apenas consoles, dumps impressos e enormes relatórios em papel contínuo.

Era comum encontrar analistas caminhando pelos corredores carregando pilhas de listagens maiores do que uma mesa de escritório.

Hoje usamos dashboards sofisticados.

Mas o raciocínio investigativo continua exatamente o mesmo.

---

Passo a Passo para Investigar uma Transação Lenta

Se amanhã você entrar em uma equipe de suporte CICS e ouvir:

"A transação CONSULTA demorou oito segundos."

Siga este roteiro:

1. Descubra quando o problema começou.

2. Compare com dias anteriores.

3. Consulte os relatórios SMF.

4. Verifique o RMF.

5. Analise a utilização da CPU.

6. Verifique o WLM.

7. Procure espera por recursos.

8. Analise SQL com EXPLAIN.

9. Verifique buffers do Db2.

10. Analise VSAM.

11. Procure contenção.

12. Verifique Storage.

13. Confira MXT e filas.

14. Compare com a baseline.

15. Só depois faça alterações.

Essa sequência evita mudanças precipitadas e aumenta muito a chance de encontrar a causa raiz.

---

Dicas para um Programador COBOL Iniciante

• Aprenda SQL antes de tentar otimizar COBOL.

• Entenda o funcionamento de índices Db2.

• Estude VSAM e seus padrões de acesso.

• Conheça as principais áreas de storage do CICS.

• Aprenda a ler relatórios SMF e RMF.

• Familiarize-se com conceitos de WLM e Dispatching.

• Nunca presuma que CPU alta é a causa do problema.

• Documente cada alteração realizada em produção.

• Crie o hábito de comparar métricas antes e depois de qualquer mudança.

• Pense sempre no sistema como um conjunto integrado, e não como componentes isolados.

---

Curiosidades que Impressionam em Entrevistas

• Uma redução de apenas 5 milissegundos em uma transação executada milhões de vezes ao dia pode economizar horas de CPU ao longo do mês.

• Em muitos ambientes corporativos, mais de 90% das reclamações de lentidão acabam tendo origem fora do código COBOL, envolvendo SQL, configuração, infraestrutura ou contenção de recursos.

• O CICS foi projetado para operar continuamente, processando cargas enormes com alta disponibilidade, o que explica sua presença em bancos, seguradoras, companhias aéreas e órgãos governamentais há décadas.

---

O Último Suspeito

Quando toda investigação termina...

Os novatos perguntam:

"Então qual era o culpado?"

A resposta dos veteranos costuma ser a mesma.

"Depende."

Porque o verdadeiro segredo do Performance Tuning nunca foi decorar comandos.

Nem decorar parâmetros.

Nem decorar tabelas.

O verdadeiro segredo é aprender a pensar como um investigador.

Cada métrica conta uma história.

Cada relatório revela uma pista.

Cada gráfico esconde um detalhe.

Cada segundo perdido possui uma explicação.

E quando você finalmente domina essa arte, deixa de ser apenas um programador COBOL.

Torna-se um detetive do desempenho, capaz de seguir rastros invisíveis entre milhões de instruções, atravessar as sombras do CICS e revelar o culpado que ninguém mais conseguia enxergar.

Na próxima vez que alguém disser, com toda a convicção, "o CICS está lento", sorria discretamente, pegue sua lupa imaginária e lembre-se da maior lição desta investigação:

No Mainframe, o gargalo raramente está onde todos estão olhando. O verdadeiro mistério está escondido entre as métricas — esperando por alguém paciente o suficiente para conectar todas as pistas.