Minha experiência é que, se você encontrar todas estas condições:
- você usa o CentOS ou o RHEL (versão 6 ou 7)
- você programou uma janela de tempo de inatividade e reinicializou após cada atualização
- seu aplicativo / serviço pode automaticamente
service stop
e start
- você mantém o sistema operacional limpo no servidor
- sem instalar RPMs off-repo
- não há repositórios reprovados como rpmforge
- sem alterações manuais de arquivos que não devem ser alterados manualmente
- muitas outras coisas - seja qual for a probabilidade de o fornecedor prever no ambiente de teste
- você tem certeza que os administradores anteriores não fizeram isso
Com tudo isso, o risco de algo dar errado em yum update
é minimizado. Eu não vejo pessoalmente um defeito de serviço ainda em tal situação. Então, de fato, você manteria seu sistema operacional mais seguro com um risco aceitável (?) De menor disponibilidade.
Ubuntu, não há experiências ruins lá, mas eu tenho um par deles, então não há dados estatísticos suficientes para garantir isso.
Para atenuar ainda mais o risco, você também pode incluir:
- emprega a ferramenta de monitoramento que verificaria se o serviço está funcionando e alcançando um resultado positivo desejado
- agendar notificação para que você possa iniciar e concluir o reparo quando ainda estiver dentro da janela de tempo de inatividade
- empregam clustering (como
pcs
)
- atualize o nó secundário, reinicialize, torne-o principal agora, etc.