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