Introdução
Self‑hosted significa controlo — mas também responsabilidade. Para instalações Affilentra (PHP/MySQL) são necessários backups fiáveis, caminhos de migração reproduzíveis e processos de rollback testados para assegurar que o rastreio, o cálculo de comissões e os pagamentos funcionem sem interrupções. Este artigo fornece recomendações práticas que pode implementar de imediato para minimizar tempos de inatividade e tornar os tempos de recuperação previsíveis.
Princípios básicos de uma estratégia robusta
- Separar funções: Operadores de software executam tarefas de infraestrutura (backups, upgrades), comerciantes coordenam campanhas e parceiros verificam a integridade do tracking.
- Separação de código e dados: Fazer backups do sistema de ficheiros (webroot, media, criativos) separadamente da base de dados.
- Automatizar, documentar, testar: Cada passo de backup e migração deve ser automatizável e reproduzível num ambiente de teste.
- Migrações minimamente invasivas: Projetar alterações ao esquema de forma que os caminhos de código antigos e novos possam coexistir temporariamente.
Estratégia de backup: intervalos e retenção
Uma combinação prática de backups completos, cópias incrementais e registo contínuo de transacções reduz a janela de recuperação.
- Base de dados:
- Backup completo (físico ou lógico) pelo menos uma vez por dia em sistemas activos.
- Para RTO/RPO reduzidos: activar e arquivar regularmente os MySQL binary logs para permitir recuperação até um ponto no tempo.
- Para bases de dados grandes: usar backups físicos (por exemplo Percona XtraBackup) ou snapshots consistentes via replicação, para evitar bloqueios.
- Sistema de ficheiros / ficheiros da aplicação:
- Backup completo diário; em caso de alterações frequentes (criativos, uploads) efectuar também cópias incrementais horárias.
- Antes de cada upgrade, criar sempre um snapshot imediato.
- Retenção: Mínimo: backups diários dos últimos 7 dias; backups semanais por 8 semanas; backups mensais por 12 meses. Ajuste a retenção conforme requisitos regulamentares e necessidades do negócio.
- Offsite e verificação: Armazenar backups encriptados em pelo menos um local externo. Testar a restauração regularmente (por exemplo, mensalmente).
Snapshots de BD e ferramentas
Escolha a ferramenta adequada ao tamanho e aos requisitos de disponibilidade da sua instalação.
- instalações pequenas: mysqldump é adequado para backups lógicos e restaurações simples.
- instalações médias a grandes: Percona XtraBackup ou snapshots físicos (LVM, ZFS) fornecem backups consistentes e mais rápidos sem longos bloqueios.
- replicação como fonte de backup: Uma réplica somente leitura pode ser usada para backups e para ambientes de teste, de modo a não impactar a carga de produção.
- Antes do upgrade: Sempre crie um snapshot consistente incluindo logs binários ativos e registre a posição do binlog.
Caminhos de migração entre versões
Planeie migrações de forma a manter a integridade dos dados e possibilitar rollbacks.
- Migrações versionadas: Utilize um framework de migrações (por exemplo, Doctrine Migrations, Phinx ou uma ferramenta interna) com scripts Up e Down claramente definidos.
- Prefira alterações aditivas: Adicione novas colunas como nullable, crie índices em passos separados e execute backfills migracionais de forma assíncrona.
- Compatibilidade para trás: Faça o deploy de código que funcione tanto com o esquema antigo quanto com o novo. Só depois de um deploy bem‑sucedido e do backfill é que se muda para o novo esquema e se removem funcionalidades legadas posteriormente.
- Evite pasos de bloqueio no esquema: Operações longas de ALTER TABLE devem ser preparadas em réplicas e então executadas por procedimentos controlados (pt‑online‑schema‑change, gh‑ost).
Ambientes de teste & CI/CD
Um ambiente de teste que reflita a produção é obrigatório.
- Cópia completa de staging: Gerar regularmente a partir de snapshots de produção, incluindo sistema de ficheiros e BD (prever mascaramento de dados sensíveis).
- Execuções automatizadas de migrações: Executar cada migração no CI contra o staging e automatizar testes de integração e smoke tests (fluxo de tracking, conversão, cálculo de comissões, histórico de pagamentos).
- Canary / Blue‑Green: Para releases maiores recomenda‑se um rollout Canary (pequena percentagem de tráfego) ou um deployment Blue‑Green, para permitir retorno rápido à ambiente estável em caso de falhas.
Processos de rollback: Passo a passo
Um plano de reversão testado minimiza os riscos operacionais.
- Preparação: Antes do release, backup completo + posição do binlog; definir checklist do release e responsabilidades.
- Priorizar opções de rollback:
- Rollback da aplicação (opção mais rápida) — quando as migrações forem reversíveis e não tiverem sido destrutivas.
- Restaurar a base de dados a partir de snapshot — necessário quando migrações incluem alterações irreversíveis ou ocorreu corrupção de dados.
- Passos em caso de erro:
- Bloquear escritas ou entrar em modo de manutenção.
- Reverter a aplicação para a versão anterior.
- Se necessário, restaurar o BD a partir do snapshot e reproduzir os binlogs até imediatamente antes da alteração com erro.
- Executar smoke tests e, após validação, liberar novamente as escritas.
- Comunicação: Informar comerciantes e parceiros de forma proativa sobre possíveis impactos no tracking e nos pagamentos.
Fluxo prático de upgrade (exemplo)
Fluxo concreto para uma janela de release normal:
- 72–48 horas antes: publicar notas do release, plano de testes, e nomear responsáveis.
- 24 horas antes: backup completo da BD, arquivar os binlogs, snapshot dos ficheiros do webroot.
- Antes do deploy: restaurar staging a partir do snapshot e executar os testes automatizados.
- Deploy em Canary/Blue‑Green: aumentar o tráfego gradualmente, monitorizar por 30–60 minutos.
- Após liberação: executar backfills assíncronos e construção de índices; remover campos antigos apenas depois de um período de observação.
Monitorização, validação e governança
Após cada upgrade são necessárias verificações sistemáticas:
- Smoke tests: gerar link de tracking, simular conversão, verificar cálculo de comissões, controlar registros de pagamento.
- Logs e métricas: observar taxas de erro, latências, comprimentos de filas e queries lentas na BD.
- Audit e change‑log: documentar cada migração e cada rollback, incluindo referência do backup e posição do binlog.
Responsabilidades baseadas em funções
Distribuição clara de tarefas reduz atritos:
- Operador de software: Assegura automação de backups, gestão de snapshots, aplicação de upgrades e rollbacks.
- Comerciantes/Merchants: Planeiam campanhas em torno das janelas de manutenção; verificam métricas de campanha e criativos após o release.
- Parceiros/Publishers: Verificam links de tracking e histórico de pagamentos após um release e reportam imediatamente discrepâncias.
Conclusão e próximos passos
Para instalações Affilentra, o planeamento compensa: backups consistentes, uma estratégia de migração em fases e procedimentos de reversão testados reduzem riscos de indisponibilidade e protegem os rendimentos. Comece com três medidas simples: backups diários da BD + arquivamento de binlog, restauração em staging antes de cada versão e uma lista de verificação escrita de reversão.
Pronto para o próximo passo? Escolha a sua entrada e receba aconselhamento sobre opções de licença adequadas e pacotes de suporte: Escolher entrada.
Próximo passo
Experimentar o Affilentra
Plataforma única que integra de forma transparente disponibilização de produtos, tracking, validação de conversões, cálculo de comissões e pagamentos através de funções claramente separadas; opção de instalação auto‑hospedada com licença perpétua sem participação nos rendimentos; os comerciantes mantêm o controlo sobre produtos, condições e materiais promocionais; os parceiros recebem links de tracking pessoais e um histórico de pagamentos auditável.