Guia · Nuvem
Um guia de migração para a nuvem para grandes empresas, da avaliação à virada
Uma migração é uma sequência de decisões, e a maioria delas é tomada antes que qualquer servidor seja movido. Este playbook apresenta as fases, a escolha da região e a residência de dados, além das práticas que tornam tranquilo o fim de semana da virada.
Para que serve um playbook
Grandes empresas raramente migram uma única vez. Migram um primeiro sistema, aprendem com ele e depois migram os dez seguintes. Um playbook registra o que foi aprendido para que a segunda onda seja mais rápida e segura que a primeira: como os sistemas são avaliados, como é a landing zone, como uma virada é conduzida e o que significa “concluído”. Este é o guia que usamos como ponto de partida com nossos clientes; ele deve ser adaptado à sua organização, e não seguido ao pé da letra.
Dois princípios permeiam todo o guia. Primeiro, migre a função de negócio, e não o servidor: a questão é como uma aplicação e seus dados continuam atendendo os usuários, e não como uma máquina virtual é copiada. Segundo, mantenha cada etapa reversível até o momento em que ela se torna permanente por decisão deliberada.
As fases
Cada fase termina com uma decisão que o comitê diretor consegue reconhecer. As fases se sobrepõem entre as ondas: a segunda onda é avaliada enquanto a primeira está sendo migrada.
- 1
Avaliar
Faça o inventário de todas as aplicações, com responsável, dependências, classificação de dados, integrações, licenciamento e infraestrutura atual. Agrupe as aplicações em ondas por dependência e risco. Defina um destino para cada uma: rehost (mover como está), replatform (pequenas mudanças, como um banco de dados gerenciado), refactor (conteinerizar ou rearquitetar), replace (SaaS) ou retire (desativar). Entrega: um plano de ondas com os destinos definidos e o primeiro business case.
- 2
Planejar
Para a primeira onda, projete a arquitetura de destino, o caminho de rede a partir das suas instalações, a identidade (SSO para pessoas, funções para workloads), o método de migração de dados e o padrão de virada de cada aplicação. Escreva os critérios de aceite nesta etapa: quais testes, quais usuários, quais relatórios precisam bater. Entrega: um desenho por aplicação e um esqueleto de runbook.
- 3
Construir a landing zone
Crie como código a estrutura de contas, a rede, a identidade, os logs, as linhas de base de segurança, o backup e os controles de custo antes que qualquer workload chegue. Essa é a base sobre a qual todas as ondas seguintes se apoiam, então vale a pena construí-la direito uma única vez. Entrega: um ambiente gerenciado pelo Terraform que passa nas próprias verificações de conformidade.
- 4
Migrar em ondas
Mova primeiro os ambientes não produtivos e depois a produção, uma onda de cada vez. Replique os dados continuamente quando o padrão exigir, execute os testes de aceite no destino com dados reais e corrija o que quebrar antes que alguém seja afetado. Entrega: um ambiente de destino aprovado no aceite, com o sistema antigo ainda em operação.
- 5
Fazer a virada
Execute o runbook ensaiado: congele as mudanças, conclua a sincronização final dos dados, redirecione o tráfego, verifique e comunique. Mantenha o ambiente de origem intacto e pronto para rollback por um período acordado. Entrega: produção rodando no destino, com o ponto de decisão de rollback ultrapassado de forma explícita.
- 6
Otimizar
Após a estabilização, ajuste o que foi superdimensionado por segurança, migre as cargas de trabalho elegíveis para serviços gerenciados ou contêineres, aplique preços com compromisso de uso onde o consumo é previsível e desative o sistema de origem. Resultado: uma linha de base de custo operacional e as lições incorporadas ao playbook para a próxima onda.
Escolha da região e residência de dados
A escolha da região vem em primeiro lugar. Uma região no próprio país, quando existe, oferece várias Availability Zones para resiliência e baixa latência para os usuários locais. A região AWS Asia Pacific (Bangkok) (ap-southeast-7) é um exemplo: ela dá às organizações com usuários na Tailândia uma opção que não existiu durante a maior parte da era da nuvem, em vez de atender o país a partir de Singapura. Para sistemas sensíveis à latência e para organizações cujas políticas ou reguladores preferem que os dados permaneçam no país, uma região local é o ponto de partida padrão.
Há dois cuidados a tomar. Regiões mais novas não são lançadas com todos os serviços; consulte a lista de serviços da região para cada serviço gerenciado do projeto antes de se comprometer e prepare uma alternativa (outro serviço ou outra região para aquele componente). A residência também é uma decisão de política antes de ser uma decisão técnica: leis de proteção de dados pessoais como a PDPA permitem a transferência internacional sob certas condições, e os reguladores setoriais, como os de serviços financeiros, podem ter suas próprias exigências. Registre por escrito quais categorias de dados devem permanecer no país e quais podem ser replicadas no exterior para recuperação de desastres, e peça a confirmação das equipes jurídica e de conformidade. Em seguida, codifique isso como restrições de região nas políticas da organização, para que um recurso no lugar errado seja impedido, e não apenas descoberto.
A recuperação de desastres merece a mesma clareza. Dentro da região, várias Availability Zones protegem contra a falha de uma instalação. Para se proteger contra um evento regional, decida se uma segunda região é aceitável para backups ou standby, qual deve ser essa região e quais tempo e ponto de recuperação o negócio está disposto a financiar.
Terraform: a landing zone como código
Tudo na landing zone que pode ser definido como código deve ser: contas e políticas organizacionais, redes e roteamento, identidade e funções, logs e trilhas de auditoria, chaves de criptografia, políticas de backup, orçamentos e alertas. O Terraform é a nossa ferramenta preferida porque é declarativo, independente de provedor e revisável no mesmo fluxo de pull requests do código das aplicações.
Algumas práticas mantêm tudo sob controle. Armazene o state remotamente, com bloqueio, um state por ambiente e por componente lógico, para que um erro em um lugar não corrompa outro. Crie módulos pequenos e bem nomeados para o que é criado repetidamente (um serviço com sua definição de contêiner, regra de load balancer, role do IAM e grupo de logs) e versione-os. Aplique tags a todos os recursos com responsável, ambiente, aplicação e centro de custo a partir de um único módulo de tags, porque o controle de custos depende disso mais tarde. Execute um plan a cada mudança, exija revisão e faça o apply a partir de um pipeline, e não de um notebook. Detecte desvios (drift) periodicamente e trate alterações manuais no console como incidentes a serem conciliados, e não como o novo normal.
O resultado é que o ambiente da segunda onda vira um pull request, e não um projeto.
Comparação dos padrões de virada
Escolha um padrão por aplicação, e não por programa. A tolerância à indisponibilidade, o volume de dados e a forma como o tráfego chega ao sistema definem o padrão adequado.
| Padrão | Como funciona | Ideal para | Indisponibilidade e rollback |
|---|---|---|---|
| Big-bang (offline) | Parar a origem, copiar os dados, iniciar o destino, trocar o DNS ou os endpoints. | Sistemas pequenos, cargas em lote, ferramentas internas com janela de manutenção. | A indisponibilidade equivale ao tempo de cópia. O rollback é simples: voltar a apontar para a origem intacta. |
| Replicar e depois trocar | Replicação contínua do banco de dados para o destino (por exemplo, com um serviço de replicação gerenciado) enquanto a origem continua em operação; sincronização final e troca na virada. | Bancos de dados e ERPs em que uma parada longa é inaceitável, mas uma curta é tolerável. | Minutos de indisponibilidade. O rollback exige replicação reversa ou a aceitação da perda dos dados gerados desde a troca; decida isso com antecedência. |
| Blue-green | Ambiente de destino totalmente construído e testado ao lado da origem; o tráfego é trocado no load balancer ou no DNS em uma única etapa. | Workloads stateless e de camada web; aplicações cuja camada de dados já foi migrada. | Praticamente zero. O rollback é a mesma troca no sentido inverso, desde que a camada de dados seja compartilhada ou sincronizada. |
| Canary / ponderado | Uma pequena parcela do tráfego (por peso, região ou grupo de usuários) é enviada ao destino e aumentada à medida que a confiança cresce. | Aplicações voltadas a clientes, com muitos usuários; detectar problemas antes que todos os percebam. | Nenhuma, por concepção. O rollback consiste em reduzir o peso. Exige gestão de sessões e consistência de dados entre os dois lados. |
| Strangler (incremental) | Direcionar uma função de cada vez para novos serviços no destino; o sistema legado diminui até ser desativado. | Grandes monólitos em refatoração; programas de modernização de vários anos. | Nenhuma por etapa. O rollback é por função. O mais lento no total, com o menor risco por mudança. |
Ensaiar o rollback
Todo runbook tem uma seção de rollback; poucas equipes já a executaram. Ensaie a virada completa pelo menos uma vez em um ambiente não produtivo, com as mesmas pessoas, a mesma checklist e um cronômetro, e depois ensaie o rollback. Defina os critérios de go/no-go antes do dia (quais testes precisam passar, quais partes interessadas precisam confirmar e até que horas) e nomeie a única pessoa que toma a decisão. Estabeleça explicitamente o ponto sem retorno: o momento a partir do qual novas transações existem apenas no destino e voltar atrás significa conciliar dados manualmente.
Durante a virada real, comunique-se em intervalos fixos, e não apenas quando algo acontece: uma mensagem de status a cada trinta minutos, mesmo que informe que tudo está dentro do previsto, mantém o negócio tranquilo e a equipe focada. Depois, faça uma revisão rápida enquanto os detalhes estão frescos e atualize o playbook.
Controle de custos desde o primeiro dia
As faturas de nuvem crescem por padrão e só diminuem quando alguém se responsabiliza por elas. Implante estes controles antes do primeiro workload de produção.
- Orçamentos com alertas por conta e por aplicação, visíveis tanto para o responsável pela aplicação quanto para o financeiro.
- Tags obrigatórias impostas por política, para que todo gasto possa ser atribuído.
- Ambientes não produtivos desligados automaticamente fora do horário de trabalho ou criados sob demanda a partir do Terraform.
- Revisões de dimensionamento um mês após cada onda, porque as migrações são dimensionadas pensando em segurança, e não em eficiência.
- Preços com compromisso de uso (savings plans ou capacidade reservada) somente depois que o consumo estiver estável e compreendido.
- Regras de ciclo de vida do armazenamento: logs, backups e snapshots passam para camadas mais baratas e expiram conforme um cronograma.
- Serviços gerenciados e contêineres onde a economia operacional for real; rearquitetar não é pré-requisito para reduzir custos.
- Uma revisão mensal de custos com o mesmo rigor da revisão de disponibilidade.
Uma segunda opinião sobre o seu plano de ondas
Compartilhe o seu plano de ondas e diremos o que faríamos de forma diferente. Nossa equipe de nuvem e infraestrutura constrói ambientes AWS gerenciados pelo Terraform e conduz migrações para grandes empresas, inclusive para a região AWS Asia Pacific (Bangkok).