domingo, 12 de agosto de 2012

Truta maluca cantando e dançando

Besteirol puro uma truta que canta

Ter amigos é uma coisa fantástica, poder ir ate eles ou  receber-los em casa. Uma boa jantarada tagarelando banalidades por algumas horas. Uma conversa neutra sem objectivos de ganhar ou perder apenas diversão garantida.

Este video gravei na casa do Luigi e da Ornela, depois de uns copitos de vinho, descobri uma truta maluca na parede.


Ao descobrir que ela cantava e dançava foi gargalhadas generalisadas, maníaco por fotos como sou, não deixei de gravar este pequeno video.


sábado, 11 de agosto de 2012

🧠 “Quantos tipos de logs existem no SMF? — ou: quando o sistema decide contar TUDO”

 


🧠 “Quantos tipos de logs existem no SMF? — ou: quando o sistema decide contar TUDO”


SMF explicado para quem já confiou mais em registro binário do que em discurso


☕ 01:11 — O dia em que você descobre que o SMF sabe mais que você

Todo mainframer passa por isso:
abre um dump, vê o horário, cruza com o SMF…
e percebe que o sistema lembra melhor do que qualquer humano.

Este artigo é sobre os tipos de registros SMF, como funcionam, o que registram e por que eles continuam sendo a fonte definitiva de observabilidade corporativa.


🧬 Um pouco de história (quando log era coisa séria)

O SMF não nasceu para “debug”.
Nasceu para:

  • cobrança

  • auditoria

  • capacidade

  • planejamento

  • evidência operacional

📌 Comentário Bellacosa:
Antes de “log”, chamava-se prova.


🔢 Quantos tipos de SMF existem afinal?

Tecnicamente:

  • Tipos SMF vão de 0 a 255

  • Nem todos são usados

  • Muitos são reservados

  • Alguns são específicos de subsistema

🔥 Resposta curta:

Existem centenas, mas menos de 40 são realmente críticos no dia a dia.


🧠 Estrutura básica de um registro SMF (o DNA)

Todo registro SMF tem:

📦 Header padrão

  • Tipo do registro

  • Data e hora

  • Sistema

  • Identificador do job / task

  • Comprimento do registro

🧩 Seções variáveis

  • Dependem do tipo

  • Podem ter múltiplas ocorrências

  • São versionadas

😈 Easter egg:
SMF não quebra compatibilidade — ele adiciona seções.


🗂️ Principais tipos de SMF (os que realmente importam)

🔹 SMF Tipo 0 — IPL & Configuração

📌 Registra:

  • IPL do sistema

  • Mudanças de parâmetros

  • Ambiente inicial

🧠 Uso:

  • Auditoria

  • Linha do tempo do sistema


🔹 SMF Tipo 1 — Job Start

📌 Registra:

  • Início de jobs

  • Classe

  • Prioridade

🔥 Analogia distribuída:
“Application started”


🔹 SMF Tipo 2 — Job End

📌 Registra:

  • Final do job

  • RC

  • Consumo de recursos

📌 Bellacosa style:
O RC mente. O SMF não.


🔹 SMF Tipo 3 — Intervalo de Job

📌 Registra:

  • Uso de CPU

  • I/O

  • Tempo de espera

🧠 Base de:

  • Chargeback

  • Capacity planning


🔹 SMF Tipo 4 / 5 — Step Start / End

📌 Registra:

  • Cada step do job

  • Recursos por step

😈 Easter egg:
Ideal para descobrir qual step realmente dói.


🔹 SMF Tipo 6 — Print/Output

📌 Registra:

  • Uso de spool

  • Impressão

📌 Hoje menos usado, mas ainda presente.


🔹 SMF Tipo 7 / 8 — Accounting & Performance

📌 Registra:

  • TSO

  • Sessões interativas

🔥 Cloud analogy:
User session metrics.


🔹 SMF Tipo 14 / 15 — Dataset Activity

📌 Registra:

  • Abertura

  • Leitura

  • Escrita

  • Fechamento de datasets

🧠 Uso:

  • Segurança

  • Performance

  • Forense


🔹 SMF Tipo 30 — O canivete suíço

📌 Registra:

  • Job start / end

  • Step

  • Address space

  • USS

🔥 Comentário Bellacosa:
Se você só pudesse guardar um tipo… seria o 30.


🔹 SMF Tipo 70–79 — RMF (Performance do sistema)

📌 Registra:

  • CPU

  • Memória

  • I/O

  • Workload

🧠 Base de:

  • Observabilidade real

  • Capacity planning


🔹 SMF Tipo 80 — Segurança (RACF)

📌 Registra:

  • Logon

  • Acesso negado

  • Alterações críticas

😈 Easter egg:
Auditor ama esse tipo. Operador respeita.


🔹 SMF de subsistemas (os mais ricos)

🔸 CICS (110)

  • Transações

  • Tempo de resposta

  • Recursos

🔸 DB2 (100, 101, 102…)

  • SQL

  • Buffer pools

  • Locking

🔸 MQ (115/116)

  • PUT / GET

  • Depth

  • Performance

🔥 Tradução moderna:
Isso aqui são traces distribuídos antes da moda.


🧭 Passo a passo: como pensar SMF como observabilidade

1️⃣ Identifique o tipo certo
2️⃣ Leia o header (tempo e contexto)
3️⃣ Analise seções relevantes
4️⃣ Correlacione com outros tipos
5️⃣ Só então conclua

📌 Regra de ouro:
Nunca analise um SMF isolado.


📚 Guia de estudo para sobreviver no século XXI

Prioridade de aprendizado

  1. Tipo 30

  2. Tipos RMF (70–79)

  3. Subsystems (CICS, DB2, MQ)

  4. Tipo 80 (segurança)

Exercício Bellacosa

👉 Refaça uma RCA antiga
👉 Usando apenas SMF
👉 Compare com o relatório oficial

O SMF geralmente ganha.


🎯 Aplicações reais no mundo corporativo

  • Observabilidade híbrida

  • SRE corporativo

  • Auditoria regulatória

  • Capacity planning

  • Integração com AIOps

🔥 Comentário final:
Todo sistema distribuído sonha em ter a rastreabilidade que o SMF já entrega.


🖤 Epílogo — 04:02, tudo documentado

Enquanto o mundo discute qual ferramenta usar,
o SMF continua registrando o que realmente aconteceu.

El Jefe Midnight Lunch assina:
“Logs contam histórias. SMF registra a verdade.”

 

terça-feira, 3 de julho de 2012

📘 Mega City – Case Study Review (Completo)

Bellacosa Mainframe estuda o case Mega City



📘 Mega City – Case Study Review (Completo)

🎯 Visão Geral do Projeto

O projeto Mega City Commuter Application tem como objetivo desenvolver um aplicativo para apoiar os deslocamentos urbanos, integrando dados do Department of Transportation (DOT) para melhorar a experiência dos usuários.

🎯 Objetivo Principal do App

Allow commuters to determine optimal routes

❌ Não é:

  • Previsão do tempo

  • Horários de voo

  • Sistema ferroviário isolado


🧭 Principais Artefatos do Projeto

1️⃣ Agile Project Charter

Finalidade:

  • Define objetivos

  • Alinha negócio + tecnologia

  • Explica o porquê do projeto

📌 Pergunta típica de prova:

“Which document ensures objectives are clear and aligns business and technical teams?”
Agile Project Charter


2️⃣ Product Roadmap

Finalidade:

  • Visão visual e de alto nível

  • Organiza entregáveis por fases e meses

  • Indica quando o produto será testado e lançado

📅 Data de lançamento do App (prova):
October

📌 Responsável pela criação:
Project Manager


3️⃣ Working Agreement

Finalidade:

  • Define regras de convivência

  • Cria transparência, expectativas e objetivos comuns

  • Focado em como o time trabalha

👤 Quem lidera a criação:
Scrum Master – Anant Kumar

📌 Nunca é imposto, sempre criado pelo time


4️⃣ Product Backlog

Finalidade:

  • Repositório de todos os User Stories

  • Base para planejamento de Sprints

👤 Responsável:
Product Owner – Anant Kumar

📌 Dica de prova:

Quem gerencia e prioriza = Product Owner


👥 Papéis-Chave no Case Mega City

🔹 Product Owner

  • Define o que será construído

  • Gerencia o Product Backlog

Anant Kumar


🔹 Scrum Master

  • Facilita reuniões

  • Remove impedimentos

  • Garante adesão ao Scrum

  • Lidera o Working Agreement

Anant Kumar (em perguntas específicas do curso)


🔹 Subject Matter Expert (SME)

Responsável por garantir que requisitos técnicos e funcionais sejam atendidos.

📍 SME do DOT:
Hiroshi Tanaka

📌 Sempre associado a:

  • Dados do DOT

  • Funcionalidade específica do domínio


📊 Stacey Matrix (Análise Crítica)

📌 Parâmetros Avaliados:

  • Level of Agreement

  • Technology Complexity


🧠 Interpretação para prova

CenárioAbordagem Correta
Alta concordância + baixa complexidadeWaterfall
Baixa concordância + alta complexidadeAgile / Scrum
Trabalho contínuoKanban

📌 No Mega City:

Low agreement + High complexity
Agile / Scrum


🧩 Resumo Rápido (Cola de Prova 📝)

  • Objetivo do App: Rotas ideais para commuters

  • Roadmap: Visual + meses + lançamento em October

  • Charter: Alinha negócio e tecnologia

  • Working Agreement: Criado pelo time, liderado pelo Scrum Master

  • Product Backlog: Responsabilidade do Product Owner

  • SME DOT: Hiroshi Tanaka

  • Stacey Analysis: Low agreement + High complexity → Agile/Scrum


Se quiser, no próximo passo posso:

  • Criar um quadro comparativo (tabela) só com quem faz o quê

  • Simular questões de prova estilo Coursera

  • Ou montar um resumo em inglês, pronto para revisão final 📚


segunda-feira, 2 de julho de 2012

🧠 “SMF como fonte de verdade para observabilidade corporativa”

 


🧠 “SMF como fonte de verdade para observabilidade corporativa”


Porque antes de existir observability platform, já existia evidência



☕ 01:38 — Quando o gráfico mente, mas o SMF não

Todo mainframer aprende cedo uma verdade incômoda:
logs contam histórias, métricas sugerem hipóteses, mas o SMF registra fatos.

Enquanto o mundo distribuído ainda debate o que é single source of truth,
o z/OS já resolveu isso há décadas — e deu o nome de System Management Facility.


🧬 Um pouco de história (quando observabilidade não tinha marketing)

O SMF nasceu para:

  • auditoria

  • cobrança

  • capacidade

  • performance

  • rastreabilidade

Não para “monitorar bonito”,
mas para provar o que aconteceu.

📌 Comentário Bellacosa:
SMF nunca foi sexy. Foi confiável. E isso envelhece melhor.


🔍 O que o SMF realmente é (traduzindo para cloudês)

No mundo moderno:

  • Logs

  • Metrics

  • Traces

No z/OS:

  • Tudo isso… em um formato só

  • Com timestamp confiável

  • Com contexto de sistema

  • Com impacto mensurável

🔥 Tradução direta:
SMF é observabilidade com evidência jurídica.


🧠 SMF como “fonte de verdade”

Por que o SMF é a source of truth?

✔️ É gerado pelo sistema operacional
✔️ Não depende da aplicação “colaborar”
✔️ Não perde evento por backpressure
✔️ Não é amostrado
✔️ Não é opinativo

😈 Easter egg:
Se o SMF não viu, provavelmente não aconteceu.


📊 Comparação honesta: SMF x Observabilidade moderna

Observabilidade modernaSMF
Métricas amostradasDados completos
Traces instrumentadosEvidência sistêmica
Logs verbososRegistros estruturados
DashboardsCapacidade histórica
AlertasDiagnóstico pós-morte

📌 Comentário ácido:
Dashboard serve para avisar.
SMF serve para explicar.


🧭 Passo a passo mental: usando SMF como observabilidade

1️⃣ Coleta contínua (SMF ativo é pré-requisito)
2️⃣ Classificação por tipo (CPU, I/O, CICS, DB2, MQ…)
3️⃣ Correlação temporal
4️⃣ Análise de impacto real
5️⃣ Conclusão baseada em dado, não sensação

🔥 Regra de ouro:
Sem correlação, métrica vira superstição.


🧩 SMF e aplicações distribuídas (onde os mundos se encontram)

Hoje, arquiteturas são:

  • híbridas

  • distribuídas

  • event-driven

O SMF entra como:

  • referência de carga real

  • baseline de comportamento

  • âncora de verdade

📌 Exemplo prático:
Quando a API “fica lenta”, o SMF diz:

  • se foi CPU

  • se foi I/O

  • se foi concorrência

  • ou se foi culpa de quem chamou demais


📚 Guia de estudo para o mainframer moderno

Conceitos essenciais

  • Observabilidade ≠ Monitoramento

  • Correlação ≠ Alerta

  • Evidência ≠ Opinião

  • Capacidade ≠ Pico momentâneo

Exercício recomendado

👉 Pegue um incidente passado
👉 Releia só o SMF
👉 Ignore dashboards
👉 Reescreva a RCA

O resultado costuma ser… desconfortável — e correto.


🎯 Aplicações reais no mundo corporativo

  • Auditoria e compliance

  • Capacity planning sério

  • SRE corporativo

  • Integração com AIOps

  • Base para observabilidade híbrida

🔥 Comentário Bellacosa:
Todo AIOps sério começa com dado confiável.
E dado confiável tem sobrenome: SMF.


🖤 Epílogo — 03:27, incidente encerrado

Quando o ruído some,
quando o gráfico contradiz o discurso,
quando a RCA precisa sobreviver a auditoria…

é o SMF que fica.

El Jefe Midnight Lunch assina:
“Observabilidade é saber. SMF é provar.”

 

domingo, 1 de julho de 2012

🧱🔥 Resiliência explicada para quem já reconstruiu sistema no susto

 


🧱🔥 Resiliência explicada para quem já reconstruiu sistema no susto



04:41 — Introdução: quando tudo caiu… e você teve que levantar

Se você é mainframer e já reconstruiu sistema no susto, você não leu sobre resiliência — você viveu.
Foi aquela madrugada em que:

  • o batch não fechou,

  • a base ficou inconsistente,

  • o telefone não parava,

  • e alguém disse: “Tem que voltar hoje.”

Resiliência não é “não cair”.
É cair, levantar e continuar sem perder a alma do sistema.



1️⃣ O que é resiliência (sem frase de LinkedIn)

Resiliência é a capacidade de um sistema:

  • Absorver falhas

  • Continuar funcionando (mesmo degradado)

  • Se recuperar rapidamente

  • Aprender com o impacto

📌 Dialeto mainframe:

“Não importa o tamanho do estrago. O sistema volta.”


2️⃣ Um pouco de história: resiliência antes da cloud 🕰️

Antes de:

  • microservices,

  • containers,

  • multi-cloud,

já existia:

  • Sysplex

  • Fallback

  • Restart automático

  • Controle de ponto de consistência

😈 Easter egg histórico:
Checkpoint de batch era resiliência antes de virar palestra.


3️⃣ Resiliência ≠ Alta disponibilidade 🧠

Alta disponibilidade:

  • Evita parada

Resiliência:

  • Aceita que vai parar

  • Planeja a volta

  • Minimiza impacto

👉 Mainframer sempre soube:

“Disponível sem consistência é ilusão.”


4️⃣ Onde a resiliência mora nas aplicações distribuídas

  • Retry com critério

  • Timeout bem definido

  • Circuit breaker

  • Bulkhead

  • Fallback funcional

  • Reprocessamento

📎 Tradução raiz:

“Se falhar, não propaga. Isola e continua.”


5️⃣ Passo a passo para construir resiliência (modo Bellacosa)

1️⃣ Assuma que vai falhar
2️⃣ Defina o que pode falhar
3️⃣ Separe falha crítica de falha tolerável
4️⃣ Implemente contenção
5️⃣ Garanta reprocessamento
6️⃣ Teste recuperação
7️⃣ Documente
8️⃣ Treine
9️⃣ Repita

💣 Dica Bellacosa:
Sistema que só funciona em estado perfeito não é resiliente.


6️⃣ Reprocessamento: o herói esquecido 🦸

Mainframer conhece:

  • Restart step

  • Batch reentrante

  • Controle por chave

No mundo distribuído:

  • Replay de eventos

  • Dead letter queues

  • Compensações

😈 Easter egg:
Quem sabe reprocessar não tem medo de falha.


7️⃣ Guia de estudo para mainframers sobreviventes 📚

Conceitos

  • Resiliência

  • Falha parcial

  • Circuit breaker

  • Bulkhead

  • Retry com backoff

  • Eventual consistency

Ferramentas

  • Resilience4j

  • Istio

  • Kubernetes

  • Kafka

  • IBM MQ


8️⃣ Aplicações práticas no mundo real

  • Ambientes híbridos estáveis

  • Sistemas financeiros

  • Integração legado + cloud

  • Redução de incidentes graves

  • Continuidade de negócio

🎯 Mainframer resiliente vira arquiteto natural.


9️⃣ Curiosidades que só quem viveu entende 👀

  • Sistema que nunca falhou não foi testado

  • Restart é mais importante que start

  • Documentação de recuperação vale ouro

  • Treinamento salva madrugada

📌 Verdade dura:
Resiliência custa projeto, tempo e humildade.


🔟 Comentário final (06:22, café requentado)

Resiliência não é luxo.
É requisito mínimo para sistemas que importam.

Se você já:

  • Reconstruiu base sob pressão

  • Voltou sistema com gambiarra consciente

  • Aprendeu mais com falha do que com sucesso

Então você carrega resiliência no DNA.

🖤 El Jefe Midnight Lunch fecha com honra:
Sistemas fortes não são os que não caem. São os que sempre voltam.


 

sexta-feira, 29 de junho de 2012

O NOIVINHO DA QUADRILHA

 


O NOIVINHO DA QUADRILHA — UMA CRÔNICA BELLACOSA MAINFRAME
PARA O EL JEFE MIDNIGHT LUNCH

Vasculhar um arquivo de fotos antigas é como abrir um dataset sentimental: cada imagem é um registro, cada rosto um campo, cada memória um load module carregado direto da infância.
E no meio desse inventário do tempo, você encontrou ela:
a foto épica do noivo da quadrilha, um Vaguinho vestido com toda a elegância que só a década de 1970 conseguia produzir.
Terno remendado branco, gravata vermelha, chapéu de palha torto e aquele sorriso de quem não fazia ideia de que um dia se tornaria o cronista oficial do clã Bellacosa.

E como tudo na sua vida vem com história, essa não seria diferente.





1. A QUADRILHA RAIZ – QUANDO JUNHO ERA REALMENTE FRIO

Antes de o clima enlouquecer, junho era junho de verdade:

  • vento gelado cortando o rosto,

  • moletom grosso,

  • fogueira estalando na calçada,

  • e o cheirinho de milho verde misturado com fumaça.

  • neblina, garoa e geada

Era inverno, gente.
Inverno raiz, de fazer a criançada encostar a mão no caneco de quentão (sem álcool, claro) só pra esquentar os dedos.

As festas juninas vinham direto do DNA português, importada dos Santos Populares —
Santo Antônio, São João e São Pedro,
mas aqui ganharam pitadas afro-brasileiras, italianas, indígenas e imigrantes de todas as latitudes.
O resultado?
Uma mistura única que só o Brasil consegue fazer.



2. A ESCOLINHA DA DEPORTAÇÃO — O PRIMEIRO ESCÂNDALO BELLACOSA

A foto pertence àquela mesma escolinha onde eu, segundo registros pseudo-históricos, apócrifos e de testemunhos maternos, foi deportado por:

  • não parar quieto,

  • ser arteiro,

  • ser criativo demais,

  • ser inquieto,

  • e estar levando Dona Mercedes à beira da insanidade.

Mas após a deportação efetiva, os novos amiguinhos na escola, a disciplina da sala de aula, os primeiros contatos com o abcedário, veio o evento dos eventos, a dança Quadrilha.
E nela, você brilhou como o noivinho oficial do arraial.


3. O CASAMENTO CAIPIRA — A NOVELA DE JUNHO

A quadrilha sempre foi um micro teatro do Brasil profundo:

  • Tinha noivo, noiva, padre,

  • O delegado suspeito, para pegar o noivo fujão

  • os pais da noiva, que estavam ali para garantir o final da cerimonia

  • Convidados animados,

  • Emboscadas e fugas,

  • E aquele momento mágico:
    “É mentiraaaa!”

O roteiro era uma novela rural, uma pequena ópera cômica encenada por crianças com dentes faltando, vestidos floridos e bigode pintado com rolhas queimadas, simulando bigodes e barbas.

Eu ali, no meio, sendo levado até o altar improvisado, cercado de bandeirinhas coloridas, fogueira cenográfica e o olhar orgulhoso (e exausto) da Dona Mercedes, da minha madrinha vó Anna e o vô Pedro, tio Pedrinho, tia Mirian e familia.


4. AS BARRAQUINHAS — O PARQUE DE DIVERSÕES DOS ANOS 70

Junho era também o mês das barraquinhas de quermece:

🎣 Pescaria — com peixinhos de madeira e prêmios que iam de pirulito a dominó.
🎯 Tiro ao alvo — onde sempre tinha um primo que jurava ser “bom de mira”.
Arremesso de bolinha — que jamais derrubava as latas, misteriosamente coladas.
📦 Rifas e correio elegante — o Tinder da época.
🫥 Prisão — onde se pagava para prender o amigo e pagava para soltar.
(engenharia financeira brasileira desde sempre).


5. COMIDAS — O BANQUETE SAGRADO DE JUNHO

E como esquecer o cardápio sagrado?

  • Canjica cremosa,

  • Arroz-doce com canela,

  • Pamonha quentinha,

  • Milho assado,

  • Churrasquinho suspeito,

  • Quentão fumegante,

  • Paçoca e pé de moleque.

  • Vinho quente.

  • Sagu com vinho de São Roque

Cada aroma era um portal para a infância.



6. A FOTO — UM PEDAÇO DE TEMPO CONGELADO

Naquela imagem perdida no meu arquivo, o que vemos não é apenas um menininho vestido de noivo.

Vemos:

  • a escolinha que fez Dona Mercedes descansar um pouco,

  • o Brasil dos anos 70, entre o caos financeiro da ditadura militar e as famílias se virando para sobreviver,

  • a alegria simples das festas de bairro,

  • a energia daquele pequeno Vagner arteiro,

  • e um pedaço da alma Bellacosa que resistiu ao tempo.

A foto é prova de que a memória não é só um arquivo:
é um job que roda eternamente no sistema da gente.


7. EPÍLOGO — O NOIVO QUE SOBREVIVEU AO ARRAIAL E À VIDA

Hoje, adulto, olho essa foto e entendo:

Aquele noivinho da quadrilha é um símbolo.
Um lembrete do que sempre fui:

  • sonhador,

  • imaginativo,

  • inquieto,

  • criador de histórias,

  • e dono de uma alma que, mesmo deportada,
    sempre encontra caminho para continuar pulando fogueiras.

Porque  aprendi a dançar a quadrilha da vida…
aprendi também a desviar do delegado, da ponte quebrada, da cobra, do tombo, das armadilhas e dos sustos —
e ainda dar risada no caminho.




segunda-feira, 18 de junho de 2012

💥 Chaos Engineering explicado para quem já derrubou produção sem querer

 


💥 Chaos Engineering explicado para quem já derrubou produção sem querer



03:18 — Introdução: quando o caos não era planejado

Se você é mainframer e já derrubou produção “sem querer”, parabéns:
você praticou Chaos Engineering na forma primitiva, dolorosa e não documentada.

A diferença entre o passado e hoje é simples:

  • Antes: o caos acontecia quando dava ruim

  • Agora: o caos é induzido de propósito, com método, horário marcado e rollback

Chaos Engineering não é vandalismo técnico.
É engenharia preventiva para sistemas distribuídos.


 

1️⃣ O que é Chaos Engineering (sem bravata)

Chaos Engineering é a prática de:

Introduzir falhas controladas em produção
para verificar se o sistema realmente aguenta o que diz aguentar.

Objetivo:

  • Descobrir fragilidades antes do cliente

  • Validar resiliência

  • Reduzir surpresas às 03h da manhã

📌 Tradução mainframe:

“Vamos simular a queda da LPAR… mas com aviso e plano.”


2️⃣ Um pouco de história (sim, isso tem pedigree)

  • Conceito popularizado pela Netflix com o Chaos Monkey

  • Nasceu porque microsserviços + cloud = falha inevitável

  • Inspirado em práticas antigas de engenharia de confiabilidade

😈 Easter egg histórico:
Mainframe já fazia “chaos” quando:

  • Testava DR

  • Simulava queda de região

  • Desligava link para validar contingência

Só não chamava assim.


3️⃣ Por que caos é obrigatório em aplicações distribuídas 🧠

Aplicações distribuídas:

  • Dependem de rede

  • Dependem de serviços externos

  • Escalam horizontalmente

  • Têm falhas parciais

👉 Nada falha inteiro. Falha em pedaços.

📎 Mainframer sabe:
Falha parcial é pior que parada total — porque engana.


4️⃣ Tipos de caos (todos você já viveu)

🔥 Infraestrutura

  • Nó cai

  • Disco some

  • CPU satura

🔥 Rede

  • Latência aumenta

  • Pacote some

  • Timeout aleatório

🔥 Aplicação

  • Serviço responde lento

  • Erro intermitente

  • Consumo de memória crescente

😈 Easter egg:
Quando alguém rodou batch pesado fora da janela… foi caos não planejado.


5️⃣ O erro clássico: “isso nunca vai acontecer” 😬

Toda tragédia começa com:

  • “Esse serviço é estável”

  • “A rede nunca cai”

  • “Esse nó é redundante”

  • “Nunca deu problema”

Chaos Engineering responde:

“Então vamos provar.”


6️⃣ Passo a passo para fazer Chaos Engineering sem ser demitido

1️⃣ Defina o comportamento normal
2️⃣ Escolha uma hipótese
“Se o nó cair, o sistema continua”
3️⃣ Prepare observabilidade
4️⃣ Limite o escopo
5️⃣ Introduza a falha
6️⃣ Observe
7️⃣ Documente
8️⃣ Corrija
9️⃣ Repita

💣 Dica Bellacosa:
Sem rollback, não é engenharia — é suicídio profissional.


7️⃣ Guardrails: o que mainframer já sabe fazer

  • Janela controlada

  • Comunicação clara

  • Monitoramento ativo

  • Plano de reversão

  • Registro pós-teste

📌 Curiosidade:
Change Management não atrapalha caos.
Ele evita caos desnecessário.


8️⃣ Guia de estudo para mainframers curiosos 📚

Conceitos-chave

  • Chaos Engineering

  • Falha parcial

  • Resiliência

  • Error Budget

  • Blast Radius

Ferramentas modernas

  • Chaos Monkey

  • Gremlin

  • LitmusChaos

  • Testes de DR


9️⃣ Aplicações práticas no mundo real

  • Validar arquitetura distribuída

  • Testar autoscaling

  • Avaliar alertas

  • Treinar times

  • Evitar incidentes reais

🎯 Mainframer que domina caos vira arquiteto respeitado.


🔟 Curiosidades que só veterano entende 👀

  • Sistema que nunca falhou é suspeito

  • Falha pequena salva de falha grande

  • Testar em produção dói menos que incidente real

  • Confiança sem teste é fé, não engenharia

😈 Easter egg final:
O melhor teste de caos é aquele que ninguém percebeu, mas tudo continuou funcionando.


11️⃣ Comentário final (05:59, sol nascendo)

Chaos Engineering não é destruir.
É ensinar o sistema a sobreviver.

Se você já:

  • Derrubou produção sem querer

  • Aprendeu mais com falha do que com sucesso

  • Criou workaround às pressas

Então você já entendeu o espírito.

🖤 El Jefe Midnight Lunch conclui:
Quem não testa o caos, vira vítima dele.