Gestão de crise: o que fazer quando o site cai na Black Friday

A Black Friday é o dia mais crítico para o comércio eletrônico. Quando o site cai nessa data, cada segundo de indisponibilidade representa milhares de reais em perdas, danos à reputação e clientes frustrados. A diferença entre uma crise gerenciada e um desastre completo está na preparação e na execução de um protocolo bem definido. Este artigo apresenta um guia prático para lidar com quedas de site durante a Black Friday, desde a preparação prévia até as lições aprendidas.

1. Preparação prévia: o que fazer antes da Black Friday

A prevenção começa semanas antes do grande dia. O primeiro passo é o mapeamento de riscos, identificando cenários de falha como pico de tráfego, falha de banco de dados, sobrecarga de CDN ou dependências externas.

Crie um playbook de crise documentado com:

  • Contatos de emergência (devops, DBA, infra, CTO, marketing)
  • Scripts de rollback automatizados para versões estáveis
  • Procedimentos de escalonamento (quem acionar e em quanto tempo)
  • Lista de comandos para restart de serviços críticos
# Exemplo de playbook de crise - Seção de contatos
# Prioridade 1 (acionamento imediato, <2 min)
- DevOps plantão: +55 11 99999-0001 (WhatsApp/Slack)
- DBA plantão: +55 11 99999-0002 (PagerDuty)

# Prioridade 2 (acionamento em 5 min)
- Comandante do incidente: Maria Souza (Slack @maria)
- C-Level: João Silva (Telegram @joao.cto)

# Scripts de rollback
- Rollback de aplicação: /scripts/rollback-app.sh
- Rollback de banco: /scripts/rollback-db.sh

Realize testes de estresse simulando o pico esperado de tráfego (2x a 3x o volume projetado). Promova game days — simulações de queda programada onde a equipe pratica o protocolo de crise sem aviso prévio.

2. Ativação do protocolo de crise: os primeiros 5 minutos

Quando o site cai, os primeiros 5 minutos definem o sucesso da resposta. Siga este checklist:

  1. Identifique o tipo de falha: aplicação (erro 500), infraestrutura (timeout, DNS), terceiros (CDN, pagamento)
  2. Acione o canal de guerra: Slack #crise-blackfriday, PagerDuty, Telegram — com todos os envolvidos
  3. Defina o comandante do incidente (única pessoa autorizada a tomar decisões críticas)
  4. Comunique stakeholders internos: C-level, marketing, suporte (mensagem padronizada)
# Mensagem padrão para comunicação interna (primeiros 5 min)
🚨 INCIDENTE CRÍTICO - BLACK FRIDAY 🚨
Tipo: [aplicação/infra/terceiros]
Impacto: [total/parcial/usuários afetados]
Comandante: [nome]
Status: [diagnosticando/mitigando]
Próxima atualização: em [5/10/15] minutos

3. Diagnóstico rápido: encontrando a causa raiz sob pressão

Com o protocolo ativado, o foco é descobrir a causa raiz rapidamente. Utilize:

  • Dashboards de APM (New Relic, Datadog, Dynatrace) para identificar gargalos ou erros
  • Métricas de infraestrutura (CPU, memória, conexões de banco) em tempo real
  • Logs centralizados (ELK Stack, Grafana Loki) com busca por palavras-chave como "error", "timeout", "OOM"
  • Rastreamento distribuído (Jaeger, Zipkin) para identificar onde a requisição quebra
# Comandos rápidos para diagnóstico (exemplo com Docker/K8s)
# Verificar logs de erro da aplicação
kubectl logs -n production --selector=app=frontend --tail=100 | grep "ERROR\|FATAL"

# Verificar uso de recursos
kubectl top pods -n production

# Testar conectividade com banco de dados
nc -zv db-internal.cluster.local 5432

A decisão crítica: mitigar imediatamente (rollback, feature toggle) ou corrigir no calor do momento? Regra de ouro: se a correção levar mais de 5 minutos, faça rollback.

4. Estratégias de mitigação imediata para manter o site no ar

Enquanto investiga a causa, implemente medidas para restaurar o serviço:

  • Auto-scaling: ative escalonamento horizontal de pods/servidores
  • Balanceamento de carga: redirecione tráfego para servidores saudáveis
  • Feature flags: desative funcionalidades não críticas (recomendações, busca avançada, chat)
  • Degradação graciosa: mostre versão estática do catálogo, sem carrinho ou login
  • Cache forçado: sirva conteúdo em cache mesmo que expire (TTL estendido)
  • Rate limiting: limite requisições por IP para proteger o backend
# Exemplo de ativação de feature toggle (usando LaunchDarkly ou similar)
# Desativar busca avançada e recomendações
curl -X POST https://api.featureflags.com/flags/disable \
  -H "Authorization: Bearer ${TOKEN}" \
  -d '{"flag": "search-advanced", "environment": "production"}'

curl -X POST https://api.featureflags.com/flags/disable \
  -H "Authorization: Bearer ${TOKEN}" \
  -d '{"flag": "recommendations", "environment": "production"}'

# Aplicar rate limiting via Nginx
rate_limit_zone blackfriday $binary_remote_addr zone=bf:10m rate=100r/s;
location /api/checkout {
  limit_req zone=bf burst=20 nodelay;
}

5. Comunicação com o usuário: transparência sem pânico

Enquanto a equipe técnica trabalha, o usuário precisa de informações claras. Nunca mostre uma página de erro genérica.

  • Página de erro personalizada: mensagem amigável explicando o problema e que a equipe já está atuando
  • Status page pública: atualize em tempo real no status.exemplo.com
  • Redes sociais: publique comunicado oficial no Twitter/X, Instagram e LinkedIn
# Exemplo de página de erro (HTML simplificado)
<!DOCTYPE html>
<html>
<head><title>Estamos de volta em breve!</title></head>
<body>
  <h1>🛒 A Black Friday está bombando!</h1>
  <p>Nosso site está temporariamente com alto volume de acessos.</p>
  <p>Nossa equipe já está trabalhando para恢复正常 o serviço.</p>
  <p>Acompanhe em tempo real: <a href="https://status.exemplo.com">status.exemplo.com</a></p>
  <p>⚠️ Não se preocupe: ofertas válidas serão estendidas.</p>
</body>
</html>

Nunca prometa tempo de resolução sem certeza. Use frases como "estamos trabalhando para恢复正常 o mais rápido possível".

6. Pós-crise: o que fazer depois que o site voltar

Após restaurar o serviço, o trabalho continua. Siga estes passos:

  1. Colete evidências: logs, métricas, screenshots, timestamps de cada ação
  2. Realize a reunião de post-mortem (sem culpa) com times de dev, infra e produto
  3. Documente a cronologia completa do incidente
# Template de post-mortem
# Título: Incidente Black Friday 2024
# Data: 29/11/2024 | Duração: 47 minutos
# Impacto: 100% dos usuários afetados, R$ 2.3M em perdas estimadas

# Linha do tempo
- 00:00:00 - Queda detectada (monitoramento)
- 00:01:30 - Canal de crise acionado
- 00:03:00 - Comandante definido
- 00:05:00 - Diagnóstico: banco de dados sobrecarregado
- 00:08:00 - Rollback de query executado
- 00:12:00 - Auto-scaling ativado
- 00:35:00 - Site恢复正常 (degradado)
- 00:47:00 - Site 100% operacional

# Causa raiz
Query não indexada em tabela de produtos com 50M+ registros

# Ações corretivas
1. Adicionar índice composto na tabela products (prazo: 24h)
2. Revisar todas as queries do checkout (prazo: 1 semana)
3. Implementar rate limiting por usuário (prazo: 2 semanas)

7. Lições aprendidas e melhoria contínua para o próximo evento

A crise termina, mas o aprendizado continua. Use o post-mortem para:

  • Atualizar o playbook com novos cenários descobertos
  • Revisar SLAs com provedores de infraestrutura e CDN
  • Aumentar budget de infraestrutura se necessário (auto-scaling maior, mais réplicas)
  • Compartilhar o relatório final com toda a empresa, celebrando os acertos e reconhecendo os erros
# Checklist de melhoria contínua pós-Black Friday
[ ] Playbook de crise atualizado com novo cenário (query lenta)
[ ] Teste de estresse agendado para próxima semana
[ ] Feature flags revisadas e novas flags criadas
[ ] SLA com cloud provider renegociado (99.99% -> 99.995%)
[ ] Comunicação interna: relatório enviado para todos os times

A gestão de crise na Black Friday não é sobre evitar quedas — é sobre responder de forma organizada, rápida e transparente quando elas acontecem. Com preparação, protocolos claros e uma equipe treinada, é possível transformar um momento de pânico em uma demonstração de competência e confiabilidade.

Referências