Migração de servidor sem downtime para site da Penha — Guia prático

Como migrar um site WordPress de missão crítica sem que nenhum visitante perceba a troca de infraestrutura? A resposta está em planejamento cirúrgico, automação de sincronismo e validação em camadas — não em sorte.

A Penha, bairro com comércio intenso e serviços 24h, exige disponibilidade contínua. Qualquer minuto de indisponibilidade impacta agendamentos, reputação e receita. Por isso, a estratégia abaixo prioriza previsibilidade sobre velocidade bruta.

Planejamento e inventário técnico

Liste cada componente: versão do PHP (8.2+), extensões (imagick, redis, mbstring), MySQL/MariaDB (10.6+), servidor web (Nginx + PHP-FPM), Redis/Memcached, certificados SSL, regras de firewall, crons do WP-Cron e jobs externos. Documente variáveis de ambiente (.env), chaves de API (Stripe, WhatsApp Business, Google Maps) e caminhos absolutos no código.

Use wp cli core version, wp plugin list --format=json e wp theme list para gerar manifesto versionado. Compare com php -m e nginx -V no destino. Qualquer divergência vira item de bloqueio no checklist.

Preparação do DNS com TTL baixo

Quarenta e oito horas antes da janela de migração, reduza o TTL dos registros A, AAAA, CNAME e TXT para 300 segundos (5 minutos). Isso força resolvers recursivos a consultar a zona com frequência, encurtando a janela de inconsistência quando o IP mudar.

Valide a propagação do TTL reduzido com dig @1.1.1.1 dominio.com A +short e dig @8.8.8.8 dominio.com A +short a cada hora. Se algum nameserver autoritativo não reflete o novo TTL, abra chamado no provedor de DNS imediatamente.

Ambiente de staging espelhado

Provisione o novo servidor com imagem idêntica à produção: mesmo SO (Ubuntu 22.04 LTS ou AlmaLinux 9), mesmos pacotes, mesmas configurações de php.ini (memory_limit, max_execution_time, opcache), my.cnf (innodb_buffer_pool_size, max_connections) e nginx.conf (worker_processes, gzip, cache keys).

Automatize com Ansible ou script shell versionado. O repositório cabeamento-estruturado-em-cambuci-garante-velocidade-para-staging-wordpress detalha como infraestrutura física previsível elimina variáveis de latência no staging.

Sincronize arquivos com:

rsync -avz --delete-after --exclude='wp-content/cache/' --exclude='wp-content/uploads/backup-*/' \
  usuario@servidor-antigo:/var/www/html/ /var/www/html/

Para o banco, prefira mydumper --threads=4 --compress --outputdir=/tmp/dump seguido de myloader --threads=4 --directory=/tmp/dump. Em bases > 5 GB, use replicação GTID temporária (MASTER_AUTO_POSITION=1) nos 30 minutos finais.

Validação funcional automatizada

Antes de tocar no DNS, execute suíte de testes no staging:

1. wp cli core verify-checksums
2. Login admin + nonce validation
3. Fluxo completo de checkout (carrinho → pagamento sandbox → webhook)
4. Formulários de contato/agendamento (CF7, Gravity Forms, Elementor Forms)
5. Endpoints REST API consumidos por app mobile
6. Geração de PDFs, exportações CSV e e-mails transacionais
7. Verificação de links quebrados com wget --spider -r -l 3 https://staging.dominio.com

Integre esses testes ao pipeline CI/CD (GitHub Actions, GitLab CI). O artigo autenticacao-via-application-passwords-na-rest-api mostra como autenticar chamadas de teste sem expor credenciais.

Troca controlada e monitoramento ativo

No horário de menor tráfego (geralmente 02h–04h), altere o registro A/AAAA para o IP do novo servidor. Mantenha o servidor antigo respondendo (não desligue).

Monitore em tempo real:

• tail -f /var/log/nginx/access.log | grep -E ' 5[0-9]{2} '
• watch -n 2 'mysqladmin -u root -p status'
• redis-cli --latency-history -h 127.0.0.1
• Uptime Kuma / Healthchecks.io para endpoints críticos

Se erro rate > 0.5% ou p95 latency > 3s por 5 minutos consecutivos, inicie rollback imediato (veja seção abaixo).

Rollback em menos de 5 minutos

Script rollback.sh versionado no repositório:

#!/usr/bin/env bash
set -euo pipefail
OLD_IP="203.0.113.10"
DOMAIN="penha-servicos.com.br"
curl -X PUT "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records/$RECORD_ID" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"type\":\"A\",\"name\":\"@\",\"content\":\"$OLD_IP\",\"ttl\":300}"
curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'
echo "Rollback concluído. Verifique propagação com dig @1.1.1.1 $DOMAIN A"

Teste o rollback em staging mensalmente. Documentação viva evita pânico.

Pós-migração: estabilização e lições aprendidas

Mantenha ambos servidores ativos por 48h com logs centralizados (Loki, Elastic ou Papertrail). Compare métricas: TTFB, Core Web Vitals, taxa de erro, uso de CPU/RAM. O post desenvolvedor-wordpress-organizando-rotina-com-troca-de-oleo-em-sao-paulo ilustra como rotinas de observabilidade evitam surpresas.

Registre runbook com timestamps, decisões, comandos executados e resultados. Compartilhe com a equipe em retrospectiva técnica.

A migração sem downtime não é mágica — é engenharia disciplinada. Com TTL baixo, staging idêntico, validação automatizada e rollback testado, o site da Penha continua atendendo emergências 24h sem piscar. desentupidora especialista na Penha

Checklist prático

Perguntas frequentes