Bellacosa Mainframe apresenta o SEV-1

☕ UM CAFÉ NO BELLACOSA MAINFRAME

🚨 INCEPTION, CLAYMORE E A DUNGEON DO SEV-1 — QUANDO O PROGRAMADOR COBOL DESCOBRIU QUE REINICIAR PRODUÇÃO NÃO ERA ANÁLISE DE CAUSA RAIZ

Incident Response, SEV-1, Blast Radius, Observabilidade, SRE, Incident Commander, Evidence-Driven Investigation, CICS, Db2, MQ, SDSF, SMF, RMF, WLM, retries, circuit breakers — e o dia em que descobrimos que o monstro talvez estivesse três camadas abaixo da realidade.

🎬 PRÓLOGO — O TELEFONE TOCOU ÀS 03:17

03:17.

Existe um horário particularmente adequado para sistemas de produção quebrarem.

Nunca às 14:30 de uma terça-feira tranquila, quando todos estão no escritório, o café está fresco e o especialista em Db2 acabou de voltar do almoço.

Não.

Produção prefere horários dramáticos.

03:17.

Nosso jovem programador COBOL acordou com o telefone vibrando.

Na tela havia apenas uma mensagem:

PRODUÇÃO FORA. SEV-1. ENTRA NA BRIDGE.

Ele abriu o notebook ainda tentando lembrar se estava acordado.

TSO.

ISPF.

SDSF.

Ao entrar na conferência encontrou uma pequena multidão.

— Deve ser Db2.

— Reinicia CICS.

— Foi o deploy.

— Não mexemos em nada.

— A CPU está normal.

— MQ está com fila.

— A rede está estranha.

— Do meu lado está tudo verde.

E então surgiu a primeira professora.

Clare, de Claymore, apoiou a espada imaginária sobre a mesa.

— Você está olhando para o monstro errado.

Antes que nosso programador pudesse perguntar qualquer coisa, outra voz surgiu.

Desta vez era Cobb, de Inception.

— E você está olhando apenas para a primeira camada.

Bem-vindo ao mundo de Incident Response.

Hoje não aprenderemos apenas como encontrar um erro.

Aprenderemos algo muito mais importante:

como pensar quando ninguém ainda sabe onde está o erro.

🧯 CAPÍTULO 1 — INCIDENTE NÃO É SINÔNIMO DE ERRO

Para começar do começo, precisamos separar três conceitos:

ALERT
INCIDENT
PROBLEM

Eles parecem semelhantes.

Não são.

Imagine que um job COBOL terminou:

JOB PAYROLL1
STEP010

ABEND S0C7

Temos um erro.

Talvez exista um alerta.

Mas isso necessariamente representa um grande incidente?

Não.

Talvez fosse um job de teste.

Talvez houvesse recuperação automática.

Talvez nenhum usuário tenha sido afetado.

Agora imagine outra situação.

Nenhum programa abendou.

CICS está UP.

Db2 está UP.

MQ está UP.

CPU está em 45%.

Tudo parece lindo.

Entretanto, uma transação que normalmente responde em 300 milissegundos agora leva 18 segundos.

Os clientes começaram a abandonar operações.

Temos um incidente.

Alert

Um alerta é um sinal:

alguma coisa talvez esteja errada.

Exemplo:

CPU > 80% por 5 minutos

Incident

Um incidente existe quando há impacto real ou iminente sobre serviço, usuários ou negócio.

Problem

O problema é a causa subjacente associada ao incidente — usando aqui a terminologia tradicional de gestão de serviços.

Podemos ter:

MEMORY LEAK
     ↓
   PROBLEM
     ↓
aplicação degrada
     ↓
  INCIDENT
     ↓
CPU/memória dispara
     ↓
   ALERT

Percebeu a inversão?

O alerta que você viu pode ser o último elo de uma cadeia que começou muito antes.

Primeira lição de Clare:

O primeiro monstro que você encontra não necessariamente é o monstro que iniciou a batalha.

🔥 CAPÍTULO 2 — PRIMEIRO SALVE A ALDEIA, DEPOIS AUTOPSIE O YOUma

Programadores possuem uma tendência compreensível.

Quando alguma coisa quebra:

descobrir erro
     ↓
corrigir erro
     ↓
voltar produção

Incident Response acrescenta outra prioridade.

detectar
   ↓
conter
   ↓
mitigar
   ↓
restaurar
   ↓
estabilizar
   ↓
investigar profundamente

Essa diferença é gigantesca.

Suponha que às 10:00 entrou a versão 2.3 de uma aplicação.

Às 10:07 começaram erros.

A versão 2.2 era estável.

Talvez descobrir o bug exato demore três horas.

Mas voltar para 2.2 pode demorar dez minutos.

Nesse cenário, pode fazer sentido operacionalmente:

V2.3
 ↓
ROLLBACK
 ↓
V2.2
 ↓
SERVIÇO RESTAURADO

e depois investigar V2.3.

Isso é mitigation.

Não necessariamente root-cause resolution.

É aqui que Cobb desenha dois círculos no quadro.

RESTORE SERVICE ≠ FIND ROOT CAUSE

E diz:

— São camadas diferentes do sonho.

Você pode restaurar o serviço sem conhecer ainda a causa definitiva.

E pode descobrir a causa sem ter restaurado o serviço.

Em um SEV-1, reduzir o dano ao cliente normalmente possui prioridade imediata.

⏱️ CAPÍTULO 3 — OS PRIMEIROS 15 MINUTOS

Existe uma disciplina específica para os primeiros minutos.

Um fluxo útil é:

1. Confirmar o incidente
2. Determinar impacto
3. Determinar blast radius
4. Verificar mudanças recentes
5. Definir responsáveis
6. Criar canais de comunicação
7. Preservar evidências
8. Suspender mudanças perigosas
9. Criar hipóteses
10. Decidir mitigação

Observe algo curioso.

Não existe:

3. REINICIE TUDO

Isso merece ser colocado numa caneca.

Antes de alterar o estado, observe.

Imagine que uma região CICS apresenta comportamento estranho.

Alguém imediatamente ordena:

CEMT PERFORM SHUTDOWN

Ela volta.

Problema resolvido?

Talvez.

Mas o restart pode ter eliminado justamente aquilo que permitiria descobrir a causa:

tasks;
locks;
storage;
conexões;
estados intermediários;
dumps;
filas transitórias;
threads;
informações temporais.

É o equivalente digital de chegar à cena de um crime e decidir:

Vamos limpar tudo antes da perícia.

Clare provavelmente desembainharia a espada nesse momento.

🔎

CAPÍTULO 4 — NÃO MUDE A CENA DO CRIME

Um dos princípios mais importantes de Incident Response é:

OBSERVE BEFORE CHANGING STATE

Antes de restart, rollback, cancelamento ou alteração:

colete métricas;
salve logs;
registre horários;
identifique processos;
registre mensagens;
preserve dumps quando necessários;
documente configurações;
determine quem está afetado.

No mainframe poderíamos consultar, conforme o problema:

SDSF
SYSLOG
JES spool
SMF
RMF
CICS statistics
Db2 statistics
MQ statistics
system dumps
application logs

Isso não significa nunca reiniciar.

Significa:

saiba por que está reiniciando e registre o estado antes, quando for possível e seguro.

🧠 CAPÍTULO 5 — INCEPTION: DESÇA UMA CAMADA

Agora Cobb assume a aula.

Um usuário diz:

O sistema está fora.

Isso é o nível zero.

Mas qual sistema?

Vamos entrar no sonho.

USUÁRIO
   ↓
DNS
   ↓
LOAD BALANCER
   ↓
PROXY/API GATEWAY
   ↓
APLICAÇÃO
   ↓
CICS
   ↓
COBOL
   ↓
DB2
   ↓
MQ
   ↓
OUTRO SISTEMA

O COBOL pode estar perfeito.

Talvez o usuário nem esteja conseguindo chegar até ele.

Um certificado TLS expirado pode fazer parecer que a aplicação caiu.

DNS pode falhar.

Um firewall pode bloquear tráfego.

O load balancer pode considerar determinado backend unhealthy.

Uma API externa pode estar lenta.

O Db2 pode estar esperando locks.

MQ pode estar acumulando mensagens.

É o princípio de Request Path Reconstruction.

Para cada hop, perguntamos:

A requisição chegou?

Saiu?

Quanto tempo permaneceu?

Qual código retornou?

É extraordinariamente poderoso.

🎯 CAPÍTULO 6 — BLAST RADIUS: QUAL O TAMANHO DO MONSTRO?

Clare conhece bem essa pergunta.

Você vê um Yoma.

Mas existem quantos?

Em Incident Response chamamos isso de blast radius.

Literalmente:

raio da explosão.

Perguntas fundamentais:

Todos os clientes?

Alguns clientes?

Todos os países?

Uma região?

Uma LPAR?

Um sysplex?

Uma aplicação?

Uma região CICS?

Uma transação?

Um endpoint?

Uma versão?

Imagine:

São Paulo     ERRO
Rio           OK
Curitiba      OK

Essa única informação vale ouro.

Se duas regiões equivalentes funcionam e apenas uma falha, várias hipóteses globais perdem força.

🪞 CAPÍTULO 7 — O SISTEMA SAUDÁVEL É SEU MELHOR DETETIVE

Existe uma técnica extremamente simples:

healthy versus unhealthy.

Compare aquilo que funciona com aquilo que não funciona.

LPAR A                 LPAR B
------                 ------
ERRO                    OK

CICS A                  CICS B
Db2 A                   Db2 B
MQ A                    MQ B

Agora pergunte:

O que é diferente?

Compare:

configuração;
versão;
PTF;
load module;
package Db2;
WLM;
RACF;
datasets;
conexões;
rede;
volume;
horário;
dependências.

Essa pergunta costuma ser melhor do que:

O que está errado?

Porque você ganhou um controle experimental.

🧪 CAPÍTULO 8 — INCIDENT RESPONSE É MÉTODO CIENTÍFICO

Chegamos a uma das partes mais fascinantes.

Uma investigação madura segue aproximadamente:

SINTOMA
 ↓
ESCOPO
 ↓
TIMELINE
 ↓
MUDANÇAS
 ↓
EVIDÊNCIAS
 ↓
HIPÓTESES
 ↓
TESTES
 ↓
ELIMINAÇÃO
 ↓
ROOT CAUSE

Suponha:

CICS está demorando oito segundos.

Hipótese:

Db2 está lento.

Então medimos.

CICS elapsed       8.200 ms
Db2                 43 ms
MQ                   18 ms
External API       7.800 ms

Ops.

Db2 não parece mais nosso principal suspeito.

A investigação não procurou somente confirmar a hipótese.

Procurou evidência capaz de destruí-la.

Isso é chamado de:

disconfirming evidence.

🧠 CAPÍTULO 9 — O MONSTRO CHAMADO CONFIRMATION BIAS

Seres humanos possuem uma falha interessante.

Quando acreditamos em alguma coisa, começamos involuntariamente a notar evidências que confirmam nossa crença.

O DBA diz:

Deve ser rede.

O network engineer:

Deve ser aplicação.

O desenvolvedor:

Deve ser banco.

O operador:

Deve ser o deploy.

E cada um começa a procurar evidências para seu suspeito favorito.

Uma investigação melhor pergunta:

Que resultado provaria que minha hipótese está errada?

Isso muda tudo.

Você deixa de defender uma teoria.

Começa a testá-la.

🕰️ CAPÍTULO 10 — CONSTRUA A TIMELINE

Cobb pega o quadro novamente.

Tempo é uma dimensão fundamental.

Imagine:

09:55 deploy
10:00 feature flag
10:04 erros começam
10:06 latency aumenta
10:08 retries aumentam
10:10 connection pool esgota
10:12 sistema praticamente indisponível

Agora temos uma narrativa.

Mas cuidado:

correlação não significa causalidade.

O deploy aconteceu antes do incidente.

Isso o torna um candidato importante.

Não prova que ele causou o incidente.

Talvez às 10:03 uma dependência externa tenha falhado.

Portanto:

MUDANÇA + PROXIMIDADE TEMPORAL
              ↓
           HIPÓTESE

não:

MUDANÇA
  ↓
CULPADO

💣 CAPÍTULO 11 — "NÃO MUDAMOS NADA"

Uma frase clássica de produção:

Aqui ninguém mudou nada.

Clare olha desconfiada.

Porque alguma coisa frequentemente mudou.

Talvez não o programa.

Mudanças podem incluir:

configuração
certificado
DNS
firewall
senha
token
schema
feature flag
biblioteca
dependência
infraestrutura
capacidade
tráfego

No mainframe:

LOAD MODULE
DBRM
PACKAGE
PLAN
PROC
JCL
PARMLIB
PROCLIB
LINKLIST
RACF
CICS definitions
MQ definitions
WLM policy
SMS
PTF
APAR
TCP/IP

E existe uma mudança ainda mais traiçoeira.

Nada foi alterado tecnicamente.

Ontem:

10.000 transações/hora

Hoje:

700.000 transações/hora

O software é idêntico.

O ambiente operacional não é.

🌊 CAPÍTULO 12 — QUANDO RETRY VIRA ARMA DE DESTRUIÇÃO EM MASSA

Temos:

APP
 ↓
SERVICE
 ↓
DATABASE

O database começa a responder lentamente.

A aplicação tenta novamente.

Parece sensato.

Mas suponha:

1.000 requests/s

Cada cliente tenta três vezes.

Temos potencialmente:

1.000 × 3 = 3.000 tentativas/s

A dependência, que já estava sobrecarregada, recebe mais carga.

Fica ainda mais lenta.

Mais timeouts.

Mais retries.

LENTIDÃO
   ↓
TIMEOUT
   ↓
RETRY
   ↓
MAIS CARGA
   ↓
MAIS LENTIDÃO
   ↓
MAIS TIMEOUT

Parabéns.

O mecanismo criado para aumentar resiliência agora está ajudando a derrubar o sistema.

Isso é retry amplification.

⚡ CAPÍTULO 13 — CIRCUIT BREAKER

Para resolver parte desse problema surgiu um conceito inspirado em eletricidade.

O circuit breaker.

CLIENT
   ↓
CIRCUIT BREAKER
   ↓
SERVICE

Normalmente temos estados conceituais:

CLOSED
 ↓
muitas falhas
 ↓
OPEN
 ↓
espera
 ↓
HALF-OPEN
 ↓
teste

Quando OPEN, paramos temporariamente de bombardear a dependência.

Podemos:

falhar rapidamente;
usar fallback;
devolver mensagem controlada;
permitir recuperação.

É melhor dizer rapidamente:

Serviço temporariamente indisponível.

do que deixar milhares de threads esperando 30 segundos antes de morrer.

🎲 CAPÍTULO 14 — JITTER E O EXÉRCITO DOS CLONES

Agora temos outro problema.

100.000 clientes falham às 12:00.

Todos foram programados:

WAIT 10 SECONDS
RETRY

Às 12:00:10:

██████████████████████████
100.000 RETRIES
██████████████████████████

Todos atacam juntos.

Esse tipo de fenômeno é associado ao chamado thundering herd.

Então usamos:

backoff + jitter

Em vez de todos retornarem exatamente no mesmo instante, introduzimos variação.

10.17 s
9.84 s
11.03 s
10.52 s
...

Espalhamos a carga.

Curiosamente, às vezes uma pequena dose de aleatoriedade torna sistemas distribuídos mais estáveis.

📊 CAPÍTULO 15 — OBSERVABILIDADE NÃO É TER UM DASHBOARD BONITO

As imagens apresentam quatro grupos úteis:

METRICS
LOGS
TRACES
EVENTS

Metrics

Respondem:

Quanto?

CPU
memory
RPS
latency
queue depth
error rate

Logs

Respondem:

O que aconteceu?

abend
exception
warning
message
error

Traces

Respondem:

Por onde a transação passou?

A → B → C → D

Events

Respondem:

O que aconteceu no ambiente?

deployment
restart
configuration change
scaling
certificate rotation

Juntos, eles contam uma história.

🦖 CAPÍTULO 16 — O MAINFRAME JÁ CONHECIA PARTE DESSA HISTÓRIA

Aqui nosso programador COBOL começa a sorrir.

Porque reconhece vários parentes.

No mundo moderno encontramos:

Prometheus
Grafana
OpenTelemetry
Kubernetes Events
distributed tracing
SLO

No universo IBM Z convivemos há muito tempo com coisas como:

SMF
RMF
WLM
SYSLOG
SDSF
CICS statistics
Db2 statistics
MQ monitoring

Não são equivalências perfeitas.

Mas tentam responder perguntas muito parecidas:

O que aconteceu?

Quando aconteceu?

Quanto recurso foi consumido?

Qual workload sofreu?

Quanto demorou?

Quem estava esperando?

Qual componente tornou-se gargalo?

O mundo cloud não inventou a necessidade de observar sistemas críticos.

Ele desenvolveu ferramentas e vocabulários contemporâneos para problemas que sistemas transacionais conhecem há décadas.

📈 CAPÍTULO 17 — A MÉDIA É UM MIMIC DISFARÇADO DE ESTATÍSTICA

Imagine 100 requisições.

95 respondem:

100 ms

Cinco respondem:

10 segundos

Uma média isolada pode esconder uma experiência péssima para uma parcela dos usuários.

Por isso usamos percentis:

p50
p95
p99

Simplificando:

p95 = 500 ms

significa que aproximadamente 95% das observações ficaram em 500 ms ou menos.

O p99 ajuda a enxergar a cauda.

Em arquiteturas distribuídas isso é particularmente importante.

Uma operação pode depender de:

A
├── B
├── C
├── D
└── E

Basta uma dependência apresentar tail latency alta para a experiência final piorar.

🗄️ CAPÍTULO 18 — REINICIAR O BANCO PODE ESCONDER O ASSASSINO

Restart é sedutor.

Banco lento.

Restart.

Voltou.

Chamado encerrado.

Só existe um pequeno problema.

O restart pode:

limpar conexões
liberar memória
encerrar queries
remover locks
reinicializar caches

Então imagine um connection leak:

restart
 ↓
10 conexões
 ↓
100
 ↓
500
 ↓
1000
 ↓
2000
 ↓
BOOM

Depois:

restart
 ↓
10 conexões

Você não corrigiu o problema.

Apenas reiniciou o cronômetro.

🟢 CAPÍTULO 19 — O GRÁFICO VERDE PODE ESTAR MENTINDO

Cobb coloca o pião sobre a mesa.

Ele gira.

O dashboard ficou verde.

Podemos fechar o incidente?

Não tão rápido.

Recovery não significa simplesmente "ficou verde".

Precisamos verificar:

funcionalidade
latência
erros
dados
replicação
filas
dependências
background jobs
capacidade
SLOs

Imagine:

CICS       OK
DB2        OK
CPU        OK
MQ         OK

Mas:

QUEUE DEPTH = 3.800.000

Existe uma montanha esperando para ser processada.

Ou pior:

serviço = disponível
dados = inconsistentes

O usuário consegue entrar.

Mas encontra saldo incorreto.

Isso não é recuperação.

É um incidente usando maquiagem.

🧟 CAPÍTULO 20 — O SEGUNDO MONSTRO

Clare avisa:

— Nunca presuma que derrotar um Yoma significa que acabou.

Imagine:

A → B → C

A ficou fora durante uma hora.

B acumulou backlog.

A volta.

Agora milhões de itens começam a atravessar B.

A → ███████████ → B → C

CPU dispara.

Filas crescem.

C sofre.

Nasce um secondary failure.

Por isso o fluxo correto não é:

RECOVER → CLOSE

mas:

RECOVER
 ↓
VERIFY
 ↓
MONITOR
 ↓
CLOSE

👨‍🚒 CAPÍTULO 21 — INCIDENT COMMANDER NÃO É O HERÓI QUE DIGITA MAIS RÁPIDO

Incidentes graves possuem também um problema humano.

Imagine vinte especialistas numa chamada.

Todos falam.

Todos investigam.

Todos dão ordens.

Resultado:

CHAOS++

O Incident Command System divide responsabilidades.

Podemos ter:

Incident Commander
Technical Lead
Operations Responders
Communications Lead
Scribe
Subject-Matter Experts
Stakeholders

O Incident Commander coordena.

O Technical Lead conduz investigação técnica.

Operations executa mudanças.

O Scribe registra timeline e decisões.

Communications informa interessados.

SMEs entram com conhecimento especializado.

Isso permite trabalho paralelo.

E principalmente evita que o melhor especialista técnico precise responder a cada três minutos:

Já voltou?

🔥 CAPÍTULO 22 — UMA IDEIA QUE VEIO DOS INCÊNDIOS

Aqui temos uma bela curiosidade histórica.

O Incident Command System moderno possui raízes na resposta americana a grandes incêndios florestais, particularmente a partir dos anos 1970.

O desafio possuía características familiares:

muitas equipes
muitas organizações
recursos diferentes
informação incompleta
situação mudando rapidamente
decisões urgentes

Parece uma war room de produção?

Exatamente.

A solução envolveu:

comando claro
funções definidas
coordenação
comunicação
procedimentos

Décadas depois, princípios semelhantes apareceriam na gestão de grandes incidentes tecnológicos.

Mudou o incêndio.

Agora:

kubectl get pods

está pegando fogo.

🧅 CAPÍTULO 23 — INCEPTION E A CEBOLA DA INFRAESTRUTURA

Um incidente moderno possui camadas.

BUSINESS
   ↓
APPLICATION
   ↓
RUNTIME
   ↓
CONTAINER
   ↓
KUBERNETES
   ↓
OPERATING SYSTEM
   ↓
NETWORK
   ↓
STORAGE
   ↓
HARDWARE

E ainda podemos acrescentar:

THIRD-PARTY DEPENDENCY

Cobb sorri.

— Precisamos descer mais um nível.

Esse é talvez o melhor paralelo com Inception.

O sintoma percebido pelo usuário pertence à camada superior.

A causa pode estar cinco níveis abaixo.

Mas existe uma diferença importante.

Em Inception, quanto mais profundamente entramos, mais difícil é saber se estamos sonhando.

Em produção, quanto mais profundamente investigamos sem método, mais fácil é esquecer qual problema estávamos tentando resolver.

Por isso mantenha sempre uma âncora:

CUSTOMER IMPACT

Nosso totem.

🧮 CAPÍTULO 24 — INVESTIGAR É REDUZIR INCERTEZA

Inicialmente podemos ter:

H = {
 aplicação,
 Db2,
 MQ,
 DNS,
 TLS,
 storage,
 CPU,
 memória,
 rede,
 configuração,
 deployment,
 dependência
}

Descobrimos:

DNS OK
TLS OK
CPU OK
DB2 OK

Então:

H = {
 aplicação,
 MQ,
 rede,
 configuração,
 deployment,
 dependência
}

Descobrimos que uma região funciona e outra não.

Reduzimos novamente.

Cada evidência deve eliminar possibilidades.

E aqui aparece uma conexão belíssima com teoria da informação.

Um bom teste não é aquele que produz mais dados.

É aquele que produz mais informação.

Perguntar:

"Podemos coletar mais 30 GB de logs?"

talvez seja menos útil que perguntar:

"O mesmo erro ocorre na outra região?"

Se a resposta for não, acabamos de eliminar uma enorme quantidade de hipóteses.

🧙 CAPÍTULO 25 — POR QUE O ENGENHEIRO VETERANO PARECE UM MAGO?

O iniciante vê:

HTTP 500

e pergunta:

Onde está o erro?

O veterano pergunta:

Desde quando?

Todos os usuários?

Todas as regiões?

Todos endpoints?

Qual percentual?

O que mudou?

Existe backlog?

Qual dependência?

Existem retries?

Existe saturation?

Qual caminho ainda funciona?

Dez perguntas depois, restam três suspeitos.

Isso parece intuição.

Frequentemente é experiência ensinando quais perguntas possuem maior poder discriminatório.

No mainframe acontece a mesma coisa.

O veterano pergunta:

Qual LPAR?

Qual região?

Qual transaction?

Qual job?

Qual step?

Qual dataset?

Qual subsystem?

Desde quando?

Só aqui?

O que mudou?

Sem utilizar esses nomes, ele está fazendo:

scope
blast-radius analysis
failure-domain isolation
timeline reconstruction
change correlation

Há décadas.

🗡️ CAPÍTULO 26 — CLAYMORE E O PERIGO DE "DESPERTAR" O INCIDENTE

Existe ainda uma analogia curiosa com Claymore.

Uma falha pequena nem sempre permanece pequena.

Imagine:

DEPENDÊNCIA LENTA
       ↓
    RETRIES
       ↓
CONNECTION POOL
       ↓
    SATURATION
       ↓
    TIMEOUTS
       ↓
MAIS RETRIES
       ↓
OUTROS SERVIÇOS
       ↓
CASCADING FAILURE

A falha original pode ter sido relativamente modesta.

Mas o sistema reage a ela.

E a reação transforma o incidente.

Quase como um despertar.

O monstro final pode ser muito maior do que o evento que iniciou tudo.

Essa é uma das grandes lições de sistemas distribuídos:

falhas possuem dinâmica.

Não analisamos apenas componentes.

Analisamos como componentes reagem às falhas de outros componentes.

🥚 EASTER EGG — O S0C7 QUE NÃO ERA S0C7

Às 04:21 nosso jovem programador encontra finalmente um:

IGZ0006S

— Achei!

Clare olha.

Cobb olha.

O DBA olha.

O operador olha.

Nosso herói anuncia:

— É o COBOL!

Silêncio.

O veterano pergunta:

— De que horas é esse ABEND?

Ele olha novamente.

01:43

O incidente começou:

03:17

O S0C7 não tinha relação alguma.

Era apenas um cadáver antigo encontrado no caminho.

Cobb pega o pião.

Clare guarda a espada.

E alguém escreve no chat:

       88  ROOT-CAUSE-FOUND VALUE 'Y'.

O veterano responde:

       MOVE 'N' TO ROOT-CAUSE-FOUND.

🏁 EPÍLOGO — O SISTEMA VOLTOU. MAS VOCÊ APRENDEU ALGUMA COISA?

Às 04:47 o serviço finalmente estabilizou.

Às 05:02 as filas começaram a diminuir.

Às 05:21 os percentis voltaram ao normal.

Às 05:40 os testes sintéticos passaram.

Às 06:10 ninguém observou novos erros.

Somente então o incidente foi encerrado.

Mas ainda faltava uma última etapa:

LEARN

Um bom incidente deveria produzir:

timeline;
causa raiz quando identificável;
fatores contribuintes;
impacto;
ações tomadas;
decisões;
pontos de observabilidade ausentes;
automações necessárias;
melhoria de runbooks;
novos alertas;
testes;
mecanismos preventivos.

E, principalmente, evitar uma cultura simplista de:

Quem fez isso?

Uma pergunta muito mais produtiva é:

Por que nosso sistema permitiu que isso produzisse tamanho impacto?

Talvez um humano tenha cometido um erro.

Humanos sempre cometerão erros.

A engenharia madura pergunta por que um único erro conseguiu atravessar tantas barreiras.

☕ A ÚLTIMA LIÇÃO DO BELLACOSA MAINFRAME

Se você é um programador COBOL iniciante, talvez tenha começado este artigo esperando aprender comandos.

Comandos são importantes.

Aprenda SDSF.

Aprenda CICS.

Aprenda Db2.

Aprenda MQ.

Aprenda SMF, RMF e WLM.

Entenda rede.

Entenda APIs.

Entenda observabilidade.

Mas existe uma habilidade acima delas:

aprender a investigar.

Ferramentas envelhecem.

Interfaces desaparecem.

Arquiteturas mudam.

Ontem:

Hoje:

Grafana

Amanhã teremos outra coisa.

Mas algumas perguntas sobrevivem:

O que aconteceu?

Quando começou?

Quem foi afetado?

Qual o blast radius?

O que mudou?

O que ainda funciona?

Qual caminho a transação percorre?

Quais são as dependências?

Quais evidências sustentam minha hipótese?

O que provaria que estou errado?

Posso mitigar sem destruir evidências?

O serviço realmente se recuperou?

O que aprendemos?

Clare olha para nosso jovem programador.

— Não ataque todo monstro que aparecer.

Cobb completa:

— E nunca confie na primeira camada.

No monitor, todos os gráficos finalmente estão verdes.

Nosso programador olha para eles.

Antes daquela madrugada teria dito:

Resolvido.

Agora não.

Ele abre SDSF.

Confere as filas.

Verifica CICS.

Consulta Db2.

Olha MQ.

Compara os tempos.

Confirma os dados.

Revisa os logs.

Espera alguns minutos.

Somente então escreve:

SERVICE VERIFIED.
INCIDENT CLOSED.

Porque finalmente entendeu a diferença entre duas frases que parecem iguais:

O sistema voltou.

Nós sabemos que o sistema se recuperou.

Entre elas existe praticamente toda a disciplina de Incident Response.

E em algum lugar do CPD, quase escondido entre milhões de registros SMF, havia um pequeno easter egg esperando o próximo programador:

       01  PRODUCTION.
           05  STATUS       PIC X(08).
           05  ROOT-CAUSE   PIC X(80).

       PROCEDURE DIVISION.

           IF STATUS = 'GREEN'
              DISPLAY
              'NAO CONFIE NO DASHBOARD AINDA'
           END-IF.

           PERFORM VERIFY-EVERYTHING.

           GOBACK.

Porque MAXCC=0000 nunca significou que o usuário está feliz.

Translate

segunda-feira, 1 de outubro de 2018