 |
| Bellacosa Mainframe e o Chaos Monkey |
☕ O Holocron do Chaos Monkey
Como um Pequeno Macaco da Netflix Ensinou ao Mundo Algo que os Sysprogs do IBM Z Já Praticavam Há Décadas
Existe um momento curioso na jornada de todo Padawan COBOL, Sysprog, arquiteto ou profissional de infraestrutura em que ele descobre uma verdade desconfortável.
Nenhum sistema é indestrutível.
Nenhuma arquitetura é perfeita.
Nenhum diagrama bonito no PowerPoint é capaz de impedir que um disco falhe, uma fibra seja rompida, uma aplicação entre em loop, uma região CICS desapareça ou uma LPAR resolva tirar férias em plena Black Friday.
Foi exatamente dessa constatação que nasceu, em 2011, uma das ideias mais influentes da engenharia moderna de software.
Um pequeno macaco digital.
Travesso.
Imprevisível.
Sem qualquer respeito pelo conforto psicológico dos administradores de sistemas.
Seu nome era Chaos Monkey.
Criado pela Netflix como parte do projeto Simian Army, o Chaos Monkey possuía uma missão aparentemente absurda:
Derrubar servidores deliberadamente.
Mas havia uma razão bastante séria por trás dessa atitude quase sociopata.
A Netflix havia aprendido uma lição dolorosa em 2008, após sofrer problemas importantes de indisponibilidade em sua infraestrutura. A empresa percebeu que esperar que a primeira falha ocorresse naturalmente era uma péssima estratégia.
Era melhor provocar pequenos desastres controlados.
Observar.
Medir.
Aprender.
Corrigir.
Repetir.
Nascia assim o movimento conhecido como Chaos Engineering.
No entanto, enquanto boa parte do mercado enxergava aquilo como uma revolução tecnológica, muitos profissionais do IBM Z apenas levantaram uma sobrancelha, tomaram um gole de café e pensaram:
Interessante...
Nós fazemos algo parecido há décadas.
Sysprogs veteranos conhecem bem essa filosofia.
Testar GDPS.
Executar Disaster Recovery.
Parar uma região CICS.
Desligar um membro Db2 Data Sharing.
Simular perda de um Queue Manager.
Trocar caminhos FICON.
Validar políticas do WLM.
Testar SA z/OS.
Mover workloads.
Executar IPLs programadas.
No fundo, a grande diferença talvez seja apenas de nomenclatura.
A Netflix colocou um macaco sorridente em apresentações corporativas.
O Mainframe chamou isso de plano de contingência, teste de disponibilidade, procedimento operacional ou simplesmente terça-feira à tarde.
Ao longo desta série do ☕ Um Café no Bellacosa Mainframe, acompanhamos a jornada de um Padawan COBOL descobrindo que resiliência não significa impedir falhas.
Significa aprender a conviver com elas.
Automatizá-las.
Medi-las.
Compreendê-las.
E principalmente garantir que o usuário continue tomando seu café tranquilamente enquanto os engenheiros observam gráficos, métricas e dashboards piscando em uma sala de guerra.
📖 Índice do 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
Nesta primeira jornada, exploramos a origem do Chaos Monkey, a crise enfrentada pela Netflix em 2008, o nascimento do Simian Army, a filosofia de Adrian Cockcroft e os princípios fundamentais do Chaos Engineering, incluindo o conceito de Steady State, hipóteses de falha e a importância de provocar pequenos desastres antes que eles ocorram naturalmente.
https://eljefemidnightlunch.blogspot.com/2020/07/o-holocron-do-chaos-monkey-o-dia-em-que.html
Parte II
Como o Macaco Escolhe suas Vítimas, o Conceito de Blast Radius e as Técnicas Secretas dos Engenheiros da Netflix
No segundo capítulo, estudamos o funcionamento interno dos experimentos de caos, aprendendo conceitos essenciais como:
Blast Radius;
Observabilidade;
Seleção controlada de componentes;
Métricas de disponibilidade;
Técnicas empregadas por SREs;
Ferramentas modernas como Gremlin, LitmusChaos, Chaos Mesh e AWS Fault Injection Simulator.
Também acompanhamos estudos de caso inspirados em arquiteturas bancárias e serviços digitais.
https://eljefemidnightlunch.blogspot.com/2020/08/o-holocron-do-chaos-monkey-como-o.htmlParte III
Quando o Macaco Entra no IBM Z: Será que o Mainframe Precisava Mesmo de um Chaos Monkey?
Na terceira etapa, levamos o Chaos Engineering para dentro do universo IBM Z.
Analisamos como os conceitos de caos podem ser aplicados em:
CICSplex;
Db2 Data Sharing;
MQ Queue Sharing Groups;
WLM;
Parallel Sysplex;
Coupling Facilities;
GDPS;
SA z/OS;
NetView;
z/OSMF;
Ansible for IBM Z.
Descobrimos que muitos princípios defendidos pela Netflix já eram praticados há décadas pelos Sysprogs mais experientes.
https://eljefemidnightlunch.blogspot.com/2020/09/o-holocron-do-chaos-monkey-quando-o.html
Parte IV
Os Laboratórios Bellacosa Mainframe: Como um Sysprog Pode Injetar Caos no IBM Z Sem Ser Expulso da Sala de Guerra
Encerrando o Holocron, construímos uma coleção de laboratórios práticos voltados para ambientes IBM Z.
Entre os exercícios apresentados estão:
Derrubar uma região CICS secundária;
Simular a perda de um membro Db2 Data Sharing;
Testar um MQ Queue Sharing Group;
Alterar políticas do WLM;
Simular indisponibilidade de uma LPAR;
Testar Coupling Facilities;
Automatizar experimentos utilizando SA z/OS, Ansible e z/OSMF.
Também apresentamos checklists, exemplos de playbooks, métricas recomendadas e um modelo de maturidade em Chaos Engineering para equipes de Sysprog.
https://eljefemidnightlunch.blogspot.com/2020/10/o-holocron-do-chaos-monkey-os.html
☕ A Última Reflexão do Bellacosa Mainframe
Talvez a maior contribuição do Chaos Monkey não tenha sido derrubar servidores.
Talvez tenha sido lembrar aos arquitetos modernos uma lição antiga que os profissionais do IBM Z conhecem há muito tempo:
Disponibilidade não é sorte.
Resiliência não é marketing.
Alta disponibilidade é a disciplina de transformar falhas inevitáveis em acontecimentos rotineiros, previsíveis e quase entediantes.
E se um pequeno macaco travesso puder nos ensinar isso, talvez ele mereça uma cadeira na próxima reunião de arquitetura... desde que fique longe do botão vermelho da produção. ☕🐵💻🚀
Sem comentários:
Enviar um comentário