Close

Ready for ITSM at high velocity?

A evolução do gerenciamento de alterações de TI

Gerenciamento de alterações — também conhecido como ativação de alterações — é uma prática de TI desenvolvida para minimizar as interrupções nos serviços de TI enquanto são feitas alterações em sistemas e serviços críticos.

Uma alteração significa adicionar, modificar ou remover qualquer coisa que possa ter um efeito direto ou indireto nos serviços.

As práticas de gerenciamento de alterações foram desenvolvidas para reduzir os incidentes e cumprir com as normas regulatórias. As práticas garantem o tratamento eficiente e imediato das alterações na infraestrutura e no código de TI. Seja na implementação de serviços novos, no gerenciamento de serviços existentes ou na resolução de problemas no código, a abordagem moderna do gerenciamento de alterações divide silos, oferece contexto e transparência, evita gargalos e minimiza riscos.

A gestão de riscos é uma prática de ITIL 4 relacionada, seguida para "garantir que a empresa entenda e lide com eficiência com os riscos". O gerenciamento de alterações e o de risco exigem o rastreamento e a vinculação de alterações para oferecer um registro auditável. A capacidade de aproveitar dados das alterações anteriores e suas taxas de sucesso permite que as empresas adaptem as práticas para equilibrar com inteligência o risco e a velocidade.

Práticas adaptáveis e informadas por dados lutam pela eficiência, ao contrário do gerenciamento de alterações tradicional, que muitas vezes pode ser lento demais, pesado de processos e sobrecarregado. Como o gerenciamento de alterações lida com desafios de risco e conformidade, auditabilidade e coordenação entre as equipes, ele pode se tornar complexo, burocrático e doloroso com frequência.

Porém, não precisa ser desse jeito. Pense no gerenciamento de alterações como uma obrigação do ITSM — nem sempre é gostosa, mas é muito importante. Com as práticas e a cultura corretas, o gerenciamento de alterações pode resultar em menos incidentes, menos estresse da equipe e mais tempo gasto oferecendo valor aos clientes.

Definição do gerenciamento de alterações

Quando pensamos no gerenciamento de alterações, a definição envolve cada aspecto da alteração — desde a tecnologia, as pessoas e os processos, até o impacto nos clientes e sistemas. Para melhor entendimento dentro do contexto do ITSM, a ITIL 4 estabeleceu uma distinção entre as práticas de gerenciamento de alterações de TI e as de gerenciamento de alterações organizacionais.

  • O Gerenciamento de alterações organizacionais é a "prática de garantir que as alterações em uma empresa sejam implementadas sem problemas e com sucesso e que benefícios duráveis sejam alcançados por meio do gerenciamento dos aspectos humanos das alterações".

Então, a ITIL 4 redefiniu o processo antigo de gerenciamento de alterações como a prática de "controle de alterações".

  • A prática de controle de alterações garante que "os riscos tenham avaliação adequada, autorizando o prosseguimento das alterações e gerenciando um cronograma de alterações para poder maximizar o número de alterações bem-sucedidas de serviços e produtos".

Esta nova escolha de nome provocou controvérsia e muitas equipes de TI rejeitaram a associação com "controle". Para alguns, esta é uma palavra tóxica que lembra burocracia, gargalos e etapas desnecessárias que o gerenciamento de alterações tradicional se tornou infame por criar.

A Axelos ouviu o feedback e deu uma resposta. "Após a liberação da ITIL 4 Foundation, ouvimos de diversas pessoas do mundo todo que "a prática foi mal interpretada ou mal entendida como tendo foco em 'controlar alterações' ou 'controlar equipes', em vez de 'controlar a frequência de alterações'"

A ITIL acabou mudando e chamando a prática de "ativação de alterações". O novo nome conota uma prática que ajuda as equipes, proporcionando a capacidade — e a liberdade — de prosseguir com as alterações.

No fim das contas, a gente não acha que o termo que você usa importe tanto. (Neste artigo, e na Atlassian, a gente se refere a ele como Gerenciamento de alterações.) O que importa de verdade é a abordagem que você usa. Comece com equipes saudáveis e a cultura certa e a empresa vai estar no caminho correto para criar uma prática efetiva de gerenciamento de alterações.

O relacionamento entre o gerenciamento de alterações e o gerenciamento de lançamentos

O gerenciamento de lançamentos é outra prática importante na conversa sobre gerenciamento de alterações. De acordo com a ITIL 4, o objetivo do "gerenciamento de lançamentos…é fazer com que os serviços e os recursos novos e alterados fiquem disponíveis para uso". Os lançamentos podem incluir tudo, desde alterações na funcionalidade do software até atualizações na documentação e no treinamento.

Na abordagem usada até o momento, o gerenciamento de lançamentos agrega alterações e as apresenta aos clientes como um pacote. O gerenciamento de lançamentos tradicional mantém padrões rígidos de gestão de projetos e pode criar atrito no lançamento de atualizações valiosas aos clientes, levando a frustrações entre as equipes que aderem aos princípios ágeis.

A gente pode reimaginar o gerenciamento de lançamentos no contexto do DevOps. Deixando a função tradicional de gestão de projetos, o gerenciamento de lançamentos deve mudar o foco para integração e automação. O primeiro passo é trazer pipelines de código para um sistema seguro que incorpora a revisão automatizada sempre que possível e oferece rastreamento e supervisão. Essa mudança pode acabar com as abordagens em silo do passado e oferecer um caminho simples para a produção. O gerenciamento de lançamentos pode ser sobre facilitar mais do que nunca o oferecimento contínuo de valor e aplicar o princípio "quem cria, gerencia".

Por que o gerenciamento de alterações de TI é importante?

As empresas modernas têm algumas expectativas críticas e concorrentes para a equipe de TI. Em primeiro lugar, elas esperam serviços estáveis e confiáveis que garantam que a empresa seja produtiva e consiga atender às expectativas do usuário final. Em segundo lugar, a equipe de TI precisa implementar atualizações regulares de serviço para permitir que a empresa se adapte à alteração constante dos requisitos de segurança, custos e negócios.

Ignorar essa responsabilidade pode ter consequências graves. A incapacidade de manter um serviço confiável pode causar danos massivos à produtividade e aos custos. Muitas empresas relatam que o tempo de inatividade custa mais de US$ 300.000 por hora, de acordo com a Gartner. Para alguns serviços baseados na web, o número pode ser muito maior.

Ao mesmo tempo, as empresas que não estão se adaptando para o futuro vão se tornar incapazes de acompanhar a velocidade dos negócios e vão ficar para trás da concorrência. A implementação muito lenta de alterações poderia resultar na perda de funcionários para trabalhar em locais com sistemas menos desajeitados ou em clientes enviando apoio e dinheiro a outras empresas que oferecem mais valor a eles.

Então, como você deve gerenciar essas necessidades conflitantes? Uma prática de gerenciamento de alterações permite que a empresa lance atualizações enquanto garante a estabilidade e mitiga os riscos. O gerenciamento de alterações ajuda a conseguir a mudança nas seguintes formas:

  • Estabelecimento de um framework para gerenciar o processo de alteração
  • Priorização das alterações necessárias para alocação correta de recursos
  • Incorporação de informações relevantes para uma tomada de decisão mais inteligente
  • Envolvimento das partes interessadas necessárias de desenvolvimento e TI nas aprovações
  • Incorporação de teste das alterações, para evitar incidentes
  • Simplificação e melhoria do fluxo de alterações para oferecer valor mais rápido

Tipos de alterações

A ITIL define três tipos de alterações.

Alterações padrão

As alterações padrão são de baixo risco, repetidas diversas vezes e pré-aprovadas. Elas são realizadas com frequência e seguem um processo documentado e aprovado.

Por exemplo, a adição de memória ou armazenamento são alterações padrão. A substituição de um roteador com falha por um roteador funcional idêntico é uma alteração padrão. A criação de uma nova instância de um banco de dados é uma alteração padrão.

Todas essas alterações são comuns e seguem um processo bem definido. E como é provável que esse processo já tenha passado uma vez pelo processo de avaliação de risco e aprovação pelo gerenciamento de alterações, ele não precisa passar pelo processo sempre que um roteador precisar ser substituído.

Para muitas empresas, as alterações padrão são uma ótima oportunidade de automação. Algumas empresas relatam que até 70% das alterações padrão podem ser automatizadas — liberando as equipes para focar nas alterações normais e emergenciais.

Alterações normais

As alterações normais são alterações não emergenciais que não têm um processo definido e pré-aprovado.

Por exemplo, o upgrade para um novo sistema de gerenciamento de conteúdo é uma alteração normal. A migração para um novo data center é uma alteração normal. As melhorias de desempenho são alterações normais. Elas não são padrão e repetidas. Existem riscos envolvidos. Mas, elas também não são emergências. O que significa que elas podem ir para a fila comum de gerenciamento de alterações para passar pela avaliação de riscos e aprovação.

Algumas alterações normais — como uma mudança de data center — são de alto risco e podem precisar da avaliação de risco e aprovação por um conselho consultivo de alterações (CAB). Outras — como uma alteração no site — podem ser de baixo risco e aprovadas em um prazo mais rápido por uma autoridade designada de alteração ou por verificações automatizadas e revisão de pares.

Alterações emergenciais

Essas alterações surgem de um erro ou ameaça inesperada e precisam ter resolução imediata — em geral, para restaurar o serviço para clientes ou funcionários ou para proteger os sistemas contra uma ameaça.

Por exemplo, a implementação de um patch de segurança é uma alteração emergencial. Resolver uma interrupção do servidor é uma alteração emergencial. Resolver um incidente grave é uma alteração emergencial.

A urgência das alterações emergenciais significa que elas precisam ser resolvidas em um prazo bem menor, porque o risco de um processo longo de revisão é mais alto do que os riscos envolvidos na resolução rápida do problema.

A forma como você categoriza as alterações depende de fatores que incluem a empresa, os processos e a tolerância a riscos. A gente defende esquecer a abordagem de "uma solução para todos os casos" e usar um tratamento diferente para cada alteração, com base na avaliação de riscos. À medida que a empresa aprende mais sobre os incidentes anteriores, os sistemas particulares, e incorpora outros dados relevantes, deve ser possível designar uma parte maior de alterações como padrão e as aprovar de antemão. O gerenciamento de alterações moderno deve tornar as solicitações o mais simples e fáceis possível.

O que é um conselho consultivo de alterações (CAB)?

Nas empresas de TI mais tradicionais, um conselho consultivo de mudanças (CAB) tem a tarefa de avaliar os riscos e aprovar (ou não) cada alteração. Na maioria dos casos, o CAB realiza reuniões agendadas com frequência para revisar todas as alterações futuras propostas e inclui especialistas, conforme o necessário, para explicar, defender ou avaliar a alteração com eles.

Por um lado, os conselhos consultivos de alterações podem ajudar a reduzir os riscos e alertar quando uma alteração não funcionar para a empresa. Por outro lado, eles também podem criar um gargalo — em especial quando são compostos por pessoas que não são próximas das alterações sendo implementadas. Em muitas empresas, o processo de aprovação do conselho consultivo de alterações (CAB) é complexo e demorado, o que retarda o processo de alteração.

Muitas equipes de TI estão se afastando das reuniões tradicionais do CAB ou restringindo o escopo das alterações mais arriscadas e das preocupações organizacionais importantes. Neste paradigma, os CABs podem se tornar uma consultoria confiável responsável por monitorar tendências e como podem ser abordadas por práticas e coordenar entre as equipes e as respectivas necessidades.

A ITIL 4 também incentiva a descentralização da sua autoridade de alterações no nível da parte interessada ou de pares. Em vez de usar um comitê separado, crie o gerenciamento de alterações em fluxos de trabalho normais com as partes interessadas relevantes. Para evitar situações de gargalo, busque a automação, as checklists virtuais e a revisão de pares como uma alternativa mais colaborativa e ágil.

O processo de gerenciamento de alterações

Para equipes ágeis e de alta velocidade, o processo de gerenciamento de alterações está se afastando das revisões longas e aprovações por partes interessadas não técnicas e se aproximando de processos automatizados e colaborativos entre as equipes de TI e desenvolvimento, aumentando a agilidade enquanto equilibra os riscos.

Aqui está uma visão geral básica de um processo de gerenciamento de alterações, junto com algumas recomendações para aumentar a velocidade de oferecimento de valor.

Step

Best Practices

Solicitação de alteração - Alguém solicita uma alteração e inclui observações sobre os possíveis riscos, a implementação esperada e os sistemas afetados.

Configure um portal intuitivo de autoatendimento para que as partes interessadas e a equipe de TI criem com facilidade uma solicitação de alteração padrão. Garanta que as equipes de desenvolvimento e TI possam colaborar na mesma plataforma para um contexto completo e transparência durante o fluxo de trabalho da solicitação de alteração.

Revisão da solicitação de alteração - Um gerente de alterações ou revisor de pares revisa a solicitação inicial de alteração. Qual a probabilidade de ser bem-sucedida? Os riscos e recompensas são precisos? Vale a pena?

Use a automação para fazer a aprovação automática da alteração ou crie um processo breve de aprovação antes da alteração ser implementada.

Plano de alteração - A equipe cria um plano para a alteração. Ele documenta os resultados esperados, os recursos, os prazos, os requisitos de teste e as formas de implementar a alteração, se necessário.

Alinhe as partes interessadas com rapidez com um pontapé inicial do gerenciamento de alterações. Coloque as equipes na mesma página com templates da base de conhecimento para documentar os planos de alteração.

Aprovação da alteração -O gerente de alterações, revisor de pares ou CAB adequado revisa o plano e aprova a alteração.

Simplifique as aprovações com as revisões de pares. Combata os silos, com rastreamento do trabalho e documentação compartilhados, para permitir a colaboração fácil e assíncrona.

Implementação da alteração - A equipe lança a alteração, os procedimentos de documentação e os resultados durante o processo.

Use a automação para habilitar os processos e padrões. A automação do fluxo de trabalho pode rotear e atribuir solicitações à próxima pessoa autorizada com base nas regras de negócios.

Encerramento da alteração - Quando adequado, o gerente da alteração revisa e encerra a alteração conforme a necessidade. O relatório deve comunicar se a alteração foi bem-sucedida, no prazo, estimada com precisão, dentro do orçamento, etc.

Retenha os artigos e tickets acessíveis da base de conhecimento para que as equipes possam aprender com trabalhos anteriores. Talvez existam oportunidades de automatizar solicitações de alteração semelhantes no futuro.

Práticas recomendadas do gerenciamento de alterações

Conforme a gente mencionou antes, o gerenciamento de alterações traz o mesmo tipo de medo que alguns de nós temos das obrigações. Nem sempre queremos passar por isso, mas sabemos da importância. E a gente pode realizar etapas para tornar tudo mais agradável.

Aqui estão algumas práticas recomendadas para o gerenciamento de alterações moderno:

  • Entenda a tolerância ao risco e as obrigações regulatórias da empresa
  • Simplifique e automatize os processos de gerenciamento de alterações sempre que possível
  • Dê aos CABs um foco mais estratégico
  • Adote práticas que tornem a alteração padrão a nova alteração normal
  • Considere diversos frameworks, como a ITIL e o DevOps, para encontrar diretrizes que funcionem melhor para a empresa
  • Priorize a colaboração
  • Use a engenharia de caos para reduzir o risco
  • Simplifique a ingestão de solicitações de alteração para as equipes de TI e desenvolvimento
  • Libere o aprendizado com métricas e KPIs das alterações
  • Adote uma abordagem voltada ao DevOps para o gerenciamento de lançamentos

Enfrentamento dos desafios do gerenciamento de alterações

Os desenvolvedores querem implantar códigos com rapidez e sem gastar mais tempo e esforço com a documentação manual. As equipes de operações de TI buscam reduzir o risco, manter registros detalhados para as auditorias e evitar incidentes. Pedir para os desenvolvedores adicionarem uma etapa a mais nos processos, fazer anotações, registrar o horário de entrada e saída, pode parecer que está afastando eles dos objetivos finais do trabalho. Pedir para as equipes de operações revisarem os processos existentes, levantarem verificações de aprovação e deixarem mais para a automação não é fácil e pode parecer que está criando mais riscos.

Ao mesmo tempo, as apostas estão mais altas do que nunca. O aumento de serviços baseados em software aumentou as expectativas e as demandas dos clientes por serviços sempre disponíveis e de alto desempenho. Em um ambiente cada vez mais dinâmico, o trabalho necessário para gerenciar serviços continua crescendo.

Então, como a gente pode superar estes desafios? O primeiro passo é esquecer o mito de que um processo pesado reduz os riscos. O segundo, adotar a cultura, as práticas e as ferramentas correspondentes que ajudam as equipes a colaborar e lançar. E, por último, fazer a incorporação contínua de informações para demonstrar o valor das etapas anteriores e continuar lutando por melhoria.