Em um mundo cada vez mais digital, a disponibilidade e a confiabilidade dos sistemas são cruciais. Falhas são inevitáveis: discos quebram, redes caem, serviços ficam sobrecarregados. A diferença entre um sistema robusto e um frágil está na capacidade de continuar operando, mesmo com componentes falhando. Nesta aula, vamos mergulhar nos princípios de resiliência e tolerância a falhas, fundamentais para qualquer profissional de DevOps que deseja construir sistemas que aguentem o tranco.

Começaremos com o conceito de redundância, a base de qualquer estratégia de alta disponibilidade. Em seguida, exploraremos o padrão de circuit breaker, essencial para evitar falhas em cascata. Depois, discutiremos como degradar graciosamente quando tudo não pode ser perfeito, e finalizaremos com uma visão geral de chaos engineering, a prática de testar a resiliência de forma proativa.

Redundância

Redundância é a duplicação de componentes críticos de um sistema com o objetivo de aumentar sua confiabilidade. Em termos simples, trata-se de ter um plano B (ou C, ou D) para quando algo falha. A redundância pode ser aplicada em diferentes níveis: hardware (servidores, discos, fontes de alimentação), software (instâncias de aplicação, microsserviços), dados (réplicas de banco de dados) e até mesmo em nível de infraestrutura (múltiplos data centers em regiões diferentes).

Existem dois tipos principais de redundância: ativa e passiva. Na redundância ativa, todos os componentes estão operando simultaneamente, distribuindo a carga. Por exemplo, um load balancer distribui tráfego entre várias instâncias de uma aplicação, todas ativas. Na redundância passiva, um componente fica em standby, pronto para assumir quando o principal falhar. Um exemplo clássico é um servidor de banco de dados em modo standby que assume o papel de primário em caso de falha.

Um dos padrões mais comuns para implementar redundância é o modelo ativo-passivo com failover. Vamos ver um exemplo de script bash que verifica a saúde de um serviço e realiza o failover para um serviço reserva:

#!/bin/bash

# Script simples de failover para um serviço web
PRIMARY_SERVICE="http://primary.example.com"
BACKUP_SERVICE="http://backup.example.com"

check_service() {
    local url=$1
    if curl -s --head --request GET $url | grep "200 OK" > /dev/null; then
        return 0
    else
        return 1
    fi
}

if check_service $PRIMARY_SERVICE; then
    echo "Serviço primário está saudável. Nenhuma ação necessária."
else
    echo "Serviço primário falhou! Realizando failover para o backup..."
    # Aqui você pode atualizar o DNS ou o load balancer para apontar para o backup
    echo "Failover executado. Backup ativo: $BACKUP_SERVICE"
fi

Na prática, ferramentas como Kubernetes gerenciam redundância automaticamente, mantendo réplicas de pods e distribuindo a carga. O importante é entender que a redundância é essencial para garantir que o sistema permaneça disponível, mas ela deve ser planejada e testada.

Circuit breakers (conceito)

O padrão de circuit breaker é inspirado no disjuntor elétrico: quando uma falha é detectada, o circuito é aberto para evitar danos maiores. Em sistemas distribuídos, quando um serviço depende de outro, uma falha no serviço downstream pode causar timeouts e sobrecarregar o serviço chamador, levando a uma falha em cascata. O circuit breaker atua como uma proteção: quando o número de falhas excede um limite, ele "abre" e, por um período, todas as chamadas ao serviço com falha são rejeitadas imediatamente, sem tentar a conexão. Isso permite que o serviço problemático se recupere sem ser sobrecarregado.

Um circuit breaker tem três estados: fechado (closed), aberto (open) e meio-aberto (half-open). No estado fechado, as chamadas são encaminhadas normalmente. Quando as falhas atingem um limite, ele muda para aberto, rejeitando chamadas imediatamente. Após um período de espera, ele muda para meio-aberto, permitindo um número limitado de chamadas de teste. Se essas chamadas tiverem sucesso, ele volta para fechado; caso contrário, volta para aberto.

Vamos ver como implementar um circuit breaker simples em bash para controlar chamadas a um serviço externo:

#!/bin/bash

CIRCUIT_STATE="closed"
FAILURE_COUNT=0
THRESHOLD=3
TIMEOUT=5

call_service() {
    # Simula uma chamada que pode falhar
    if [ $((RANDOM % 2)) -eq 0 ]; then
        echo "Sucesso"
        return 0
    else
        echo "Falha"
        return 1
    fi
}

while true; do
    case $CIRCUIT_STATE in
        closed)
            if call_service; then
                FAILURE_COUNT=0
                echo "Chamada bem-sucedida. Estado: fechado."
            else
                FAILURE_COUNT=$((FAILURE_COUNT + 1))
                echo "Falha número $FAILURE_COUNT de $THRESHOLD"
                if [ $FAILURE_COUNT -ge $THRESHOLD ]; then
                    CIRCUIT_STATE="open"
                    echo "Circuit breaker aberto!"
                fi
            fi
            ;;
        open)
            echo "Circuit breaker aberto. Chamada rejeitada."
            sleep $TIMEOUT
            CIRCUIT_STATE="half-open"
            ;;
        half-open)
            if call_service; then
                CIRCUIT_STATE="closed"
                FAILURE_COUNT=0
                echo "Circuit breaker fechado novamente."
            else
                CIRCUIT_STATE="open"
                echo "Falha no teste. Circuit breaker permanece aberto."
            fi
            ;;
    esac
    sleep 1
done

Em aplicações reais, bibliotecas como Hystrix (Java) ou Resilience4j (Java) implementam circuit breakers de forma robusta. O conceito é essencial para evitar que uma falha pontual derrube todo o sistema.

Graceful degradation

Graceful degradation, ou degradação graciosa, é a capacidade de um sistema de manter funcionalidade reduzida quando partes dele falham ou estão sobrecarregadas. Em vez de falhar completamente, o sistema ajusta seu comportamento para continuar fornecendo um serviço mínimo, mesmo que com menos recursos ou funcionalidades.

Um exemplo clássico é um site de e-commerce que, quando o serviço de recomendações está fora do ar, ainda permite que os usuários naveguem e comprem produtos, apenas sem as recomendações personalizadas. Outro exemplo é um serviço de streaming que reduz a qualidade do vídeo durante picos de tráfego para evitar buffering.

Implementar degradação graciosa envolve identificar funcionalidades críticas e não críticas. As críticas devem ser preservadas, enquanto as não críticas podem ser desativadas ou simplificadas. Em um script bash, podemos simular um sistema que degrada quando o uso de memória está alto:

#!/bin/bash

MEM_THRESHOLD=80

check_memory() {
    local usage=$(free | awk '/Mem/{printf "%d", $3/$2*100}')
    echo $usage
}

while true; do
    mem_usage=$(check_memory)
    echo "Uso de memória: $mem_usage%"
    if [ $mem_usage -gt $MEM_THRESHOLD ]; then
        echo "ALERTA: Memória alta. Ativando modo degradado."
        # Desativa funcionalidades não essenciais
        echo "Modo degradado: cache desativado, processamento em lote pausado."
    else
        echo "Sistema operando normalmente."
    fi
    sleep 5
done

Na prática, em arquiteturas de microsserviços, a degradação graciosa pode ser alcançada com fallbacks, como servir dados em cache quando o banco de dados está indisponível. É uma estratégia de design que prioriza a experiência do usuário, mantendo o sistema acessível.

Chaos engineering (visão geral)

Chaos engineering é a disciplina de experimentar em um sistema para construir confiança em sua capacidade de resistir a condições turbulentas. Em vez de esperar que falhas aconteçam, os engenheiros de chaos introduzem falhas propositalmente em ambientes controlados para observar como o sistema reage, identificar fraquezas e corrigi-las antes que se tornem problemas reais.

O princípio fundamental é "quebrar coisas de propósito" para aprender. Isso pode incluir matar instâncias de servidores, injetar latência de rede, esgotar recursos ou simular falhas de dependências. Ferramentas como Chaos Monkey (da Netflix) são famosas por desligar instâncias aleatoriamente em produção para garantir que o sistema sobreviva.

Um exemplo simples de teste de chaos em bash é simular a morte de um processo crítico:

#!/bin/bash

# Simula a morte de um processo crítico (nginx, por exemplo)
kill -9 $(pgrep nginx)
echo "Processo nginx morto. O sistema deve se recuperar automaticamente."

# Aguarda alguns segundos e verifica se o processo foi reiniciado (pelo supervisor)
sleep 5
if pgrep nginx > /dev/null; then
    echo "nginx reiniciado com sucesso pelo supervisor."
else
    echo "FALHA: nginx não foi reiniciado! Investigar."
fi

Chaos engineering deve ser feito com cuidado, começando em ambientes de teste e gradualmente avançando para produção, sempre com monitoramento e rollback prontos. O objetivo é melhorar a resiliência de forma proativa, não causar caos desnecessário.

Boas práticas e observações finais

  • Comece pequeno: Implemente redundância e circuit breakers em serviços críticos antes de expandir.
  • Monitore tudo: A resiliência depende de observabilidade. Use métricas, logs e tracing para entender o comportamento do sistema.
  • Teste regularmente: Realize testes de caos e simulações de falha para validar suas estratégias.
  • Documente os procedimentos: Tenha runbooks claros para failover e degradação.
  • Automatize a recuperação: Sempre que possível, automatize o failover e a reinicialização de serviços.

Resiliência não é um estado final, mas um processo contínuo de melhoria. Ao aplicar esses conceitos, você estará mais preparado para lidar com o inesperado e garantir que seus sistemas permaneçam disponíveis.

Referências

Exercícios

  1. Explique a diferença entre redundância ativa e passiva, dando um exemplo de cada.

    2. ✓ Resposta: Redundância ativa: todos os componentes operam simultaneamente, como um load balancer distribuindo tráfego entre várias instâncias de um servidor web. Redundância passiva: um componente fica em standby, como um servidor de banco de dados replicado que assume o papel principal em caso de falha.
  2. Descreva os três estados de um circuit breaker e o que acontece em cada um.

    3. ✓ Resposta: Fechado: as chamadas são permitidas normalmente. Aberto: as chamadas são rejeitadas imediatamente por um período, para dar tempo de recuperação. Meio-aberto: um número limitado de chamadas de teste é permitido para verificar se o serviço se recuperou; se bem-sucedidas, o circuito volta a fechar, caso contrário, permanece aberto.
  3. Cite um exemplo de degradação graciosa em um sistema real e explique como ela ajuda o usuário final.

    4. ✓ Resposta: Um site de e-commerce que, quando o serviço de recomendações falha, ainda permite navegação e compra, apenas sem recomendações personalizadas. Isso mantém a funcionalidade principal disponível, melhorando a experiência do usuário em vez de mostrar um erro fatal.
  4. Qual é o objetivo principal do chaos engineering e como ele contribui para a resiliência do sistema?

    5. ✓ Resposta: O objetivo é descobrir fraquezas no sistema antes que elas causem problemas reais, introduzindo falhas controladas e observando como o sistema responde. Isso permite corrigir vulnerabilidades de forma proativa, aumentando a confiança na resiliência do sistema.
  5. Escreva um pequeno script bash que simule um failover manual entre dois serviços (primário e backup), verificando a disponibilidade com curl.

    6. ✓ Resposta: 
    #!/bin/bash

PRIMARY="http://primary.example.com"
BACKUP="http://backup.example.com"

check() {
    curl -s --head --request GET $1 | grep "200 OK" > /dev/null
}

if check $PRIMARY; then
    echo "Primário ativo."
else
    echo "Primário falhou! Ativando backup..."
    # Simula a troca de DNS ou load balancer
    echo "Backup ativo: $BACKUP"
fi