Vou conduzir gestão de mudanças em sistemas

Classificar a mudança pelo risco

Nem toda mudança merece o mesmo tratamento. Tratar todas como crítica esgota o processo; tratar todas como triviais convida o incidente. Três níveis cobrem a maioria dos casos.

Padrão (baixo risco): mudança rotineira, pré-aprovada por categoria, com procedimento conhecido e impacto previsível. Reset de senha, abertura de acesso padrão, adição de regra de firewall pré-aprovada, deploy automatizado de versão menor. Pode ser executada por técnico capacitado sem aprovação individual.

Normal (médio risco): mudança fora do padrão pré-aprovado, em sistema relevante, com algum risco residual. Update de versão de aplicação, alteração de configuração de banco, mudança em integração entre sistemas. Exige aprovação formal e janela planejada.

Emergencial (alta urgência): mudança que não pode esperar o ciclo normal por causa de risco maior em não fazer (vulnerabilidade crítica, incidente em curso). Exige aprovação acelerada com decisor sênior, mas mantém o procedimento mínimo (rollback, comunicação, registro).

O que NÃO é mudança padrão

Cuidado para não classificar como padrão o que ainda não foi executado várias vezes com sucesso documentado. "Padrão" significa que o procedimento está validado pela prática repetida — não que a mudança é fácil. Tratar como padrão uma mudança nova porque "vai dar certo" é convite para incidente.

Plano de rollback é tão importante quanto a mudança

Toda mudança precisa de plano de rollback escrito antes de começar. Plano de rollback que só existe na cabeça do executor é tão útil quanto plano nenhum quando o executor está sob pressão e a mudança deu errado às duas da manhã. O plano cobre três cenários: rollback imediato (durante a execução, ao perceber problema), rollback pós-execução (quando o problema aparece nas horas seguintes) e ponto de não retorno (a partir de qual etapa não dá mais para voltar).

Para mudanças em banco de dados, rollback exige cuidado especial: snapshot antes, scripts reversíveis quando possível, ponto de restauração documentado. Migração de schema raramente é totalmente reversível, e por isso merece teste em homologação com dados de produção mascarados.

Comunicação às áreas afetadas

Comunicação prévia evita ruído de chamado e cria credibilidade. Para mudanças com impacto perceptível, aviso de pelo menos 48 horas com: o que muda, quando começa, quanto deve durar, que serviços ficam indisponíveis, o que fazer em caso de problema durante a janela. Para áreas-cliente com SLA contratual, comunicação ao gestor da área e não só ao usuário final.

Após a mudança, comunicação de encerramento. Mesmo quando tudo correu bem, dizer que terminou. Silêncio gera desconfiança e abre chamado "para confirmar se está tudo certo". Quando a mudança trouxe novidade visível para o usuário, comunicação separada explicando o que mudou e como usar.