Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

 

Bellacosa Mainframe e divida tecnica, engenharia do caos e resiliencia no mundo mainframe

☕ Um Café no Bellacosa Mainframe

Technical Debt, Chaos Engineering e Resiliência no Mundo COBOL

Uma viagem dos cartões perfurados à engenharia de confiabilidade moderna

Existe uma curiosidade interessante sobre o universo Mainframe.

Boa parte dos desenvolvedores mais jovens acredita que sistemas COBOL foram escritos uma única vez, colocados em produção em algum momento dos anos 80 e simplesmente ficaram funcionando até hoje, imutáveis, como fósseis tecnológicos preservados em um museu digital.

A realidade é completamente diferente.

Poucas plataformas de tecnologia evoluíram tanto quanto o ecossistema IBM Z.

O hardware mudou.

O sistema operacional mudou.

Os compiladores mudaram.

As técnicas de desenvolvimento mudaram.

A forma de entregar software mudou.

As exigências regulatórias mudaram.

E os desenvolvedores também precisaram mudar.

Hoje falamos sobre APIs REST, Git, DevOps, Inteligência Artificial, Observabilidade, Chaos Engineering e Cloud Native. Entretanto, curiosamente, os sistemas que movimentam bilhões de dólares por dia continuam sendo executados por programas COBOL escritos há décadas.

Seria isso uma contradição?

Na verdade, não.

Talvez seja justamente uma demonstração de sucesso.

O primeiro legado não foi um erro

Em 1959 nasceu o COBOL.

Naquela época não existiam metodologias ágeis.

Não existia internet.

Não existiam smartphones.

Muitos programas eram escritos em cartões perfurados.

Armazenamento era caro.

Memória era limitada.

CPU era um recurso precioso.

As equipes construíam software pensando em algo muito importante:

Confiabilidade.

A aplicação precisava funcionar.

Sempre.

Mesmo que demorasse algumas horas para processar milhares de contas bancárias durante a madrugada.

Foi nesse ambiente que nasceu uma cultura extremamente disciplinada.

Documentação.

Padrões.

Controle de mudanças.

Testes.

Auditorias.

Processos.

Talvez os desenvolvedores daquela época não soubessem, mas estavam criando alguns dos primeiros conceitos de Engenharia de Confiabilidade.

Technical Debt: a dívida que todos nós fazemos

Em 1992, Ward Cunningham criou uma analogia brilhante.

Ele comparou decisões de desenvolvimento com empréstimos bancários.

Imagine que você precise entregar um sistema até sexta-feira.

Você poderia construir uma solução perfeita.

Ou poderia desenvolver algo funcional, mais simples, entregando rapidamente.

Você ganha velocidade.

Mas assume uma dívida.

E como toda dívida, ela possui juros.

Esses juros aparecem de várias formas.

Mais bugs.

Mais incidentes.

Mais retrabalho.

Maior consumo de CPU.

Maior dificuldade de manutenção.

Menor velocidade de inovação.

No Mainframe isso acontece frequentemente.

Talvez exista um programa COBOL com 25 mil linhas.

Talvez exista um COPYBOOK criado em 1987.

Talvez apenas um profissional conheça determinada aplicação.

Tudo isso representa dívida técnica.

O problema não é possuir dívida.

O problema é não saber que ela existe.

Nem toda dívida é ruim

Muitos desenvolvedores iniciantes acreditam que Technical Debt sempre significa erro.

Não é verdade.

Às vezes ela é estratégica.

Um banco pode precisar adequar sistemas rapidamente para atender uma nova regulamentação do BACEN.

Uma seguradora pode precisar disponibilizar um novo produto imediatamente.

Uma fintech pode lançar um MVP para validar mercado.

Nesses casos, assumir dívida técnica pode ser perfeitamente aceitável.

Desde que exista um plano para pagá-la posteriormente.

E aqui encontramos uma das primeiras lições importantes para um desenvolvedor COBOL júnior:

Escreva código pensando que alguém precisará entendê-lo daqui a dez anos.

Esse alguém pode ser você mesmo.

O mito da reescrita completa

Existe uma frase bastante comum em empresas:

"Precisamos jogar tudo fora."

Geralmente essa frase surge quando o ambiente está muito complexo.

Mas a IBM apresenta uma visão diferente.

Você não precisa substituir quarenta anos de sistemas.

Você pode modernizar gradualmente.

Esse conceito ficou conhecido como Strangler Pattern.

Imagine um sistema COBOL que processa contas correntes.

Ele continua funcionando.

Mas uma nova camada é criada.

z/OS Connect.

APIs REST.

Microserviços.

Containers.

Aplicações Java.

Python.

Inteligência Artificial.

O COBOL permanece processando transações críticas.

As aplicações modernas apenas consomem seus serviços.

A dívida começa a diminuir sem que seja necessário desligar o coração operacional da empresa.

Testes automatizados são seus melhores amigos

Durante muitos anos, testar em Mainframe significava reservar uma janela de homologação.

Executar jobs.

Analisar relatórios.

Esperar dias.

Hoje isso mudou.

Ferramentas como zUnit permitem criar testes automatizados.

Jenkins integra pipelines.

GitHub Actions executa validações.

DBB facilita builds.

Zowe aproxima o mundo Mainframe das práticas DevOps modernas.

Se você está começando em COBOL, desenvolva o hábito de pensar:

"O que acontece se o CPF estiver inválido?"

"E se a data vier vazia?"

"E se houver overflow?"

Programadores experientes não escrevem apenas funcionalidades.

Eles escrevem confiança.

Code Review: aprendendo com outros desenvolvedores

Uma das melhores maneiras de evoluir tecnicamente é revisar código.

Olhar programas COBOL antigos.

Analisar SQL.

Entender JCLs.

Perguntar.

Questionar.

Aprender.

Muitos problemas são identificados antes mesmo de chegar à produção.

Um cursor esquecido.

Um COMMIT ausente.

Um SORT desnecessário.

Uma consulta DB2 sem índice adequado.

Dois pares de olhos normalmente enxergam mais do que um.

Refatoração não significa reescrever

Refatorar é melhorar.

Não é destruir.

Não é começar do zero.

Pequenas melhorias acumuladas ao longo do tempo fazem enorme diferença.

Renomear variáveis.

Extrair rotinas.

Separar módulos.

Eliminar GOTO.

Criar serviços reutilizáveis.

Transformar programas gigantes em componentes menores.

Refatoração contínua é uma das formas mais eficientes de pagar Technical Debt.

Observabilidade: enxergando o que realmente acontece

Existe uma frase bastante conhecida:

Se você não consegue medir, não consegue melhorar.

No mundo IBM Z temos ferramentas extraordinárias.

SMF.

RMF.

OMEGAMON.

Instana.

Grafana.

Elas permitem compreender:

CPU.

I/O.

Latência.

Filas.

Conexões.

Transações.

Antes de corrigir qualquer problema, precisamos enxergá-lo.

Observabilidade é a base da engenharia moderna.

Chaos Engineering: quebrando para aprender

Talvez o conceito mais surpreendente para desenvolvedores COBOL seja Chaos Engineering.

A ideia surgiu popularmente na Netflix.

Mas a IBM mostra que ela pode ser aplicada em praticamente qualquer ambiente.

O princípio é simples.

Não espere uma falha em produção.

Provoque pequenas falhas.

Aprenda.

Corrija.

Teste novamente.

Por exemplo:

O que acontece se o IMS Connect ficar indisponível?

Se a fila MQ atingir 95% de ocupação?

Se um membro do Sysplex parar?

Se o DB2 responder lentamente?

Chaos Engineering não significa desligar servidores aleatoriamente.

É ciência.

Você cria uma hipótese.

Executa um experimento controlado.

Observa.

Aprende.

Melhora.

Repete.

Resiliência é um investimento

A IBM utiliza uma analogia muito interessante.

Imagine um ciclista.

Ele pode sair apenas com a bicicleta.

Ou levar uma bomba de ar.

Kit de reparo.

Câmara reserva.

Pneu reserva.

Carro de apoio.

Mecânico.

Quanto maior a disponibilidade desejada, maior será o custo.

Em tecnologia ocorre exatamente o mesmo.

Alta disponibilidade.

Disaster Recovery.

Cyber Recovery.

Backups.

Replicação.

GDPS.

Sysplex.

Active-Active.

Tudo possui custo.

O objetivo não é atingir disponibilidade infinita.

O objetivo é encontrar equilíbrio entre risco, orçamento e necessidade do negócio.

O desenvolvedor COBOL de 2026

O profissional COBOL moderno não é apenas alguém que conhece MOVE, PERFORM e READ.

Ele entende Git.

Conhece APIs.

Aprende DevOps.

Sabe interpretar métricas.

Participa de revisões.

Automatiza testes.

Compreende observabilidade.

Conhece conceitos de segurança.

Entende resiliência.

Estuda Inteligência Artificial.

E principalmente, continua cultivando algo que sempre esteve presente no universo Mainframe:

Disciplina técnica.

Os sistemas que movimentam bilhões de transações diariamente não permanecem relevantes por acaso.

Eles permanecem relevantes porque existem profissionais dispostos a compreender o passado, melhorar continuamente o presente e testar constantemente o futuro.

E talvez seja exatamente essa a maior lição do Mainframe.

Tecnologia muda.

Ferramentas mudam.

Buzzwords mudam.

Mas excelência em engenharia continua sendo atemporal.

E isso, felizmente, nunca sai de moda.

Até o próximo café.

☕ Bellacosa Mainframe

Bellacosa Mainframe Network

Siga nossas newsletters e comunidades no LinkedIn

☕ Um Café no Bellacosa Mainframe Subscribe on LinkedIn

🚀 COBOL Jr. Subscribe on LinkedIn

💻 Bellacosa Mainframe Follow Company

🟩 COBOL Life Follow Showcase

 

Bellacosa Mainframe e o capacity planning aplicado a pensão alimenticia

☕ Um Café no Bellacosa Mainframe

O Homem que Resolveu a Pensão com Capacity Planning

Ou: quando o Red Team encontrou uma vulnerabilidade no ambiente familiar, o Blue Team chamou o advogado, o WLM redistribuiu os recursos — e o CAB aprovou uma mudança que exigia urologista

---

Existem histórias que começam num tribunal.

Outras começam num casamento.

Algumas começam com uma decisão ruim tomada às três da manhã.

Esta começa como quase todas as grandes histórias da civilização ocidental deveriam começar:

num boteco, em Itatiba, com uma Original sobre a mesa.

Não vou dar nomes porque nomes estragam excelentes histórias e enriquecem advogados.

Diremos apenas que nosso protagonista era um sujeito normal.

Trabalhava.

Tinha esposa.

Tinha filhos.

Pagava contas.

Provavelmente reclamava do preço da gasolina.

Talvez discutisse futebol.

Nada que justificasse abertura de incidente no ServiceNow.

Até que um dia o ambiente de produção recebeu uma atualização não prevista no roadmap.

Havia um filho fora do casamento.

E, com ele, chegou uma palavra capaz de transformar qualquer mesa de bar brasileira numa banca examinadora da Faculdade de Direito:

pensão.

Imediatamente aparece o especialista.

Ele sempre aparece.

Pode ser o dono do bar.

Pode ser o sujeito da mesa ao lado.

Pode ser o cunhado do primo do padeiro.

Mas aparecerá.

— Pensão é trinta por cento.

Não.

Respire.

Pegue sua cerveja.

Não existe uma lei brasileira dizendo que pensão alimentícia é obrigatoriamente 30% ou 1/3 da renda.

O Código Civil determina que os alimentos sejam fixados considerando as necessidades de quem os recebe e os recursos de quem deve prestá-los. O valor pode ser percentual, quantia fixa ou adotar outros critérios conforme o caso.

O próprio STJ tem inúmeros casos com percentuais diferentes, e recentemente reiterou que alterações familiares, inclusive nascimento de outros filhos, não provocam automaticamente redução: é necessário demonstrar concretamente mudança na capacidade financeira.

Portanto:

não existe SYS1.PARMLIB(PENSAO30).

Mas experimente explicar isso depois da segunda Original.

Boa sorte.

---

🍺 1. O workload que ninguém colocou no capacity planning

Nosso protagonista já tinha filhos dentro do casamento.

Essas crianças obviamente consumiam recursos.

Comida.

Escola.

Roupa.

Médico.

Transporte.

Casa.

Conta de luz.

Tênis que inexplicavelmente deixa de servir três semanas depois de comprado.

Material escolar cujo preço sugere que o caderno foi produzido artesanalmente por monges suíços.

Era um workload perfeitamente real.

Só havia uma diferença.

Esses custos estavam dentro da vida doméstica.

Não chegavam todo mês acompanhados de uma ordem judicial dizendo:

EXEC PGM=PENSAO

Então aparece outro filho, de outro relacionamento, e aquela obrigação passa a ter representação jurídica explícita.

Percentual.

Data.

Processo.

Valor.

Prazo.

Comprovante.

Subitamente nosso amigo descobriu uma das grandes verdades dos sistemas complexos:

Aquilo que existe e aquilo que o sistema consegue enxergar não são necessariamente a mesma coisa.

Os filhos do casamento já consumiam CPU.

Mas boa parte dessa CPU estava escondida dentro do enorme address space chamado:

FAMÍLIA.

O novo workload chegou etiquetado.

Mensurado.

Monitorado.

Com SLA.

E execução judicial disponível caso o SLA não fosse cumprido.

O WLM doméstico começou a chiar.

---

🔴 2. Entra o Red Team

É aqui que nossos chimpanzés sóbrios entram na sala.

🐒 O chimpanzé jurídico abre o Código Civil.

🐒 O chimpanzé financeiro abre uma planilha.

🐒 O chimpanzé COBOL pergunta por que ninguém documentou aquilo antes.

🐒 O chimpanzé do bar tenta abrir outra Original e é imediatamente removido do War Room.

O Red Team recebe uma única missão:

encontre todas as maneiras pelas quais esse ambiente pode cair.

Primeira pergunta:

— O novo pagamento cabe no orçamento?

Talvez.

Segunda:

— E os filhos que já existiam?

Continuam existindo.

Terceira:

— O sistema está enxergando corretamente todas as obrigações?

Aí começa a ficar interessante.

A Constituição brasileira não admite filhos de primeira e segunda classe. Filhos havidos ou não dentro do casamento possuem os mesmos direitos e qualificações.

Portanto, juridicamente, não existe:

FILHO_PROD

e

FILHO_DEV

Todos entraram em produção.

Todos têm SLA.

E ninguém pode simplesmente executar:

CANCEL CHILD

porque a conta ficou inconveniente.

O problema então não era eliminar uma obrigação.

Era fazer o sistema enxergar todas as obrigações adequadamente.

---

🔵 3. Blue Team chamado às pressas

O Blue Team entrou.

E, como frequentemente ocorre quando o Red Team encontra algo realmente sério, ninguém estava sorrindo.

A solução não seria:

— Não pago.

Isso é equivalente a resolver falta de espaço em DASD desligando o catálogo.

Funciona maravilhosamente até o telefone tocar.

Também não seria:

— Tenho outros filhos, então automaticamente pago menos.

Não funciona assim.

O STJ já deixou claro que constituir outra família ou ter outros filhos não basta, sozinho, para reduzir alimentos anteriormente fixados. É necessária demonstração concreta de alteração financeira.

Além disso, valores diferentes para filhos de relacionamentos diferentes podem existir quando as circunstâncias forem diferentes — por exemplo, necessidades distintas ou capacidades econômicas diferentes dos responsáveis. Igualdade entre filhos não significa obrigatoriamente copiar o mesmo número em todas as linhas da planilha.

Portanto o Blue Team precisava fazer aquilo que todo bom Blue Team faz:

telemetria.

Quanto entra?

Quanto sai?

Quantos dependentes existem?

Quanto custa cada núcleo?

Quais obrigações já estão formalizadas?

Quais despesas estão escondidas dentro da operação cotidiana?

Não era glamour.

Era SMF familiar.

---

⚖️ 4. Quando o divórcio virou observabilidade

E então chegamos à parte que, contada rapidamente num boteco, parece uma piada jurídica.

Nosso protagonista se divorciou.

Calma.

Não estamos dizendo:

“Divórcio reduz pensão.”

Não reduz automaticamente.

Também não estamos oferecendo:

“Faça um divórcio fictício e economize.”

Isso seria outro tipo de história, provavelmente terminando numa sala com iluminação fluorescente ruim.

O que aconteceu naquele caso concreto, segundo a história que chegou à nossa mesa, foi mais interessante.

Com o divórcio, obrigações que anteriormente estavam diluídas dentro da vida matrimonial passaram a ficar muito mais formalmente identificadas.

Os demais filhos continuavam sendo filhos.

Continuavam precisando de recursos.

Mas agora a arquitetura financeira familiar aparecia de maneira diferente perante o sistema.

Aquilo que antes era:

DESPESAS_GERAIS_DA_CASA

passou a poder ser apresentado de maneira muito mais explícita como:

OBRIGAÇÕES_COM_FILHO_A

OBRIGAÇÕES_COM_FILHO_B

OBRIGAÇÕES_COM_FILHO_C

Eis o momento em que nosso programador imaginário bate na mesa:

— AHÁ!

Não foi criado dinheiro novo.

Não desapareceram necessidades.

Mudou a observabilidade.

A capacidade do alimentante passou a ser analisada diante de um conjunto mais claramente demonstrável de obrigações.

O Código Civil inclusive permite revisão de alimentos quando muda a situação financeira de quem paga ou de quem recebe.

Era quase um caso de performance.

Você olha para o sistema e acredita que determinado address space está consumindo 30%.

Depois ativa a instrumentação correta.

Descobre que existem vários workloads concorrendo pelos mesmos recursos.

O problema não era necessariamente excesso de CPU.

Era capacity planning ruim.

---

🧮 5. WLM Family Edition

Imagine agora o WLM olhando para aquilo.

Temos recursos finitos.

Temos workloads legítimos.

Temos diferentes necessidades.

Temos prioridades constitucionais.

E temos alguém na mesa gritando:

— MAS É 30%!

O WLM responde:

“Cidadão, saia da sala.”

Não existe matemática mágica capaz de transformar Direito de Família numa divisão de pizza.

Se alguém ganha R$ 10.000, não significa automaticamente:

R$ 3.000 para criança A.

Depois outra aparece:

mais R$ 3.000.

Depois outra:

mais R$ 3.000.

Depois:

— O senhor ainda precisa comer?

Porque necessidades e possibilidades precisam ser examinadas concretamente.

Da mesma maneira, ninguém pode simplesmente dizer:

— Tenho quatro filhos, então cada um recebe exatamente 25% do orçamento infantil.

Um deles pode ter tratamento médico.

Outro pode estudar em circunstâncias diferentes.

Outro pode morar em cidade mais cara.

As condições econômicas dos respectivos pais e mães também importam.

O STJ já aceitou expressamente valores diferentes para filhos de relacionamentos distintos justamente quando as condições concretas justificavam.

O WLM não distribui tudo com ROUND ROBIN.

Ainda bem.

---

🔴 6. O Red Team não estava satisfeito

Depois de muito trabalho, a arquitetura aparentemente estabilizou.

Orçamento reorganizado.

Obrigações visíveis.

Advogados fazendo aquilo que advogados fazem.

Documentos.

Peticionamentos.

Planilhas.

Audiências.

Prazos.

Nosso protagonista respirou.

Blue Team abriu o dashboard.

Tudo verde.

CPU normal.

Paging controlado.

Sem ABENDs.

O gerente declarou:

INCIDENT RESOLVED.

O Red Team levantou a mão.

Silêncio.

Sempre desconfie quando o Red Team levanta a mão depois de todo mundo dizer que acabou.

— Temos uma vulnerabilidade residual.

Blue Team:

— Qual?

Red Team:

— O sistema ainda aceita novos workloads.

Ninguém disse nada.

O arquiteto conferiu o diagrama.

Era verdade.

Todo aquele esforço havia resolvido o incidente atual.

Mas a classe de incidente permanecia tecnicamente possível.

Novo relacionamento.

Nova gravidez.

Novo filho.

Nova obrigação.

Novo capacity planning.

Novo advogado.

Nova Original.

O Red Team escreveu no quadro:

ROOT CAUSE NOT ELIMINATED

Agora nosso amigo precisava tomar uma decisão.

Plano B?

Plano C?

Plano D?

Até Z?

Ou eliminar a superfície de ataque?

---

🏥 7. O Blue Team chamou o urologista

É aqui que a história deixa de ser Direito de Família e entra definitivamente para a história da engenharia.

Nosso protagonista analisou o post-mortem.

Leu o RCA.

Verificou o impacto.

Avaliou recorrência.

E decidiu:

vasectomia.

Pausa dramática.

Essa palavra precisa ficar sozinha.

Porque qualquer escritor que enterre uma punchline dessas dentro de um parágrafo merece perder acesso ao editor.

VASECTOMIA.

😂

O homem não aumentou o orçamento jurídico.

Não contratou advogado em regime de plantão.

Não criou um novo fundo de contingência.

Não implementou mais uma camada de observabilidade.

Ele simplesmente decidiu:

“Novos deployments desta categoria não serão mais necessários.”

---

🛠️ 8. Change Request URO-001

Naturalmente, nenhuma alteração séria entra em produção sem CAB.

Portanto imaginemos a documentação.

CHANGE ID: URO-001
Descrição: alteração da infraestrutura reprodutiva.
Categoria: Preventive Maintenance.
Motivo: redução permanente da superfície de risco.
Impacto esperado: bloqueio de novos provisionamentos biológicos.
Downtime: limitado.
Rollback: não tratar como trivial.
Owner: proprietário da infraestrutura.
Implementador: urologista devidamente habilitado.
Validação: espermograma conforme orientação médica.
Status: CHANGE APPROVED.

Aqui cabe um parêntese sério dentro da palhaçada.

Vasectomia não produz esterilidade imediatamente. Após o procedimento ainda pode haver espermatozoides residuais, razão pela qual deve ser seguido o acompanhamento médico e realizada a confirmação apropriada antes de abandonar outros métodos contraceptivos.

Sim.

Até o nosso CAB de boteco tem ambiente de homologação.

---

🐒 9. Os chimpanzés fazem o post-mortem

Chimpanzé jurídico:

— Obrigações existentes continuam existindo.

Correto.

Chimpanzé financeiro:

— A mudança não reduz retroativamente nenhuma obrigação.

Correto.

Chimpanzé de segurança:

— Mas reduz determinada classe de risco futuro.

Muito bem.

Chimpanzé COBOL:

— Podemos fechar o ticket?

Ainda não.

Chimpanzé do bar:

— AGORA posso abrir a Original?

Pode.

🍺 PSHHHT.

Começa o post-mortem.

O objetivo do post-mortem não é descobrir culpados.

Essa é uma diferença importante.

Filhos não são incidentes.

Crianças não são despesas indesejadas numa planilha.

E mulheres ou homens não precisam ser transformados em atacantes para que alguém pratique gestão de risco.

O incidente, aqui, é a ausência de planejamento diante das consequências possíveis das próprias decisões.

Essa diferença salva a história de virar chorume de rede social.

Red Team não significa:

“Todas as mulheres tentarão alguma coisa.”

Significa:

“Existe algum cenário possível capaz de causar um impacto que preciso compreender?”

Blue Team não significa:

“Como escapar das responsabilidades?”

Significa:

“Como cumprir responsabilidades sem destruir a estabilidade do restante do ambiente?”

Chaos Engineering não significa desejar o desastre.

Significa perguntar:

“Se acontecer, o sistema continua funcionando?”

---

🧠 10. O verdadeiro Chaos Engineering

É aqui que nossa história volta àquelas páginas imaginárias guardadas na gaveta.

O sujeito verdadeiramente paranoico pergunta:

— Qual é a probabilidade?

O Chaos Engineer responde:

— Não estou perguntando isso ainda.

Primeiro:

“É possível?”

Depois:

“Qual seria o impacto?”

E então:

“Tenho como absorver?”

Existem acontecimentos raríssimos que não merecem nenhum preparo porque o impacto seria pequeno.

Existem outros raríssimos cujo impacto seria tão gigantesco que algum plano B é absolutamente razoável.

Você não precisa acreditar que o datacenter pegará fogo amanhã para manter extintores.

Você não precisa acreditar que todos os discos falharão para fazer backup.

Você não precisa acreditar que seu relacionamento acabará para manter documentos patrimoniais organizados.

Você não precisa acreditar que terá outro filho para pensar seriamente sobre contracepção.

Planejamento não é previsão.

É humildade diante da possibilidade de que o universo tenha senso de humor.

---

🔴🔵 11. Red Team versus Blue Team

Vamos colocar os dois lados frente a frente.

RED TEAM: E se surgir uma obrigação financeira inesperada?

BLUE TEAM: Reserva e capacidade financeira.

RED TEAM: E se existirem outras obrigações que o sistema não esteja enxergando adequadamente?

BLUE TEAM: Documentação.

RED TEAM: E se a situação mudar?

BLUE TEAM: Revisão pelos meios legais adequados.

RED TEAM: E se o primeiro advogado estiver errado?

BLUE TEAM: Segunda opinião.

RED TEAM: E se outro filho nascer?

BLUE TEAM: Contracepção.

RED TEAM: E se a contracepção falhar?

Blue Team olha lentamente para o urologista.

Red Team fecha o notebook.

— Sem mais perguntas.

😂

---

☕ 12. A grande lição que ninguém pediu

Existe uma tendência moderna de chamar qualquer preparação para cenário desagradável de paranoia.

Talvez seja.

Mas existe uma diferença entre paranoia improdutiva e arquitetura resiliente.

A primeira faz você viver esperando o ataque.

A segunda permite viver normalmente porque o ataque não precisa mais ocupar sua cabeça todos os dias.

Esse talvez seja o detalhe mais bonito do bom planejamento.

O plano fica na gaveta.

Você não acorda toda manhã lendo o Disaster Recovery Manual.

Você simplesmente sabe que ele existe.

Relacionamentos continuam sendo relacionamentos.

Filhos continuam sendo filhos.

Amor continua sendo amor.

Mas ninguém precisa entregar acesso SPECIAL ao RACF apenas para provar confiança.

O mundo adulto tem contratos, seguros, backups, testamentos, reservas, redundâncias, procedimentos médicos e advogados justamente porque confiar na vida não significa presumir que ela sempre obedecerá ao roteiro.

---

🍺 Epílogo — Garçom, outra Original

Voltamos ao boteco.

A história terminou.

Na mesa havia copos vazios, guardanapos rabiscados e provavelmente um diagrama de arquitetura que jamais deveria ser apresentado numa conferência da IBM.

Alguém perguntou:

— Então depois do divórcio, advogado, pensão, revisão e toda aquela confusão... o que ele fez?

Nosso narrador bebeu um gole.

Olhou para a mesa.

E respondeu:

— Vasectomia.

Silêncio.

Um segundo.

Dois.

Alguém começou a rir.

Outro quase cuspiu a cerveja.

Um terceiro bateu na mesa.

E eu percebi que aquele homem havia aplicado à própria vida uma das lições mais antigas da engenharia:

Você pode passar a existência inteira criando planos B, C, D, E até Z.

Ou, em determinados casos, pode eliminar definitivamente uma classe inteira de incidente.

O Red Team encerrou o teste.

O Blue Team atualizou o runbook.

O WLM estabilizou os workloads existentes.

O CAB fechou a mudança.

O urologista recebeu seus honorários.

E ninguém mexeu nos direitos de nenhuma criança.

Olhei para o garçom.

— Amigo...

Ele já sabia.

Pegou outra garrafa.

— Original?

— Original.

Porque algumas histórias terminam com uma sentença judicial.

Outras terminam com uma lição de vida.

Esta terminou com uma cerveja e um Change Request aprovado.

E, convenhamos:

para uma retrospectiva de produção, não foi um resultado ruim.

---

Nota jurídica: esta é uma crônica inspirada em situação hipotética/anedótica e não constitui orientação jurídica individual. No Brasil, não há percentual legal obrigatório de 30% para pensão alimentícia; valores dependem das circunstâncias concretas, especialmente necessidades do alimentando e capacidade de quem presta os alimentos. Filhos havidos dentro ou fora do casamento possuem igualdade jurídica. Alterações relevantes na situação financeira podem fundamentar pedido judicial de revisão, mas divórcio ou nascimento de outros filhos não produzem redução automática.

 

Bellacosa Mainframe e o Chaos Monkey

☕ O Holocron do Chaos Monkey

Como um Pequeno Macaco da Netflix Ensinou ao Mundo Algo que os Sysprogs do IBM Z Já Praticavam Há Décadas

Existe um momento curioso na jornada de todo Padawan COBOL, Sysprog, arquiteto ou profissional de infraestrutura em que ele descobre uma verdade desconfortável.

Nenhum sistema é indestrutível.

Nenhuma arquitetura é perfeita.

Nenhum diagrama bonito no PowerPoint é capaz de impedir que um disco falhe, uma fibra seja rompida, uma aplicação entre em loop, uma região CICS desapareça ou uma LPAR resolva tirar férias em plena Black Friday.

Foi exatamente dessa constatação que nasceu, em 2011, uma das ideias mais influentes da engenharia moderna de software.

Um pequeno macaco digital.

Travesso.

Imprevisível.

Sem qualquer respeito pelo conforto psicológico dos administradores de sistemas.

Seu nome era Chaos Monkey.

Criado pela Netflix como parte do projeto Simian Army, o Chaos Monkey possuía uma missão aparentemente absurda:

Derrubar servidores deliberadamente.

Mas havia uma razão bastante séria por trás dessa atitude quase sociopata.

A Netflix havia aprendido uma lição dolorosa em 2008, após sofrer problemas importantes de indisponibilidade em sua infraestrutura. A empresa percebeu que esperar que a primeira falha ocorresse naturalmente era uma péssima estratégia.

Era melhor provocar pequenos desastres controlados.

Observar.

Medir.

Aprender.

Corrigir.

Repetir.

Nascia assim o movimento conhecido como Chaos Engineering.

No entanto, enquanto boa parte do mercado enxergava aquilo como uma revolução tecnológica, muitos profissionais do IBM Z apenas levantaram uma sobrancelha, tomaram um gole de café e pensaram:

Interessante...

Nós fazemos algo parecido há décadas.

Sysprogs veteranos conhecem bem essa filosofia.

Testar GDPS.

Executar Disaster Recovery.

Parar uma região CICS.

Desligar um membro Db2 Data Sharing.

Simular perda de um Queue Manager.

Trocar caminhos FICON.

Validar políticas do WLM.

Testar SA z/OS.

Mover workloads.

Executar IPLs programadas.

No fundo, a grande diferença talvez seja apenas de nomenclatura.

A Netflix colocou um macaco sorridente em apresentações corporativas.

O Mainframe chamou isso de plano de contingência, teste de disponibilidade, procedimento operacional ou simplesmente terça-feira à tarde.

Ao longo desta série do ☕ Um Café no Bellacosa Mainframe, acompanhamos a jornada de um Padawan COBOL descobrindo que resiliência não significa impedir falhas.

Significa aprender a conviver com elas.

Automatizá-las.

Medi-las.

Compreendê-las.

E principalmente garantir que o usuário continue tomando seu café tranquilamente enquanto os engenheiros observam gráficos, métricas e dashboards piscando em uma sala de guerra.

---

📖 Índice do Holocron do Chaos Monkey

Parte I

O Dia em que a Netflix Soltou um Macaco no Datacenter e Descobriu Algo que os Sysprogs do IBM Z Já Sabiam Há Décadas

Nesta primeira jornada, exploramos a origem do Chaos Monkey, a crise enfrentada pela Netflix em 2008, o nascimento do Simian Army, a filosofia de Adrian Cockcroft e os princípios fundamentais do Chaos Engineering, incluindo o conceito de Steady State, hipóteses de falha e a importância de provocar pequenos desastres antes que eles ocorram naturalmente.

https://eljefemidnightlunch.blogspot.com/2020/07/o-holocron-do-chaos-monkey-o-dia-em-que.html

---

Parte II

Como o Macaco Escolhe suas Vítimas, o Conceito de Blast Radius e as Técnicas Secretas dos Engenheiros da Netflix

No segundo capítulo, estudamos o funcionamento interno dos experimentos de caos, aprendendo conceitos essenciais como:

• Blast Radius;

• Observabilidade;

• Seleção controlada de componentes;

• Métricas de disponibilidade;

• Técnicas empregadas por SREs;

• Ferramentas modernas como Gremlin, LitmusChaos, Chaos Mesh e AWS Fault Injection Simulator.

Também acompanhamos estudos de caso inspirados em arquiteturas bancárias e serviços digitais.

https://eljefemidnightlunch.blogspot.com/2020/08/o-holocron-do-chaos-monkey-como-o.html

---

Parte III

Quando o Macaco Entra no IBM Z: Será que o Mainframe Precisava Mesmo de um Chaos Monkey?

Na terceira etapa, levamos o Chaos Engineering para dentro do universo IBM Z.

Analisamos como os conceitos de caos podem ser aplicados em:

• CICSplex;

• Db2 Data Sharing;

• MQ Queue Sharing Groups;

• WLM;

• Parallel Sysplex;

• Coupling Facilities;

• GDPS;

• SA z/OS;

• NetView;

• z/OSMF;

• Ansible for IBM Z.

Descobrimos que muitos princípios defendidos pela Netflix já eram praticados há décadas pelos Sysprogs mais experientes.

https://eljefemidnightlunch.blogspot.com/2020/09/o-holocron-do-chaos-monkey-quando-o.html

---

Parte IV

Os Laboratórios Bellacosa Mainframe: Como um Sysprog Pode Injetar Caos no IBM Z Sem Ser Expulso da Sala de Guerra

Encerrando o Holocron, construímos uma coleção de laboratórios práticos voltados para ambientes IBM Z.

Entre os exercícios apresentados estão:

• Derrubar uma região CICS secundária;

• Simular a perda de um membro Db2 Data Sharing;

• Testar um MQ Queue Sharing Group;

• Alterar políticas do WLM;

• Simular indisponibilidade de uma LPAR;

• Testar Coupling Facilities;

• Automatizar experimentos utilizando SA z/OS, Ansible e z/OSMF.

Também apresentamos checklists, exemplos de playbooks, métricas recomendadas e um modelo de maturidade em Chaos Engineering para equipes de Sysprog.

https://eljefemidnightlunch.blogspot.com/2020/10/o-holocron-do-chaos-monkey-os.html

---

☕ A Última Reflexão do Bellacosa Mainframe

Talvez a maior contribuição do Chaos Monkey não tenha sido derrubar servidores.

Talvez tenha sido lembrar aos arquitetos modernos uma lição antiga que os profissionais do IBM Z conhecem há muito tempo:

Disponibilidade não é sorte.

Resiliência não é marketing.

Alta disponibilidade é a disciplina de transformar falhas inevitáveis em acontecimentos rotineiros, previsíveis e quase entediantes.

E se um pequeno macaco travesso puder nos ensinar isso, talvez ele mereça uma cadeira na próxima reunião de arquitetura... desde que fique longe do botão vermelho da produção. ☕🐵💻🚀

O Holocron do Chaos Monkey – Os Laboratórios Bellacosa Mainframe: Como um Sysprog Pode Injetar Caos no IBM Z Sem Ser Expulso da Sala de Guerra - Parte IV

 

Bellacosa Mainframe e o chaos monkey parte iv

☕ Um Café no Bellacosa Mainframe

O Holocron do Chaos Monkey – Parte IV

Os Laboratórios Bellacosa Mainframe: Como um Sysprog Pode Injetar Caos no IBM Z Sem Ser Expulso da Sala de Guerra

"Em produção todos são especialistas em alta disponibilidade. Em laboratório descobrimos quem realmente sabe recuperá-la."

---

O Café das 3 da Manhã e a Última Lição do Mestre

03h11.

A sala estava silenciosa.

O RMF Monitor III permanecia aberto.

OMEGAMON coletava estatísticas.

O SDSF exibia centenas de jobs.

MQ continuava movimentando mensagens.

Db2 processava commits.

CICS atendia milhares de transações.

O Padawan perguntou.

— Mestre...

— Sim?

— Já entendi a teoria.

— Já entendi o Blast Radius.

— Já entendi observabilidade.

— Já entendi o Parallel Sysplex.

— Mas...

— Como fazemos isso de verdade?

O velho Sysprog sorriu.

Abriu um caderno antigo.

Escrito na capa.

Bellacosa Chaos Labs

---

Filosofia dos Laboratórios

Objetivo:

Não quebrar ambientes.

Objetivo:

Aprender.

Medir.

Observar.

Melhorar.

---

Princípios.

Pequeno impacto

Rollback rápido

Equipe avisada

Métricas disponíveis

Documentação obrigatória

---

Laboratório 1

Chaos Monkey para CICS

---

Ambiente

CICSPLEX01

TOR01

TOR02

AOR01

AOR02

AOR03

FOR01

---

Hipótese

Posso perder AOR02.

Sem impacto.

---

Métricas

CPU

Task Rate

Response Time

Storage

SOS

Abends

---

Execução

Método 1

CEMT PERFORM SHUTDOWN

---

Método 2

CEMT SET REGION QUIESCED

---

Método 3

SA z/OS

INGREQ AOR02 STOP

---

Observar

OMEGAMON

RMF

CICS Explorer

SMF110

---

Resultado esperado

TOR redireciona.

Usuários continuam.

---

Hipótese validada

SIM

---

Laboratório 2

Chaos Monkey para Db2

---

Ambiente

DB2A

DB2B

DB2C

CF1

CF2

---

Hipótese

DB2B pode falhar.

---

Observar

GBP

IRLM

Claims

Commits

Threads

---

Simulação

-STOP DB2 MODE(QUIESCE)

---

ou

-STOP DB2

ambiente controlado.

---

Métricas

SMF 100

SMF101

IFCID

OMEGAMON

---

Verificar

Aplicações continuam.

Sim.

Não.

---

Laboratório 3

Chaos Monkey para MQ

---

Ambiente

MQA

MQB

MQC

QSG

---

Hipótese

MQB pode desaparecer.

---

Execução

STOP QMGR

---

Observar

Queue Depth

Channels

Persistent Messages

Restart

---

Ferramentas

MQ Explorer

MO71

OMEGAMON MQ

SMF115

---

Resultado

Mensagens preservadas.

---

Laboratório 4

Chaos Monkey para WLM

Talvez um dos mais interessantes.

---

Hipótese

Aplicação suporta degradação.

---

Situação

Service Class

HIGH

MEDIUM

LOW

---

Alteração

Política.

Reduzir.

Importance.

---

Observação

Velocity

Execution Delay

CPU

SRB

---

Pergunta

Quem sofre primeiro?

---

Descoberta

Aplicações frágeis.

Aparecem rapidamente.

---

Laboratório 5

Simulando Perda de LPAR

---

Ambiente

LPAR1

LPAR2

LPAR3

LPAR4

---

Hipótese

Perda.

LPAR2.

---

Observar

XCF

Coupling

Db2

MQ

CICS

---

Ferramentas

RMF

NetView

SA

OMEGAMON

---

Resultado

Sysplex redistribui.

---

Laboratório 6

Coupling Facility

Apenas para ambientes preparados.

---

Hipótese

CF1 indisponível.

---

Observação

Lock Structure

Cache Structure

GBP

Latency

---

Resultado esperado

CF2 assume.

---

Laboratório 7

z/OS Connect

Ambientes híbridos.

---

REST

JSON

APIs

---

Hipótese

API Gateway indisponível.

---

Monitorar

HTTP 500

Timeout

MQ

Db2

---

Laboratório 8

Batch Chaos

Pouco discutido.

Muito útil.

---

Parar JES Initiator.

---

Perguntas.

Jobs aguardam?

Restart funciona?

Dependências quebram?

---

O Papel do Ansible

Chaos moderno.

Precisa ser repetível.

---

Exemplo.

Playbook.

---
- hosts: zos

tasks:


- stop_cics


- collect_rmf


- wait


- validate


- restart


- report

---

Benefícios.

Auditoria

Versionamento

Git

Rollback

---

Exemplo Python

if latency < 120:

    print("Hipótese válida")

else:

    print("Ajustar arquitetura")

---

O Checklist Bellacosa Chaos

Antes

Hipótese

Blast Radius

Equipe

Janela

Backup

Dashboard

Autorização

Rollback

---

Durante

Coletar métricas

Observar

Documentar

Registrar horário

---

Depois

Corrigir

Melhorar

Automatizar

Repetir

---

O Nível de Maturidade Chaos para IBM Z

Nível 1

Sem testes.

---

Nível 2

DR anual.

---

Nível 3

Testes trimestrais.

---

Nível 4

Automação.

---

Nível 5

Chaos contínuo.

---

Nível 6

Auto Healing.

IA.

Ansible.

SA z/OS.

---

O Futuro

IBM Z já possui.

Observabilidade.

Automação.

Resiliência.

Telemetry.

OpenTelemetry.

Ansible.

AIOps.

Watson.

Instana.

Zowe.

z/OSMF.

---

Talvez o próximo passo seja.

Chaos Engineering Assistido por IA.

---

IA pergunta.

Posso testar?

---

Sysprog.

Sim.

---

IA.

Executa.

Coleta.

Analisa.

Produz relatório.

Abre Change.

Atualiza Wiki.

Agenda próximo teste.

---

Bibliografia Recomendada

Chaos Engineering

Netflix

Google SRE

Building Secure and Reliable Systems

IBM Redbooks

Parallel Sysplex Handbook

SA z/OS Planning Guide

CICS TS Administration Guide

Db2 Data Sharing Redbook

MQ for z/OS Redbooks

RMF User Guide

SMF Manuals

---

A Última Conversa do Padawan

O relógio marcava quase quatro horas da manhã.

O café havia acabado.

O mestre fechou o caderno.

O Padawan perguntou.

— Então...

— Sim.

— O Chaos Monkey é apenas um macaco derrubando servidores?

O velho Sysprog sorriu.

— Não.

— O Chaos Monkey é um professor.

Ele ensina humildade.

Ensina observabilidade.

Ensina automação.

Ensina recuperação.

Ensina arquitetura.

Ensina disciplina.

Ensina documentação.

E acima de tudo.

Ensina que sistemas confiáveis não são aqueles que nunca falham.

São aqueles que falharam inúmeras vezes.

Em laboratório.

Sob controle.

Com métricas.

Com aprendizado.

Com engenharia.

Muito antes dos usuários.

Muito antes dos auditores.

Muito antes da manchete do jornal.

E talvez seja exatamente por isso que tantos Sysprogs veteranos olham para o Chaos Monkey e apenas dão um pequeno sorriso.

Porque, no fundo, sabem que o IBM Z passou décadas ensinando a mesma lição.

Disponibilidade não é sorte.

Resiliência não é marketing.

Alta disponibilidade é a arte de transformar falhas inevitáveis em eventos rotineiros, previsíveis e quase entediantes.

---

☕ Fim do Holocron do Chaos Monkey

Teste. Observe. Aprenda. Evolua. E nunca deixe que o primeiro desastre da sua arquitetura aconteça em uma segunda-feira às 9h da manhã.

O Holocron do Chaos Monkey – Quando o Macaco Entra no IBM Z: Será que o Mainframe Precisava Mesmo de um Chaos Monkey? - Parte III

 

Bellacosa Mainframe e o chaos monkey parte iii

☕ Um Café no Bellacosa Mainframe

O Holocron do Chaos Monkey – Parte III

Quando o Macaco Entra no IBM Z: Será que o Mainframe Precisava Mesmo de um Chaos Monkey?

"O pessoal da Netflix inventou o Chaos Monkey em 2011. O pessoal do IBM Z talvez apenas tenha respondido: 'Interessante... nós chamamos isso de terça-feira de teste de contingência.'"

---

O Café da Madrugada e a Pergunta que Incomodava o Padawan

Já passavam das duas horas da manhã.

O monitor do RMF permanecia aberto.

No SDSF, milhares de jobs continuavam terminando com CC=0000.

OMEGAMON mostrava gráficos verdes.

O CICSplex estava equilibrado.

O Db2 Data Sharing parecia tranquilo.

MQ continuava escoando mensagens.

WLM distribuía trabalho silenciosamente.

O Padawan então perguntou.

— Mestre...

— Sim?

— Existe um Chaos Monkey para z/OS?

O velho Sysprog tomou um gole de café.

Pensou alguns segundos.

E respondeu.

— Não exatamente.

— Mas existe algo muito mais interessante.

— O quê?

— Um ambiente que foi construído durante décadas assumindo que o desastre iria acontecer.

E talvez seja essa a maior diferença filosófica entre boa parte do mundo distribuído moderno e o IBM Z.

---

O IBM Z Nasceu em uma Época em que Falhar Era Inaceitável

Para entender isso precisamos voltar algumas décadas.

Década de 1960.

Década de 1970.

Década de 1980.

Não existiam containers.

Não existia Kubernetes.

Não existia AWS.

Não existia Netflix.

Mas existiam bancos.

Bolsa de valores.

Companhias aéreas.

Seguradoras.

Governos.

E todos tinham uma exigência simples.

Não pode parar.

Nunca.

Ou quase nunca.

Enquanto muitas arquiteturas modernas foram inicialmente criadas pensando em escalabilidade e depois adaptadas para alta disponibilidade, o Mainframe nasceu praticamente no caminho inverso.

Primeiro.

Disponibilidade.

Depois.

Performance.

Depois.

Escalabilidade.

---

O Que é o Chaos Engineering Sob a Ótica IBM Z?

Podemos resumir Chaos Engineering em uma frase.

Provocar falhas controladas para validar a resiliência do ambiente.

No IBM Z isso pode ser traduzido como:

Testar a perda de componentes críticos antes que a natureza faça isso por você.

---

Exemplos.

Perder uma região CICS.

Perder uma LPAR.

Perder um membro Db2.

Perder um Queue Manager.

Perder um caminho FICON.

Perder conectividade XCF.

Perder uma Coupling Facility.

Alterar prioridades WLM.

Testar GDPS.

Executar Disaster Recovery.

---

O Primeiro Macaco do Mainframe Talvez Tenha Sido o Operador

Uma curiosidade interessante.

Durante muitos anos.

Chaos Engineering era praticamente um procedimento operacional.

O operador recebia uma lista.

---

Plano DR

Passo 1.

Parar CICSA

Passo 2.

Monitorar.

Passo 3.

Verificar workload.

Passo 4.

Liberar usuários.

Passo 5.

Restaurar.

---

Em essência.

Era um experimento de caos.

Manual.

Documentado.

Auditável.

E bastante eficiente.

---

Chaos Monkey em CICS

Talvez seja um dos melhores ambientes para começar.

---

Suponha.

CICSPLX01

TOR01

TOR02

AOR01

AOR02

AOR03

FOR01

---

Objetivo.

Testar disponibilidade.

---

Hipótese.

Posso perder AOR02.

Sem impacto.

---

Experimento.

CEMT PERFORM SHUTDOWN

ou

CEMT SET REGION QUIESCED

---

Observação.

Transações continuam?

Sessões perdem estado?

CPU aumenta?

Fila cresce?

---

Resultado esperado.

Usuário não percebe.

---

Hipótese validada.

---

Chaos Monkey para Db2 Data Sharing

Esse é provavelmente um dos experimentos mais interessantes.

---

Ambiente.

DB2A

DB2B

DB2C

---

CF1

CF2

---

Objetivo.

Validar.

Data Sharing.

---

Hipótese.

Posso perder DB2B.

Sem indisponibilidade.

---

Experimento.

STOP DB2

ou

Simulação planejada.

---

Monitorar.

Locks.

Claims.

Threads.

Group Buffer Pools.

IRLM.

---

Resultado.

DB2A

DB2C

Assumem.

---

Aplicação continua.

---

Cliente feliz.

---

Auditoria satisfeita.

---

Chaos Monkey para MQ

MQ nasceu para sobreviver.

Mas precisa ser testado.

---

Ambiente.

MQA

MQB

MQC

---

QSG.

---

Hipótese.

Perder MQB.

---

Experimento.

STOP QMGR

---

Monitorar.

Depth.

Channels.

Message persistence.

---

Observação.

Filas crescem?

Canal reinicia?

Mensagem desapareceu?

---

Problemas descobertos.

Excelente.

Era justamente isso.

---

O WLM é Talvez o Melhor Chaos Monkey do z/OS

Muitos Sysprogs não percebem.

Mas o WLM executa constantemente decisões semelhantes.

---

CPU saturada.

---

Quem ganha?

---

Batch?

CICS?

Db2?

MQ?

---

Service Class.

---

Importance.

---

Velocity.

---

Execution Delay.

---

WLM pergunta.

Quem merece recursos?

Chaos Engineering pergunta.

Quem continua funcionando sem eles?

---

Filosoficamente.

São primos.

---

O Parallel Sysplex é um Grande Exercício Permanente de Chaos Engineering

Imagine.

Quatro LPARs.

---

LPAR1

LPAR2

LPAR3

LPAR4

---

CICS.

Db2.

MQ.

IMS.

---

Hipótese.

Perder uma LPAR.

---

Resultado esperado.

XCF redistribui.

WLM ajusta.

Db2 assume.

MQ continua.

Usuário nem percebe.

---

Isso é praticamente.

Chaos Engineering.

Em hardware.

---

Coupling Facility: O Chefe Final

Talvez nenhum experimento seja tão delicado.

---

Perder CF.

---

Hipótese.

CF secundária assume.

---

Monitorar.

GBP.

Locks.

Cache.

Latency.

---

Se algo quebrar.

Descobrimos.

Antes do desastre.

---

SA z/OS: O Maestro do Caos Controlado

System Automation.

É uma ferramenta extremamente interessante.

Porque permite.

Criar cenários.

Automatizar.

Testar.

Recuperar.

---

Exemplo.

INGREQ STOP

---

Observação.

---

INGLIST

---

INGINFO

---

DISPSYS

---

Automação responde.

---

Reinício.

---

Failover.

---

Recuperação.

---

Hipótese validada.

---

NetView e Chaos Engineering

NetView talvez seja um dos maiores aliados.

---

Alertas.

---

Mensagens.

---

Automação.

---

Scripts.

---

Correlação.

---

Quando algo falha.

Precisamos saber.

Rapidamente.

---

NetView ajuda.

---

Chaos precisa disso.

---

z/OSMF e APIs

Experimentos podem ser automatizados.

REST.

Ansible.

Python.

Zowe.

---

Exemplo.

Playbook.

---

Parar região.

Esperar.

Coletar métricas.

Reiniciar.

Gerar relatório.

---

Padawan feliz.

Sysprog também.

---

Ansible para IBM Z

Talvez seja uma das melhores ferramentas modernas.

---

Playbook.

- stop_cics

- collect_rmf

- wait

- validate

- start_cics

- generate_report

---

Tudo documentado.

Versionado.

Auditável.

Repetível.

---

Chaos Engineering adora isso.

---

O Que Nunca Deve Ser Feito

Existem limites.

---

Nunca.

Produção.

Sem autorização.

---

Nunca.

Sem rollback.

---

Nunca.

Sem métricas.

---

Nunca.

Sem observabilidade.

---

Nunca.

Sem janela.

---

Nunca.

Sem comunicação.

---

Nunca.

Sem plano B.

---

O Checklist Bellacosa Mainframe

Antes de executar um experimento.

Pergunte.

Tenho hipótese?

Sim.

Não.

---

Tenho métrica?

---

Tenho rollback?

---

Tenho dashboard?

---

Tenho equipe?

---

Tenho autorização?

---

Tenho documentação?

---

Blast Radius aceitável?

---

Se todas forem SIM.

Experimento aprovado.

---

O Dia em que o Padawan Entendeu

O Padawan olhou para o mestre.

E perguntou.

— Então...

— Sim.

— O Mainframe não precisava de um Chaos Monkey?

O velho sorriu.

— Precisava.

— E ele existiu.

— Quem?

O Sysprog.

O operador.

O arquiteto.

O especialista de DR.

O administrador de CICS.

O DBA Db2.

O administrador MQ.

Todos eles.

Durante décadas.

Simulando falhas.

Executando testes.

Planejando contingências.

Fazendo IPL.

Trocando caminhos.

Parando regiões.

Validando recuperação.

Aprendendo.

Melhorando.

Repetindo.

Muito antes de alguém colocar um macaco sorridente em uma apresentação do PowerPoint.

Porque talvez a maior lição do IBM Z seja esta:

Resiliência não é a capacidade de evitar falhas.

É a capacidade de continuar prestando serviço quando as falhas inevitavelmente chegam.

---

Continua na Parte IV

No próximo capítulo do Holocron do Chaos Monkey, construiremos os Laboratórios Bellacosa Mainframe, incluindo:

• Laboratório 1 – Derrubando uma região CICS com segurança;

• Laboratório 2 – Simulando a perda de um membro Db2 Data Sharing;

• Laboratório 3 – Testando MQ Queue Sharing Group;

• Laboratório 4 – Experimentos com WLM;

• Laboratório 5 – Perda controlada de uma LPAR em Parallel Sysplex;

• Playbooks Ansible, comandos z/OS, exemplos práticos, métricas RMF/SMF e checklists utilizados por Sysprogs para transformar caos em conhecimento operacional.

O Holocron do Chaos Monkey – Como o Macaco Escolhe suas Vítimas, o Conceito de Blast Radius e as Técnicas Secretas dos Engenheiros da Netflix - Parte II

 

Bellacosa Mainframe e o chaos monkey parte II

☕ Um Café no Bellacosa Mainframe

O Holocron do Chaos Monkey – Parte II

Como o Macaco Escolhe suas Vítimas, o Conceito de Blast Radius e as Técnicas Secretas dos Engenheiros da Netflix

"A diferença entre um sistema resiliente e um sistema frágil é que o resiliente já sobreviveu ao desastre em laboratório."

---

O Café Esfria e o Macaco Aprende Novos Truques

O relógio marcava 01h17.

O Padawan COBOL ainda estava intrigado.

Na noite anterior, havia descoberto que a Netflix possuía um pequeno macaco virtual cuja diversão favorita era assassinar servidores em plena luz do dia.

Algo que parecia absurdo.

Algo que, para um operador acostumado a passar horas analisando mensagens DFHxxxx, DSNxxxx, IEAxxxx e $HASPxxxx, soava quase criminoso.

Ele olhou para o velho Sysprog do Bellacosa Mainframe.

— Mestre...

— Sim?

— O Chaos Monkey simplesmente escolhe qualquer servidor e aperta o botão vermelho?

O velho tomou um gole de café.

Sorriu.

E respondeu.

— Se fosse apenas isso, meu jovem Padawan, chamaríamos de estagiário em produção.

O Chaos Monkey é muito mais sofisticado.

Ele trabalha com hipóteses.

Métricas.

Estatística.

Probabilidade.

E principalmente com um conceito extremamente importante.

Blast Radius.

---

O Conceito de Blast Radius

Talvez a maior contribuição filosófica do Chaos Engineering seja uma pergunta simples.

Quanto estrago eu posso causar antes de me tornar um problema para a empresa?

Esse conceito recebeu o nome de:

Blast Radius

Em português poderíamos traduzir como:

Raio de Explosão

Ou

Zona de impacto controlado

---

Imagine uma granada.

A explosão possui um alcance limitado.

Pessoas próximas são afetadas.

Pessoas distantes permanecem seguras.

Chaos Engineering funciona da mesma forma.

Não se derruba tudo.

Derruba-se apenas uma pequena parte.

E observa-se.

---

Exemplo Netflix

Serviços existentes:

Catalog Service

Authentication Service

Billing Service

Streaming Service

Recommendation Engine

CDN Controller

Número total de instâncias:

300

Chaos Monkey escolhe:

2 instâncias.

Blast Radius.

0,66%

Impacto esperado:

Nenhum cliente deve perceber.

---

Exemplo IBM Z

Ambiente.

---

LPAR PROD1

LPAR PROD2

LPAR PROD3

CICSA

CICSB

CICSC

Db2A

Db2B

MQA

MQB

---

Experimento.

Parar CICSB.

Blast Radius.

16%

Objetivo.

Nenhum terminal 3270 deve perder sessão.

Nenhuma transação deve falhar.

Nenhum SLA deve ser violado.

---

Quanto Menor o Blast Radius, Melhor

Essa é uma das regras mais importantes.

Nunca comece destruindo metade do ambiente.

Comece pequeno.

Muito pequeno.

Ridiculamente pequeno.

Primeiro.

Mate uma instância.

Depois.

Mate duas.

Depois.

Uma AZ.

Depois.

Uma região.

Depois.

Teste desastre.

---

No mundo IBM Z.

Primeiro.

Pare uma região AOR.

Depois.

Um TOR.

Depois.

Um MQ Manager.

Depois.

Um membro Db2.

Depois.

Uma LPAR.

Somente depois.

Teste GDPS.

---

O Conceito de Steady State

Na Parte I falamos rapidamente sobre isso.

Agora vamos aprofundar.

Chaos Engineering não começa derrubando servidores.

Começa respondendo.

O que é comportamento normal?

---

Exemplo.

Sistema bancário.

TPS

8000

CPU

42%

Latência

120 ms

Erros

0,002%

---

Esse é o estado estável.

Steady State.

---

Hipótese.

Posso perder um servidor.

Mantendo.

TPS acima de 7800.

Latência abaixo de 150 ms.

Erro abaixo de 0,01%.

---

Agora sim.

Executamos o caos.

---

Como o Chaos Monkey Escolhe suas Vítimas

Muita gente imagina.

Servidor.

Sorteio.

Desliga.

Fim.

Não.

Existem estratégias.

---

Estratégia 1

Seleção aleatória pura

Número aleatório.

Escolha.

Encerrar.

---

Vantagem.

Simples.

---

Desvantagem.

Pode escolher servidores pouco importantes.

---

Estratégia 2

Weighted Random

Peso.

Criticidade.

Histórico.

Capacidade.

---

Exemplo.

API01

peso 30

API02

peso 10

API03

peso 60

---

Maior chance.

API03.

---

Estratégia 3

Tag Based

AWS Tags.

Kubernetes Labels.

---

Production

Homolog

ChaosEnabled

---

Exemplo.

ChaosEnabled=true

Apenas esses.

Serão vítimas.

---

Estratégia 4

Janela Programada

09h às 11h

Terça-feira

Equipe presente

Observabilidade ativa

---

Muito usada.

Na Netflix.

Google.

Spotify.

---

O Segredo dos SREs

Os Site Reliability Engineers possuem um mantra.

Não faça experimentos quando ninguém puder observar.

Parece óbvio.

Mas muitas empresas ignoram.

---

É necessário.

Logs.

Dashboards.

Tracing.

Alertas.

Equipe disponível.

Rollback.

Runbook.

---

Sem isso.

Chaos vira apenas.

Caos.

---

O Conceito de Observabilidade

Chaos Engineering depende totalmente dela.

---

Logs

---

Métricas

---

Tracing

---

Eventos

---

Alertas

---

No IBM Z.

RMF.

SMF.

OMEGAMON.

NetView.

SA z/OS.

CICS Monitoring.

Db2 Monitor.

MQ Statistics.

SDSF.

JES2.

WLM.

---

Exemplo Completo — Banco Digital

Arquitetura.

---

Load Balancer

6 APIs

Kafka

Redis

Postgres

IAM

PIX

Open Finance

---

Estado.

12000 TPS

85ms

Erro 0,001%

---

Hipótese.

Perder API04.

---

Chaos.

Kill.

API04.

---

Resultado.

Latência.

91ms.

TPS.

Erro.

0,003%

---

Hipótese validada.

---

Novo teste.

Perder Redis.

---

Resultado.

Latência.

650 ms.

---

Fila cresce.

---

Clientes reclamam.

---

Descoberta.

Redis era SPOF.

---

Problema corrigido.

---

Single Point of Failure

Talvez o maior inimigo.

SPOF.

---

IBM Z nasceu combatendo isso.

---

Redundância.

---

Coupling Facility.

---

Parallel Sysplex.

---

FICON redundante.

---

Db2 Sharing.

---

MQ QSG.

---

GDPS.

---

WLM.

---

RACF Database Sharing.

---

ODS.

---

XCF.

---

Sysplex Timer.

---

STP.

---

Chaos Engineering apenas tornou explícita uma filosofia que ambientes críticos praticam há décadas.

---

Ferramentas Modernas

Gremlin

Plataforma comercial.

CPU.

Memória.

Rede.

Disco.

DNS.

Processos.

---

LitmusChaos

Kubernetes.

---

CRDs.

Experimentos.

GitOps.

---

Chaos Mesh

Cloud Native.

---

Latência.

IO.

Kernel.

---

AWS FIS

Fault Injection Simulator.

---

Instâncias.

EBS.

Rede.

---

PowerfulSeal

Clusters Kubernetes.

---

Chaos Toolkit

Python.

Open Source.

---

Truques Utilizados por Equipes Experientes

Truque 1

Sempre começar em homologação.

---

Truque 2

Executar experimentos repetidamente.

---

Truque 3

Automatizar.

---

CI/CD.

---

GitOps.

---

Ansible.

---

Terraform.

---

Truque 4

Documentar tudo.

---

Hipótese.

Resultado.

Aprendizado.

Correção.

---

Truque 5

Criar um catálogo.

Chaos Experiments.

Versão.

Data.

Owner.

---

Um Sysprog Descobre o Chaos Monkey

O Padawan olhou para o mestre.

— Então...

— Sim.

— Chaos Engineering é ensinar o sistema a sofrer.

— Exatamente.

— Até ele parar de sentir dor.

— Não.

O velho sorriu.

— Até ele continuar funcionando mesmo sentindo.

Porque a disponibilidade perfeita não existe.

Hardware quebra.

Fibra rompe.

Discos falham.

Firmware possui bugs.

Aplicações vazam memória.

Operadores cometem erros.

Pessoas esquecem procedimentos.

O objetivo nunca foi impedir falhas.

O objetivo sempre foi algo muito mais ambicioso.

Fazer com que as falhas se tornem acontecimentos comuns, previsíveis e entediantes.

E foi nesse momento que o Padawan percebeu algo curioso.

Talvez o Chaos Monkey nunca tivesse sido realmente uma invenção revolucionária.

Talvez fosse apenas uma nova linguagem para explicar uma velha sabedoria dos Sysprogs do IBM Z:

Não espere o desastre ensinar sua arquitetura. Ensine sua arquitetura a sobreviver ao desastre antes que ele aconteça.

---

Continua na Parte III

No próximo capítulo do Holocron do Chaos Monkey, entraremos definitivamente no território do IBM Z:

• Existe um Chaos Monkey para z/OS?

• Como testar falhas em CICSplex, Db2 Data Sharing e MQ QSG.

• O papel do WLM, Sysplex, XCF e GDPS.

• Como construir experimentos de caos seguros para Sysprogs.

• Técnicas usando SA z/OS, NetView, z/OSMF e Ansible Automation Platform.

• Laboratórios Bellacosa Mainframe com exemplos práticos para Padawans e Sysprogs Seniores.

O Holocron do Chaos Monkey – O Dia em que a Netflix Soltou um Macaco no Datacenter e Descobriu Algo que os Sysprogs do IBM Z Já Sabiam Há Décadas - Parte I

 

Bellacosa Mainframe e o chaos monkey parte i

☕ Um Café no Bellacosa Mainframe

O Holocron do Chaos Monkey – Parte I

O Dia em que a Netflix Soltou um Macaco no Datacenter e Descobriu Algo que os Sysprogs do IBM Z Já Sabiam Há Décadas

"Existem duas categorias de administradores de sistemas: os que já perderam servidores em produção e os que ainda não descobriram que já perderam."

— Provérbio não oficial dos Sysprogs que já passaram por uma IPL às três da manhã.

---

O Café, o Padawan e a Pergunta Incômoda

Era quase meia-noite.

O jovem Padawan COBOL observava sua tela ISPF iluminada enquanto uma caneca de café começava lentamente a esfriar.

No SDSF, milhares de jobs terminavam normalmente.

No RMF, os gráficos permaneciam estáveis.

No Db2 Data Sharing, todos os membros estavam ativos.

MQ respondia.

CICS aceitava transações.

WLM parecia satisfeito.

RACF não reclamava.

Tudo parecia perfeito.

Foi então que o velho Sysprog do Bellacosa Mainframe fez uma pergunta aparentemente simples.

— E se eu desligar uma LPAR agora?

O Padawan arregalou os olhos.

— Em produção?

— Não.

— Em homologação?

— Talvez.

— Em laboratório?

— Definitivamente.

— Mas... por quê?

O velho Sysprog sorriu.

— Porque sistemas que nunca foram testados sob falha não são sistemas resilientes.

São apenas sistemas que tiveram sorte.

E foi exatamente essa pergunta que levou uma empresa de streaming de vídeos a criar um dos conceitos mais influentes da engenharia moderna de software.

Um pequeno macaco digital.

Travesso.

Imprevisível.

E absolutamente genial.

Seu nome era Chaos Monkey.

---

Antes do Macaco Existia o Trauma

Para compreender a origem do Chaos Monkey precisamos voltar alguns anos.

Mais especificamente para 2008.

Naquela época a Netflix ainda não era a gigante que conhecemos.

Ela era uma empresa em transição.

Durante muito tempo seu negócio principal havia sido enviar DVDs pelo correio.

Milhões de DVDs.

Milhões de envelopes vermelhos.

Milhões de assinantes.

Mas o streaming começava a crescer.

E isso trouxe um problema monumental.

---

O Datacenter que Quase Matou a Netflix

Em agosto de 2008 ocorreu um incidente importante.

A base de dados principal da Netflix sofreu corrupção.

Diversos serviços ficaram indisponíveis.

A recuperação foi lenta.

Custosa.

Dolorosa.

A empresa percebeu algo desconfortável.

Seu sistema era robusto.

Mas não era antifrágil.

Era eficiente.

Mas dependia demais de componentes específicos.

A pergunta passou a assombrar os arquitetos:

O que acontece se um servidor morrer?

E se um rack inteiro desaparecer?

E se perdermos uma zona de disponibilidade?

E se um datacenter simplesmente sumir?

E se tudo isso acontecer numa sexta-feira às 18h?

Perguntas semelhantes já eram familiares para administradores IBM Z.

Um Sysprog veterano talvez reformulasse:

• E se perdermos um CF?

• E se uma região CICS cair?

• E se um membro Db2 sair do grupo?

• E se um CHPID apresentar erro?

• E se uma LPAR inteira desaparecer?

A Netflix precisava responder a perguntas equivalentes.

---

Conhecendo Adrian Cockcroft

Uma das figuras centrais dessa história é Adrian Cockcroft.

Na época ele era arquiteto de cloud da Netflix.

Cockcroft possuía uma visão bastante pragmática.

Ele defendia uma ideia simples.

Falhas não são exceções.

Falhas são eventos normais.

Portanto:

Se você sabe que algo vai falhar, por que esperar que aconteça sozinho?

Por que não provocar a falha?

Em ambiente controlado.

Sob observação.

Durante o horário comercial.

Com engenheiros atentos.

Antes que a natureza faça isso às três horas da manhã.

Essa filosofia mudaria para sempre a maneira como sistemas distribuídos seriam projetados.

---

O Nascimento do Simian Army

Em 2011 surgiu um conjunto de ferramentas chamado:

Simian Army

A tradução seria algo como:

Exército dos Símios

Cada "macaco" tinha uma função específica.

---

Chaos Monkey

Mata instâncias aleatoriamente.

---

Janitor Monkey

Remove recursos abandonados.

---

Conformity Monkey

Verifica aderência às políticas.

---

Security Monkey

Audita vulnerabilidades.

---

Doctor Monkey

Detecta máquinas defeituosas.

---

Chaos Gorilla

Simula perda de uma zona inteira.

---

Chaos Kong

Simula perda de uma região completa.

Era uma abordagem brilhante.

Em vez de esperar desastres...

Eles ensaiavam desastres.

Como bombeiros.

Como pilotos.

Como astronautas.

Como equipes de recuperação de desastres em grandes bancos.

Algo bastante familiar para profissionais IBM Z.

---

O Macaco que Derruba Servidores

O Chaos Monkey original era relativamente simples.

Seu trabalho consistia basicamente em:

Selecionar uma instância.

Escolher aleatoriamente.

Desligá-la.

E observar.

Nada mais.

Nada menos.

Mas por trás dessa simplicidade existia uma filosofia extremamente sofisticada.

---

O Conceito de Steady State

Primeira pergunta:

Como sabemos que o sistema está saudável?

Precisamos definir métricas.

Exemplos:

Tempo médio de resposta.

Número de transações.

Erros HTTP.

Latência.

TPS.

CPU.

Consumo de memória.

No IBM Z poderíamos medir:

SMF 30

SMF 72

RMF

OMEGAMON

CICS Monitoring

Db2 Accounting

MQ Statistics

WLM Service Classes

---

A Hipótese

Exemplo.

Hipótese:

Posso perder um servidor API sem impacto ao cliente.

Hipótese IBM Z:

Posso perder uma região TOR sem indisponibilidade.

Hipótese Db2:

Posso perder um membro Data Sharing.

Hipótese MQ:

Posso perder um Queue Manager.

---

O Experimento

Agora o macaco trabalha.

Servidor API-03.

Encerrar.

Pronto.

Observar.

---

Resultado

Usuário percebeu?

Latência aumentou?

Filas cresceram?

CPU disparou?

Alarmes tocaram?

Se tudo continuou funcionando...

Excelente.

Sistema resiliente.

Se não...

Descobrimos um problema.

Antes do cliente.

Antes do auditor.

Antes do jornal.

Antes do diretor ligar perguntando:

Quem derrubou o banco?

---

Um Exemplo Passo a Passo

Suponha um ambiente com:

4 servidores Web

3 APIs

2 bancos

Redis

MQ

Load Balancer

---

Estado inicial.

Web01

Web02

Web03

Web04

API01

API02

API03

DB01

DB02

---

Métrica.

99,99%

TPS = 5000

Latência = 80 ms

---

Chaos Monkey escolhe.

API02.

---

Comando.

Shutdown.

---

Balanceador detecta.

Remove API02.

---

API01 assume.

API03 assume.

---

Usuários continuam navegando.

Nenhum impacto.

Experimento aprovado.

---

Caso contrário:

Erro 500.

Sessões perdidas.

Timeout.

Fila congestionada.

Problema descoberto.

Correção necessária.

---

O Conceito Mais Importante: O Sistema Já Está Quebrado

Talvez a principal lição do Chaos Engineering seja esta:

O sistema não é confiável porque nunca falhou.

Ele é confiável porque já falhou centenas de vezes.

Em laboratório.

Em homologação.

Sob controle.

Com métricas.

Com observabilidade.

Com aprendizado.

Isso é extremamente próximo da cultura tradicional do IBM Z.

Sysprogs experientes sempre fizeram algo semelhante.

Trocar caminhos.

Testar GDPS.

Executar DR.

Parar regiões.

Mover workloads.

Fazer IPL programada.

Testar fallback.

Treinar operadores.

A diferença é que a Netflix deu um nome elegante para algo que muitas equipes de infraestrutura críticas já praticavam intuitivamente havia décadas.

---

Curiosidades Sobre o Chaos Monkey

Algumas curiosidades interessantes:

O Chaos Monkey original foi desenvolvido principalmente para a infraestrutura AWS.

Muitas equipes tinham medo de habilitá-lo.

Alguns executivos perguntavam:

Vocês estão pagando engenheiros para derrubar servidores?

A resposta era:

Sim.

Porque a alternativa é deixar que os clientes descubram os problemas.

Atualmente, dezenas de empresas utilizam princípios derivados do Chaos Engineering.

Entre elas:

Google.

Microsoft.

Amazon.

LinkedIn.

Spotify.

Uber.

Shopify.

Salesforce.

E, cada vez mais, instituições financeiras que operam ambientes híbridos envolvendo IBM Z.

---

O Que Aprenderemos na Próxima Parte?

Na Parte II do Holocron do Chaos Monkey, o Padawan descobrirá:

• O conceito de Blast Radius;

• Como SREs escolhem vítimas para os experimentos;

• Técnicas avançadas utilizadas por equipes do Google e Netflix;

• Como criar hipóteses de falha inteligentes;

• Ferramentas modernas como Gremlin, LitmusChaos, Chaos Mesh e AWS Fault Injection Simulator;

• Um estudo de caso completo de um banco digital submetido a experimentos de caos;

• E por que um pequeno macaco digital pode ensinar mais sobre arquitetura resiliente do que dezenas de diagramas coloridos em apresentações corporativas.

---

No Bellacosa Mainframe costumamos dizer que a alta disponibilidade não nasce quando tudo funciona. Ela nasce quando alguma coisa quebra, todos observam atentamente, aprendem com a experiência e descobrem que o sistema continua servindo café para os usuários como se nada tivesse acontecido.