☕ Um Café no Bellacosa Mainframe
🌑 IT Key Risk Indicators — Antes do ABEND, sempre existe um sinal
Sob a batuta de Riddick: no escuro do datacenter, sobreviver não depende de enxergar tudo. Depende de perceber aquilo que os outros ainda não conseguem ver.
Existe uma cena recorrente em praticamente toda operação de TI.
03:17 da madrugada.
O telefone toca.
O monitor começa a piscar.
O grupo de mensagens acorda.
Alguém escreve:
PRODUÇÃO FORA.
Outro pergunta:
O que mudou?
Um terceiro responde:
Nada.
E essa talvez seja uma das respostas mais assustadoras que podem aparecer durante um incidente.
Porque alguma coisa mudou.
Talvez não às 03:17.
Talvez tenha começado três meses antes.
Um patch foi adiado.
Uma configuração temporária tornou-se permanente.
Um ticket envelheceu.
Depois outro.
Uma mudança emergencial foi aprovada.
Um deployment falhou.
Um backup apresentou erro.
Um teste de recuperação foi postergado.
A latência começou a aumentar discretamente.
Separadamente, nenhuma dessas coisas parecia suficiente para abrir uma War Room.
Juntas, estavam contando uma história.
Só que ninguém estava ouvindo.
É aqui que entram os Key Risk Indicators — KRIs.
E para conversar sobre sinais escondidos, ambientes hostis, sobrevivência e a capacidade de enxergar aquilo que os demais ignoram, hoje nosso tutor não será Poirot, Sherlock Holmes ou Jack Bauer.
Apaguem as luzes do datacenter.
Nosso guia será Riddick.
🌑 1. Riddick não precisa que alguém acenda a luz
Em Pitch Black, existe uma vantagem fundamental que transforma Riddick em alguém especialmente perigoso quando todos os outros ficam vulneráveis:
ele consegue operar no escuro.
Essa é uma excelente metáfora para Risk Management.
Quando tudo está verde, qualquer um consegue dizer:
SYSTEM STATUS = OK
CPU normal.
CICS funcionando.
Db2 funcionando.
MQ funcionando.
Rede funcionando.
Jobs terminando.
Dashboard verde.
Executivos tranquilos.
Café quente.
O problema é perceber alguma coisa quando ainda não existe uma falha evidente.
Um bom KRI tenta justamente aumentar nossa capacidade de enxergar nesse escuro operacional.
Ele não precisa dizer:
INCIDENT = TRUE
Pode dizer:
RISK EXPOSURE = INCREASING
E essa diferença é gigantesca.
📊 2. Primeiro: KRI não é simplesmente uma métrica
Quem está começando em COBOL, mainframe ou operações pode encontrar centenas de números durante um único dia.
CPU.
Storage.
I/O.
Transactions per second.
Response time.
Fila.
Número de jobs.
ABENDs.
Tickets.
Disponibilidade.
Quantidade de mudanças.
Tudo isso pode ser medido.
Mas nem toda métrica é automaticamente um KRI.
Considere:
FAILED DEPLOYMENTS = 4
Temos um número.
Agora:
TOTAL DEPLOYMENTS = 100
FAILED DEPLOYMENTS = 4
FAILURE RATE = 4%
Temos um indicador melhor.
Mas falta contexto.
Historicamente:
JAN = 0.7%
FEV = 0.9%
MAR = 1.2%
ABR = 2.1%
MAI = 3.0%
JUN = 4.0%
O valor atual ganhou uma característica importantíssima:
tendência.
Agora descobrimos que o limite de tolerância definido pela organização é 3%.
CURRENT = 4.0%
THRESHOLD = 3.0%
TREND = UP
E sabemos quem responde por isso:
OWNER = APPLICATION DELIVERY
Finalmente existe uma ação prevista:
IF FAILURE_RATE > 3%
PERFORM ROOT_CAUSE_ANALYSIS
REVIEW RELEASE_PIPELINE
ESCALATE TO OWNER
END-IF
Agora começamos a ter algo parecido com um verdadeiro KRI.
💻 3. Pensando como um programador COBOL
Vamos traduzir isso para uma lógica extremamente simples.
IF WS-CURRENT-RISK > WS-RISK-LIMIT
MOVE 'ACTION' TO WS-RISK-STATUS
ELSE
MOVE 'NORMAL' TO WS-RISK-STATUS
END-IF.
Parece fácil.
Mas a realidade é mais interessante.
Talvez tenhamos:
EVALUATE TRUE
WHEN WS-CURRENT-RISK >= WS-CRITICAL-LIMIT
MOVE 'CRITICAL' TO WS-RISK-STATUS
WHEN WS-CURRENT-RISK >= WS-ACTION-LIMIT
MOVE 'ACTION' TO WS-RISK-STATUS
WHEN WS-CURRENT-RISK >= WS-WARNING-LIMIT
MOVE 'WATCH' TO WS-RISK-STATUS
WHEN OTHER
MOVE 'NORMAL' TO WS-RISK-STATUS
END-EVALUATE.
Agora nosso KRI ganhou quatro estados:
NORMAL
↓
WATCH
↓
ACTION
↓
CRITICAL
Isso é muito mais útil do que simplesmente:
VERDE
VERMELHO
Porque o objetivo de Risk Management é justamente atuar antes de chegar ao vermelho.
Riddick não espera a criatura estar mordendo seu pescoço para concluir que talvez exista algum risco naquele planeta.
🧭 4. Technology Strategy & Oversight — alguns monstros demoram anos para aparecer
O primeiro domínio do infográfico apresenta:
IT Strategy Alignment Gap
Technology Decision Delay
IT Portfolio Overrun Rate
Essa seção é importante porque destrói uma ideia comum:
risco de TI é problema técnico.
Não necessariamente.
Imagine um sistema funcionando perfeitamente.
Só existe um pequeno detalhe.
Ele precisa ser modernizado.
Ano 1:
MODERNIZATION = POSTPONED
Ano 2:
MODERNIZATION = POSTPONED
Ano 3:
MODERNIZATION = POSTPONED
Nada caiu.
Então alguém conclui:
Viu? Não precisava mexer.
Só que durante esses três anos:
Specialists available ↓
Technical documentation ↓
Vendor support remaining ↓
Maintenance cost ↑
Dependencies ↑
Security exposure ↑
Operational complexity ↑
O sistema não necessariamente piorou.
A exposição ao risco piorou.
Technology Decision Delay consegue ajudar a revelar justamente esse tipo de situação.
🎫 5. Ticket Backlog Aging — os esqueletos dentro da caverna
Agora entramos em Service Management:
Major Incident Volume
SLA Breach Rate
Ticket Backlog Aging
Contar tickets é útil.
Mas considere:
Sistema A
TICKETS = 1.000
AVERAGE AGE = 3 DAYS
Sistema B
TICKETS = 300
AVERAGE AGE = 74 DAYS
Qual deles é mais perigoso?
Não temos informação suficiente para responder.
Mas o segundo desperta imediatamente minha curiosidade.
Por que esses tickets permanecem abertos?
São irrelevantes?
Não existe equipe?
Não existe solução?
Existe dependência externa?
Ou pior:
a organização simplesmente se acostumou com os problemas?
Essa última hipótese é perigosíssima.
Quando ouvimos:
Isso acontece de vez em quando.
Riddick provavelmente já estaria olhando para o teto.
Porque alguma coisa está andando lá em cima.
🖥️ 6. Capacity Threshold — CPU a 95% não significa Armageddon
O infográfico apresenta:
Critical Infrastructure Downtime
Capacity Threshold Breach Rate
Network Latency Exception Rate
Aqui precisamos tomar muito cuidado com números isolados.
Imagine:
CPU = 95%
Alguém vê isso no monitor e grita:
SOCORRO!
Não necessariamente.
Especialmente no universo IBM Z, precisamos perguntar:
Qual LPAR?
Qual workload?
Quanto tempo?
Qual horário?
Qual prioridade?
Existe degradação?
Existe fila?
Qual objetivo de serviço?
O WLM está cumprindo as metas?
Esse comportamento é esperado?
Uma máquina trabalhando intensamente não significa necessariamente uma máquina com problemas.
É como encontrar Riddick correndo.
Talvez esteja fugindo.
Talvez esteja perseguindo alguma coisa.
O número sozinho não conta a história.
🚨 7. Threshold sem contexto cria Alert Fatigue
Existe outro perigo.
Configure alarmes para absolutamente tudo.
CPU > 70% ALERT
CPU > 75% ALERT
QUEUE > 10 ALERT
DISK > 60% ALERT
LATENCY > X ALERT
MEMORY > Y ALERT
Logo teremos:
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
ALERT
O cérebro humano faz aquilo que sempre faz quando é bombardeado continuamente pela mesma informação:
começa a ignorá-la.
Isso é alert fatigue.
Quando tudo parece urgente, nada parece urgente.
O verdadeiro desafio não é gerar sinais.
É gerar sinais relevantes.
☁️ 8. Cloud — criar alguma coisa ficou assustadoramente fácil
Na seção Cloud & Platform Operations encontramos:
Uncontrolled Cloud Resource Growth
Cloud Cost Variance Rate
Platform Configuration Drift
Cloud trouxe uma transformação maravilhosa.
Provisionamento que antigamente poderia exigir dias ou semanas agora pode acontecer em minutos.
CLICK
CLICK
CLICK
RESOURCE CREATED
Fantástico.
Agora avance seis meses.
Alguém encontra aquele recurso.
RESOURCE-ID: X92827
OWNER: ?
PURPOSE: ?
DATA: ?
EXPIRATION: ?
BUSINESS SERVICE: ?
Pergunta:
Quem criou isso?
Resposta:
Roberto.
Chama o Roberto.
Roberto saiu da empresa em fevereiro.
Temos então um pequeno animal vivendo tranquilamente no escuro.
Ele ainda não mordeu ninguém.
Mas existe.
🧬 9. Configuration Drift — "não mexe porque funciona"
Este é um dos meus favoritos.
Temos um baseline:
SERVER CONFIGURATION 1.0
Todos começam iguais.
Depois ocorre uma emergência.
Servidor C recebe uma pequena alteração.
Depois Servidor D.
Depois alguém aplica uma correção temporária no E.
Depois uma mudança manual acontece no F.
Um ano depois:
SERVER-A = STANDARD
SERVER-B = STANDARD
SERVER-C = ALMOST STANDARD
SERVER-D = CUSTOM
SERVER-E = LEGACY
SERVER-F = DON'T TOUCH
😂
E quando perguntamos por quê:
Não mexe porque funciona.
Essa frase merece atenção.
Configuration Drift mede a distância entre:
como acreditamos que o ambiente esteja
e
como ele realmente está.
Essa distância é território perfeito para risco operacional.
🚀 10. Emergency Change Rate — emergência não pode virar processo
Applications & Change apresenta:
Emergency Change Rate
Failed Deployment Rate
Application Defect Leakage
Uma emergência eventualmente acontecerá.
O problema começa quando:
EMERGENCY CHANGE
deixa de significar exceção e passa a significar:
NOSSO PROCESSO NORMAL
Imagine:
JAN 4%
FEB 5%
MAR 8%
APR 13%
MAY 21%
JUN 32%
Não tivemos necessariamente um grande incidente.
Mas alguma coisa mudou profundamente na organização.
Talvez os prazos estejam ruins.
Talvez os testes tenham sido comprimidos.
Talvez exista dívida técnica.
Talvez releases estejam chegando sem planejamento.
O KRI não responde necessariamente por quê.
Ele diz:
Riddick, tem alguma coisa se mexendo naquela direção.
Agora investigue.
🔗 11. O segredo verdadeiro está na correlação
Imagine observarmos:
Emergency Change Rate ↑
Failed Deployment Rate ↑
Ticket Backlog Aging ↑
Configuration Drift ↑
Patch Aging Exposure ↑
Separadamente são cinco indicadores.
Juntos podem representar uma história:
PRESSÃO OPERACIONAL
↓
MAIS ATALHOS
↓
MAIS MUDANÇAS EMERGENCIAIS
↓
MAIS FALHAS
↓
MAIS TICKETS
↓
MENOS TEMPO PARA CORREÇÃO
↓
MAIS DÍVIDA
↓
MAIOR EXPOSIÇÃO
Agora ficamos realmente interessados.
O melhor sinal pode não ser um KRI. Pode ser a combinação de vários KRIs.
🗄️ 12. Data & Integration — tudo pode estar UP e o negócio DOWN
O infográfico mostra:
Data Pipeline Failure Rate
Integration Error Volume
Data Availability Breach Rate
Imagine uma arquitetura:
MOBILE
│
▼
API
│
▼
z/OS Connect
│
▼
CICS
│
▼
MQ
│
▼
COBOL
│
▼
Db2
Nos dashboards:
NETWORK UP
CICS UP
MQ UP
DB2 UP
Z/OS UP
Cliente:
Não consigo concluir a operação.
Temos então uma diferença fundamental entre:
component availability
e
business service availability.
O cliente não compra CICS.
Não compra MQ.
Não compra Db2.
Ele compra uma capacidade de negócio.
Se essa capacidade não funciona, pouco importa que seis dashboards estejam verdes.
👻 13. Unmanaged Asset Ratio — o servidor fantasma
Agora chegamos aos ativos:
Unmanaged Asset Ratio
Patch Aging Exposure
CMDB Accuracy Gap
Pergunta aparentemente simples:
Quantos servidores temos?
Resposta da CMDB:
4.821
Scanner:
5.137
Cloud:
5.028
Security:
4.934
Financeiro:
5.316
Ops.
Temos um problema.
Porque existe uma máxima brutalmente simples:
Você não consegue gerenciar adequadamente aquilo que não sabe que existe.
O servidor desconhecido talvez esteja funcionando perfeitamente.
Isso não significa ausência de risco.
Significa ausência de visibilidade.
Riddick provavelmente chamaria isso de alguma coisa respirando no escuro.
🩹 14. Patch Aging — não conte apenas patches
Patch Aging Exposure é mais interessante do que simplesmente:
PATCHES MISSING = 187
Precisamos saber:
idade
criticidade
sistema
exposição
vulnerabilidade
business impact
owner
Um patch crítico atrasado 180 dias num servidor exposto pode ser muito mais relevante do que cinquenta atualizações pequenas atrasadas dois dias.
Novamente:
contexto transforma números em informação.
💾 15. Backup verde não significa recuperação garantida
Chegamos a Continuity & Recovery:
Backup Failure Rate
Recovery Test Failure Rate
Service Restoration Delay
Aqui está uma das minhas frases favoritas:
Backup não existe para fazer backup.
Backup existe para restaurar.
Parece piada.
Não é.
Imagine:
BACKUP SUCCESS RATE = 99.98%
Champanhe!
Agora:
Restaure o ambiente.
Silêncio.
O job:
RC=0000
não prova necessariamente que o negócio conseguirá recuperar aquilo que necessita dentro dos objetivos esperados.
É por isso que Recovery Test Failure Rate merece enorme atenção executiva.
⏱️ 16. RTO e RPO entram na caverna
Dois conceitos precisam aparecer aqui.
RPO — Recovery Point Objective
Quanto de informação podemos perder?
Exemplo:
RPO = 15 MINUTES
RTO — Recovery Time Objective
Quanto tempo podemos ficar sem o serviço?
RTO = 2 HOURS
Agora imagine:
RTO acordado = 2 horas
Recovery test = 7 horas
O backup funcionou.
O teste funcionou.
Mesmo assim:
o objetivo falhou.
Essa é uma diferença extremamente importante.
🎯 17. Qual KRI merece mais atenção executiva?
A publicação original termina perguntando isso.
Eu responderia:
depende do negócio e do risco.
Mas se alguém colocasse uma arma fictícia na mesa da War Room e me obrigasse a escolher um dos apresentados, eu olharia com enorme atenção para:
Recovery Test Failure Rate.
Porque descobrir durante um desastre que a última camada de recuperação não funciona é especialmente cruel.
Mas ainda prefiro observar um conjunto:
UNMANAGED ASSETS ↑
PATCH AGING ↑
CONFIGURATION DRIFT ↑
EMERGENCY CHANGES ↑
FAILED DEPLOYMENTS ↑
RECOVERY TEST FAILURES ↑
Isso pode revelar algo maior:
perda progressiva de controle operacional.
Esse é o monstro que realmente me interessa.
👔 18. O executivo não precisa aprender JCL
Imagine apresentar ao board:
IEF450I PAYROLL STEP030
ABEND=S0C4
Silêncio.
Talvez alguém pergunte:
Isso é ruim?
😂
Não devemos exigir que o executivo traduza detalhes operacionais.
Nosso trabalho é transformar isso em risco compreensível:
TECHNICAL EVENT
↓
SERVICE IMPACT
↓
BUSINESS IMPACT
↓
FINANCIAL / REGULATORY EXPOSURE
↓
DECISION
O executivo precisa entender:
impacto, tendência, exposição, owner, decisão necessária e prazo.
Essa é a verdadeira tradução.
🚦 19. Meu dashboard não teria apenas verde e vermelho
Eu faria algo assim:
KRI VALUE TREND LIMIT STATUS
Patch Aging 17% ↑ 15% ACTION
Emergency Change 12% ↑ 10% ACTION
Failed Deployment 4% → 5% WATCH
Recovery Failure 1% ↓ 2% NORMAL
Ticket Aging 27d ↑ 20d CRITICAL
E acrescentaria:
OWNER
BUSINESS IMPACT
ACTION
DUE DATE
Porque um quadrado vermelho sem responsável é decoração corporativa.
🤖 20. E então entra IA, AIOps e análise preditiva
Agora a coisa fica realmente interessante.
Imagine armazenarmos anos de histórico.
A IA encontra repetidamente:
Ticket Aging ↑
+
Emergency Change ↑
+
Failed Deployment ↑
+
Latency Exception ↑
e descobre que essa combinação frequentemente antecedeu Major Incidents.
Na próxima vez que o padrão surgir, ainda não existe incidente.
Mas podemos gerar:
RISK PATTERN DETECTED
Não estamos prevendo o futuro magicamente.
Estamos dizendo:
A situação atual se parece significativamente com situações anteriores que terminaram mal.
Isso é extremamente poderoso.
Passamos de:
MONITOR
↓
ALERT
↓
INCIDENT
para:
MONITOR
↓
CORRELATE
↓
DETECT PATTERN
↓
ASSESS RISK
↓
INTERVENE
↓
PREVENT
Esse é o caminho de uma operação cada vez mais inteligente.
🥚 Easter egg — o monstro nunca apareceu às 03:17
Agora apague novamente as luzes.
03:17:04
P1 INCIDENT DECLARED
Todo mundo acredita que o problema começou ali.
Riddick volta alguns passos.
90 dias antes
PATCH DEFERRED
63 dias antes
TICKET OPENED
48 dias antes
CONFIGURATION CHANGED
31 dias antes
DEPLOYMENT FAILED
17 dias antes
EMERGENCY CHANGE
8 dias antes
LATENCY EXCEPTION
3 dias antes
BACKUP WARNING
03:17
SERVICE DOWN
O incidente não nasceu às 03:17.
Às 03:17 ele apenas saiu do escuro.
E essa talvez seja a melhor maneira de explicar KRI para alguém começando no universo COBOL, z/OS ou operações.
O operador vê:
ABEND
O analista pergunta:
WHAT HAPPENED?
O investigador pergunta:
WHAT HAPPENED BEFORE THAT?
O profissional de Risk Management pergunta algo ainda melhor:
WHAT WAS ALREADY CHANGING
BEFORE ANYTHING FAILED?
É aí que deixamos de simplesmente apagar incêndios.
Começamos a procurar fumaça.
Depois calor.
Depois padrões.
Depois condições que tornam o incêndio provável.
No universo de Riddick, sobreviver no escuro exige perceber movimentos antes que as criaturas estejam sobre você.
No universo de TI acontece algo muito parecido.
Major Incident Volume mostra quantos monstros chegaram até você.
KRI tenta mostrar onde eles estão se movimentando.
E quando alguém disser:
"Mas ainda não aconteceu nada..."
talvez essa seja justamente a melhor hora para investigar.
Porque às 03:17, meu caro programador COBOL, a aula acabou.
A partir dali é produção.
E produção não perdoa quem só aprendeu a enxergar depois que acenderam a luz vermelha. ☕🌑💻
