Translate

Mostrar mensagens com a etiqueta netview. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta netview. Mostrar todas as mensagens

sábado, 30 de maio de 2026

☕🔥 LABORATÓRIO DEFINITIVO — IBM Z SYSTEM AUTOMATION, ZOWE CLI E DEVOPS PARA SYSprog PADAWAN

 

Bellacosa Mainframe e o laboratorio pratico de IBM System Automation

☕🔥 LABORATÓRIO DEFINITIVO — IBM Z SYSTEM AUTOMATION, ZOWE CLI E DEVOPS PARA SYSprog PADAWAN

20 Exercícios Práticos no Estilo Bellacosa Mainframe

Existe um momento na vida do sysprog padawan em que ele para de apenas observar o console verde…
e começa a automatizar o universo.

Este laboratório foi criado para:

  • iniciantes

  • operadores

  • sysprogs juniors

  • estudantes IBM Z

  • aventureiros do Zowe

  • guerreiros do NetView

Aqui você aprenderá:
✅ SA REST Server
✅ Swagger UI
✅ Zowe CLI
✅ Dynamic Resources
✅ APIs REST
✅ Curl
✅ Ansible
✅ Integração DevOps

Tudo em exercícios práticos.

Prepare o café.
Ajuste o SDSF.
E vamos entrar no hyperspace do IBM Z moderno.


☕ LAB 1 — ENTENDENDO O ECOSSISTEMA

Objetivo

Identificar os componentes da arquitetura moderna do SA.


Exercício

Explique o papel dos seguintes componentes:

  • System Automation

  • REST Server

  • Zowe CLI

  • Ansible Collection


Solução

ComponenteFunção
SA z/OSmotor de automação
REST Servergateway API
Zowe CLIinterface shell moderna
Ansibleautomação declarativa

☕ LAB 2 — ACESSANDO O SWAGGER UI

Objetivo

Explorar a documentação REST.


Exercício

Abra no navegador:

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

Liste:

  • endpoints

  • métodos HTTP

  • exemplos JSON


Solução

Você verá:

  • GET

  • POST

  • DELETE

  • responses

  • parameters

  • CURL examples


☕ LAB 3 — IDENTIFICANDO HTTP VERBS

Objetivo

Entender operações REST.


Exercício

Associe:

VerboFunção
GET?
POST?
DELETE?

Solução

VerboFunção
GETconsulta
POSTcriação/request
DELETEremoção

☕ LAB 4 — TESTANDO API VIA SWAGGER

Objetivo

Executar chamada REST real.


Exercício

Execute:

GET /resources

Solução esperada

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

☕ LAB 5 — TESTANDO CURL

Objetivo

Executar API sem browser.


Exercício

Monte um CURL para listar resources.


Solução

curl -X GET https://server/resources

☕ LAB 6 — INSTALANDO ZOWE CLI

Objetivo

Preparar ambiente moderno.


Exercício

Liste os pré-requisitos do Zowe.


Solução

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

Instalação:

npm install -g @zowe/cli

☕ LAB 7 — LISTANDO PLUGINS

Objetivo

Conhecer extensões do Zowe.


Exercício

Qual comando lista plugins instalados?


Solução

zowe plugins list

☕ LAB 8 — INSTALANDO O PLUGIN SA

Objetivo

Integrar SA ao Zowe.


Exercício

Instale o plugin System Automation.


Solução

zowe plugins install @ibm/system-automation-for-zowe-cli

☕ LAB 9 — EXPLORANDO HELP

Objetivo

Aprender ajuda integrada.


Exercício

Obtenha ajuda do plugin SA.


Solução

zowe sa --help

☕ LAB 10 — GERANDO HELP HTML

Objetivo

Visualizar documentação web.


Exercício

Gere ajuda HTML.


Solução

zowe sa --help-web

☕ LAB 11 — LISTANDO RESOURCES

Objetivo

Consultar runtime SA.


Exercício

Liste todos os resources automatizados.


Solução

zowe sa list resources

☕ LAB 12 — LISTANDO TEMPLATES

Objetivo

Conhecer templates dinâmicos.


Exercício

Liste templates disponíveis.


Solução

zowe sa list templates

☕ LAB 13 — CRIANDO DYNAMIC RESOURCE

Objetivo

Entender provisioning dinâmico.


Exercício

Explique o conceito de dynamic resource.


Solução

Resource criado:

  • em runtime

  • sem rebuild total

  • sem restart global

Conceito semelhante a:

  • containers

  • pods

  • runtime provisioning


☕ LAB 14 — DELETANDO RESOURCE

Objetivo

Operar lifecycle.


Exercício

Delete resource GFBJOST.


Solução

zowe sa del res --name GFBJOST

☕ LAB 15 — ANALISANDO O REST SERVER

Objetivo

Entender arquitetura.


Exercício

Explique a diferença entre:

  • OPT_EMBEDDED_WEBSERVER

  • OPT_LIBERTY_DEPLOYED


Solução

ModoCaracterística
EmbeddedTomcat embutido
Libertydeploy WebSphere Liberty

☕ LAB 16 — CONFIG FILES ZOWE

Objetivo

Entender profiles.


Exercício

Explique:

  • base profile

  • sa profile


Solução

ProfileUso
basepropriedades genéricas
sapropriedades específicas SA

☕ LAB 17 — ENTENDENDO ANSIBLE

Objetivo

Introdução DevOps.


Exercício

Explique o que é automação declarativa.


Solução

Você descreve:

o estado desejado.

O Ansible executa:

automaticamente.


☕ LAB 18 — PLAYBOOK BÁSICO

Objetivo

Criar resource via YAML.


Exercício

Crie playbook simples.


Solução

- hosts: zos
  roles:
    - sa_create_dynamic_resource

☕ LAB 19 — PIPELINE DEVOPS

Objetivo

Entender integração moderna.


Exercício

Explique fluxo:

Git
 ↓
Pipeline
 ↓
Ansible
 ↓
REST API
 ↓
SA

Solução

Esse fluxo:

  • automatiza deploy

  • cria resources

  • inicia aplicações

  • integra mainframe ao DevOps


☕ LAB 20 — O SYSprog DO FUTURO

Objetivo

Reflexão final.


Exercício

Explique por que:

o mainframe moderno não vive apenas de ISPF e SDSF.


Solução

Porque o IBM Z moderno agora usa:

  • APIs REST

  • JSON

  • YAML

  • Zowe

  • Ansible

  • AIOps

  • observabilidade

  • pipelines DevOps

O sysprog moderno precisa dominar:

  • operação clássica

  • automação moderna

  • integração híbrida


☕ DESAFIO FINAL DO PADAWAN

Monte um cenário onde:

  • um Git Push

  • dispara um pipeline

  • executa Ansible

  • cria dynamic resource

  • inicia aplicação automaticamente no IBM Z.

Se você conseguir explicar esse fluxo…
você deixou de ser apenas operador.

E começou sua transformação em:

IBM Z Platform Engineer.


☕ FRASE FINAL DO LABORATÓRIO

“O futuro do mainframe não é abandonar o legado.
É conectar o legado ao universo das APIs, automação e DevOps.”

— Bellacosa Mainframe

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.


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.