Anotações de campoPrepare sua diretiva para implantar patches

Mark D. Scott

Em um trabalho recente, eu e o cliente nos deparamos com um problema interessante relacionado aos service packs. A equipe de TI decidiu aplicar o SP2 aos servidores de produção do SQL Server. Eles fizeram o que se espera de uma equipe responsável: aplicaram o service pack aos servidores no ambiente de teste para garantir que os aplicativos que utilizavam o SQL Server não seriam interrompidos. Tudo parecia funcionar bem no teste. Notificaram todos os membros da organização e agendaram a aplicação do patch nos servidores.

Tudo foi feito no ambiente de produção sem qualquer contratempo. Eles continuaram a distribuir os patches aos servidores nos setores de preparação, teste e, por fim, desenvolvimento. Uma implantação padrão. Até que um dos desenvolvedores tentou abrir seu projeto do Reporting Services. De repente, começou a encontrar uma infinidade de pequenos problemas. Relatórios eram abertos, mas partes deles estavam indisponíveis. Outro desenvolvedor abriu um banco de dados do Analysis Services. Sem problemas. Até que tentou abrir a guia Membros Calculados. Com certeza havia algo errado.

Como você já deve estar imaginando, o problema ocorreu porque os servidores receberam o service pack, mas os desenvolvedores, não. Como as ferramentas clientes do SQL Server instaladas nos desktops foram consideradas parte da implantação dos desktops, e não dos servidores, não foram levadas em conta na atualização. E a distribuição do service pack aos desenvolvedores envolveu uma outra rodada de testes e configurações. Isso, sem falar no fato de que nem todos os desenvolvedores ficaram parados — ou seja, alguns deles já tinham aplicado por conta própria um service pack em seus desktops. Isso, por si só, já renderia outro artigo.

Enquanto essa confusão era corrigida, a manutenção de alguns dos aplicativos analíticos usados pela empresa foi praticamente interrompida. Esse evento trouxe à tona a inconsistência e a falta de clareza da diretiva para a implantação de service packs, além de demonstrar algumas brechas na comunicação entre departamentos. A distribuição de service packs é muito importante, pois mantém todo o ambiente mais seguro.

Algumas organizações resistem à aplicação de service packs, pois temem o desentendimento e a confusão causados pela distribuição do software mais do que as vulnerabilidades que o service pack pode eliminar. Outras simplesmente não têm uma diretiva, e permitem que usuários individuais e administradores de sistemas apliquem ou ignorem os patches conforme sua preferência. Isso cria outros "pesadelos" para a manutenção, pois os patches aparecem em alguns servidores, mas não em outros. Alguns estão totalmente protegidos, enquanto outros permanecem no mesmo estado de quando foram instalados.

A maioria das organizações de TI maiores e/ou mais sofisticadas tem conhecimento dos modelos de otimização de infraestrutura e percebe a necessidade de estabelecer de forma proativa uma diretiva e procedimentos de implementação que impeçam esse tipo de acontecimento. Essas organizações sabem que é possível automatizar vários processos e prevenir gafes desse tipo. Mas, no fim das contas e para além das ferramentas, as pessoas precisam entender que tudo o que fazem afeta outras pessoas e outros departamentos. E precisam estabelecer uma comunicação.

É fácil pensar na forma como um service pack afetará seu domínio, avaliar o subconjunto de elementos que se aplicam a seus sistemas e cuidar do que lhe diz respeito. É mais difícil ir além e levar em conta os efeitos da alteração fora da sua área de atuação. Algumas vezes, nosso pensamento se torna tão limitado quanto os aplicativos que gerenciamos.

A boa notícia é que esse evento foi relativamente fácil de corrigir. A organização já tinha um modelo amadurecido. Quando o problema foi identificado (mais uma vez, com certa confusão, pois ele só existia para os desenvolvedores que seguiam as regras), o patch foi distribuído com rapidez (e automaticamente). Uma injeção de comunicação clara e um sistema bem projetado ajudaram a corrigir a falha com o mínimo possível de inatividade e interrupção.

Parece que a solução consiste em permitir o amadurecimento de nossa infraestrutura — e de nós mesmos. Uma diretiva eficaz para a implantação de service packs engloba procedimentos, produtos e pessoas.

Mark D. Scott é consultor sênior da Microsoft Consulting Services. Ele trabalha junto com os clientes para projetar e criar aplicativos de grande escala centrados em dados. Entre em contato com Mark pelos emails granddaddy2002@msn.com ou mascott@microsoft.com.