Atualizando Aplicativos em um Ambiente Corporativo

2

Sou muito novo neste assunto e esperava que alguém pudesse lançar alguma luz sobre isso. Estou trabalhando na criação de uma rede corporativa que obviamente terá vários servidores e várias estações de trabalho.

Digamos que uma nova versão do Adobe Flash seja lançada. Eu acho que você gostaria de testar essa atualização em um ambiente de teste antes de "empurrá-lo" para os servidores e estações de trabalho.

Como vocês controlam, testam e empurram as atualizações de aplicativos? (Eu não estou falando sobre atualizações do Windows). Você usa uma ferramenta sysadmin de terceiros? Software desenvolvido em casa?

Qualquer informação será muito apreciada:)

    
por user145133 10.07.2012 / 16:41

3 respostas

1

Existem ferramentas para ajudar nisso, como o SCCM da Microsoft, a Implantação do Software Active Directory, o Altaris, o LanDesk etc. Há um milhão e uma maneiras de implantar atualizações, mas empresas que seguem as melhores práticas comerciais e não fazem os usuários administradores usam pelo menos um desses.

Quanto ao teste, eu usualmente empurro a atualização para minha própria máquina e um pequeno laboratório de teste primeiro. Dê uma olhada por alguns minutos e depois encaminhe para um grupo seleto dentro do departamento de TI que saiba que eles fazem parte do meu cronograma de lançamento antecipado. Então, se não houver problemas, eu o envio para todos.

    
por 10.07.2012 / 20:39
2

O SCCM da Microsoft e vários outros produtos farão isso. No entanto, eles permitem que você faça a tarefa específica: Instale o software. A grande questão é como você coordena isso?

Em "A Prática de Administração de Sistemas e Redes" existe um capítulo que recomenda as seguintes metodologias:

  1. "um, alguns, muitos" - Atualize sua própria máquina e teste por alguns dias. Atualize um pouco mais (digamos, os outros administradores de seu time). Em seguida, implemente "muitos": grupos maiores e maiores.

  2. "canary" - Atualize um a cada [período de tempo] até terminar.

  3. "exponencial" - Atualize 1, depois 2 mais, depois mais 4 e depois 8 mais. O tamanho do grupo dobra a cada vez.

  4. "risco-adverso passado" - Divida a organização em grupos e faça a maior aceitação de risco primeiro, o mais desfavorável ao risco. Por exemplo, pode haver um grupo que se orgulhe de ser inovador e que se ofereça em primeiro lugar (o departamento de TI, o departamento de engenharia). Pode haver um grupo que é muito suspeito de upgrades e eles vão por último (departamento de contabilidade, os executivos, etc.) Os grupos menores provavelmente devem ir primeiro também.

Não importa o quanto você agrupa as atualizações, as atualizações devem ser testadas primeiro e.

Após cada "grupo" de atualizações, faça uma série de testes. Se algum teste falhar ou se forem relatados problemas, pare de fazer atualizações. Reverta para a versão anterior, se possível (ou segura).

Os upgrades não devem começar até que você tenha feito seus próprios testes. Por exemplo, em um laboratório ou em sua própria máquina. Testes mais estruturados incluiriam a tentativa de atualização em um de cada tipo de máquina, um de cada versão do sistema operacional e assim por diante. Os testes devem incluir iniciar e parar o software, bem como executar suas principais funções (desde que você mencionou o Flash: tente reproduzir um vídeo, executar um jogo em flash e assim por diante). É bom manter uma página wiki que documente quais combinações foram testadas e quais testes foram executados. A próxima vez que você atualizar este pacote, você terá uma boa lista de testes para usar. Se um problema for relatado durante as atualizações, adicione um teste à lista para evitar esse problema no futuro. Desde que você mencionou o Flash, recentemente encontrei um problema com o aplicativo rastreador de alimentos do Vigilante do Peso e uma certa versão do Flash. Adicionamos o URL desse aplicativo à lista de testes e agora sabemos que novos upgrades em Flash precisam ser testados antes de lançá-lo.

Entre cada "grupo" de atualizações, faça uma pausa por algum tempo para ver se os erros aparecem. Se isso é um dia ou uma semana depende de muitos fatores: isso é uma grande mudança? As atualizações anteriores do grupo foram bem-sucedidas? Monitore seus tickets do Helpdesk para relatos de problemas relacionados à atualização. Se você tem assistentes de helpdesk em tempo integral, mantenha-os informados sobre quais atualizações estão em andamento para que eles estejam à procura de problemas.

Se você usa "um, alguns, muitos" ou outras metodologias depende de muitos fatores. "Um, alguns, muitos" é bom em ambientes menores. "Exponencial" é bom em um grande ambiente de desktop, onde centenas de máquinas são controladas centralmente. "Anúncios de risco últimos" é bom quando você pode dividir seus usuários em grupos específicos que têm diferentes "personalidades". "Canary" é usado em web farms e grid computing, onde você tem centenas ou milhares de máquinas, todas com a mesma configuração.

O mais importante é fazer boas anotações. Se você teve que fazer uma boa atualização uma vez, você terá que fazer mais atualizações no futuro. Você quer que o processo se torne repetível e manter uma lista de testes realizados é fundamental para isso. Da próxima vez que você fizer uma atualização similar, haverá menos raciocínio a ser feito, o que significa menos erros ("oops, esqueci de testar o blá-blá-blá") e será mais rápido. Na verdade, se você apenas mantiver a documentação básica, poderá delegá-la ao novo sysadmin junior que você contratou. Ele ou ela pode repetir seu processo, adicioná-lo e melhorá-lo. Você pode se concentrar em treiná-los e verificar seu trabalho. Enquanto isso, você pode trabalhar em outros projetos.

    
por 17.07.2012 / 15:18
0

se você estiver procurando por uma ferramenta leve para fazer o script de atualizações do sistema e gerenciar perfis diferentes, dê uma olhada no wpkg . Ele fornece apenas uma estrutura, mas no final você precisa descobrir a sintaxe de atualização / instalação silenciosa / desinstalação por conta própria.

depois de implementá-lo, você pode ter poucas máquinas virtuais - membros de um grupo de teste - nas quais você testa novas versões antes de disponibilizá-las para todos os usuários.

sites como itninja [antigo appdeploy] ou wpkg.org pode ser fonte de receitas de instalação autônoma para software diferente.

    
por 17.07.2012 / 16:40