Dado um servidor interno rodando em modo de produção, eu gostaria de manter o impacto sobre os usuários o mais baixo possível ao implantar atualizações regulares (para o próprio servidor, não para as máquinas dos usuários. Mas isso seria um problema bastante semelhante).
A resposta óbvia à minha pergunta é “à noite, quando os usuários estão em casa”. Mas “noite” é um longo período de tempo. Deve-se começar no início da noite para talvez detectar problemas com a atualização logo no início e estar pronto para reverter? Ou é melhor começar de manhã cedo e usar os primeiros usuários como “cobaias” para acionar os problemas mais rapidamente? Ou no meio da noite, quando a concentração de quem supervisiona a atualização é muito baixa, mas é garantido que não há identificadores de arquivos abertos de alguns usuários que trabalham até tarde?
Existem trabalhos de pesquisa sobre o tema?
Responder1
Por que não observar historicamente o uso simultâneo do seu sistema e determinar quais horários do dia o uso está mais baixo? Em seguida, coloque o troco bem no meio desse período de baixo uso.
Ao calcular quanto tempo a mudança levará, inclua testes pré/pós-implementação e testes de verificação de produção. Além disso, calcule quanto tempo a alteração levará para ser revertida se algum teste falhar.
IMHO, seus 'primeiros usuários' não deveriam ser cobaias. Fazer com que usuários ativos basicamente testem suas alterações com verificação de produção não é uma coisa boa. Isso destrói a confiança dos usuários finais e os resultados inesperados podem atrapalhar a produção, o que significa que você não apenas precisa reverter a alteração, mas também reverter qualquer “dano” que a alteração possa ter causado.
Não conheço nenhum artigo de pesquisa, mas dê uma olhada em qualquer estrutura de gerenciamento de serviços de TI (ITSM), como o ITIL, e você encontrará muitos padrões e práticas recomendadas em gerenciamento de lançamento de software. Todos os sistemas são diferentes, portanto a extensão de quantas práticas você adota e a formalidade dependem. Os padrões ITSM têm grandes sistemas em mente.
Responder2
Isso depende inteiramente da natureza do negócio. Alguns escritórios funcionam das 9h às 17h, cinco dias por semana. Outros negócios funcionam 24 horas por dia, 365 dias por ano. Outros factores, como a disponibilidade de pessoal e de recursos, desempenham um papel significativo. Nenhum artigo de pesquisa poderia cobrir de forma abrangente todos os cronogramas ou eventualidades possíveis.
Em última análise, a gestão da empresa ou departamento em conjunto com a gestão de TI tem que determinar o que é melhor.
A chave para o sucesso é comunicar aos usuários quando o tempo de inatividade está programado para começar, quanto tempo deve durar, qualquer preparação exigida dos usuários e o que eles podem esperar como resultado do sucesso ou do fracasso. Uma grande parte disso é atender às expectativas que você definiu.
No final, nada fica gravado em pedra. Se o processo não funcionar, faça ajustes. Sua flexibilidade e adaptabilidade serão apreciadas.
Ao realizar procedimentos de manutenção e atualização em equipamentos de teste com antecedência, quando possível, você estará mais bem preparado quando chegar a hora de implementá-los em sistemas de produção.
Responder3
Eu trabalho em um ISP e, pela minha experiência, a maioria das pessoas que eu consideraria administradores de sistema pesados escolhem as noites de sexta-feira nos fins de semana de feriados para fazer grandes revisões na rede. Isso lhes dá 24 horas extras para testar e, se necessário, reverter suas alterações. No entanto, em grande parte, isso depende inteiramente da natureza e dos hábitos dos seus usuários.
Responder4
No meu caso, instalamos as atualizações às 4h, para evitar impacto em qualquer usuário, mesmo aqueles que trabalham um pouco até tarde.
Se você tiver um bom sistema de monitoramento que avisa caso ocorra algum problema, você poderá corrigi-lo de manhã cedo, antes mesmo de ir para o trabalho.