Bellacosa Mainframe e os incidentesque derrubam o sistema

☕ Um Café no Bellacosa Mainframe

⚔️ LISBETH E A FORJA DOS 50 INCIDENTES — QUANDO O COBOL DESCOBRIU QUE PRODUÇÃO NÃO CAI, ELA DEIXA PISTAS

Linux, CPU, memória, storage, DNS, firewall, load balancer, cloud, Docker, Kubernetes, Terraform, Db2, CICS, WLM, SMF, RMF — e o dia em que Lisbeth descobriu que reiniciar o servidor não era troubleshooting, era bater na espada com um martelo e torcer para ela ficar reta.

---

🎬 PRÓLOGO — BEM-VINDO À FORJA, PROGRAMADOR COBOL

Imagine a cena.

Você acabou de entrar na equipe de desenvolvimento mainframe. Aprendeu um pouco de COBOL, descobriu que PIC X(10) não é uma fotografia com dez pixels, conseguiu sobreviver ao primeiro JCL e já sabe que apagar uma linha de //DD aleatoriamente porque “parecia não servir para nada” pode ser uma maneira bastante eficiente de conhecer pessoalmente o pessoal da Produção.

São 03:17 da madrugada.

Sim, padawan. Esse horário ainda vai aparecer novamente.

Seu telefone toca.

— Produção está fora!

Você pergunta:

— O que caiu?

A resposta:

— Tudo!

Pronto.

Você acaba de conhecer uma das mensagens de erro menos úteis da história da computação.

Em Aincrad, provavelmente alguém gritaria que um boss apareceu no andar. No nosso mundo, “tudo caiu” pode significar desde um servidor realmente indisponível até uma única transação CICS respondendo em oito segundos.

É nesse momento que entra nossa tutora:

Lisbeth — Rika Shinozaki, de Sword Art Online.

E não escolhi Lisbeth por acaso.

Kirito pode chegar com aquela cara de protagonista e querer resolver tudo no braço, mas Lisbeth trabalha de outra maneira. Antes de fabricar uma arma, ela precisa entender material, resistência, objetivo, comportamento e condições de uso.

Troubleshooting profissional funciona exatamente assim.

Você não olha para uma espada quebrada e começa a martelar.

E não olha para uma aplicação quebrada e começa a reiniciar coisas.

Primeiro observe. Depois obtenha evidências. Só então altere o ambiente.

Bem-vindo à forja.

---

🔥 CAPÍTULO 1 — “O SISTEMA CAIU” NÃO É UM DIAGNÓSTICO

A primeira coisa que precisamos destruir é uma ideia muito comum entre iniciantes:

outage não significa necessariamente que o computador desligou.

Existem pelo menos dois cenários fundamentais.

Full Outage

O serviço realmente está indisponível:

USUÁRIO
   |
   X
SERVIÇO

Ninguém consegue utilizá-lo.

Agora temos o segundo cenário.

Partial Degradation

USUÁRIO
   |
   +---- transação A → 0,3 segundo
   +---- transação B → 0,4 segundo
   +---- transação C → 9 segundos
   +---- transação D → TIMEOUT
   +---- transação E → 0,5 segundo

O serviço tecnicamente continua funcionando.

Mas tente explicar isso ao cliente cuja compra ficou parada durante nove segundos.

No mainframe podemos ter:

z/OS       UP
CICS       UP
Db2        UP
MQ         UP
TCP/IP     UP
JES2       UP

E mesmo assim:

Response Time ↑
Db2 Lock Wait ↑
MQ Queue Depth ↑
CPU ↑
Timeouts ↑

Tudo está UP.

E tudo está ruim.

Essa distinção é fundamental porque estado operacional e qualidade do serviço são coisas diferentes.

Lisbeth provavelmente diria:

“A espada continua inteira. Isso não significa que ainda esteja boa para lutar.”

---

💥 CAPÍTULO 2 — BLAST RADIUS: O RATO PEQUENO QUE DERRUBOU O CASTELO

Outro conceito importantíssimo é blast radius: a extensão do impacto causado por uma falha.

Imagine:

                    DNS
                     |
        +------------+------------+
        |            |            |
     SISTEMA A    SISTEMA B    SISTEMA C
        |            |            |
       Db2           MQ          API

DNS parece apenas um componente.

Mas dezenas ou centenas de serviços podem depender dele.

Se ele falha, aparentemente temos:

Sistema A caiu
Sistema B caiu
Sistema C caiu
API caiu
MQ não conecta
Aplicação web caiu

O iniciante enxerga seis incidentes.

O engenheiro experiente pergunta:

O que todos os afetados têm em comum?

Essa talvez seja uma das perguntas mais poderosas de um War Room.

No mainframe, pense em RACF.

Uma alteração incorreta pode atingir:

            RACF
              |
     +--------+--------+
     |        |        |
    CICS     MQ       Batch
     |        |        |
    Db2      API      Dataset

Você pode passar duas horas investigando CICS, Db2 e MQ separadamente.

Ou descobrir em dez minutos que todos começaram a apresentar problemas depois de uma mudança de autorização.

O tamanho da alteração não determina o tamanho do desastre.

Uma linha pode derrubar uma arquitetura inteira.

---

🔎 CAPÍTULO 3 — LISBETH ENSINA O MÉTODO CIENTÍFICO DO WAR ROOM

A coleção de incidentes apresentada nesta conversa possui um tesouro escondido:

OBSERVE
   ↓
EVIDENCE
   ↓
HYPOTHESIS
   ↓
TEST
   ↓
FIX
   ↓
VERIFY

Eu acrescentaria:

LEARN
   ↓
PREVENT

Esse fluxo separa troubleshooting de superstição tecnológica.

O método ruim é:

Aplicação lenta
      ↓
RESTART
      ↓
Voltou?

O clássico:

“Reinicia para ver.”

Às vezes funciona.

E justamente por funcionar ocasionalmente tornou-se um dos hábitos mais perigosos da informática.

Imagine uma região CICS apresentando degradação porque existe contenção em determinado recurso.

Alguém faz recycle.

O problema desaparece.

Todos comemoram.

Mas também desapareceram parte das condições que permitiriam entender o incidente.

Quatro dias depois:

03:17.

Telefone toca.

— Caiu novamente.

Parabéns.

Você não resolveu o incidente anterior.

Apenas zerou o tabuleiro.

---

🧭 CAPÍTULO 4 — AS QUATRO PERGUNTAS DE LISBETH

Antes de tocar no ambiente, acrescente quatro dimensões:

TIME
CHANGE
SCOPE
CORRELATION

TIME — quando começou?

14:03?

Ontem?

Gradualmente?

Somente durante o batch?

CHANGE — o que mudou?

Deploy?

Configuração?

Firewall?

Certificado?

Carga?

SCOPE — quem está afetado?

Um usuário?

Todos?

Uma região?

Um CICS?

Uma LPAR?

Uma API?

CORRELATION — o que os afetados compartilham?

Db2?

MQ?

DNS?

Storage?

RACF?

Rede?

Essa combinação reduz brutalmente o universo de possibilidades.

---

🖥️ CAPÍTULO 5 — CPU EM 100% NÃO SIGNIFICA “COMPRE CPU”

Nos incidentes Linux, uma das primeiras situações é CPU Saturation.

Você encontra:

CPU = 99%

O iniciante conclui:

“Falta CPU.”

Calma.

CPU alta é uma evidência, não necessariamente a causa raiz.

Pode existir:

loop infinito
processo runaway
query problemática
retry storm
carga inesperada
job agendado
algoritmo ruim

No Linux, comandos como:

top
ps aux --sort=-%cpu
uptime

ajudam na investigação.

No mainframe mudamos as ferramentas:

RMF
SMF
WLM
SDSF

Mas mantemos a pergunta:

Quem está consumindo recurso e por quê?

Essa diferença é enorme.

Capacity Planning não é simplesmente olhar para CPU e comprar capacidade.

É entender comportamento do workload.

---

🧠 CAPÍTULO 6 — O OOM KILLER: QUANDO O SISTEMA OPERACIONAL EXECUTA O PRISIONEIRO

Agora memória.

Linux começa a ficar sem RAM.

Um processo desaparece.

A aplicação registra:

Process terminated

Você conclui:

“A aplicação crashou.”

Talvez não.

Ela pode ter sido vítima do OOM Killer — Out Of Memory Killer.

Simplificando:

RAM acaba
   ↓
kernel precisa sobreviver
   ↓
escolhe processo
   ↓
mata processo

Isso introduz uma distinção preciosa:

PROCESSO MORREU

não significa necessariamente:

PROCESSO SE MATOU

Ele pode ter sido morto externamente.

Esse raciocínio vale para qualquer investigação: sempre procure saber quem iniciou a ação observada.

---

💾 CAPÍTULO 7 — “NO SPACE LEFT” QUANDO AINDA EXISTE ESPAÇO

Aqui encontramos uma das curiosidades mais deliciosas da série.

Você executa:

df -h

e existe espaço.

Mesmo assim:

No space left on device

Como?

Inodes.

Um filesystem não precisa apenas de bytes para armazenar conteúdo. Ele também precisa manter estruturas que representam arquivos.

Portanto podemos ter:

ESPAÇO       55% utilizado
INODES      100% utilizados

Resultado:

não conseguimos criar novos arquivos.

Um milhão de pequenos arquivos pode esgotar inodes sem esgotar a capacidade em bytes.

Para o programador COBOL, existe uma bela lição conceitual aqui:

capacidade física não é necessariamente capacidade utilizável.

No z/OS, obviamente não estamos falando de inodes para datasets tradicionais, mas podemos encontrar outras restrições envolvendo:

PRIMARY
SECONDARY
EXTENTS
VOLUME
SMS
DATACLAS
STORCLAS
VTOC
CATALOG

Ter DASD disponível em algum lugar não garante que determinado dataset consiga crescer daquela maneira naquele momento.

---

🌐 CAPÍTULO 8 — “A REDE CAIU” É O PRIMO DO “PROGRAMA DEU ERRO”

Outro clássico.

Usuário não consegue acessar.

Conclusão instantânea:

“Rede.”

Não.

Construa a espada peça por peça:

DNS
 ↓
ROUTE
 ↓
FIREWALL
 ↓
PORT
 ↓
PROCESS
 ↓
APPLICATION

Pergunte:

Até onde funciona?

Essa mudança de pergunta é fantástica.

Em vez de investigar todo o universo, encontramos a fronteira entre:

FUNCIONA | NÃO FUNCIONA

---

📖 CAPÍTULO 9 — DNS: O CATÁLOGO TELEFÔNICO QUE TODO MUNDO ESQUECE ATÉ QUE QUEBRE

Você conhece:

api.bellacosa.com

A máquina precisa descobrir algo como:

192.0.2.123

Se a resolução falha, talvez o servidor esteja perfeitamente saudável.

Aplicação funcionando.

Banco funcionando.

Rede funcionando.

Mas o usuário não sabe para onde ir.

Ferramentas Linux incluem:

dig
nslookup

É por isso que problemas de DNS frequentemente parecem problemas de aplicação.

O sintoma aparece longe da causa.

---

🛣️ CAPÍTULO 10 — ROUTING: O CASTELO EXISTE, MAS NÃO EXISTE ESTRADA

Agora temos endereço.

Isso não significa que conseguimos chegar até ele.

SOURCE
   ↓
ROUTER A
   ↓
ROUTER B
   X
ROUTER C
   ↓
DESTINATION

Uma rota errada pode tornar um servidor perfeitamente saudável inacessível.

A lição:

existência não implica alcançabilidade.

Parece filosofia de boteco.

Mas também é engenharia de redes.

---

🔥 CAPÍTULO 11 — FIREWALL: EU SEI QUE VOCÊ EXISTE, MAS VOCÊ NÃO ENTRA

Agora:

DNS       OK
ROUTE     OK
HOST      OK
SERVICE   OK
FIREWALL  BLOCK

Do ponto de vista do servidor:

“Estou funcionando.”

Do ponto de vista do cliente:

“Está tudo morto.”

Essa diferença entre saúde interna e experiência externa é uma das maiores mensagens da coleção inteira.

Monitorar apenas componentes não basta.

Precisamos monitorar serviços.

---

🚪 CAPÍTULO 12 — REFUSED E TIMEOUT CONTAM HISTÓRIAS DIFERENTES

Três mensagens parecidas podem representar três mundos.

Address already in use

A aplicação tenta ocupar uma porta que já está sendo utilizada.

Connection refused

Você conseguiu chegar ao host, mas não encontrou um serviço aceitando a conexão como esperado.

Timeout

Você esperou e a conversa não terminou adequadamente.

Timeout pode envolver:

route
firewall
packet loss
load balancer
congestionamento
aplicação
dependência

E existe um detalhe delicioso:

o tempo do erro também é evidência.

Falha imediatamente?

Depois de 5 segundos?

Exatamente 30?

Sempre 60?

Um timeout extremamente regular pode apontar para configuração de algum componente intermediário.

Cronômetro também é ferramenta de diagnóstico.

---

⚖️ CAPÍTULO 13 — O LOAD BALANCER QUE DERRUBOU SERVIDORES SAUDÁVEIS

Imagine três aplicações:

APP1  OK
APP2  OK
APP3  OK

Load balancer executa:

GET /healthz

Mas o endpoint correto é:

GET /health

O resultado?

APP1 UNHEALTHY
APP2 UNHEALTHY
APP3 UNHEALTHY

O balanceador remove todas.

Temos então uma situação digna de Aincrad:

todos os servidores estão funcionando e o serviço está completamente indisponível.

Por quê?

Porque saúde física e saúde lógica são diferentes.

---

❤️ CAPÍTULO 14 — HEALTH CHECK TAMBÉM PODE SER PERIGOSO

Imagine um /health verificando:

aplicação
Db2
MQ
cache
DNS
API externa
serviço secundário

Uma API pouco importante cai.

Health check retorna FAIL.

Load balancer remove instância.

Todas as instâncias fazem igual.

Resultado:

dependência secundária falha
            ↓
health checks falham
            ↓
instâncias removidas
            ↓
OUTAGE TOTAL

Maravilhoso.

Criamos um mecanismo de alta disponibilidade capaz de aumentar a indisponibilidade.

Por isso health checks precisam ser cuidadosamente projetados.

---

☁️ CAPÍTULO 15 — “RUNNING” NÃO SIGNIFICA “FUNCIONANDO”

Uma VM aparece no console:

RUNNING

Isso não prova:

SSH OK
OS OK
PROCESS OK
APP OK
DATABASE OK
USER OK

Existem camadas:

Hardware
   ↓
Hypervisor
   ↓
VM
   ↓
Operating System
   ↓
Process
   ↓
Application
   ↓
Dependency
   ↓
Business Transaction

No mainframe:

CEC
 ↓
LPAR
 ↓
z/OS
 ↓
CICS
 ↓
Transaction
 ↓
Db2/MQ
 ↓
Business

CICS UP não significa transação saudável.

JOB ACTIVE não significa trabalho útil sendo realizado.

Guarde esta frase:

Estado não é progresso.

---

💽 CAPÍTULO 16 — STORAGE TEM PELO MENOS TRÊS MANEIRAS DE MACHUCAR VOCÊ

Storage pode apresentar problemas de:

CAPACITY
AVAILABILITY
PERFORMANCE

Um volume pode estar cheio.

Pode estar inacessível.

Ou pode estar disponível e absurdamente lento.

Esse terceiro caso engana muita gente.

Porque:

STORAGE = ONLINE

não significa:

STORAGE = PERFORMANDO BEM

Entram conceitos como:

IOPS, throughput e latency.

Dois workloads podem movimentar 10 GB e produzir comportamentos completamente diferentes.

Um pode ler grandes blocos sequencialmente.

Outro pode realizar milhões de pequenas operações aleatórias.

Mesmo volume.

Workloads completamente diferentes.

No universo IBM Z pense em:

DASD
I/O response time
cache
channels
EXCP
Db2 buffer pools
synchronous reads

Não pergunte apenas:

“Quanto temos?”

Pergunte também:

“Como estamos usando?”

---

🗄️ CAPÍTULO 17 — O BANCO FICOU SEM CONEXÕES

Suponha:

MAX CONNECTIONS = 500

A aplicação abre conexões e não libera adequadamente.

100
200
300
400
499
500

Chega a próxima:

💥

A solução rápida:

MAX CONNECTIONS = 1000

Pode aliviar.

Mas se existe vazamento:

500 → 1000 → 2000 → 4000

Você não corrigiu o problema.

Apenas comprou tempo.

Isso é equivalente a aumentar o balde enquanto alguém continua abrindo a torneira.

---

🌪️ CAPÍTULO 18 — RETRY STORM: QUANDO A RESILIÊNCIA ATACA O SISTEMA

Aqui existe uma consequência fascinante.

Banco fica lento.

Aplicação recebe timeout.

Programador implementou:

IF ERROR
   RETRY
END-IF

Parece sensato.

Até acontecer:

100 requests
    ↓
100 failures
    ↓
100 retries
    ↓
200 requests
    ↓
mais failures
    ↓
mais retries

O sistema debilitado recebe mais carga porque está debilitado.

Surge a retry storm.

Por isso arquiteturas resilientes empregam mecanismos como:

exponential backoff
jitter
circuit breaker
retry budget

Resiliência mal implementada pode produzir indisponibilidade.

---

🐳 CAPÍTULO 19 — DOCKER: PRIMEIRO DESCUBRA SE MORREU UM OU MORRERAM TODOS

Temos:

Container A FAIL
Container B OK
Container C OK

Suspeitamos de A.

Mas:

Container A FAIL
Container B FAIL
Container C FAIL
Container D FAIL

Pare de investigar cada aplicação individualmente.

Pergunte o que elas compartilham:

HOST
CPU
MEMORY
DISK
NETWORK
DNS
STORAGE

Isso é correlação operacional.

É exatamente a lógica do blast radius reaparecendo.

---

☸️ CAPÍTULO 20 — CRASHLOOPBACKOFF NÃO É A DOENÇA

Kubernetes mostra:

CrashLoopBackOff

Muita gente trata isso como causa.

Na realidade, é mais próximo de um estado resultante:

START
 ↓
CRASH
 ↓
RESTART
 ↓
CRASH
 ↓
RESTART
 ↓
CRASH
 ↓
BACKOFF

O Kubernetes está dizendo:

“Eu tentei. Morreu. Tentei novamente. Morreu novamente. Agora vou esperar um pouco antes de continuar insistindo.”

A causa pode estar em:

config
secret
dependency
permission
OOM
bug
filesystem
health probe

Portanto:

não conserte o CrashLoopBackOff; descubra por que o processo está crashando.

---

📦 CAPÍTULO 21 — IMAGEPULLBACKOFF: O AVENTUREIRO NEM ENTROU NA DUNGEON

Outro caso:

Pod
 ↓
precisa da imagem
 ↓
Registry
 X

Possíveis causas:

tag errada
imagem inexistente
credencial inválida
DNS
rede
rate limit
registry indisponível

Aqui a aplicação sequer começou.

Essa observação é fundamental:

descubra em qual estágio do ciclo de vida ocorreu a falha.

Não faz sentido procurar erro de aplicação se a aplicação nunca executou.

---

⏳ CAPÍTULO 22 — PENDING NÃO SIGNIFICA QUEBRADO

Pod está:

Pending

Pode estar esperando:

CPU
Memory
GPU
PVC
quota
node selector
toleration
scheduler

Isso nos leva novamente à diferença entre:

CAPACIDADE TOTAL

e:

CAPACIDADE UTILIZÁVEL POR AQUELE WORKLOAD

O cluster pode possuir recursos livres e mesmo assim não conseguir posicionar determinado Pod.

Para quem conhece WLM, a filosofia não soa tão alienígena.

---

🌐 CAPÍTULO 23 — O CAMINHO DO PACOTE NO KUBERNETES

Grave:

USER
 ↓
INGRESS
 ↓
SERVICE
 ↓
ENDPOINT
 ↓
POD

Quando algo falhar, percorra a cadeia.

Pod responde?

Endpoint existe?

Service encontra Endpoint?

Ingress encontra Service?

DNS aponta corretamente?

O método é:

teste cada fronteira.

Não:

“Delete todos os Pods e invoque os deuses de Aincrad.”

---

🏷️ CAPÍTULO 24 — UMA LETRA PODE DERRUBAR TUDO

Service:

selector:
  app: payment

Pod:

labels:
  app: payments

Um s.

Resultado:

SERVICE     EXISTS
POD         EXISTS
ENDPOINTS   NONE

Tudo existe.

Nada conversa.

Esse é um tipo especialmente interessante de incidente:

os componentes estão corretos individualmente; a relação entre eles está errada.

E sistemas distribuídos são essencialmente coleções de relações.

---

🏗️ CAPÍTULO 25 — TERRAFORM: AUTOMATIZANDO O SUCESSO E O DESASTRE

Infrastructure as Code traz:

CODE
 ↓
PLAN
 ↓
REVIEW
 ↓
APPLY
 ↓
VERIFY

Fantástico.

Mas automação possui uma característica maravilhosa e assustadora:

computadores conseguem executar erros humanos em velocidade industrial.

Manualmente você pode alterar um servidor errado.

Automação pode alterar 300.

Por isso:

terraform plan

não é decoração.

É uma oportunidade de enxergar o futuro.

---

☠️ CAPÍTULO 26 — O SINAL -/+ QUE PODE ESTRAGAR SEU CAFÉ

Imagine o Terraform indicando que determinado recurso será destruído e recriado.

Você pensava estar fazendo uma pequena alteração.

Terraform pretende:

DESTROY
   ↓
CREATE

E alguém simplesmente executa:

terraform apply

Lisbeth arrancaria o martelo da sua mão.

Leia o plano.

Principalmente alterações destrutivas.

Peer review em infraestrutura não é burocracia.

É proteção contra blast radius automatizado.

---

👻 CAPÍTULO 27 — CONFIGURATION DRIFT: O FANTASMA DA INFRAESTRUTURA

Código diz:

ESTADO A

Mas alguém entrou no console manualmente e alterou:

ESTADO B

Agora:

CODE ≠ REALIDADE

Isso é configuration drift.

Depois alguém altera uma inocente linha no Terraform.

O plano aparece gigantesco.

— Mas eu só mudei uma coisa!

Sim.

Só que a realidade já havia se afastado do estado declarado.

Esse conceito possui enorme importância mesmo fora do Terraform.

Ambientes mainframe também sofrem quando:

documentação
configuração
procedimento
produção

deixam de representar a mesma realidade.

---

🏛️ CAPÍTULO 28 — E O QUE TUDO ISSO TEM A VER COM COBOL?

Quase tudo.

Não devemos criar equivalências técnicas falsas, mas podemos criar analogias mentais úteis:

Mundo moderno	Universo mainframe
Linux host	z/OS / LPAR
Process	Address Space
Database	Db2 / IMS
Storage	DASD / storage subsystem
IAM	RACF / SAF
Monitoring	RMF / SMF
Workload management	WLM
Application server	CICS / IMS TM, dependendo do contexto
Messaging	MQ
Network	TCP/IP
Logs/events	SYSLOG, JES, CICS/Db2 traces e logs

O programador COBOL moderno não precisa transformar-se em administrador Kubernetes.

Mas precisa compreender que sua aplicação vive dentro de um ecossistema de dependências.

Seu COBOL pode estar perfeito.

Mesmo assim:

COBOL
 ↓
CICS
 ↓
Db2
 ↓
Storage

Se storage degrada:

Db2 espera
 ↓
CICS espera
 ↓
COBOL espera
 ↓
cliente espera

Quem leva a culpa?

Normalmente:

“O sistema está lento.”

---

🔬 CAPÍTULO 29 — CORRELAÇÃO NÃO É CAUSA

Deploy:

14:02

Incidente:

14:03

Suspeito?

Muito.

Prova?

Não.

Às 14:03 também poderia ter ocorrido:

certificado expirou
batch iniciou
storage saturou
DNS mudou
dependência caiu

Portanto:

TIMELINE
   ↓
HIPÓTESE

mas:

EVIDÊNCIA
   ↓
CONFIRMAÇÃO

Essa distinção evita duas horas de War Room culpando o último deploy enquanto o verdadeiro culpado está tranquilamente consumindo I/O no andar de baixo da dungeon.

---

🧰 CAPÍTULO 30 — O CHECKLIST DA FORJA DE LISBETH

Quando receber:

“Produção caiu!”

não saia reiniciando coisas.

Siga algo próximo disto:

1. Defina o sintoma real. O que exatamente o usuário não consegue fazer?

2. Determine o impacto. Quantos usuários, aplicações ou regiões foram afetados?

3. Descubra quando começou. Procure uma timeline precisa.

4. Verifique mudanças recentes. Deploy, configuração, infraestrutura, segurança, capacidade.

5. Procure denominadores comuns. DNS, Db2, MQ, storage, RACF, rede etc.

6. Determine a última camada comprovadamente saudável.

7. Colete evidências antes de alterar o ambiente.

8. Crie hipóteses testáveis.

9. Teste com o menor impacto possível.

10. Aplique a menor correção segura.

11. Verifique pela perspectiva do usuário.

12. Faça RCA e prevenção.

Observe o item 11.

Não basta:

CICS = UP

Teste:

TRANSACTION = OK?

E melhor ainda:

BUSINESS TRANSACTION = OK?

---

🧙 CAPÍTULO 31 — A EVOLUÇÃO DO PROGRAMADOR COBOL

O iniciante vê:

APPLICATION DOWN

e pensa:

RESTART

O profissional começa a pensar:

Qual aplicação?
Qual usuário?
Desde quando?
Todos?
Alguns?
Qual ambiente?
O que mudou?
Qual dependência?
Qual erro?
Qual latência?
Qual padrão?
Qual componente comum?

E existe uma diferença monumental entre essas duas formas de trabalhar.

A primeira reage.

A segunda investiga.

---

⚔️ CAPÍTULO 32 — LISBETH FINALMENTE ENTREGA A ESPADA

Depois de Linux, redes, load balancers, cloud, storage, bancos, Docker, Kubernetes e Terraform, talvez pareça que estudamos dezenas de assuntos diferentes.

Mas retire os nomes das tecnologias.

O que sobra?

RESOURCE
CAPACITY
DEPENDENCY
CONNECTIVITY
CONFIGURATION
STATE
CHANGE
OBSERVABILITY

Essa é a verdadeira dungeon.

Tecnologias mudam.

Essas categorias continuam reaparecendo.

O mainframe dos anos 1970, o Linux moderno, um cluster Kubernetes e uma cloud pública parecem mundos diferentes.

Mas todos possuem:

recursos finitos, dependências, configurações, estados, caminhos de comunicação e seres humanos perfeitamente capazes de alterar alguma coisa às 17:59 de sexta-feira.

---

🕵️ EASTER EGG — O INCIDENTE DAS 03:17

Você chegou até aqui.

Então merece descobrir por que o relógio marcou 03:17 duas vezes.

Imagine que o telefone toca exatamente às 03:17.

Produção está lenta.

CPU aumentou.

Db2 apresenta waits.

CICS começa a acumular transações.

Um jovem engenheiro declara:

“É CPU!”

Lisbeth olha para ele.

Não fala nada.

Você abre a timeline.

Descobre:

03:15  Batch iniciou
03:16  I/O aumentou
03:16  Db2 response time aumentou
03:17  CICS response time aumentou
03:17  CPU aumentou
03:18  usuários começaram a reclamar

Agora temos outra história.

CPU não iniciou o problema.

Ela também reagiu ao workload.

A pista estava na ordem dos acontecimentos.

03:17 não era a causa. Era apenas o momento em que o castelo começou a sentir o terremoto iniciado dois minutos antes.

Esse é o Easter Egg.

Em incidentes complexos:

timeline é quase uma máquina do tempo.

---

☕ EPÍLOGO — NÃO CONSERTE A ESPADA ANTES DE DESCOBRIR ONDE ELA QUEBROU

Lisbeth não seria uma boa ferreira se simplesmente pegasse qualquer espada quebrada, desse cinco marteladas e gritasse:

“Próximo!”

Um engenheiro de produção também não deveria trabalhar assim.

Quando ocorrer um incidente:

Observe
   ↓
Colete evidências
   ↓
Defina o escopo
   ↓
Monte a timeline
   ↓
Procure correlações
   ↓
Crie hipóteses
   ↓
Teste
   ↓
Corrija
   ↓
Verifique
   ↓
Aprenda
   ↓
Previna

Essa sequência vale para:

Linux
Cloud
Network
Storage
Database
Docker
Kubernetes
Terraform
z/OS
CICS
IMS
Db2
MQ
RACF
WLM

E provavelmente continuará válida quando metade dessas tecnologias já tiver virado questão de arqueologia computacional.

Porque troubleshooting não é decorar comandos.

Não é saber kubectl de cabeça.

Não é decorar comandos de SDSF.

Não é executar terraform apply.

E definitivamente não é saber onde fica o botão Restart.

Troubleshooting é construir uma explicação baseada em evidências para responder:

O que aconteceu, onde aconteceu, quando começou, quem foi afetado, por que aconteceu e como sabemos que realmente corrigimos?

Quando você consegue responder essas perguntas, algo interessante acontece.

Você deixa de ser apenas o programador COBOL que recebeu uma ligação porque “o sistema caiu”.

Você começa a enxergar o sistema inteiro:

USUÁRIO
   ↓
APLICAÇÃO
   ↓
MIDDLEWARE
   ↓
DATABASE
   ↓
NETWORK
   ↓
STORAGE
   ↓
INFRASTRUCTURE

E principalmente as relações entre essas camadas.

É aí que nasce aquela habilidade difícil de colocar num curso ou numa certificação: raciocínio operacional.

O COBOL continua importante.

O JCL continua importante.

CICS, Db2, MQ, RACF, WLM, SMF e RMF continuam importantes.

Mas acima de todas essas ferramentas existe algo ainda mais poderoso:

a capacidade de olhar para cinquenta sintomas e descobrir qual história as evidências estão tentando contar.

Lisbeth coloca a espada recém-forjada sobre o balcão.

Você pergunta:

— Está pronta?

Ela provavelmente responderia:

— Ainda não.

— Mas ela já está inteira!

— Exatamente. Agora precisamos testar.

E essa talvez seja a última e mais importante lição dos 50 incidentes:

o fato de o sistema ter voltado não prova que o incidente terminou.

Primeiro restauramos o serviço.

Depois entendemos a causa.

Depois verificamos.

Depois aprendemos.

E finalmente tentamos impedir que o telefone volte a tocar às 03:17.

Porque em Aincrad morrer significava não voltar.

Em Produção existe algo talvez ainda mais assustador:

o incidente volta na segunda-feira.

☕ Um Café no Bellacosa Mainframe — onde até uma ferreira de Sword Art Online sabe que RESTART não é Root Cause Analysis.