Contexto
A operação cresceu com múltiplos clientes e o modelo baseado em Docker Compose começou a gerar fricção em deploy, escalabilidade e troubleshooting.
O objetivo foi migrar para K3s com downtime mínimo, mantendo governança por tenant e previsibilidade de custo.
Ação
Rollout da migração
Ordem do rollout
Decisão
Migrar um tenant piloto antes dos demais grupos de clientes.
Motivo
Validar runbook, métricas e rollback em uma área limitada.
Consequência
Problemas de configuração aparecem antes de afetar toda a base.
Resultado
Migração concluída sem incidente de disponibilidade percebido pelos tenants. O rollout faseado permitiu detectar problemas de configuração no tenant piloto antes que afetassem a base inteira, e o checklist de smoke tests pegou regressões antes de virarem incidente.
Rollout faseado ou total
Aprendizado
-
Migrar todos os tenants de uma vez, sem fase piloto, teria escondido problemas até a escala total — e aí o custo de rollback seria maior.
-
Ignorar limites de recursos por tenant gera noisy neighbor: um tenant barulhento derruba a performance dos outros no mesmo node.
-
Rollback não formalizado por serviço crítico é dívida técnica disfarçada de economia de tempo — cobra na primeira migração que dá errado.