Atualização de sistema quebrou processo crítico

Os dois caminhos: rollback e hotfix

A decisão de qual caminho seguir define a próxima hora. Rollback reverte o sistema ao estado anterior ao update — restaura o que funcionava, mas perde também o que o update trazia (correções, novas funcionalidades, atualizações de segurança). Hotfix mantém o update e corrige o problema específico — preserva o ganho do update mas exige tempo para o fix chegar (ou ser construído) e testar.

Quando rollback é o caminho

Quando rollback é tecnicamente simples e rápido (sistema sem migração complexa de schema, snapshot recente, procedimento documentado). Quando o hotfix não tem prazo confiável. Quando o impacto do problema atual é maior que o ganho perdido com a reversão. Para sistemas críticos em hora crítica, rollback costuma ser o caminho seguro.

Quando hotfix faz sentido

Quando rollback é tecnicamente complexo ou demorado (migração de banco, integrações que mudaram, dados gerados no novo formato). Quando o fornecedor confirma fix em janela curta. Quando o ganho do update é central (correção de segurança crítica, por exemplo) e voltar atrás abre outro risco.

Comunicação às áreas afetadas

Atualização que quebrou produção gera atrito imediato — usuários sentem na hora. Comunicação proativa nas primeiras minutos reduz substancialmente o tumulto. Mensagem padrão: o que está quebrado, qual o impacto, qual o caminho de resolução (rollback em X minutos ou hotfix em Y), contorno disponível, próxima atualização em Z. Tom honesto, sem minimizar e sem dramatizar. Para sistemas com cliente externo afetado, comunicação ao cliente passa por revisão estratégica.

RCA: por que a regressão passou?

O update foi aplicado por algum processo, em algum momento — a quebra revela falha nesse processo. RCA precisa cobrir não só causa técnica, mas:

O ambiente de teste cobria esse cenário?

Se não cobria, por quê? É cenário comum que devia estar coberto, ou é caso raro? Como expandir cobertura no próximo ciclo?

O teste em homologação foi feito?

Se sim, por que não pegou? Se não, por quê? A pressa estava justificada ou era pressão indevida? Como reforçar a disciplina?

O fornecedor tinha conhecimento prévio da regressão?

Para sistemas de terceiros, regressão em release é responsabilidade do fornecedor. Bug conhecido sem aviso quebra confiança e merece formalização — possivelmente penalidade contratual.

O change management permitiu a aplicação?

Janela controlada, aprovação prévia, rollback plan documentado eram parte do change? Se não, por quê? Se sim, como melhorar?