Change Management: O Que É e Como Gerenciar Mudanças de TI com o ITIL

Em uma pesquisa do Gartner, mais de 70% dos incidentes de TI têm origem em mudanças mal gerenciadas em ambientes de produção. Um deploy não planejado, uma atualização de configuração sem aprovação formal, uma migração executada fora da janela de manutenção — qualquer uma dessas situações pode derrubar serviços críticos e acionar uma corrida contra o tempo para restaurar a operação. O change management de TI existe para eliminar esse risco sistêmico.

Dentro do framework ITIL e das práticas de ITSM, o gerenciamento de mudanças é o processo que controla o ciclo de vida de todas as alterações em infraestrutura, sistemas e serviços de TI, desde a solicitação até a implementação e o registro pós-execução. O objetivo não é burocracia: é garantir que mudanças necessárias sejam feitas com o menor risco possível para a continuidade do negócio.

Este guia explica o que é change management, os três tipos de mudança, o fluxo de aprovação via CAB e como integrar o processo com pipelines de CI/CD modernos sem sacrificar velocidade de entrega.

O que é Change Management em TI

Change management em TI, ou gerenciamento de mudanças, é o processo estruturado de planejamento, avaliação de risco, aprovação, implementação e registro de alterações em qualquer componente do ambiente de TI. Componentes incluem infraestrutura de servidores e redes, sistemas operacionais, aplicações, bancos de dados, configurações de segurança e integrações com serviços externos.

O processo responde a uma realidade operacional: ambientes de TI produtivos não podem ser modificados sem controle. A ausência de um processo formal de mudanças cria dependência de memória individual, elimina rastreabilidade e torna a análise de causa raiz de incidentes extremamente difícil, pois não há registro do que mudou e quando.

Dentro do contexto ITIL 4, o change management foi renomeado como “change enablement” para reforçar que o objetivo do processo é habilitar mudanças com segurança, não bloqueá-las.

Os 3 Tipos de Mudança no ITIL

O framework ITIL classifica as mudanças em três categorias, cada uma com um fluxo de aprovação proporcional ao risco envolvido.

Mudança Padrão (Standard Change)

Mudanças pré-aprovadas, de baixo risco e alto grau de repetição. Seguem um procedimento documentado e testado, sem necessidade de avaliação individual a cada execução. Exemplos: atualização de certificado SSL com procedimento validado, reinicialização de serviço com runbook documentado, criação de conta de usuário conforme política definida.

O registro de mudanças padrão é feito no GLPI ou ferramenta ITSM equivalente, mas o processo de aprovação já foi concluído na criação do procedimento padrão, não na execução individual.

Mudança Normal (Normal Change)

Mudanças que requerem avaliação de risco e aprovação antes da implementação. É a categoria mais comum em ambientes corporativos. O fluxo envolve abertura de RFC (Request for Change), análise pelo CAB (Change Advisory Board), aprovação formal e agendamento em janela de manutenção.

A criticidade e o impacto esperado determinam a urgência da aprovação: mudanças de baixo impacto podem ser aprovadas em ciclo semanal pelo CAB, enquanto mudanças de alto impacto requerem reunião específica.

Mudança Emergencial (Emergency Change)

Mudanças necessárias para restaurar serviço após incidente crítico ou responder a vulnerabilidade de segurança ativa. O tempo de aprovação é comprimido, mas o processo não é eliminado. Um ECAB (Emergency Change Advisory Board) ou aprovador designado avalia e aprova de forma expedita.

O registro detalhado da mudança emergencial é obrigatório, mesmo que feito após a execução. Esse registro alimenta o postmortem do incidente e evita que a urgência sirva de justificativa para práticas inseguras recorrentes.

O Fluxo de Aprovação: Como Funciona o CAB

O Change Advisory Board (CAB) é o comitê responsável pela avaliação e aprovação de mudanças normais. Sua composição varia conforme a organização, mas tipicamente inclui representantes de infraestrutura, segurança da informação, operações e, para mudanças de alto impacto, representantes do negócio.

O fluxo padrão de uma mudança normal segue estas etapas:

1. Abertura do RFC — o solicitante documenta o que será alterado, o motivo, o impacto esperado, o plano de rollback e a janela de implementação proposta. A qualidade do RFC determina a velocidade de aprovação.

2. Avaliação de risco — o CAB analisa o RFC considerando: histórico de mudanças similares, disponibilidade dos serviços afetados no período proposto, dependências com outras mudanças e validade do plano de rollback.

3. Aprovação ou rejeição — o CAB aprova, rejeita ou solicita ajustes no RFC. Mudanças aprovadas entram no calendário de mudanças (Forward Schedule of Change).

4. Implementação e registro — a mudança é executada na janela aprovada. O executor registra o resultado (sucesso, sucesso parcial ou falha) e aciona rollback se necessário.

5. Revisão pós-implementação (PIR) — para mudanças de alto impacto, uma revisão formal avalia se o resultado esperado foi atingido e se há ajustes a fazer no processo.

O uso de ferramentas ITSM como o GLPI automatiza grande parte desse fluxo, eliminando o controle por planilhas e garantindo rastreabilidade completa de cada mudança.

Change Management e CI/CD: Como Integrar sem Perder Velocidade

A crítica mais comum ao change management tradicional é que ele atrasa entregas. Essa percepção tem fundamento histórico — processos de aprovação semanais do CAB são incompatíveis com times que fazem múltiplos deploys por dia. Contudo, a solução não é eliminar o processo, mas adaptá-lo ao ritmo dos pipelines modernos.

A integração entre change management e CI/CD se dá em três camadas:

Automação de mudanças padrão: deploys que seguem um pipeline validado (testes automatizados, análise estática, deploy canary com rollback automático) podem ser classificados como mudanças padrão automatizadas. O pipeline CI/CD registra a mudança automaticamente na ferramenta ITSM e executa sem aprovação manual.

Change freeze e janelas de manutenção via pipeline: o pipeline CI/CD consulta o calendário de mudanças antes de executar qualquer deploy em produção. Se houver change freeze ativo ou mudanças conflitantes agendadas, o pipeline aguarda ou aciona notificação para revisão humana.

Rastreabilidade automática: cada commit, tag de release e deploy é associado automaticamente ao RFC correspondente na ferramenta ITSM. Isso elimina o esforço manual de registro e garante que o auditor de qualquer incidente consiga rastrear exatamente o que mudou e quem aprovou.

A documentação oficial do ITIL 4 reconhece explicitamente essa evolução, recomendando que o change enablement seja integrado aos pipelines de entrega contínua em vez de operado como processo paralelo.

Métricas de Change Management que Importam

O desempenho do processo de mudanças deve ser medido com KPIs que reflitam tanto eficiência quanto segurança.

Taxa de mudanças com falha (Failed Change Rate): percentual de mudanças que causaram incidente ou precisaram de rollback. O benchmark ITIL aponta menos de 5% como referência para organizações maduras.

Tempo médio de aprovação (Lead Time for Change): do RFC à aprovação. Tempos altos indicam processo com gargalos no CAB ou RFC mal documentados.

Taxa de mudanças não autorizadas: mudanças detectadas em produção sem RFC associado. Qualquer percentual acima de zero indica falha de processo ou de cultura.

Percentual de mudanças na janela aprovada: mudanças executadas fora da janela aprovada representam risco não avaliado. A meta é 100%.

As métricas de change management se conectam diretamente com as DORA Metrics, especialmente o Change Failure Rate e o Mean Time to Recovery — dois indicadores centrais de performance de entrega de software.

Conclusão

O change management não é um obstáculo à agilidade — é a estrutura que torna a agilidade sustentável. Ambientes que implementam o processo corretamente conseguem mover mais rápido com mais segurança porque cada mudança é planejada, rastreável e reversível.

A integração com CI/CD e ferramentas ITSM elimina o atrito burocrático sem abrir mão do controle. O resultado é um ambiente onde times de engenharia entregam com frequência, os processos de aprovação são proporcionais ao risco e a causa raiz de qualquer incidente pode ser identificada em minutos, não horas.

Se sua organização quer estruturar ou evoluir o processo de change management com integração ao pipeline de entrega e às práticas de SRE, fale com nossos especialistas.