É possível atualizar um site sem o deixar indisponível?

Muitas atualizações podem ser implementadas mantendo o site existente disponível. Isto é frequentemente viável para alterações de conteúdo e design, novas páginas e versões de software preparadas com cuidado.

Não é uma promessa aplicável a todas as alterações. Uma atualização que envolva encomendas em curso, contas de clientes, versões de software incompatíveis, infraestrutura ou um serviço externo pode exigir uma janela de manutenção definida. A questão útil não é apenas saber se o site estará online. Importa perceber o que continuará disponível, como será verificada a alteração e o que acontecerá se não funcionar como esperado.

Que atualizações podem ser feitas com o site em funcionamento?

Correções de texto, substituições de imagens, novos artigos e páginas e alterações visuais isoladas podem muitas vezes ser preparadas e disponibilizadas sem retirar todo o site do ar. Também é possível lançar pequenas alterações de software desta forma quando o site e o processo de publicação o permitem.

O tipo de atualização, por si só, não resolve a questão. Uma alteração normal de conteúdo pode afetar menus, pesquisa, páginas em cache ou ficheiros gerados num site, enquanto noutro altera apenas uma página. Mesmo uma tarefa familiar deve ser avaliada no contexto do sistema onde é realizada.

«Online» também precisa de um significado prático. A página inicial carregar corretamente não prova que os pedidos de contacto, pagamentos, início de sessão, pesquisas ou tarefas administrativas continuem a funcionar. As áreas importantes para a empresa precisam de verificações próprias.

O que protege um site de teste?

Um site de teste é um ambiente separado onde uma alteração pode ser preparada e revista antes de chegar aos visitantes. Pode evitar que esquemas incompletos, textos por terminar e falhas funcionais evidentes apareçam no site público durante o trabalho.

O ambiente de teste reduz a incerteza, mas não a elimina. A cópia de teste pode ter dados, tráfego, configuração, credenciais, serviços ligados ou recursos de servidor diferentes. Um teste bem-sucedido é uma indicação útil, não uma garantia de que a produção terá um comportamento idêntico.

O plano de publicação continua a ter de identificar o que será verificado depois de a alteração chegar ao site público.

Como pode uma nova versão substituir a anterior sem mostrar uma página em branco?

Uma opção consiste em preparar a nova versão separadamente enquanto a versão existente continua a servir os visitantes. O tráfego só é encaminhado para a nova versão depois dos testes. Se surgir um problema grave, poderá ser possível voltar a encaminhar o tráfego para a versão anterior.

Este método é frequentemente chamado implementação blue-green. A AWS descreve-o como a transferência de tráfego entre dois ambientes com versões diferentes de uma aplicação. O objetivo é uma indisponibilidade quase nula e um regresso mais rápido ao ambiente anterior.

A implementação blue-green não é a única forma de publicar uma atualização. Alguns sistemas substituem ficheiros de forma atómica, atualizam um servidor de cada vez, encaminham apenas parte do tráfego para a nova versão ou ativam uma funcionalidade concluída quando o trabalho de suporte está pronto. O método adequado depende do site, do alojamento, dos dados e das consequências de uma falha.

Porque são diferentes as alterações à base de dados?

Uma base de dados pode conter encomendas atuais, contas, reservas, mensagens de formulários, inventário, adesões ou conteúdo publicado. Durante uma implementação, tanto a versão antiga como a nova do site podem ter de funcionar com esses dados.

Se a estrutura da base de dados mudar de forma que apenas uma versão do software a compreenda, regressar à versão anterior pode deixar de ser simples. As alterações demoradas também podem competir com a atividade normal do site. Algumas implementações separam, por isso, a preparação da base de dados da atualização da aplicação, mantêm as estruturas antiga e nova compatíveis durante algum tempo ou transferem dados em lotes controlados.

As orientações públicas da GitLab para migrações de bases de dados mostram o nível de detalhe que este planeamento pode exigir. Distinguem migrações regulares, pós-implementação e em segundo plano, e abordam o momento, a reversibilidade, as transações e a contenção de bloqueios. Esses métodos específicos não servem para todos os sites, mas o princípio geral é útil: alterações a dados em tempo real precisam do seu próprio plano de implementação e recuperação.

Uma cópia de segurança é o mesmo que reverter uma versão?

Não. Uma cópia de segurança é uma cópia guardada de dados ou ficheiros que pode ser restaurada. Uma reversão é um procedimento preparado para regressar a um estado funcional conhecido depois de uma implementação sem sucesso.

Restaurar uma cópia de segurança pode demorar e pode substituir encomendas, pedidos de contacto, edições ou alterações de conta válidos feitos depois de a cópia ter sido criada. O código do site pode ser revertido rapidamente, mas isso pode não desfazer uma alteração à base de dados nem uma operação já concluída por um serviço externo de pagamentos, reservas ou correio eletrónico.

Um plano responsável identifica o que pode ser revertido, o que tem de ser corrigido numa nova alteração e como serão tratados os dados criados durante a implementação. As orientações da AWS para alterações sem sucesso recomendam preparar os passos de recuperação antes da implementação e usar monitorização para decidir se a alteração foi bem-sucedida.

Porque poderá alguém continuar a ver a página antiga após uma atualização?

Um site pode manter-se disponível durante toda a atualização e, ainda assim, apresentar brevemente versões diferentes de uma página ou ficheiro a diferentes visitantes. Os navegadores, as redes de distribuição de conteúdos, as caches do servidor e as páginas geradas podem conservar o conteúdo anterior até este expirar, ser validado novamente ou ser limpo de propósito.

Isto é diferente de uma interrupção. Continua a ser relevante quando a atualização altera preços, condições, detalhes de uma campanha, disponibilidade ou outra informação sensível ao tempo.

A limpeza da cache também deve ser proporcional. A Cloudflare recomenda, sempre que possível, uma limpeza direcionada, porque limpar toda a cache faz com que os pedidos seguintes regressem ao servidor de origem até o conteúdo voltar a ser armazenado em cache. O plano deve identificar as páginas e os ficheiros alterados, em vez de tratar todas as caches como um único bloco descartável.

Quando é que uma janela de manutenção é a opção responsável?

Uma janela de manutenção pode ser adequada quando manter o site totalmente ativo durante a atualização representar um risco maior do que uma interrupção curta e comunicada. Isto pode aplicar-se quando:

• os dados em tempo real não podem ser alterados em segurança durante a atualização;
• as versões antiga e nova não conseguem trabalhar com a mesma estrutura de dados;
• a infraestrutura ou o encaminhamento de rede têm de mudar num único passo controlado;
• um fornecedor externo exige uma interrupção ou não disponibiliza um percurso de teste em paralelo;
• ainda não se conhece suficientemente o site atual para fazer uma alteração segura em produção;
• a recuperação seria mais clara e rápida se a atividade fosse suspensa durante um período definido.

A janela deve ter uma justificação, âmbito, duração prevista, decisão de recuperação e plano de comunicação. Para uma empresa que depende de pedidos de contacto, encomendas, reservas ou acesso de membros, não basta dizer «o site estará indisponível para manutenção».

O que devemos perguntar antes de aprovar a atualização?

• Que páginas e funções vão mudar?
• O que poderão continuar a fazer os visitantes e os colaboradores durante o trabalho?
• A alteração será preparada num ambiente separado do site público?
• Como serão protegidos os pedidos de contacto, pagamentos, reservas, alterações de conta e outros dados em tempo real?
• Que verificações confirmarão que a implementação foi bem-sucedida?
• Qual é o plano de recuperação se uma dessas verificações falhar?
• É possível reverter o software sem anular dados novos válidos?
• O alojamento, pagamentos, correio eletrónico, identidade, reservas ou outros serviços externos afetam o calendário?
• Quem decide se se continua, se se corrige ou se se reverte?
• Como e quando serão informados os utilizadores afetados?

As respostas não têm de descrever todos os comandos técnicos. Devem deixar claro o efeito para a empresa.

Como aborda a LINK-V as atualizações de sites?

Quando avaliamos ou mantemos um site, analisamos o site, o alojamento, o CMS, a base de dados, as integrações, as cópias de segurança, os acessos e os riscos operacionais antes de decidir como publicar o trabalho. O método correto depende do que muda e do sistema existente.

O nosso objetivo é que as atualizações normais decorram com tranquilidade e proporção, sendo claros quando uma alteração exige uma interrupção controlada. Se o seu site apoia vendas diárias, pedidos de contacto, reservas, adesões ou publicações, podemos avaliar a sua configuração de manutenção e acompanhamento contínuo.