Como você atualiza um site ativo e movimentado da maneira mais educada possível?

https://stackoverflow.com/questions/67368

09-06-2019
|

Pergunta

Ao implementar alterações em um site ativo, como você verifica se o ao vivo sistema está funcionando corretamente?Quais ferramentas você usa?Quem faz isso?Você bloqueia o acesso ao site durante o período de teste?Que quantidade de tempo de inatividade é aceitável?

Solução

Costumo fazer todos os meus testes em outro ambiente (não no ambiente real!).Isso me permite enviar as atualizações para o site ativo sabendo que o código deve estar funcionando bem, e eu apenas faço testes de sanidade nos dados ativos - certifique-se de que não esqueci um arquivo em algum lugar ou que algo estranho deu errado.

Portanto, testes adequados em um ambiente de teste ou teste e, em seguida, apenas uma verificação trivial de integridade.Não há necessidade de tempo de inatividade.

Outras dicas

Muitos bons conselhos já.

Como as pessoas mencionaram, se você não tiver um único ponto envolvido, é simples implementar as alterações gradualmente, atualizando um servidor de aplicativos por vez.Mas isso raramente acontece, então vamos ignorar isso e focar nas partes difíceis.

Geralmente há um banco de dados que é comum a todo o resto.Então isso significa tempo de inatividade para todo o sistema. Como você minimiza isso?

Automação.Faça o script de todo o procedimento de implantação.Isso (especialmente) inclui quaisquer alterações no esquema do banco de dados.Isso inclui (especialmente) qualquer migração de dados necessária entre versões do esquema.

Controle de qualidade.Certifique-se de que haja testes.Testes de aceitação automatizados (o que o usuário vê e espera do ponto de vista da lógica de negócios/experiência).Considere ter contas de teste no sistema de produção nas quais você possa criar scripts para testar atividades somente leitura.Se você não interage com outros sistemas externos, considere realizar atividades de gravação também.Pode ser necessário filtrar a atividade da conta de teste em certas partes do sistema, especialmente se elas lidarem com dinheiro e contabilidade.Os contadores de grãos ficam chateados, por boas razões, quando os grãos não combinam.

Ensaiar.Implante em um ambiente de teste que seja o mais idêntico possível ao de produção.Faça isso com volumes de dados de produção e dados de produção.Você precisa sentir quanto tempo leva uma alteração na tabela.E você precisa verificar se uma tabela alterada funciona tanto estruturalmente quanto com todas as chaves estrangeiras nos dados reais.

Se você tiver grandes volumes de dados, as alterações de esquema levarão tempo.Talvez mais tempo do que você pode ficar inativo.Uma solução é usar migrações de dados em fases, para que a alteração do esquema seja preenchida com dados "recentes" ou "atuais" (digamos, de um ou três meses) durante o tempo de inatividade, e os dados dos cinco anos restantes possam aparecer depois que você estiver on-line novamente.Para o usuário final, as coisas parecem boas, mas alguns recursos não podem ser acessados por mais algumas horas/dias/qualquer coisa.

No trabalho, passamos um período com o código congelado no ambiente de teste.Então, após algumas semanas de aviso prévio, retiramos o site à meia-noite de sexta-feira, trabalhamos a noite toda na implantação e validação e o colocamos no ar no sábado, no final da manhã.As estatísticas de tráfego nos mostraram que este era o melhor período para fazer isso.

Se você tiver um conjunto de servidores com balanceamento de carga, poderá colocar um por um off-line separadamente e atualizá-lo.Sem tempo de inatividade para os usuários!

Tenha uma imagem e/ou página de backup fofa e desarmante.Alguns sites implementam jogos javascript simples para mantê-lo ocupado enquanto aguarda a atualização.

Por exemplo, falhe baleia.

-Adão

No último local onde trabalhei, o QA realizava testes no Ambiente QA.Quaisquer problemas importantes seriam corrigidos, testados e verificados antes da implementação.

Após a compilação ter sido certificada pelo controle de qualidade, a equipe de suporte à produção enviou o código para o ambiente Staging, onde o cliente consulta o site e verifica se tudo está conforme desejado.

O lançamento real da produção ocorre fora do horário comercial (depois das 21h).se for um empurrão noturno de emergência, ou a partir das 5h.- 8 horas da manhã.se for uma implementação normalmente agendada).

O site está hospedado em vários servidores, que têm balanceamento de carga usando um balanceador de carga F5:

Alguns servidores foram removidos da produção,
o código está instalado e
uma verificação superficial é executada nos servidores antes de colocá-los de volta no pool.

Isso é repetido até que todos os servidores sejam atualizados para o código mais recente e permita que o site permaneça ativo o tempo todo.

Esse processo é ideal, mas há casos em que o banco de dados também precisa ser atualizado.Se for esse o caso, existem duas opções, dependendo se o novo banco de dados irá quebrar o site ou não.

Se o novo banco de dados for incompatível com o front-end existente, você não terá outra escolha a não ser ter uma janela de tempo em que o site ficará inativo.

Mas se o novo banco de dados for compatível com o front-end existente, você ainda poderá enviar o código sem nenhum tempo de inatividade real, mas isso exigirá que haja dois servidores de banco de dados de produção.

Todo o tráfego é roteado para o segundo banco de dados e o primeiro servidor de banco de dados é extraído.
O primeiro banco de dados é atualizado e, após a conclusão da verificação, é colocado novamente em produção.
Todo o tráfego é roteado para o primeiro banco de dados e o segundo banco de dados é extraído.
O segundo banco de dados é atualizado e, após a verificação ser concluída, colocado novamente em produção.
A próxima etapa é realizar as atualizações parciais conforme descrito acima.

Então, para resumir:

Ao implementar alterações em um site ativo, como você verifica se o sistema ativo está funcionando corretamente? Na melhor das hipóteses, isso é feito de forma incremental.
Quais ferramentas você usa? Verificações manuais para verificar se o código está instalado corretamente junto com alguns testes automatizados básicos, usando qualquer ferramenta de automação.Usamos Selenium IDE.
Quem faz isso? O DBA realiza atualizações de banco de dados, o suporte técnico/administradores de sistema envia/pull os servidores e instala o código, e o suporte de controle de qualidade ou produção executa os testes manuais e/ou executa os testes automatizados.
Você bloqueia o acesso ao site durante o período de teste? Se possível, isso deve ser evitado a todo custo, principalmente, como Gilles mencionou anteriormente, se for um site pago.
Que quantidade de tempo de inatividade é aceitável? O tempo de inatividade deve ser restrito aos horários em que os usuários têm menor probabilidade de usar o site e deve ser feito em menos de 3 horas.
Observação: 3 horas é muito generoso.Depois de praticar e ensaiar, como jplindstrom mencionou, a equipe terá todo o processo resolvido e poderá entrar e sair em menos de uma hora.

Espero que isto ajude!

Parte disso depende se você também está atualizando um banco de dados.No passado, se o banco de dados estivesse sendo atualizado, desligávamos o site por um período de manutenção planejado (e publicado) - geralmente algo fora do horário em que o impacto era mínimo.Se a atualização não envolver o banco de dados, em um ambiente com carga balanceada, retiraremos 1 caixa do mix, implantaremos e testaremos.Se desse certo, ele entrava no mix e a outra caixa (assumindo 2 caixas) era trazida e atualizada/testada.

Observação:NÃO estamos testando o código, apenas que a implantação ocorreu sem problemas, de modo que o tempo de inatividade foi mínimo.Como foi mencionado, o código já deveria ter passado nos testes em outro ambiente.

Longos tempos de inatividade (horas) da IMHO são aceitáveis para um site gratuito.Se você educar seus usuários o suficiente, eles entenderão que é uma necessidade.Talvez dê a eles algo para brincar até que o site volte a funcionar (por exemplo.jogo em flash, transmissão ao vivo da webcam mostrando a equipe de desenvolvimento trabalhando, etc.).Para um site que as pessoas pagam para acessar, muitas pessoas vão perder seu tempo com reclamações se você as alimentar com períodos de inatividade regulares.Eu evitaria o tempo de inatividade como uma praga e lançaria atualizações muito lenta e cuidadosamente se estivesse executando um serviço que cobra dos usuários.

Na minha configuração atual, tenho um site secundário conectado ao mesmo banco de dados e cache da live copy para testar minhas alterações.

Também tenho vários scripts de "observador de páginas" em execução em tarefas cron que usam expressões regulares para verificar se o site está renderizando as páginas principais corretamente.

A resposta é que depende".Em primeiro lugar, no tipo de ambiente em que você está liberando.É um site do tipo "olá, mundo" em um host compartilhado em algum lugar ou um google.com com meio milhão de servidores?Normalmente existe um usuário por dia, ou mais, alguns milhões?Você está publicando HTML/CSS/JPG ou existe um back-end grande e complicado com servidores SQL, servidores de camada intermediária, caches distribuídos, etc.?

Em geral - se você puder ter ambientes separados para desenvolvimento, controle de qualidade, preparação e produção - tenha-os.Se você tiver os recursos - crie o ecossistema para poder construir o pacote instalável completo com 1 (um) clique.E certifique-se de que o mesmo a instalação binária pode ser instalada com sucesso em DEV/QA/STAGE/PROD com outro único clique...Há muito material escrito sobre esse assunto e você precisa ser mais específico em sua pergunta para obter uma resposta razoável

Execute seu servidor principal em uma porta diferente de 80.Use um servidor leve (por exemplo,nginx) na frente dele na porta 80.Ao atualizar seu site, inicie outra instância em uma nova porta.Teste.Quando estiver satisfeito com a implantação correta, edite o arquivo de configuração do proxy e reinicie-o.No caso do nginx, isso resulta em tempo de inatividade zero ou solicitações com falha e também pode fornecer melhorias de desempenho em relação à opção de hospedagem somente Apache mais típica.

É claro que isso não substitui um servidor de teste adequado, é apenas uma maneira “educada” de realizar a transferência com recursos limitados.

Para testar tudo o melhor possível em um site de desenvolvimento separado antes de ir ao ar, eu uso o selênio (um testador de páginas da web) para percorrer todas as partes navegáveis do site, preencher valores fictícios em formulários, verifique se esses valores aparecem na direita lugares como resultado, etc.

É poderoso o suficiente para verificar muito JavaScript ou coisas dinâmicas.

Em seguida, uma rápida execução com o Selenium novamente após a atualização do site ao vivo verifica se a atualização funcionou e que não há links ou erros de banco de dados ausentes.

Isso me salvou algumas vezes pegando erros sutis que eu teria perdido apenas manualmente.

Além disso, se você colocar o site ao vivo atrás de algum tipo de "proxy reverso" ou balanceador de carga (se for grande), isso facilita o retorno à versão anterior, se houver problemas.

A única maneira de torná-lo transparente para seus usuários é colocá-lo atrás de um proxy com balanceamento de carga.Você desativa um servidor enquanto atualiza outro servidor.Então, quando terminar de atualizar, coloque o que você atualizou online e retire o outro.É assim que a gente faz.

Se você tiver algum tipo de versão 'beta', não a implemente no servidor ativo.Se você tem um 'site ativo e ocupado', é provável que as pessoas acessem ele e quebrem alguma coisa.

Esta é uma configuração típica de alta disponibilidade. Para manter a alta disponibilidade, você precisará de no mínimo 3 servidores.2 servidores ativos e 1 servidor de teste.Além de quaisquer outros servidores extras, se você quiser ter um banco de dados dedicado ou algo assim.

Crie uma classe de host e implante seu site ativo nessa classe de host.Por classe de host quero dizer um conjunto de hosts onde o balanceamento de carga é configurado e é fácil adicionar e remover hosts da classe.

Quando você terminar o teste beta e estiver pronto para produção, não há necessidade de desativar seu site, apenas remova algum host da classe de host de produção, adicione-os na nova classe de host e implante seu código mais recente lá e teste corretamente.Quando tiver certeza de que tudo está funcionando bem, mova todo o seu host gradualmente para o novo e aponte a nova classe de host como classe de host de produção.Ou você pode usar o mesmo que estava usando inicialmente. A ideia por trás dessa atividade é garantir que você esteja testando sua implantação nas caixas de produção, onde seu site estará em execução após a implantação, porque os problemas de implantação são assustadores e difíceis de depurar.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow