 |
| 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ÇONingué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 segundoO 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 UPE 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 APIDNS 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 caiuO 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 DatasetVocê 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
↓
VERIFYEu acrescentaria:
LEARN
↓
PREVENTEsse 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
CORRELATIONTIME — 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 ruimNo Linux, comandos como:
top
ps aux --sort=-%cpu
uptimeajudam na investigação.
No mainframe mudamos as ferramentas:
RMF
SMF
WLM
SDSFMas 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 terminatedVocê 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 processoIsso introduz uma distinção preciosa:
PROCESSO MORREUnão significa necessariamente:
PROCESSO SE MATOUEle 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 -he existe espaço.
Mesmo assim:
No space left on deviceComo?
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% utilizadosResultado:
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
CATALOGTer 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
↓
APPLICATIONPergunte:
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.comA máquina precisa descobrir algo como:
192.0.2.123Se 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
↓
DESTINATIONUma 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 BLOCKDo 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ênciaE 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 OKLoad balancer executa:
GET /healthzMas o endpoint correto é:
GET /healthO resultado?
APP1 UNHEALTHY
APP2 UNHEALTHY
APP3 UNHEALTHYO 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árioUma 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 TOTALMaravilhoso.
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:
RUNNINGIsso não prova:
SSH OK
OS OK
PROCESS OK
APP OK
DATABASE OK
USER OKExistem camadas:
Hardware
↓
Hypervisor
↓
VM
↓
Operating System
↓
Process
↓
Application
↓
Dependency
↓
Business TransactionNo mainframe:
CEC
↓
LPAR
↓
z/OS
↓
CICS
↓
Transaction
↓
Db2/MQ
↓
BusinessCICS 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
PERFORMANCEUm volume pode estar cheio.
Pode estar inacessível.
Ou pode estar disponível e absurdamente lento.
Esse terceiro caso engana muita gente.
Porque:
STORAGE = ONLINEnão significa:
STORAGE = PERFORMANDO BEMEntram 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 readsNão pergunte apenas:
“Quanto temos?”
Pergunte também:
“Como estamos usando?”
🗄️ CAPÍTULO 17 — O BANCO FICOU SEM CONEXÕES
Suponha:
MAX CONNECTIONS = 500A aplicação abre conexões e não libera adequadamente.
100
200
300
400
499
500Chega a próxima:
💥
A solução rápida:
MAX CONNECTIONS = 1000Pode aliviar.
Mas se existe vazamento:
500 → 1000 → 2000 → 4000Você 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-IFParece sensato.
Até acontecer:
100 requests
↓
100 failures
↓
100 retries
↓
200 requests
↓
mais failures
↓
mais retriesO 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 budgetResiliê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 OKSuspeitamos de A.
Mas:
Container A FAIL
Container B FAIL
Container C FAIL
Container D FAILPare de investigar cada aplicação individualmente.
Pergunte o que elas compartilham:
HOST
CPU
MEMORY
DISK
NETWORK
DNS
STORAGEIsso é correlação operacional.
É exatamente a lógica do blast radius reaparecendo.
☸️ CAPÍTULO 20 — CRASHLOOPBACKOFF NÃO É A DOENÇA
Kubernetes mostra:
CrashLoopBackOffMuita gente trata isso como causa.
Na realidade, é mais próximo de um estado resultante:
START
↓
CRASH
↓
RESTART
↓
CRASH
↓
RESTART
↓
CRASH
↓
BACKOFFO 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 probePortanto:
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
XPossíveis causas:
tag errada
imagem inexistente
credencial inválida
DNS
rede
rate limit
registry indisponívelAqui 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á:
PendingPode estar esperando:
CPU
Memory
GPU
PVC
quota
node selector
toleration
schedulerIsso nos leva novamente à diferença entre:
CAPACIDADE TOTALe:
CAPACIDADE UTILIZÁVEL POR AQUELE WORKLOADO 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
↓
PODQuando 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: paymentPod:
labels:
app: paymentsUm s.
Resultado:
SERVICE EXISTS
POD EXISTS
ENDPOINTS NONETudo 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
↓
VERIFYFantá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 plannã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
↓
CREATEE alguém simplesmente executa:
terraform applyLisbeth 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 AMas alguém entrou no console manualmente e alterou:
ESTADO BAgora:
CODE ≠ REALIDADEIsso é 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çãodeixam 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
↓
StorageSe storage degrada:
Db2 espera
↓
CICS espera
↓
COBOL espera
↓
cliente esperaQuem leva a culpa?
Normalmente:
“O sistema está lento.”
🔬 CAPÍTULO 29 — CORRELAÇÃO NÃO É CAUSA
Deploy:
14:02Incidente:
14:03Suspeito?
Muito.
Prova?
Não.
Às 14:03 também poderia ter ocorrido:
certificado expirou
batch iniciou
storage saturou
DNS mudou
dependência caiuPortanto:
TIMELINE
↓
HIPÓTESEmas:
EVIDÊNCIA
↓
CONFIRMAÇÃOEssa 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:
Defina o sintoma real. O que exatamente o usuário não consegue fazer?
Determine o impacto. Quantos usuários, aplicações ou regiões foram afetados?
Descubra quando começou. Procure uma timeline precisa.
Verifique mudanças recentes. Deploy, configuração, infraestrutura, segurança, capacidade.
Procure denominadores comuns. DNS, Db2, MQ, storage, RACF, rede etc.
Determine a última camada comprovadamente saudável.
Colete evidências antes de alterar o ambiente.
Crie hipóteses testáveis.
Teste com o menor impacto possível.
Aplique a menor correção segura.
Verifique pela perspectiva do usuário.
Faça RCA e prevenção.
Observe o item 11.
Não basta:
CICS = UPTeste:
TRANSACTION = OK?E melhor ainda:
BUSINESS TRANSACTION = OK?🧙 CAPÍTULO 31 — A EVOLUÇÃO DO PROGRAMADOR COBOL
O iniciante vê:
APPLICATION DOWNe pensa:
RESTARTO 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
OBSERVABILITYEssa é 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 reclamarAgora 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
↓
PrevinaEssa sequência vale para:
Linux
Cloud
Network
Storage
Database
Docker
Kubernetes
Terraform
z/OS
CICS
IMS
Db2
MQ
RACF
WLME 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
↓
INFRASTRUCTUREE 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.
