Gestão de Mudanças no Portal Nyverra: RFC, CAB e plano de rollback

Há uma frase que resume décadas de gestão de serviços: “não existe mudança sem risco; existe mudança sem controle”. Atualizar um servidor, trocar uma regra de firewall, alterar um fluxo do ERP — cada uma dessas ações pode derrubar um serviço. A gestão de mudanças existe para que a alteração seja planejada, aprovada e reversível.

Este guia percorre o módulo de Mudanças do Portal Nyverra ITSM: o conceito de RFC, tipos e avaliação de risco, o papel do CAB, o fluxo de aprovação (com a regra que impede autoaprovação), a janela de implantação e o plano de rollback — além da ligação com problemas, chamados e liberações.

Interface do módulo no Portal Nyverra ITSM.

Mudança, RFC e o lugar no ITIL

Uma mudança (código CHG) é uma alteração planejada em serviços ou infraestrutura. Cada solicitação de alteração é registrada como uma RFC (Request for Change), que carrega descrição, tipo, risco, impacto, plano de implementação e plano de retorno.

Para não confundir as disciplinas ITIL:

Disciplina	Pergunta que responde
Incidente	“Como restauro o serviço agora?”
Problema	“Por que isso aconteceu?”
Mudança	“Como altero com segurança?”
Liberação	“O que sobe junto nesta janela?”

A mudança é o elo entre a causa raiz identificada (problema) e a entrega coordenada (liberação).

Tipos e risco: nem toda mudança é igual

Tratar uma troca de disco como uma atualização de ERP é receita para o caos. O Portal trabalha com tipos de mudança que definem o nível de controle:

Tipo	Característica	Controle típico
Standard	Repetitiva, de baixo risco, pré-autorizada	Fluxo leve
Normal	Alteração planejada comum	Aprovação e janela
Emergency	Correção urgente para restaurar serviço	Fluxo mais rápido, aprovação retroativa

O risco e o impacto informados na RFC determinam quem aprova e quanto detalhe o plano exige. Mudanças de risco alto só deveriam avançar com plano de rollback documentado.

O CAB (Comitê de Assessoramento de Mudanças)

O CAB é o fórum que avalia mudanças de maior impacto. No Portal, isso se traduz em reuniões do CAB e no registro de decisões: quem avaliou, o que foi decidido e por quê. Mudanças maiores podem exigir essa deliberação antes da aprovação; mudanças simples seguem por aprovação direta. O objetivo do CAB não é burocratizar, e sim distribuir a responsabilidade da decisão.

Quem usa

Perfil	Uso típico
Técnico / gestor de mudança	Criar, submeter, implementar
Aprovador / CAB	Aprovar ou rejeitar, com comentário
Representante do cliente	Em mudanças com cliente identificado, pode aprovar (perfil CUSTOMER)

O ciclo de vida de uma mudança

1. Rascunho: o solicitante monta a RFC (título, descrição, tipo, risco, impacto, janela, plano).
2. Submissão para aprovação: a RFC entra na fila de aprovação.
3. Aprovação / rejeição: o aprovador lê impacto e rollback e decide. Rejeição costuma devolver a RFC para correção.
4. Implementação: aprovada, a mudança é implantada na janela planejada.
5. Encerramento: registrado o resultado e vinculados os itens resolvidos.

A regra da autoaprovação

Um princípio de controle interno, reforçado pelo Portal: quem cria não aprova a própria mudança (nem o próprio chamado). Essa segregação de funções evita que a autorização vire formalidade. É por isso que, ao submeter uma RFC, ela não aparece na sua fila de aprovações — ela vai para outros aprovadores.

Janela, rollback e evidências

• Janela de implantação: o período autorizado para executar a mudança. Fora dela, a execução é indício de processo frouxo.
• Plano de rollback: como voltar atrás se algo der errado. Em mudanças de risco alto, é obrigatório.
• Vínculos: a mudança registra os chamados/problemas que resolve e a liberação a que pertence, fechando a trilha de auditoria.

Regras de negócio

Regra	Explicação
Tipos importam	Emergency tem fluxo mais rápido; Normal passa por mais controles.
CAB	Mudanças maiores podem exigir reunião/registro de decisão, conforme configuração.
Aprovação	Sem a aprovação pendente resolvida, não se avança o status indevidamente.
Rollback	Documentar o plano de retorno antes da implementação em mudanças de risco alto.
Autoaprovação	O criador não aprova a própria RFC (ADR-015).

Como usar: passo a passo

1. Crie a mudança: Gestão de serviços → Mudanças → Nova; informe título, descrição, tipo, risco, impacto, janela e plano.
2. Salve como rascunho enquanto ajusta, ou submeta para aprovação.
3. Aprove/rejeite: no detalhe ou em Aprovações pendentes; leia impacto e rollback e registre comentário.
4. Implemente dentro da janela e registre o resultado.
5. Vincule chamados/problemas resolvidos e a liberação correspondente.

Boas práticas

• Nunca registre uma mudança sem plano de rollback — sobretudo em risco alto.
• Use a mudança como fechamento do problema: problema → RCA → mudança → liberação.
• Combine a janela com o Downtime Manager para suprimir alertas de monitoramento durante a intervenção.
• Para mudanças emergenciais, registre a aprovação retroativa e documente a decisão.
• Comunique as partes afetadas antes da janela — cliente avisado é cliente satisfeito.

Erros comuns

Situação	O que fazer
“Vou só editar o status” sem aprovação	Respeite o fluxo; a aprovação existe por segregação de funções.
Mudança sem janela definida	Defina início/fim; execução fora de janela quebra o controle.
RFC sem vínculo com o problema	Vincule para manter a rastreabilidade da causa raiz.

Perguntas frequentes

Qual a diferença entre mudança e liberação?
A mudança é a alteração individual; a liberação agrupa várias mudanças que entram juntas em produção.

Posso aprovar a mudança que eu criei?
Não. O Portal aplica a regra de autoaprovação proibida.

Emergency dispensa aprovação?
Dispensa o processo longo, não o controle — a aprovação pode ser retroativa, mas fica registrada.

Automatize via API

O módulo é exposto por API (/api/mudancas, /api/cab-reunioes, vínculo /api/problema-mudanca-links), com transições de status e aprovação controladas por RBAC (CHANGE_*). Referência em developer.nyverra.com.

Cenários de uso: tipos de mudança na prática

1. Mudança padrão (Standard). Reiniciar um serviço conhecido, aplicar um patch aprovado, adicionar um usuário a um grupo. São operações repetitivas e de baixo risco, com fluxo leve — não deveriam parar no CAB. O valor está em registrar para manter a trilha, mesmo quando a execução é quase automática.

2. Mudança normal com janela. Atualizar o ERP, trocar um firewall, migrar um banco. Aqui entram avaliação de risco, aprovação, janela de manutenção e plano de rollback. É a mudança que mais se beneficia do vínculo com o Downtime Manager e com a liberação.

3. Mudança emergencial. Um incidente crítico exige alteração imediata. O fluxo é acelerado; a aprovação é retroativa, mas registrada. Sem isso, o “jeitinho” de produção vira o incidente do mês seguinte sem ninguém saber o que mudou.

KPIs de gestão de mudanças

Indicador	O que revela
Taxa de sucesso (mudanças sem incidente posterior)	Qualidade do planejamento
% de mudanças emergenciais	Quanto a operação ainda é reativa
Tempo médio de aprovação	Agilidade do CAB/fluxo
Mudanças com rollback executado	Precisão da avaliação de risco
Mudanças fora da janela	Disciplina de execução

Uma queda no percentual de mudanças emergenciais costuma indicar amadurecimento: a organização passou a planejar em vez de apagar fogo.

Automação e integração

Boa parte do trabalho de mudança é previsível. Regras de Automação podem notificar os afetados, abrir tarefas-padrão e iniciar o Downtime automaticamente ao aprovar uma mudança. Integrar monitoramento e CMDB permite prever o impacto antes de submeter a RFC — quem depende do que vai mudar. É a diferença entre mudar “no escuro” e mudar sabendo exatamente o alcance.

Conclusão

Gestão de mudanças é a arte de alterar sem surpreender. Com tipos e risco, CAB, aprovação segregada, janela e rollback, o Portal Nyverra ITSM dá à TI o controle que a produção exige — e a tranquilidade que o negócio espera.