O Chaos Engineering é uma disciplina que surgiu para lidar com a imprevisibilidade de sistemas distribuídos em escala. Em vez de tentar prever todas as falhas possíveis, o Chaos Engineering propõe testar ativamente o sistema em condições adversas, de forma controlada, para descobrir fraquezas antes que elas causem incidentes reais. Essa prática, popularizada por empresas como Netflix, visa construir confiança na capacidade do sistema de resistir a turbulências.

Nesta aula, vamos mergulhar nos princípios que norteiam o Chaos Engineering, entender como projetar experimentos seguros e produtivos, conhecer as ferramentas mais utilizadas no mercado e discutir a importância da cultura para o sucesso dessa prática. Ao final, você terá uma visão clara de como implementar Chaos Engineering no seu ambiente, mesmo começando em pequena escala.

Princípios

Os princípios do Chaos Engineering foram formalizados nos 'Princípios do Chaos Engineering' publicados pela comunidade. Eles servem como guia para a prática e ajudam a diferenciar o caos controlado de ações irresponsáveis. O primeiro princípio é 'Hypothesize about steady state': antes de qualquer experimento, você deve definir o que é o comportamento 'normal' do sistema, ou seja, suas métricas de saúde (como latência, taxa de erros, throughput) e o estado esperado.

O segundo princípio é 'Vary real-world events': os experimentos devem simular eventos reais, como falhas de servidores, picos de tráfego, latência de rede, ou até mesmo a perda de uma zona de disponibilidade inteira. Isso garante que os testes sejam relevantes e não artificiais. O terceiro princípio é 'Run experiments in production': embora possa parecer assustador, é no ambiente de produção que as verdadeiras fraquezas aparecem. Ambientes de staging muitas vezes não replicam a complexidade e o tráfego reais. Por fim, o princípio 'Automate experiments to run continuously' sugere que os experimentos devem ser automatizados e integrados ao pipeline de entrega, para que a resiliência seja verificada constantemente.

Além desses, há o princípio de 'Minimize blast radius', que veremos em detalhe na próxima seção, mas que está implícito em todos os experimentos: o impacto deve ser contido para não causar danos aos usuários.

Experimentos controlados

Um experimento controlado de Chaos Engineering segue um ciclo rigoroso: planejamento, execução, observação e aprendizado. O objetivo é provar ou refutar uma hipótese sobre a resiliência do sistema, sem causar danos irreparáveis. Para isso, é essencial definir um 'blast radius' (raio de explosão), ou seja, a área de impacto do experimento. Por exemplo, você pode escolher testar apenas uma instância de um serviço, ou um subconjunto de usuários, para que o impacto seja limitado.

O processo começa com a definição da hipótese: 'Se matarmos uma instância do serviço X, a latência média permanecerá abaixo de 200ms e a taxa de erro será zero'. Em seguida, você seleciona as métricas de steady state e os alertas que serão monitorados. Durante a execução, é crucial ter um plano de rollback: se algo sair do controle, você deve ser capaz de reverter rapidamente. Ferramentas como o Chaos Toolkit permitem que você defina 'steady-state hypothesis' e 'method' (ação de caos) em um arquivo de configuração.

Exemplo de experimento com Chaos Toolkit:

# experiment.json
{
  "version": "1.0.0",
  "title": "Kill one instance of payment-service",
  "description": "Verifica se o serviço de pagamento continua operando com uma instância a menos.",
  "steady-state-hypothesis": {
    "title": "Serviço deve estar saudável",
    "probes": [
      {
        "type": "probe",
        "name": "check-http-200",
        "provider": {
          "type": "http",
          "url": "https://api.example.com/health",
          "method": "GET",
          "expectation": 200
        }
      }
    ]
  },
  "method": [
    {
      "type": "action",
      "name": "kill-instance",
      "provider": {
        "type": "python",
        "module": "chaosk8s.pod.actions",
        "func": "kill_pod",
        "arguments": {
          "name": "payment-service-abc123",
          "namespace": "production"
        }
      }
    }
  ]
}

Nesse exemplo, a hipótese é que matar um pod específico não afetará a saúde do sistema. O experimento executa a ação de matar o pod e, em seguida, verifica se o endpoint de saúde continua retornando 200. Se a hipótese for refutada, você tem uma oportunidade de aprendizado e correção.

É importante começar com experimentos pequenos e aumentar gradualmente a complexidade. Nunca realize um experimento sem comunicação com a equipe e sem ter um plano de contingência bem definido.

Ferramentas (visão geral)

Existem diversas ferramentas para implementar Chaos Engineering, cada uma com seus pontos fortes. A escolha depende do seu ambiente (Kubernetes, nuvem, on-premise) e da complexidade desejada. As principais categorias são: ferramentas de injeção de falhas, plataformas gerenciadas e frameworks.

Entre as ferramentas mais populares, destacam-se:

  • Chaos Monkey (Netflix): A pioneira, que encerra instâncias aleatórias em produção para incentivar a resiliência. Faz parte do conjunto Spinnaker.
  • Chaos Toolkit: Um framework open-source que permite criar experimentos declarativos em JSON ou Python. É extensível e pode ser usado com Kubernetes, AWS, etc.
  • Gremlin: Uma plataforma comercial que oferece uma interface amigável, com muitos tipos de ataques (CPU, memória, rede, etc.) e recursos de segurança.
  • Litmus: Uma ferramenta cloud-native para Kubernetes, que permite criar experimentos como CRDs (Custom Resource Definitions).
  • Chaos Mesh: Outra ferramenta para Kubernetes, que fornece uma interface visual e suporte a vários tipos de falhas, como falhas de rede, de disco, de pod, etc.

Para quem está começando, o Chaos Toolkit é uma ótima escolha por ser simples e gratuito. Veja um exemplo de como instalar e executar um experimento simples com ele:

# Instalação via pip
pip install chaostoolkit

# Executa um experimento (assumindo que você tem um arquivo experiment.json)
chaos run experiment.json

Além dessas, há ferramentas específicas para infraestrutura como o Pumba (para Docker) e o Toxiproxy (para simular falhas de rede). A escolha da ferramenta deve considerar a facilidade de integração com seu stack e a capacidade de automatizar os experimentos.

Cultura

O Chaos Engineering não é apenas uma questão técnica; é uma mudança cultural. A cultura de chaos engineering envolve a aceitação de que falhas são inevitáveis e que testá-las proativamente é melhor do que ser surpreendido por elas. Isso requer um ambiente de confiança, onde as equipes não são punidas por encontrar problemas, mas sim encorajadas a resolvê-los.

Para fomentar essa cultura, é fundamental ter o apoio da liderança e promover a colaboração entre as equipes de desenvolvimento, operações e segurança. Workshops e 'game days' (dias de jogo) são práticas comuns, onde a equipe se reúne para realizar experimentos e simular incidentes em um ambiente seguro. Além disso, é importante documentar os aprendizados e compartilhá-los amplamente.

Outro aspecto cultural é o 'blameless postmortem': quando um experimento revela uma falha, a discussão deve focar no sistema e nos processos, não em culpar indivíduos. Isso encoraja as pessoas a participar ativamente dos experimentos sem medo de represálias. Com o tempo, a prática de chaos engineering se torna parte do ciclo de desenvolvimento, aumentando a resiliência geral do sistema e a confiança das equipes.

Boas práticas e observações finais

Para concluir, aqui estão algumas boas práticas ao adotar Chaos Engineering:

  • Comece pequeno: escolha um serviço não crítico para os primeiros experimentos.
  • Monitore tudo: tenha métricas e alertas bem definidos antes de começar.
  • Comunique-se: avise a equipe sobre os experimentos e tenha um canal de comunicação para emergências.
  • Automatize gradualmente: primeiro execute manualmente, depois automatize para rodar regularmente.
  • Use ambientes de produção com cuidado: se possível, comece em staging e evolua para produção com experimentos de baixo impacto.
  • Sempre tenha um plano de rollback.

Lembre-se de que o objetivo não é quebrar o sistema, mas sim entender como ele se comporta sob estresse e melhorá-lo. O Chaos Engineering é uma jornada contínua de aprendizado e melhoria.

Referências

Exercícios

  1. Explique os três princípios fundamentais do Chaos Engineering e dê um exemplo de cada.

    ✓ Resposta: Os três princípios são: 1) Hipótese sobre o estado estável (definir o comportamento normal do sistema); 2) Variar eventos do mundo real (simular falhas reais como queda de servidor); 3) Executar experimentos em produção (testar no ambiente real). Exemplo: para o primeiro, definir que a latência média deve ser < 200ms; para o segundo, simular uma falha de rede; para o terceiro, executar um experimento em produção durante horário de baixo tráfego.
  2. Descreva o ciclo de um experimento controlado de Chaos Engineering.

    ✓ Resposta: O ciclo inclui: 1) Planejamento: definir hipótese, escopo, métricas e plano de rollback; 2) Execução: injetar a falha de forma controlada; 3) Observação: monitorar as métricas e comparar com o steady state; 4) Aprendizado: analisar os resultados e documentar conclusões. Em seguida, tomar ações corretivas se necessário.
  3. Cite duas ferramentas de Chaos Engineering e explique uma diferença entre elas.

    ✓ Resposta: Duas ferramentas são Chaos Monkey e Gremlin. Chaos Monkey é open-source e foca em encerrar instâncias, enquanto Gremlin é comercial e oferece uma vasta gama de ataques (CPU, memória, rede) com interface amigável. A diferença principal é que o Gremlin é mais abrangente e fácil de usar, enquanto o Chaos Monkey é mais simples e limitado a falhas de instância.
  4. Por que a cultura é importante no Chaos Engineering? Dê um exemplo de como promover essa cultura.

    ✓ Resposta: A cultura é importante porque sem ela, as equipes podem ter medo de causar falhas e não adotar a prática. Promover uma cultura de confiança e aprendizado, onde falhas são vistas como oportunidades de melhoria, é essencial. Exemplo: realizar game days onde a equipe se reúne para simular incidentes em um ambiente seguro, sem punições, e depois discutir os aprendizados abertamente.
  5. Escreva um pequeno experimento (em JSON) usando Chaos Toolkit que verifique se o serviço de pagamento responde após a injeção de latência.

    ✓ Resposta: Um exemplo de experimento:
    {
  "version": "1.0.0",
  "title": "Adicionar latência ao serviço de pagamento",
  "steady-state-hypothesis": {
    "title": "Serviço responde em menos de 500ms",
    "probes": [
      {
        "type": "probe",
        "name": "check-latency",
        "provider": {
          "type": "http",
          "url": "http://payment-service/health",
          "method": "GET",
          "timeout": 500
        }
      }
    ]
  },
  "method": [
    {
      "type": "action",
      "name": "add-latency",
      "provider": {
        "type": "python",
        "module": "chaostoxiproxy.actions",
        "func": "add_latency",
        "arguments": {
          "proxy": "payment-proxy",
          "latency": 1000,
          "duration": 30
        }
      }
    }
  ]
}