Landing zone no Azure: a fundação que evita retrabalho na migração

📚 Continue aprendendo sobre este tema:

A analogia que resolve a conversa com a diretoria

Imagine que a empresa comprou um terreno para construir o novo galpão. Existem duas formas de começar. Na primeira, você descarrega as máquinas assim que o caminhão chega, no lugar que estiver livre. Na segunda, você define antes onde entra a energia, por onde passa a água, onde ficam as docas, quem tem chave de qual portão e como o espaço será dividido entre setores.

As duas colocam as máquinas no terreno. A diferença aparece no segundo ano, quando é preciso ampliar. No primeiro caso, ampliar significa mover o que já está funcionando. No segundo, significa ocupar o espaço que já estava previsto.

Landing zone é a segunda opção aplicada à nuvem. A palavra descreve o ambiente preparado que recebe as cargas de trabalho: a estrutura de contas, a identidade, a rede, a governança e as regras automáticas de conformidade já montadas antes de o primeiro servidor aterrissar.

Por que isso é decisão de diretoria e não só de TI

Porque é a camada que determina três coisas que a diretoria acompanha:

Quanto você consegue enxergar do custo. Sem uma estrutura de contas e etiquetas definida, a fatura da nuvem chega como um número único e ninguém consegue dizer quanto custa o ERP, quanto custa o ambiente de testes e quanto custa aquele projeto que já acabou.
Quem consegue fazer o quê. Sem desenho de acesso, o caminho mais fácil é dar permissão ampla para todo mundo trabalhar, e essa permissão nunca é revista.
Quanto tempo leva para migrar o próximo sistema. Com a fundação pronta, cada nova carga de trabalho é uma tarefa repetível. Sem ela, cada migração é um projeto novo que redebate as mesmas questões.

As seis camadas de uma landing zone

Os nomes comerciais mudam com o tempo e variam entre provedores. As funções, não. Estas são as seis camadas que precisam estar decididas e documentadas antes da migração.

1. Estrutura de assinaturas e grupos de gerenciamento

No Azure, a assinatura é a unidade em que os recursos vivem e em que o consumo é somado. O grupo de gerenciamento é o contêiner que agrupa assinaturas e permite aplicar uma mesma regra a todas de uma vez, sem repetir configuração.

A decisão prática é como você vai separar. Os critérios que mais funcionam em média empresa:

Por ambiente: produção separada de homologação e de desenvolvimento. É a separação mais importante, porque impede que um teste consuma ou derrube o que sustenta a operação.
Por criticidade ou por unidade de negócio: quando existem áreas com regras diferentes de acesso, de retenção de dados ou de disponibilidade.
Por serviço compartilhado: aquilo que atende a todos, como conectividade e identidade, costuma ficar em um espaço próprio, com uma política de mudança mais rígida.

Uma advertência que evita frustração: mover recursos de uma assinatura para outra depois que tudo está rodando é possível em muitos casos, mas raramente é indolor. Endereçamento, permissões, integrações e apontamentos precisam ser revistos. É por isso que essa é a primeira decisão e não a última.

2. Identidade e acesso

Esta é a camada que centraliza quem é quem. Ela responde por três perguntas: como a pessoa prova que é ela mesma, o que ela pode fazer depois de entrar e por quanto tempo esse poder dura.

O que precisa estar definido antes de migrar:

Fonte única de identidade. O diretório corporativo e o ambiente de nuvem precisam conversar, para que desligar uma pessoa no RH tenha efeito real no acesso dela. Duas bases de usuários independentes é a receita para contas órfãs.
Papéis em vez de permissões avulsas. O acesso é concedido por função (quem administra rede, quem administra banco, quem só consulta), não pessoa a pessoa.
Contas administrativas separadas das contas de uso diário. Ninguém lê e-mail com a conta que pode apagar um ambiente inteiro.
Autenticação multifator obrigatória para acesso administrativo, sem exceção. É o controle de maior efeito e menor custo do conjunto.
Contas de serviço mapeadas. Toda integração automática precisa de identidade própria, com dono nomeado e credencial rotacionada.

3. Rede e conectividade

A rede é a decisão mais difícil de refazer, porque endereço IP em uso é endereço que outros sistemas já conhecem. O que precisa ser resolvido no papel:

Plano de endereçamento. Faixas reservadas para a nuvem que não conflitem com nenhuma faixa usada na matriz, nas filiais, no parceiro que se conecta com você e no que já foi usado por sistemas antigos. Sobreposição de faixas é o problema mais comum e o mais caro de corrigir depois.
Topologia. O desenho mais adotado concentra os serviços compartilhados (saída para a internet, inspeção de tráfego, conexão com a matriz) em uma rede central, e liga as redes de cada aplicação a essa central. Isso evita que cada projeto crie seu próprio caminho de saída.
Forma de conexão com a sede. Túnel criptografado pela internet ou conexão dedicada privada. A escolha depende de volume de dados, sensibilidade e tolerância a variação de latência, e é especialmente relevante quando o ERP fica na nuvem e os usuários ficam na fábrica.
Segmentação. Cada camada de aplicação em sua própria sub-rede, com regras explícitas de quem fala com quem. Rede plana na nuvem tem o mesmo defeito que rede plana no escritório: um comprometimento em qualquer ponto alcança tudo.
Resolução de nomes. Definir como os nomes internos serão resolvidos dos dois lados. Boa parte das falhas em migração de aplicação é problema de nome, não de rede.

4. Governança de etiquetas

Etiqueta, ou tag, é um par de rótulo e valor que você prende a cada recurso. Parece burocracia e é o que separa uma fatura legível de um número indecifrável.

O conjunto mínimo que recomendamos padronizar desde o primeiro dia:

Etiqueta	Para que serve na prática
Centro de custo	Permite ratear a fatura entre áreas sem trabalho manual no fim do mês
Dono técnico	Diz a quem perguntar antes de desligar, atualizar ou reiniciar um recurso
Ambiente	Separa produção de homologação e de desenvolvimento em relatórios e em regras automáticas
Aplicação ou sistema	Agrupa tudo que sustenta o mesmo sistema, mesmo espalhado por vários recursos
Criticidade	Define prioridade de atendimento, de backup e de janela de manutenção
Data de revisão	Marca ambientes temporários para que alguém decida se eles ainda são necessários

A etiqueta só funciona se for obrigatória. Padrão que depende de boa vontade dura até a primeira urgência. A camada de política, a seguir, é o que torna isso automático. Sem etiquetagem consistente, qualquer esforço de controle de custo trabalha no escuro, como explicamos em FinOps e a redução de custos de nuvem.

5. Política e conformidade automática

Esta é a camada que faz a plataforma cobrar as regras sozinha, sem depender de alguém lembrar. Ela funciona de três formas: impedindo o que não é permitido, corrigindo automaticamente o que está fora do padrão e apenas registrando desvios para revisão posterior.

Exemplos de regras que costumam entrar no primeiro conjunto:

Só é possível criar recursos nas regiões aprovadas pela empresa, o que evita que um dado sensível vá parar em outro país por descuido.
Recurso sem as etiquetas obrigatórias não é criado, ou herda automaticamente a etiqueta do agrupamento em que está.
Armazenamento precisa nascer com criptografia e sem acesso público.
Determinados tipos ou tamanhos de máquina ficam bloqueados, o que evita que alguém provisione um recurso desproporcional por engano.
Todo recurso precisa enviar seus registros de atividade para o repositório central de logs.

O ganho aqui é de escala. Uma regra escrita uma vez passa a valer para todos os recursos criados dali em diante, inclusive pelos que entraram na equipe depois de você.

6. Observabilidade, backup e custo

A sexta camada é o que permite operar depois que a migração termina:

Registro centralizado. Logs de atividade e de segurança em um repositório único, com retenção definida. Sem isso, investigar um incidente vira arqueologia.
Monitoramento desde o primeiro recurso. Nenhuma carga de trabalho entra em produção sem alerta e sem responsável definido, com as mesmas métricas que você já acompanha no ambiente local.
Política de backup e de retenção definida por criticidade, e não decidida recurso a recurso na hora da criação.
Orçamento com alerta de consumo. Um teto por assinatura, com aviso antes de estourar, evita a surpresa de fim de mês.

O que acontece quando se migra sem landing zone

Vale descrever o padrão, porque ele se repete. A migração começa por um servidor de arquivos, que alguém sobe rápido para provar que funciona. Funciona. A partir daí, cada novo sistema segue o mesmo caminho improvisado.

Decisão adiada	Como o problema aparece	O que custa para corrigir depois
Plano de endereçamento	A faixa escolhida no primeiro dia conflita com a rede de uma filial ou de um parceiro	Reendereçar sistemas em produção, com parada e revisão de todas as integrações
Separação de ambientes	Teste e produção convivem no mesmo espaço lógico e nas mesmas permissões	Recriar e mover recursos, com janela de indisponibilidade e risco de esquecer dependências
Modelo de acesso	Meia dúzia de pessoas com permissão total, herdada de quando o ambiente era pequeno	Revisão completa de permissões, quase sempre com quebra de rotinas automáticas não documentadas
Etiquetas obrigatórias	A fatura não se explica e ninguém sabe de quem é aquele recurso ligado há meses	Inventário manual retroativo, recurso por recurso, para descobrir dono e finalidade
Política automática	Cada recurso foi criado de um jeito, conforme o critério de quem estava de plantão	Trabalho de padronização em ambiente vivo, com risco a cada ajuste
Registro centralizado	Ocorre um incidente e não existe histórico suficiente para reconstruir o que houve	Não tem correção. O dado que não foi guardado não volta

Repare que nenhuma dessas correções aparece como linha nova de investimento no orçamento. Elas aparecem como atraso, como horas de equipe consumidas e como aquela sensação de que o projeto de nuvem nunca termina.

A ordem de construção que funciona

A boa notícia é que uma landing zone para média empresa não precisa contemplar tudo que uma corporação global precisaria. Ela precisa contemplar o que é difícil de mudar depois. A ordem sugerida:

Inventariar antes de desenhar. Sem saber o que existe hoje, quem usa e do que depende, qualquer desenho é chute. O ponto de partida está descrito em como fazer um inventário de TI.
Definir a estrutura de assinaturas e grupos. Comece simples, com produção separada de não produção e um espaço para serviços compartilhados.
Fechar o plano de endereçamento considerando matriz, filiais, parceiros e crescimento previsto. Reserve faixas com folga, porque faixa reservada e não usada não custa nada, e faixa insuficiente custa uma migração.
Montar identidade e acesso, com papéis, contas administrativas separadas e multifator obrigatório.
Subir a conectividade com a sede e validar rota, nome e latência antes de qualquer carga de trabalho real.
Publicar o padrão de etiquetas e as políticas obrigatórias, começando em modo de registro e depois passando para modo de bloqueio, para não travar a equipe de uma vez.
Ligar registro, monitoramento, backup e orçamento com alerta.
Migrar a primeira carga de trabalho de baixo risco e usá-la para validar o desenho, corrigindo o que apareceu antes de escalar.
Documentar e repetir. A partir daqui, cada migração deveria ser um procedimento conhecido, não uma discussão.

Essa sequência conversa diretamente com o roteiro geral descrito em migrar para a nuvem: por onde começar. A landing zone é a etapa que fica entre o diagnóstico e a primeira onda de migração.

Landing zone quando existe SAP no ambiente

Se a empresa roda SAP, a fundação ganha exigências extras, e elas precisam entrar no desenho desde o início:

Latência entre usuário e aplicação vira critério de arquitetura, não detalhe. A escolha da região e da forma de conexão com a sede afeta diretamente a percepção de lentidão no dia a dia.
Separação clara entre produção, qualidade e desenvolvimento, com caminho definido de transporte entre eles.
Janela de parada e política de backup pensadas antes, porque o ERP é o sistema em que restaurar sem plano custa mais caro.
Acesso administrativo restrito e auditável, dado que se trata da base de dados fiscal e contábil da empresa.

O comportamento do ERP em nuvem depende bastante de como essa base foi montada, assunto que detalhamos em SAP Business One na nuvem e performance.

Erros comuns de quem monta a fundação

Copiar um modelo corporativo grande demais. Uma estrutura com dezenas de agrupamentos e políticas em uma empresa de cem pessoas vira burocracia que ninguém mantém. Comece pelo que é difícil de mudar depois.
Tratar a landing zone como projeto que termina. Ela evolui. O que não pode é evoluir por improviso, sem registro de mudança.
Bloquear tudo no primeiro dia. Políticas que impedem a equipe de trabalhar são desligadas na primeira urgência e nunca mais religadas. Comece registrando desvios, ajuste, depois bloqueie.
Deixar o ambiente antigo sem plano de desligamento. Manter o servidor local ligado por segurança, indefinidamente, é pagar duas vezes pela mesma carga de trabalho.
Nomear sem padrão. Nome de recurso improvisado é o irmão gêmeo da etiqueta ausente, e cobra o mesmo preço em confusão futura.

Perguntas frequentes

Landing zone atrasa a migração?

Ela adia o primeiro servidor migrado e antecipa o último. As decisões de estrutura consomem tempo de planejamento no começo, mas transformam cada migração seguinte em tarefa repetível, com padrão de rede, de acesso e de monitoramento já resolvido. O projeto que parece mais rápido é justamente o que costuma se arrastar, porque cada novo sistema reabre a mesma discussão e alguns exigem refazer o que já estava pronto.

Já migramos sem landing zone. Perdemos a chance?

Não, mas o trabalho muda de natureza. Em vez de desenhar em terreno livre, você organiza em ambiente vivo. O caminho é fazer o inventário do que já está na nuvem, definir o padrão desejado, aplicar primeiro o que não exige parada (etiquetas, papéis de acesso, registro centralizado, orçamento com alerta) e tratar o que exige parada, como endereçamento e separação de assinaturas, como projeto próprio com janela negociada. O importante é interromper a criação de novos recursos fora do padrão enquanto isso.

Esse conceito serve só para o Azure?

O termo é mais usado no universo Microsoft, mas a ideia vale para qualquer provedor. Muda o nome dos componentes, não a necessidade: organizar contas, centralizar identidade, planejar endereçamento, padronizar rótulos, automatizar regras e ligar monitoramento antes de migrar. Se a empresa ainda está escolhendo o provedor, vale comparar os cenários em AWS e Azure: qual combina com o seu cenário.

Como a BS IT Solutions constrói essa fundação

A BS IT Solutions desenha e implanta a estrutura de nuvem antes da migração: organização de assinaturas, modelo de identidade e acesso, plano de endereçamento e conectividade com a sede, padrão de etiquetas, políticas automáticas de conformidade, registro centralizado e monitoramento. Trabalhamos com Azure, AWS e Google Cloud, com atenção especial a ambientes que sustentam SAP, e integramos a operação ao NOC 24x7 e às práticas de segurança. O atendimento é presencial em São Paulo e região metropolitana e remoto em todo o Brasil, dentro do serviço de cloud computing.

Fale com um especialista da BS IT Solutions e comece a sua migração pela fundação, não pelo primeiro servidor.