Alguma idéia de como executar manutenção em um site que está sempre em uso?

Question

Eu ajudo com um grande site de jogos na Austrália. Corremos competições das 7 da manhã até 1 da manhã do dia seguinte, todos os dias da semana. Nós não pulamos um dia desde que o site foi lançado. Naturalmente, isso faz com que a manutenção seja extremamente difícil de executar, e achamos que nosso servidor de teste está com até 50 commits à frente de nossa ramificação de produção. Geralmente, o desenvolvedor principal tem que acordar muito cedo para mesclar as ramificações e garantir que tudo esteja funcionando corretamente.

Estamos tentando tornar nosso site de teste o mais parecido possível com o site de produção, mas só podemos torná-lo semelhante.

Nosso site é baseado no Laravel com um servidor Node.JS em tempo real. Estamos usando o Laravel Forge.

Alguém tem alguma sugestão sobre como poderíamos enviar atualizações com mais frequência? Estamos abertos a qualquer coisa.

    

Answer 1

Existem muitas coisas que você pode fazer para melhorar seu processo de implantação. Alguns deles são:

• Certifique-se de que seu código esteja bem testado.

  Idealmente, você deve ter 100% de cobertura de teste de unidade, bem como testes de integração para todos os cenários imagináveis.

  Se você não tem isso, provavelmente deveria largar tudo e cuidar disso.

  Analise o desenvolvimento orientado por comportamento.

  Ter uma suíte de testes completa permitirá que você ...

• Execute a integração contínua.

  Sempre que alguém fizer uma alteração, o CI poderá então automaticamente executar a suíte de testes nele. Se a suíte de testes passar, ela poderá ser implantada imediatamente (ou agendar uma implantação). Para alterações que não requeiram alterações significativas em seus bancos de dados, isso, por si só, economizará muito tempo e dor de cabeça.

  No caso de um problema, o IC também pode fornecer uma reversão com um clique.

  O CI é muito menos útil se sua suíte de testes não for completa e correta, pois a premissa inteira é a capacidade de validar seu código de maneira automatizada.

• Faça atualizações atômicas.

  Idealmente, você não deve apenas copiar novos arquivos sobre o antigo no servidor de produção. Em vez disso, use uma ferramenta como capistrano, que copia todos os arquivos para um novo local e, em seguida, usa um link simbólico para apontar para a implantação desejada. Retroceder é instantâneo, pois envolve simplesmente alterar o link simbólico para apontar para a implantação anterior. (Embora isso não cubra necessariamente a migração do banco de dados.)

  Verifique também se os contêineres, como o Docker, podem ajudá-lo.

• Faça alterações menores e mais frequentes.

  Se você tem testes, CI, ou nada, isso sozinho pode ajudar você de maneira significativa. Cada mudança deve ter seu próprio branch git, e uma implantação deve ter o menor número de alterações possível. Como as alterações são menores, há menos chances de dar errado durante uma implantação.

  Na mesma nota, torne as alterações mais isoladas sempre que possível. Se você fez uma alteração no jogo Omaha e não afeta o Texas Hold'em, o 5 card stud ou qualquer outra coisa, então esse é o único jogo que precisa ser suspenso para uma manutenção.

• Analise qualquer coisa de longa duração.

  Você mencionou que algumas partes de suas implantações levam muito tempo. Isso é provavelmente alterações do esquema do banco de dados. Vale a pena ter um DBA em seu banco de dados, juntamente com cada alteração de esquema, para ver o que pode estar tendo um melhor desempenho.

  Peça a um especialista para analisar qualquer outra parte de uma implantação que consuma grandes blocos de tempo.

• Trabalhe horas estranhas.

  Você já pode estar fazendo isso, mas vale a pena mencionar. Não se espera que os desenvolvedores (e administradores de sistemas!) Trabalhem "9 a 5", especialmente para uma operação 24x7. Se é esperado que alguém passe as horas da madrugada tomando conta de uma implantação, consertando qualquer problema e, em seguida, mantendo uma programação diurna, suas expectativas não são realistas, e você está configurando essa pessoa para o desgaste.

Answer 2

Parece que você tem uma janela de manutenção das 01:00 às 07:00 todos os dias. O problema não é tempo, mas conveniência. Isso é normal e muitas pessoas lidam com isso como parte do negócio.

Você pode ter dois (ou mais back-end) sistemas com um front-end que direcionam o tráfego para o que estiver no momento. Uma vez que você está feliz que um lançamento vai funcionar, você diz ao front-end para mudar para o novo sistema. isso deve ser fácil de escrever e demorar um pouco.

Agora você tem a opção de deixar o sistema antigo para que possa voltar ou atualizá-lo para que ele possa ser usado como reserva para o sistema ao vivo até a hora de construir / testar o próximo atualizações.

    

Answer 3

Alterando as outras respostas: você deve seguir o modelo de implantação azul-verde . Quando você quiser lançar uma nova versão, implante-a em um site de teste interno. Em seguida, você pode executar testes automatizados no site de produção da próxima versão. Quando os testes passam, você aponta o balanceador de carga para usar o novo site.

Isso ajuda da seguinte maneira:

1. Problemas graves sempre são encontrados com tempo de inatividade zero.
2. A mudança para uma nova versão tem exatamente zero tempo de inatividade porque a nova versão já foi iniciada e aquecida.
3. Você pode voltar para a versão antiga a qualquer momento porque ela ainda está funcionando fisicamente.

Todos os outros problemas que você e outros mencionaram se tornam menos graves quando você pode implementar a qualquer momento de maneira livre de estresse. O modelo de implantação azul-verde é uma solução bastante completa para problemas de implantação.

    

Answer 4

O que você fará se o seu data center principal sofrer uma interrupção, o que acontece em todos os data centers de tempos em tempos? Você pode aceitar o tempo de inatividade, pode fazer failover para outro datacenter, pode estar em execução no modo ativo-ativo em vários data centers o tempo todo ou pode ter algum outro plano. Qualquer um deles, faça isso quando você fizer lançamentos e, em seguida, você poderá desativar seu data center principal durante uma versão. Se você estiver preparado para ter um tempo de inatividade quando o seu data center tiver uma interrupção, você estará preparado para ter tempo de inatividade, portanto, isso não deve ser um problema durante uma versão.

    

Answer 5

Para adicionar as respostas anteriores:

• Use uma estratégia de implantação que permita reversões e comutação instantânea, o Capistrano ou praticamente qualquer outro sistema de implantação ajudará nisso. Você pode usar coisas como instantâneos de banco de dados e links simbólicos de código para poder reverter rapidamente a um estado anterior.

• Use o gerenciamento de configuração completo, não deixe nada gerenciado manualmente. Sistemas como SaltStack, Ansible e Puppet são exemplos. Eles também podem ser aplicados a configurações de contêineres Docker e caixas vagantes.

• Use o HA para garantir que você possa entregar solicitações ao atualizar um nó. Se a atualização falhar, simplesmente desconecte o nó e, quando ele for revertido, coloque-o de volta e sua solução de HA observará e enviará novamente os pedidos para o nó. HAProxy é um exemplo, mas o nginx também funciona bem.

• Certifique-se de que o aplicativo possa lidar com instâncias simultâneas, usei repositórios de dados com versão central usados para dados não-codificados que precisam ser armazenados em disco, como cache. Dessa forma, você nunca terá um aplicativo atualizado executado em cache de arquivos de uma versão diferente. Isso seria feito em cima de limpar caches e fazer aquecimentos de cache, é claro. (A coisa do cache é apenas um exemplo)

Geralmente, configuro fluxos de trabalho em que os gerentes de equipe podem aprovar solicitações de mesclagem para uma ramificação especial que faz todos os itens de IC normais, mas como uma última etapa adicional também começa a ser enviada para nós de produção. O que você basicamente faz é executar uma implementação manual de IC em uma instância de produção. Se essa instância não gerar respostas inválidas, quebras ou coisas estranhas em seus dados, você fará upgrade em massa de todos os nós usando a solução de IC escolhida. Dessa forma, se uma implantação funcionar, você saberá que todas as implantações funcionarão para uma tag / confirmação específica.

Neste momento, parece que você está executando um aplicativo de produção em um único nó, com um processo de implantação, uma origem e um destino. Isso praticamente significa que cada etapa desse fluxo de trabalho é um ponto de falha que, por si só, pode quebrar o site. Garantir que tal coisa não possa acontecer é a base de todos os processos de CI, HA e failover. Não execute apenas um nó, não execute apenas um processo de HA, não execute em apenas um endereço IP, não execute apenas um CDN, etc. Pode soar caro, mas colocar uma cópia do que você já tem em um rack em um servidor com sua própria conexão geralmente custa menos de uma hora de inatividade em um site de negócios.

    

Answer 6

Eu concordo globalmente com Michael em todos os seus pontos ( link ).

Na minha opinião, a primeira melhoria que você deve fazer é usar uma ferramenta de implantação (Capistrano).

Ele permitirá que você implante pacificamente e, em seguida, mude para a versão mais recente instantaneamente. Se algo der errado, você pode voltar para a versão de trabalho instantaneamente, simplesmente mudando o symlink atual para uma versão de trabalho.

E o Capistrano é bastante rápido de lidar primeiro (comparado a começar a usar testes e CI, o que será um investimento maior em tempo).

Em segundo lugar, se o dinheiro não for seu problema main , você deve ter um servidor de desenvolvimento iso-prod para testar seu aplicativo antes de implantá-lo na produção. Use uma solução industrial (Ansible, Chef, Puppet) para gerenciar instâncias de VPS.