Translate

Mostrar mensagens com a etiqueta sa zos. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta sa zos. Mostrar todas as mensagens

sexta-feira, 29 de maio de 2026

☕🔥 “DO 3270 AO DEVOPS” — O GUIA DEFINITIVO DO SYSprog PADAWAN PARA IBM Z SYSTEM AUTOMATION, ZOWE E APIs MODERNAS

 

Bellacosa Mainframe e o IBM Z System Automation


☕🔥 “DO 3270 AO DEVOPS” — O GUIA DEFINITIVO DO SYSprog PADAWAN PARA IBM Z SYSTEM AUTOMATION, ZOWE E APIs MODERNAS

Existe um momento na vida de todo sysprog padawan em que ele percebe uma verdade assustadora:

“O mainframe moderno não vive mais apenas de ISPF, SDSF e comandos verdes.”

E nesse instante começa a jornada.

Uma jornada que leva o operador clássico do:

  • INGLIST

  • INGAMS

  • TSO

  • NetView

  • Automation Table

para um novo universo:

  • REST APIs

  • Swagger

  • Zowe CLI

  • Ansible

  • YAML

  • DevOps

  • GitOps

  • AIOps

Sim…
o IBM Z mudou.

E se você ainda imagina que automação no mainframe significa apenas:

START CICS
STOP DB2

então prepare seu café porque hoje vamos entrar no:

IBM Z System Automation MODERNO.


☕ O QUE É IBM Z SYSTEM AUTOMATION?

O IBM Z System Automation (SA z/OS):

é o cérebro operacional do mainframe.

Ele é responsável por:

  • iniciar subsistemas

  • parar aplicações

  • monitorar ambientes

  • tratar falhas

  • executar recovery automático

  • coordenar dependências

Pense nele como:

o “Kubernetes” do mundo enterprise tradicional.


🔥 EXEMPLO PRÁTICO

Imagine:

Você possui:

  • DB2

  • CICS

  • MQ

  • Batch

  • WebSphere

Tudo depende um do outro.

O SA sabe:

  • o que iniciar primeiro

  • o que depende do quê

  • como reagir a falhas

  • como automatizar recovery


☕ O MUNDO ANTIGO DO SYSprog

Durante décadas:

o mainframe foi operado principalmente via 3270.

Comandos clássicos:

INGLIST
INGAMS
INGREQ
INGSET

Painéis verdes.
PF Keys.
Automation Tables.
Policy Database.

Funcionava maravilhosamente.

E ainda funciona.

Mas o mundo mudou.


🔥 O PROBLEMA

Enquanto Linux e Cloud evoluíam para:

  • APIs

  • pipelines

  • automação declarativa

  • integração CI/CD

o mainframe parecia isolado.

Até que a IBM começou uma revolução silenciosa.


☕ NASCE O SYSTEM AUTOMATION OPERATIONS REST SERVER

Esse componente:

mudou tudo.

O SA ganhou:

APIs REST modernas.

Agora qualquer software consegue conversar com o mainframe usando:

  • HTTP

  • JSON

  • REST

  • CURL


🧠 O QUE ISSO SIGNIFICA?

Antes:

Operador
   ↓
3270
   ↓
NetView

Agora:

Pipeline DevOps
      ↓
REST API
      ↓
IBM Z System Automation

☕ O QUE O REST SERVER CONSEGUE FAZER?

Ele permite:

✅ listar resources
✅ iniciar aplicações
✅ parar subsistemas
✅ criar dynamic resources
✅ deletar resources
✅ refresh policy
✅ consultar requests
✅ interagir com automation managers


🔥 MAS EXISTE UMA LIMITAÇÃO IMPORTANTE

O REST API:

NÃO edita a policy.

Ele opera:

o runtime.

Ou seja:

  • você controla recursos

  • mas não altera definições da policy

Isso é importante para:

  • segurança

  • governança

  • integridade operacional


☕ SWAGGER UI — O LABORATÓRIO SECRETO DO SYSprog

Depois que o REST Server está ativo:

nasce o Swagger UI.

URL típica:

http://server:port/ibm/sa/swagger-ui/index.html

🔥 O QUE É ISSO?

Uma interface web interativa que mostra:

  • endpoints

  • parâmetros

  • JSON

  • responses

  • códigos HTTP

E MAIS:

você pode testar chamadas ao vivo.


☕ EXEMPLO REAL

Consultar resources:

GET /resources

Resposta:

{
 "resource":"CICSA",
 "status":"UP"
}

🔥 AGORA O SYSprog COMEÇA A VIRAR DEVOPS ENGINEER

Porque:

APIs permitem integração total.


☕ CURL — O PODER BRUTO

O Swagger ainda mostra comandos CURL.

Exemplo:

curl -X GET https://server/resources

Agora imagine:

  • scripts

  • automação

  • pipelines

  • monitoramento externo

Tudo falando com SA.


☕ E ENTÃO SURGE O ZOWE CLI

O Zowe foi outra revolução gigantesca.

Ele trouxe:

shell moderno para o mainframe.


🔥 ANTES

3270

🔥 AGORA

zowe sa list resources

🧠 O ZOWE É COMO UM “LINUX TERMINAL” PARA z/OS

E isso reduz brutalmente:

a barreira de entrada no mainframe.


☕ POR QUE ISSO É IMPORTANTE?

Hoje muitos profissionais:

  • conhecem Linux

  • usam Git

  • usam shell

  • usam pipelines

Mas:

  • não conhecem ISPF

  • não conhecem PF Keys

  • não conhecem 3270

O Zowe resolve isso.


☕ COMO O ZOWE FUNCIONA?

Arquitetura:

Zowe CLI
    ↓
SA Plug-in
    ↓
REST Server
    ↓
IBM Z System Automation

🔥 O ZOWE NÃO SUBSTITUI O NETVIEW

Ele é:

uma interface adicional.


☕ INSTALANDO O ZOWE

Pré-requisitos:

✅ Node.js
✅ npm
✅ gnome-keyring (Linux)

Instalação:

npm install -g @zowe/cli

☕ INSTALANDO O PLUGIN SA

zowe plugins install

☕ COMANDOS IMPORTANTES

Listar resources:

zowe sa list resources

Deletar dynamic resource:

zowe sa del res --name TESTE1

Ajuda:

zowe sa --help

Ajuda HTML:

zowe sa --help-web

☕ DYNAMIC RESOURCES — O CONCEITO MAIS IMPORTANTE

Isso aqui muda completamente a automação do mainframe.


🔥 O QUE É UM DYNAMIC RESOURCE?

Um recurso criado:

em runtime.

Sem:

  • rebuild

  • refresh completo

  • restart global


🧠 ISSO É MUITO “CLOUD-LIKE”


☕ ANALOGIA MODERNA

CloudSA
PodDynamic Resource
kubectlZowe
YAMLPlaybook
DeploymentTemplate

☕ ENTRA O ANSIBLE

Agora chegamos ao nível Jedi.


🔥 O QUE É O ANSIBLE?

Ferramenta de automação declarativa baseada em:

YAML.


🧠 “DECLARATIVA” SIGNIFICA:

Você descreve:

o estado desejado.

E o Ansible executa.


☕ IBM Z SYSTEM AUTOMATION ANSIBLE COLLECTION

A IBM criou uma collection específica para SA.

Ela oferece duas roles:

sa_create_dynamic_resource
sa_delete_dynamic_resource

☕ EXEMPLO DE PLAYBOOK

- hosts: zos
  roles:
    - sa_create_dynamic_resource

🔥 O QUE ACONTECE?

Playbook
   ↓
REST API
   ↓
SA REST Server
   ↓
INGDYN CREATE

☕ ISSO É REVOLUCIONÁRIO

Porque agora:

o mainframe entra no pipeline DevOps.


☕ CENÁRIO REAL

Imagine:

Developer faz:

git push

Pipeline executa:

Ansible
 ↓
Deploy
 ↓
Create dynamic resource
 ↓
Start application

Tudo automático.


☕ O SYSprog DO FUTURO

O profissional moderno não será apenas:

operador de console.

Ele será:

  • automation engineer

  • platform engineer

  • DevOps specialist

  • API integrator


☕ AIOPS — O PRÓXIMO PASSO

A IBM está indo além.

Agora fala-se em:

AIOps.

Artificial Intelligence for IT Operations.


🔥 O OBJETIVO

Usar:

  • analytics

  • machine learning

  • observability

  • automation

para criar:

sistemas autônomos.


☕ O SA FAZ PARTE DISSO

Hoje o SA integra:

  • observabilidade

  • automation

  • REST APIs

  • eventos

  • workflows


☕ O SYSprog PADAWAN PRECISA ENTENDER UMA VERDADE

O mainframe:

não está parado no tempo.

Na verdade:

ele está se tornando uma plataforma híbrida programável.


☕ O QUE VOCÊ DEVE ESTUDAR AGORA?

Depois desse curso:

  • REST APIs

  • JSON

  • YAML

  • Python

  • Zowe

  • Ansible

  • Git

  • OpenShift

  • z/OSMF

  • SMU


☕ DICA DE OURO DO LOBO VELHO

Aprenda:

os dois mundos.

Porque o profissional mais poderoso será aquele que souber:

✅ INGLIST
✅ NetView
✅ Policy
✅ Automation Tables

MAS TAMBÉM:

✅ APIs
✅ Zowe
✅ YAML
✅ Ansible
✅ DevOps


☕ CONCLUSÃO

O IBM Z moderno está atravessando a maior transformação operacional desde o surgimento do Sysplex.

O que antes era:

  • centralizado

  • fechado

  • baseado em 3270

está se tornando:

  • orientado a APIs

  • integrado a pipelines

  • declarativo

  • automatizado

  • cloud-aware

E o IBM Z System Automation é uma das peças centrais dessa transformação.

O sysprog padawan que aprender isso agora:

estará anos à frente do mercado.

Porque o futuro do mainframe:

não é abandonar o legado.

É integrar o legado ao futuro.


sábado, 17 de outubro de 2020

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ã.


quarta-feira, 16 de setembro de 2020

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.