 |
| 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.
Sem comentários:
Enviar um comentário