Boas práticas em ambientes de produção

Objetivos

Nesta aula você vai:

• Aplicar hardening de segurança para Redis em produção
• Configurar monitoramento, alertas e observabilidade
• Elaborar planos de backup, disaster recovery e runbooks

Conteúdo

O epílogo operacional

Chegamos ao capítulo final do módulo — aquele em que os personagens (dados, cache, replicas) precisam sobreviver não apenas à história feliz do deploy, mas às segundas-feiras de tráfego real, às madrugadas de incidente e às auditorias de segurança. Operar cache em produção é a diferença entre um sistema que funciona no demo e um que funciona por anos.

Segurança: hardening essencial

Autenticação e rede

# Senha obrigatória
redis-cli CONFIG SET requirepass "senha-forte-com-32-chars-minimo"

# Renomear comandos perigosos
redis-cli CONFIG SET rename-command FLUSHALL ""
redis-cli CONFIG SET rename-command FLUSHDB ""
redis-cli CONFIG SET rename-command CONFIG "CONFIG-a8b3c9d2"
redis-cli CONFIG SET rename-command DEBUG ""
redis-cli CONFIG SET rename-command KEYS ""

# Bind apenas em interfaces necessárias
# redis.conf: bind 10.0.1.5 (não 0.0.0.0)

ACL (Redis 6.0+)

# Criar usuário com permissões limitadas
redis-cli ACL SETUSER app-readonly on >senha-app ~cache:* +get +mget +hgetall -@all
redis-cli ACL SETUSER app-writer on >senha-app ~cache:* +get +set +del +hset +expire -@all

# Listar usuários
redis-cli ACL LIST

# Verificar permissões
redis-cli ACL GETUSER app-readonly

TLS

# redis.conf — criptografia em trânsito
tls-port 6379
port 0                    # Desabilitar porta não-TLS
tls-cert-file /path/to/cert.pem
tls-key-file /path/to/key.pem
tls-ca-cert-file /path/to/ca.pem

Monitoramento e alertas

Métricas essenciais

# Coleta manual para diagnóstico
redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO replication
redis-cli INFO clients
redis-cli SLOWLOG GET 10
redis-cli LATENCY DOCTOR

Prometheus + Grafana

# redis_exporter expõe métricas em :9121/metrics
# Queries Grafana essenciais:

# Memória
redis_memory_used_bytes / redis_memory_max_bytes

# Ops por segundo
rate(redis_commands_processed_total[1m])

# Latência P99 (se instrumentado)
histogram_quantile(0.99, rate(redis_commands_duration_seconds_bucket[5m]))

# Eviction rate
rate(redis_evicted_keys_total[5m])

# Replication lag
redis_master_repl_offset - redis_slave_repl_offset

Backup e disaster recovery

Estratégia RDB + AOF

# RDB: snapshot periódico
# redis.conf
save 900 1       # 1 mudança em 15 min
save 300 10      # 10 mudanças em 5 min
save 60 10000    # 10000 mudanças em 1 min

# AOF: log de cada escrita
appendonly yes
appendfsync everysec    # Balanceado (perda máxima: 1s)

# Backup manual
redis-cli BGSAVE
redis-cli LASTSAVE
# Copiar dump.rdb para storage seguro (S3, GCS)

Procedimento de restore

# 1. Parar Redis
systemctl stop redis

# 2. Restaurar arquivo
cp /backup/dump.rdb /var/lib/redis/dump.rdb
# ou: cp /backup/appendonly.aof /var/lib/redis/appendonly.aof

# 3. Verificar permissões
chown redis:redis /var/lib/redis/dump.rdb

# 4. Iniciar e validar
systemctl start redis
redis-cli PING
redis-cli DBSIZE
redis-cli --scan --pattern "sessao:*" | wc -l

Runbooks operacionais

Runbook: memória acima de 90%

1. Verificar: redis-cli INFO memory
2. Identificar maiores chaves: redis-cli --bigkeys
3. Verificar eviction: redis-cli INFO stats | grep evicted
4. Ações imediatas:
   a. Aumentar maxmemory (se RAM disponível)
   b. Reduzir TTLs de cache não-crítico
   c. Remover chaves obsoletas (SCAN + DEL em lote)
5. Ações de médio prazo:
   a. Revisar política de eviction
   b. Avaliar sharding (Redis Cluster)
   c. Otimizar estruturas de dados (Hash vs JSON)

Runbook: failover com Sentinel

1. Detectar: alerta master_link_status=down
2. Verificar: redis-cli -p 26379 SENTINEL master mymaster
3. Sentinel promove replica automaticamente (10-30s)
4. Validar novo master:
   redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
5. Verificar aplicações reconectaram (logs de app)
6. Pós-incidente:
   a. Investigar causa do master original
   b. Reintegrar nó antigo como replica
   c. Documentar timeline no postmortem

Runbook: latência P99 degradada

1. redis-cli LATENCY DOCTOR
2. redis-cli SLOWLOG GET 20
3. Verificar:
   a. BGSAVE em andamento? (INFO persistence)
   b. Fragmentação alta? (mem_fragmentation_ratio)
   c. Hot key? (--hotkeys)
   d. Rede saturada? (iftop, ping entre nós)
4. Ações:
   a. Comando lento → otimizar ou proibir
   b. BGSAVE → agendar em janela de baixo tráfego
   c. Hot key → local cache ou sharding
   d. Fragmentação → activedefrag ou restart planejado

Configuração de produção recomendada

# redis.conf — produção essencial

# Memória
maxmemory 6gb
maxmemory-policy allkeys-lru

# Persistência
save 300 10
appendonly yes
appendfsync everysec
no-appendfsync-on-rewrite yes

# Replicação
min-replicas-to-write 1
min-replicas-max-lag 10
repl-backlog-size 256mb

# Segurança
requirepass "senha-forte"
rename-command FLUSHALL ""
rename-command KEYS ""

# Performance
tcp-keepalive 300
timeout 0
hz 10
dynamic-hz yes

# Defrag (Redis 4.0+)
activedefrag yes

# Slowlog
slowlog-log-slower-than 10000
slowlog-max-len 128

# Limites
maxclients 10000

Game days: testar antes do incidente

# Simular failover controlado
redis-cli -p 26379 SENTINEL failover mymaster
# Monitorar tempo de recuperação

# Simular kill
redis-cli DEBUG SEGFAULT  # NUNCA em produção!
# Em staging: kill -9 <pid> e medir recovery

Checklist de produção

Segurança:

• Autenticação habilitada (requirepass ou ACL)
• Comandos perigosos renomeados/desabilitados
• Bind em IP privado (não 0.0.0.0 público)
• TLS habilitado (se dados sensíveis)
• Firewall restritivo

Disponibilidade:

• Mínimo 1 replica + 3 Sentinels
• min-replicas-to-write configurado
• Clientes usam Sentinel-aware drivers
• Failover testado (game day)

Performance:

• maxmemory configurado (70-80% RAM)
• Política de eviction alinhada ao domínio
• Slowlog monitorado
• P99 medido e com SLA definido

Dados:

• Backup automatizado (RDB + AOF)
• Restore testado
• RPO e RTO documentados

Operação:

• Runbooks escritos e acessíveis
• Alertas configurados (Prometheus/Grafana)
• On-call rotation definida
• Postmortem template pronto

Resumo

• Segurança: autenticação, ACL, desabilitar comandos perigosos, rede privada
• Monitoramento: memória, eviction, replication lag, slowlog, P99
• Backup: RDB + AOF com restore testado; Sentinel para HA
• Game days regulares validam que runbooks funcionam antes do incidente real

Para refletir

"Produção não é o lugar onde se aprende — é o lugar onde se aplica o que já foi ensaiado."

Quantos itens do checklist de produção seu ambiente Redis atende hoje? Qual seria o primeiro a implementar?