Resultado da Enquete e Parâmetros para definição de uma Política de atualização de servidores

Semana passada lancei uma enquete sobre a forma como as pessoas fazem a atualização de servidores SQL Server em seus ambientes.

Analisando os resultados vemos que não há muito consenso sobre como atualizar os servidores:

Quais os tipos de atualização que você costuma aplicar em seus servidores SQL Server?

Agora fica a pergunta, como deve ser uma política de atualização de servidores?

Essa é uma pergunta difícil e não existe regra para isso, a resposta será o velho e bom… DEPENDE!

De qualquer forma há uma série de pontos que devem ser levados em conta ao fazer uma política, sendo elas:

  1. Ambiente: existe um ambiente igual ou pelo menos similar onde as atualizações podem ser homologadas?
  2. Equipe: há no corpo de funcionários pessoas com um tempo pré-determinado para trabalhar na atualização dos servidores?
  3. Ferramentas: existem ferramentas para dar suporte a atualização?
  4. Processo: existe um processo formal, documentado e aprovado que determina COMO, QUANDO, QUEM, ONDE, deve ser aplicada a política?
  5. Tempo: existe uma definição da quantidade de tempo em que a atualização ficará em avaliação e o tempo máximo que um ambiente pode ficar vulnerável até que receba uma atualização?
  6. Criticidade: há um critério para definir tratamentos diferentes para atualizações de nível de segurança diferentes?

Tendo tudo isso em mente você pode começar a definir sua política de atualização. Antes de comentar sobre os pontos acima, vou explicar como a Microsoft disponibiliza suas atualizações e os tipos de atualizações existentes.

Toda segunda terça-feira do mês ocorre a chamada Patch Tuesday, que é quando a Microsoft disponibiliza atualizações de segurança. Já na quarta terça-feira do mês a Microsoft libera atualizações não relacionadas a segurança.

Sendo assim, é possível definir sua política baseada nessas datas, sabendo a janela de tempo que você tem até que novas atualizações sejam disponibilizadas. Um ponto importante a lembrar é que, se sua janela for muito grande, pode acontecer de uma nova atualização que substitui uma anterior (cumulativa) pode ser lançada, e isso pode causar alguma confusão.

Uma dica é seguir sempre os Security Bulletins da Microsoft, que são avisos que ela emite ANTES de lançar as atualizações da Patch Tuesday, permitindo que as empresas planejem suas ações de segurança.

Agora que sabemos como é o processo de liberação de atualização da Microsoft, precisamos entender os tipos de atualizações existentes para o SQL Server.

Existem 3 categorias de atualização (patch) para o SQL Server, os Service Packs (SPs), Cumulative Updates (CUs) e os Hotfixes.

Cada uma dessas categorias é um super (ou sub) conjunto de outras. Os Hotfixes são atualizações voltadas para um problema/falha bem específica. Os CUs são conjuntos de Hotfixes e os SPs são conjuntos de CUs e Hotfixes. Ou seja, ao lançar um Cumulative Update a Microsoft agrupa uma série de atualizações já previamente liberadas (e possivelmente outras novas) em uma espécie de “pacotão”.

Mas a diferença não é apenas essa. Além desse agrupamento, existe também um nível de testes/validações maior em cada conjunto desses. Um Hotfix passa por um conjunto de testes mínimo, que é muito maior para os CUs e ainda maior para os SPs.

É por esse motivo que a Microsoft só recomenda que você só aplique um Hotfix caso você realmente enfrente aquele problema para o qual ele foi criado, pois como a quantidade de testes não foi exaustiva, há a chance de que a aplicação daquele Hotfix comprometa alguma outra funcionalidade do sistema.

De qualquer forma vale lembrar que NADA garante que a aplicação de um CU ou até mesmo de um SP não vai comprometer seu sistema, pois mesmo exaustivos, os testes podem ter deixado passar alguma situação problemática.

É exatamente por isso que muita gente só aplica os CUs e SPs, ou apenas os SPs, e que a própria Microsoft de certa forma “dificulta” o download dos Hotfixes (você tem de acessar a página da Knowledge Base, solicitar o link via e-mail, etc).

Tendo isso em mente, vamos analisar então cada um dos 4 pontos que citei anteriormente e ver o impacto que causam na definição de sua política.

  • Ambiente: como a aplicação de um patch pode causar problemas ao sistema, validar o mesmo em um ambiente de testes é essencial. Quanto mais próximo do ambiente real for o ambiente de testes, maior a segurança de seu processo de homologação!
  • Equipe: a aplicação de atualizações deve ser feito por pessoas com conhecimento em troubleshooting e que tenham um tempo de seu dia (ou normalmente da sua noite!) para realizar essa tarefa que, por sua criticidade, não deve ser feita “as pressas” nem por pessoas sem o devido conhecimento!
  • Ferramentas: o uso de ferramentas como o WSUS, SCCM, etc, permite gerenciar melhor seu ambiente e o processo de aplicação de patches, garantindo um processo mais seguro e também permitindo gerar relatórios, sejam eles para conferência ou auditoria.
  • Processo: sem um processo definido, a aplicação de patches passar a ser um processo onde cada um faz da sua forma, o que causa uma série de riscos. Imagine alguém que prefere atualizar um cluster iniciando pelo nó ativo? Ou que prefere atualizar em horário de produção por ser “mais cômodo”?! Uma boa política precisa também definir o processo de ROLLBACK, em caso da atualização apresentar algum problema.
  • Tempo: uma atualização deve ser validada por um certo tempo antes de ser aplicada em produção, mas esse tempo não deve ser tão longo ao ponto de deixar o ambiente vulnerável por muito tempo, nem tão curto que permita a aplicação em ambiente de produção sem a devida validação.
  • Criticidade: uma atualização de segurança de nível crítico nunca pode ser tratada da mesmo forma de uma de nível urgente. Devem haver definições sobre como se dará esse tratamento diferenciado.

Por fim, aconselho sempre ler o blog do SQL Server Release Services onde são divulgadas as atualizações relativas a SQL Server. Apenas um detalhe, nesse blog acredito que eles divulgam apenas as atualizações “normais”, ficando as relacionadas a segurança vinculadas ao Boletim da Patch Tuesday.

Outras fontes de referência sobre os builds existentes para as várias versões do SQL Server, contendo inclusive o link onde você pode fazer o download delas são essas duas:

E você, já definiu a política de atualização de seus servidores? Considerou os pontos que mencionei no artigo? Algum outro ponto? Deixe seu comentário!

Esse post foi publicado em Artigos, patches, Segurança, Virtual PASS BR. Bookmark o link permanente.

7 respostas para Resultado da Enquete e Parâmetros para definição de uma Política de atualização de servidores

  1. Pingback: [Enquete] Como é sua política de atualização de servidores? | Vladimir M. B. Magalhães – Learn and Share

  2. Muito bom Vladmir! Esse é um assunto muito importante que poucos dão a devida atenção. Aqui na empresa temos a politica de aplicar SP e CU uma vez por semestre e disponibilizamos o ambiente de homologação por 90 dias para que as equipes de sistemas façam os devidos testes antes de ir para produção.

    Abraço.

    • magalhaesv disse:

      Pois é Tiago, muita gente não tem uma política definida e termina deixando seu ambiente sob risco! Mas as empresas estão cada dia mais exigindo uma melhor governança de seus ambientes e isso com certeza vai mudar!

  3. Pois é Vlad, Tiago.

    É muito difícil definir políticas de Update. O que vale mais a pena? Aplicar uma atualização com poucos testes e evitar problemas com segurança ou passar vários meses testando e deixando o sistema vulnerável? Essa é uma pergunta muito difícil de responder.

    Grande abraço e parabéns pelo Post.

  4. Pingback: SQL Server 2008 R2 SP2 CU3 (KB2754552) – Erro na instalação | Vladimir M. B. Magalhães – Learn and Share

  5. Pingback: SQL Server 2012 Service Pack 1 já disponível | Vladimir M. B. Magalhães – Learn and Share

  6. Pingback: SQL Server 2008 R2 SP2 CU3 (KB2754552) – Installation Error | Vladimir M. B. Magalhães – Learn and Share

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s