☕ 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

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

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. ☕🌑💻

Translate

segunda-feira, 24 de junho de 2024