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