Netflix: Chaos Engineering e Resiliência por Design

Antes de 2008, a Netflix operava dois datacenters próprios. Em agosto daquele ano, uma corrupção de banco de dados derrubou o serviço de DVD por três dias, um incidente que expôs a fragilidade de uma arquitetura monolítica onde um único ponto de falha podia paralisar tudo. A decisão de migrar para AWS não foi apenas operacional; foi uma aposta arquitetural de que a nuvem, com sua elasticidade e redundância geográfica, permitiria construir algo qualitativamente diferente.

O problema real, porém, não era a infraestrutura. Era a cultura e a engenharia ao redor dela. Sistemas distribuídos em nuvem introduzem uma classe de falhas que datacenters tradicionais raramente experimentam em produção: instâncias que somem silenciosamente, latências que explodem de forma assimétrica, partições de rede que isolam zonas inteiras. A resposta convencional é tentar prevenir essas falhas com redundância passiva, múltiplas AZs, replicação síncrona, failover automático configurado mas nunca testado.

A Netflix rejeitou essa abordagem. A premissa central que guia toda a arquitetura de resiliência deles é: se você não testa falhas em produção, você não sabe se seu sistema sobrevive a elas. Redundância não testada é ilusão de redundância. Um failover que nunca foi exercitado em condições reais vai falhar no pior momento possível, quando a carga está no pico, quando a equipe está dormindo, quando o incidente já está em andamento. Essa premissa não é filosófica; ela é operacional. E foi ela que gerou a Simian Army.

A arquitetura de resiliência da Netflix não é um produto único, é uma composição de mecanismos independentes que se reforçam. Entender cada camada separadamente é essencial para entender por que o conjunto funciona.

Camada 1: Degradação Graciosa com Hystrix. Todo serviço que faz chamadas a dependências externas é envolvido por um circuit breaker Hystrix. Quando uma dependência começa a falhar ou a exceder timeouts configurados, o circuito abre e a chamada retorna imediatamente um valor de fallback, geralmente dados em cache, uma resposta estática ou uma versão degradada da feature. O exemplo canônico é o serviço de recomendações: se ele falha, o usuário recebe uma lista de filmes populares pré-computada em vez de recomendações personalizadas. A experiência é pior, mas o serviço continua funcionando. Esse padrão: fail fast, fallback gracefully, é aplicado sistematicamente em centenas de microservices.

Camada 2: Service Discovery Dinâmico com Eureka. O Eureka é o registro de serviços interno da Netflix. Cada instância se registra ao iniciar e envia heartbeats periódicos. Quando uma instância morre, seja por falha real ou por ação do Chaos Monkey, ela é removida do registro em segundos. O Zuul, o API Gateway, consulta o Eureka para rotear requisições apenas para instâncias saudáveis. Não há DNS TTL longo para aguardar; a convergência é rápida. Isso significa que a morte de uma instância individual é absorvida pela camada de roteamento sem intervenção humana.

Camada 3: Failover Regional com Chaos Kong. O nível mais alto de resiliência é o failover regional. A Netflix opera em múltiplas regiões AWS simultaneamente, não em modo ativo-passivo, mas ativo-ativo com capacidade de absorver o tráfego de uma região inteira. O Chaos Kong simula a perda completa de uma região: ele desvia todo o tráfego de, digamos, us-east-1 para us-west-2 via Route 53, e a equipe observa se o sistema aguenta. Esse exercício é feito periodicamente em produção. A Cassandra, o banco de dados principal para dados de catálogo e perfil, opera com replicação multi-região configurada para consistência eventual, uma escolha deliberada que prioriza disponibilidade sobre consistência forte (teorema CAP, partição AP).

Camada 4: A Simian Army como Cultura de Engenharia. A Simian Army não é apenas um conjunto de ferramentas; é a institucionalização de uma cultura. O Chaos Monkey roda durante o horário comercial (não à meia-noite) de forma deliberada, se vai causar um problema, é melhor que aconteça quando a equipe está acordada e pode responder. O Conformity Monkey verifica se as instâncias seguem as melhores práticas configuradas. O Security Monkey audita configurações de segurança. O Doctor Monkey faz health checks. Cada macaco ataca uma dimensão diferente da resiliência, e o conjunto cria pressão contínua para que os times construam serviços que sobrevivem a falhas em vez de depender de que as falhas não aconteçam.

Em 2014, a Netflix publicou o documento Principles of Chaos Engineering, uma tentativa de formalizar o que estava sendo praticado empiricamente. Os princípios são cinco, e cada um tem implicações arquiteturais diretas que vale examinar com cuidado.

1. Construa uma hipótese sobre o comportamento em estado estável. Antes de injetar qualquer falha, você precisa definir o que é normal. Para a Netflix, isso significa métricas de negócio: stream starts per second (SPS) é a métrica primária, não CPU ou latência. Se o SPS cai, algo está errado. Essa escolha de métrica é arquiteturalmente importante: ela força a instrumentação a ser orientada ao resultado de negócio, não ao estado técnico interno.

2. Varie eventos do mundo real. As falhas injetadas devem refletir o que realmente acontece: instâncias que morrem, discos que falham, latências de rede que aumentam, dependências externas que ficam lentas. Não é sobre criar cenários artificiais, é sobre reproduzir em condições controladas o que a produção já experimenta de forma não controlada.

3. Execute experimentos em produção. Esse é o princípio mais controverso e o mais importante. Ambientes de staging não replicam a carga real, os padrões de tráfego reais, os dados reais. Um bug que só aparece com 10 milhões de requisições simultâneas não vai aparecer no staging. A Netflix aceita o risco de degradação em produção como o custo de ter confiança real na resiliência.

4. Automatize experimentos para rodar continuamente. Resiliência não é um estado que você atinge uma vez; é uma propriedade que precisa ser mantida. Cada deploy novo pode introduzir uma regressão de resiliência. Chaos Monkey rodando continuamente garante que o sistema seja testado sob condições de falha após cada mudança.

5. Minimize o raio de explosão. Experimentos começam pequenos, uma instância, uma AZ, um percentual do tráfego. O raio de explosão é expandido gradualmente à medida que a confiança aumenta. Isso é o que permite rodar em produção sem causar incidentes maiores sistematicamente.

O que a Netflix fez foi transformar esses princípios em infraestrutura executável. A distância entre o princípio e a implementação é onde a maioria das organizações falha, elas adotam o vocabulário do chaos engineering sem construir os mecanismos de fallback que tornam os experimentos seguros de executar.