Plano de Ação¶
Visão Geral das Fases¶
Abordagem
Todas as alterações seguem o princípio de staging primeiro, produção depois. Nenhuma alteração é aplicada diretamente em produção sem validação prévia no ambiente de qualidade (www.qual.unicef.pt). Os tempos indicados incluem margens de segurança para testes e validação.
Fase 1 — Configurações Azure (Risco Baixo, 1 dia)¶
Estas alterações são de configuração no Azure Portal. Não requerem alterações de código. Devem ser aplicadas primeiro no ambiente de qualidade para validação e depois em produção.
| # | Ação | Local | Risco | Tempo |
|---|---|---|---|---|
| 1 | Ativar Always On no App Service | Azure Portal → App Service → Configuration → General Settings | Nenhum | 5 min |
| 2 | Ativar Application Insights ingestion | Azure Portal → Application Insights → Properties | Nenhum | 15 min |
| 3 | Ativar HTTP/2 | Azure Portal → App Service → Configuration → General Settings | Nenhum | 5 min |
| 4 | Configurar Health Check path | Azure Portal → App Service → Health check | Nenhum | 15 min |
32-bit vs 64-bit
A configuração 32-bit é mantida nesta fase. O modo 32-bit é mais eficiente em termos de memória. Após a limpeza da base de dados e ativação do Application Insights, será possível monitorizar o consumo real de memória e decidir se a alteração é necessária.
Processo de Aplicação¶
Nota sobre o worker 64-bit
A mudança de 32-bit para 64-bit pode, em casos raros, causar incompatibilidades com DLLs compiladas para x86. Embora seja improvável neste projeto, recomenda-se testar primeiro em qualidade durante pelo menos 24 horas antes de aplicar em produção.
Impacto Esperado
Com Always On ativo, os cold starts deixam de acontecer. Com o worker em 64-bit, a aplicação passa a ter acesso a toda a memória disponível (em vez do limite de 2 GB). Estas duas alterações, por si só, deverão eliminar os crashes mais frequentes.
Fase 2 — Limpeza da Base de Dados (Risco Médio, 2-3 semanas)¶
Esta é a fase mais crítica e que requer mais cuidado. Envolve a execução de scripts SQL para remover dados acumulados desnecessários. O processo deve ser rigoroso e faseado.
Semana 1 — Preparação e Testes em Staging¶
| # | Ação | Risco | Tempo Estimado |
|---|---|---|---|
| 1 | Exportar backup fresco da BD de produção (uncdb-prd) |
Nenhum | 30 min |
| 2 | Restaurar backup no ambiente de qualidade (uncdb-qual) |
Nenhum | 1 hora |
| 3 | Executar scripts de limpeza em qualidade, um de cada vez | Baixo | 1 dia |
| 4 | Validação funcional completa em qualidade — testar todas as páginas, navegação, pesquisa, backoffice Umbraco | Nenhum | 2-3 dias |
| 5 | Documentar resultados: tamanhos antes/depois, tempos de resposta | Nenhum | 1 dia |
Semana 2 — Validação Alargada e Preparação para Produção¶
| # | Ação | Risco | Tempo Estimado |
|---|---|---|---|
| 6 | Manter qualidade em observação com dados limpos durante vários dias | Nenhum | 3-5 dias |
| 7 | Testar cenários de carga: cold start, navegação intensiva, backoffice | Nenhum | 1 dia |
| 8 | Preparar plano de rollback detalhado | Nenhum | 2 horas |
| 9 | Alinhar janela de manutenção com a equipa UNICEF | Nenhum | - |
Semana 3 — Execução em Produção¶
| # | Ação | Risco | Tempo Estimado |
|---|---|---|---|
| 10 | Fazer backup completo da BD de produção (PITR + export manual) | Nenhum | 30 min |
| 11 | Executar scripts de limpeza em produção, durante janela de manutenção | Médio | 2-4 horas |
| 12 | Reconstruir índices SQL | Baixo | 30 min |
| 13 | Reiniciar App Service para limpar caches em memória | Nenhum | 5 min |
| 14 | Validação funcional — testar site, backoffice, API | Nenhum | 1-2 horas |
| 15 | Monitorizar durante 48-72 horas | Nenhum | 3 dias |
Ordem de Execução dos Scripts¶
Plano de Rollback
Em caso de problemas após a limpeza em produção, é possível restaurar a base de dados para qualquer ponto nos últimos 14 dias usando o Azure SQL Point-In-Time Restore. Este processo demora aproximadamente 30-60 minutos. O comando está documentado na secção Disaster Recovery.
Janela de Manutenção
A execução em produção deve ser realizada durante um período de baixo tráfego, acordado previamente com a equipa UNICEF. Recomenda-se um sábado de manhã ou um período noturno.
Impacto Esperado
Redução significativa do tamanho da base de dados. Cold starts substancialmente mais rápidos. Gestão de redirecionamentos funcional novamente (icUrlTracker utilizável). Queries mais rápidas em toda a aplicação.
Fase 3 — Otimizações (Risco Baixo, 2 semanas)¶
Após as correções imediatas e a limpeza da BD, estas otimizações melhoram a resiliência e a monitorização. Devem ser implementadas com base nos dados recolhidos pelo Application Insights nas semanas anteriores.
| # | Ação | Prioridade | Notas |
|---|---|---|---|
| 1 | Configurar Auto Heal rules | Alta | Reinício automático em caso de memória elevada ou erros |
| 2 | Configurar alertas no Application Insights | Alta | Alertas de tempo de resposta, erros, disponibilidade |
| 3 | Configurar testes de disponibilidade | Alta | Ping tests a cada 5 minutos de múltiplas localizações |
| 4 | Avaliar escalamento do SQL (S1 → S2 ou vCore) | Média | Decidir com base nos dados reais do App Insights |
| 5 | Desligar recursos não utilizados | Média | Após confirmação da equipa (~475-585 EUR/mês de poupança) |
| 6 | Rever e limpar DNS records não utilizados | Média | Remover registos A a apontar para servidores externos |
| 7 | Corrigir certificados SSL em falta | Alta | Domínios sem SSL: guerras, crises, presentesunicef |
| 8 | Configurar monitorização externa | Média | UptimeRobot ou similar como backup independente |
Fase 4 — Evolução Técnica (Longo Prazo)¶
Estas são melhorias estruturais que devem ser planeadas a médio/longo prazo. Requerem investimento significativo mas são essenciais para a sustentabilidade do projeto.
| # | Ação | Horizonte | Complexidade | Benefício |
|---|---|---|---|---|
| 1 | Implementar CI/CD pipeline | 1-2 meses | Média | Deploys automatizados e controlados com slot swap |
| 2 | Remover código de pagamentos (se confirmado que não é usado) | 1-2 meses | Baixa | Reduzir superfície de ataque e complexidade |
| 3 | Upgrade Umbraco 7 → 13+ (.NET 8) | 6-12 meses | Alta | Suporte ativo, performance, segurança |
| 4 | Substituir AngularJS 1.x por framework moderno | 6-12 meses | Alta | AngularJS descontinuado desde janeiro de 2022 |
| 5 | Migrar para .NET 8+ | 6-12 meses | Alta | Performance, suporte LTS, funcionalidades modernas |
Nota sobre Umbraco 7
O Umbraco 7 atingiu o fim de vida (EOL) e já não recebe atualizações de segurança. A migração para Umbraco 13+ (LTS) deve ser considerada uma prioridade estratégica. Esta migração implica reescrever a camada de frontend e adaptar os templates.