As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Planejamento de ondas
Em essência, um plano de ondas é um cronograma de migração e é semelhante a outras atividades de planejamento de projetos. Recomendamos que você use as ondas de migração como um meio de criar grupos gerenciáveis, reduzir riscos e organizar atividades em torno desses grupos.
Para criar planos de onda de migração eficazes e de alta confiança, você deve obter uma visão completa do portfólio de aplicativos, da infraestrutura associada (computação, armazenamento, redes), do mapeamento de dependências e da estratégia de migração.
Além dos aplicativos de negócios, que são uma forma de agrupar uma coleção de componentes de software e infraestrutura, você pode usar outros níveis de grupo. Uma onda é o nível mais alto do grupo. Em uma onda, você pode criar grupos de dependência. Esse tipo de subgrupo pode conter mais de um aplicativo. Por exemplo, dois ou mais aplicativos que precisam ser migrados ao mesmo tempo devido a dependências técnicas, como baixa latência ou outros fatores. Em seguida, esse grupo de dependências é gerenciado como um todo. Vários grupos de dependência podem ser atribuídos a uma onda. Em seguida, você pode atribuir uma data de migração para toda a onda ou para grupos de dependência individuais dentro de uma onda. A data de migração é a data e a hora em que esse grupo será parado no local atual e ativado em AWS.
As ondas de migração têm várias atividades. Recomendamos que você organize a onda em fases e defina uma duração esperada para cada fase. As fases abaixo servem como exemplo:
-
Projeto: Nesta fase de onda, o projeto alvo para cada aplicação na onda é confirmado e aprovado.
-
Planejamento de transição: essa fase de onda inclui a criação ou iteração de runbooks de transição e o planejamento de todas as etapas necessárias para migrar o aplicativo (incluindo cenários de reversão). AWS
-
Pre-migration: Essa fase inclui atividades de implantação da landing zone, como provisionamento de contas, configuração, testes de pré-migração, configuração de ferramentas de migração e replicação de dados.
-
Transição: Essa fase é quando a migração real ocorre. Durante esse período, os aplicativos são interrompidos no local atual, os dados são sincronizados pela última vez, os testes de negócios são realizados e a migração é finalizada. Essa fase inclui a transferência operacional.
-
Hypercare ou Post-migration: Essa fase é um período em que as equipes de migração estão disponíveis para apoiar as operações em caso de problemas. Além disso, as otimizações podem ser aplicadas conforme necessário.
-
Fechamento da onda: nesta fase, você revisa as métricas e as lições aprendidas e fecha formalmente a onda.
Não há uma duração predefinida para uma onda de migração e isso dependerá do nível de esforço e complexidade. Recomendamos manter as ondas de migração dentro de 6 a 10 semanas. Casos em que é necessário mais tempo, por exemplo, ao reescrever completamente um componente do aplicativo, geralmente são mais bem tratados fora das ondas de migração.
Para medir o sucesso e acompanhar o progresso, as ondas devem estar alinhadas aos resultados e aos fatores de negócios. Isso também influenciará a duração da onda e os grupos de dependência que uma onda contém. A conclusão de uma onda deve refletir uma conquista mensurável.
Há várias maneiras de organizar as ondas de migração. A tabela a seguir descreve as opções mais comuns de organização de ondas. Geralmente são combinados.
Tipo de organização do Wave |
Description |
Prós |
Contras |
|---|---|---|---|
Por estratégia de migração ou pilha de tecnologia |
Atribua aplicativos com uma estratégia ou padrão de migração comum a uma onda. Por exemplo, uma onda contendo somente aplicativos de rehospedagem. |
Equipes dedicadas por padrão ou pilha podem receber ondas inteiras. Duração homogênea das atividades. |
Requer mais análise das dependências, especialmente para aplicativos que seguem padrões diferentes. |
Por domínio de negócios |
Crie ondas por domínio comercial. Por exemplo, uma onda de gerenciamento de pedidos ou uma onda de pagamentos. |
Dados compartilhados normalmente dentro de um determinado domínio. Envolvimento consistente da equipe. |
Aumento do risco devido ao impacto de todo o domínio comercial. |
Por capacidade técnica |
Agrupe aplicativos que usam um ou mais recursos. Por exemplo, uma onda somente de computação ou uma onda de balanceamento de carga de computação +. |
As migrações começam mais rapidamente à medida que os recursos técnicos são ativados ao longo do tempo. Remove a dependência de uma landing zone totalmente operacional. |
Cria bolsões de complexidade em ondas posteriores. |
Por ambiente |
Uma onda contém um ambiente específico para um conjunto de aplicativos. Por exemplo, uma onda de desenvolvimento ou uma onda de produção. |
Non-production as ondas se beneficiam da flexibilidade durante a execução. Risco reduzido de migração da produção. |
Requer foco na análise de dependências para evitar a perda de dependências que não estão presentes em ambientes de não produção. |
Por prioridade de negócios |
Cria grupos puramente com base em um determinado critério de priorização. |
Aborda os resultados comerciais. |
Normalmente, muitas equipes estão envolvidas; é difícil coordenar. |
A seção sobre como estabelecer uma linha de base para o portfólio de aplicativos descreveu quatro categorias de dependências técnicas. Essas dependências contribuem para a criação de ondas de migração e a definição de grupos de dependência. Os grupos de dependência serão determinados pela criticidade da dependência. Além disso, dependências não técnicas devem ser consideradas. Por exemplo, cronogramas de lançamento de aplicativos, janelas de manutenção e datas comerciais importantes (como processamento no final do mês ou no final do trimestre) podem influenciar o plano de onda.
Determine se a dependência é leve ou difícil. Uma dependência suave é uma relação entre dois ou mais ativos, ou entre um ativo e uma restrição, que não depende da localização dos componentes. Por exemplo, dois sistemas que operam na mesma rede local (ou na mesma infraestrutura) podem ser separados movendo um desses sistemas para a nuvem enquanto o outro permanece no local. Uma dependência rígida é uma relação entre dois ou mais ativos, ou entre um ativo e uma restrição, que depende da localização. Por exemplo, dois sistemas que operam na mesma rede local e que são altamente dependentes da baixa latência para comunicação entre o servidor de aplicativos e o servidor de banco de dados têm uma forte dependência. Mover apenas um desses sistemas para a nuvem causaria problemas de funcionalidade ou desempenho que não podem ser resolvidos. Da mesma forma, motivos não técnicos, como disponibilidade de recursos (como a equipe que está realizando a migração) ou restrições operacionais (como janelas de manutenção em que dois sistemas só podem ser migrados em um determinado período), podem criar uma forte dependência desses ativos.
Para criar um plano de onda de migração, determine seus grupos de dependências analisando dependências, de preferência a partir de uma fonte de dados altamente confiável, como ferramentas de descoberta especializadas. Combine essas informações com seus critérios de priorização de aplicativos e circunstâncias operacionais.
Determinar dependências técnicas é um desafio. Vários pontos de dados são necessários e nenhuma fonte de dados contém todos eles. Por exemplo, embora você possa obter informações de comunicação de processo a processo a partir de ferramentas de descoberta, é difícil classificá-las em dependências flexíveis e rígidas. Também é difícil determinar a tolerância à latência apenas com base nos dados da rede.
As técnicas a seguir podem ajudá-lo a lidar com a ambigüidade de determinar dependências reais:
-
Colete todos os dados conforme descrito na seção de requisitos de dados e quaisquer outros pontos de dados que você tenha considerado necessários.
-
Filtre as informações de dependência (ou dados de comunicação) e exclua serviços compartilhados, como Active Directory, backup e monitoramento de tráfego. Os serviços técnicos compartilhados tendem a unir todo o escopo.
-
Classifique todas as informações. Se disponível, use a frequência da rede e os volumes de transferência de dados entre os componentes.
-
Reúna-se com proprietários de aplicativos, arquitetos e equipes de suporte. Discuta o tipo de conexão. Eles são síncronos ou assíncronos? Eles estão cientes dos requisitos mínimos de latência? Quais são as conexões críticas e o que acontece se elas não estiverem disponíveis? Você está perdendo conexões importantes? Considere que os processos em lote podem ocorrer esporadicamente e estar ausentes no conjunto de dados.
-
Se sua ferramenta de descoberta fornecer um gráfico de dados, procure aplicativos únicos que unam grandes clusters de aplicativos. Esses pontos únicos de conexão podem ajudar a dividir os dados em grupos menores.
O AWS Transform pode ajudar você a analisar dependências e realizar o planejamento de ondas.
Criando um plano de ondas
Um pré-requisito para migrar uma onda de aplicativos são os dados do portfólio de aplicativos e a avaliação detalhada do grupo de aplicativos que serão migrados na onda. A avaliação detalhada deve incluir a lista de aplicativos na onda, os detalhes da infraestrutura associada, um projeto de destino e uma estratégia de migração para cada aplicativo.
Estabelecer a propriedade e a governança da onda é fundamental para gerenciar e monitorar o trabalho da onda, as dependências do programa, o gerenciamento de mudanças, os problemas e os riscos. Garanta que exista uma estrutura de governança para gerenciar o plano.
Para delinear o plano de onda, comece com uma construção de onda padrão. O que acontece dentro de uma onda? Depois que a entrada inicial for definida, a onda pode começar. Normalmente, as atividades serão:
-
Refine o plano de transição. Essa atividade deve descrever os runbooks e as etapas que devem ser tomadas no momento da migração, incluindo a coordenação com outras equipes internas e externas.
-
Refine o plano de reversão. O que deve ser feito para reverter os aplicativos se as coisas derem errado?
-
Prepare a infraestrutura de destino. Por exemplo, você pode criar ou ampliar a AWS landing zone (segurança Conta da AWS, rede, serviços de infraestrutura, outras infraestruturas de suporte).
-
Teste a infraestrutura de destino.
-
Opere as ferramentas de migração. Por exemplo, instale agentes de replicação e inicie a transferência de dados.
-
Conduza um plano de transição e execute tiragens secas. Agrupe todos os membros da equipe participantes e analise todas as etapas com antecedência.
-
Monitore a replicação de dados e as implantações de infraestrutura.
-
Confirme a prontidão para operação da infraestrutura e dos aplicativos em AWS.
-
Confirme a prontidão de segurança.
-
Confirme os requisitos regulatórios e de conformidade (por exemplo, validação da carga de trabalho antes e depois da migração), se aplicável.
-
Migre os aplicativos AWS e realize testes antes da ativação.
-
Forneça suporte pós-migração por um período de tempo, como 3 dias, quando as equipes de operações e as equipes de migração estiverem totalmente disponíveis para resolver problemas e aplicar otimizações.
-
Faça uma revisão pós-migração. Documente as lições aprendidas e incorpore-as às futuras ondas.
-
Realize o encerramento da onda confirmando a transferência operacional e a obtenção de métricas para relatórios.
A duração de cada uma dessas atividades será ditada pela complexidade do escopo, pela capacidade das ondas, pelas pessoas envolvidas e por suas circunstâncias únicas. Sempre que possível, ondas menores são preferíveis, pois isso reduzirá o impacto de quaisquer atrasos ou bloqueios de migração. Determine, com suas equipes, qual será a duração padrão de uma onda.
Em seguida, continue analisando as datas para criar uma estrutura inicial de alto nível de ondas vazias (sem nenhum aplicativo atribuído ainda). Considere as seguintes perguntas:
-
Qual é a duração total do programa de migração?
-
Quais são os prazos?
-
Há datas fixas de saída do data center?
-
Existem datas de término do contrato de colocação?
-
Quais são os ciclos de atualização de aplicativos e infraestrutura?
-
Quais são os ciclos de manutenção e lançamento de aplicativos?
-
Há alguma data em que as migrações devem ser evitadas (por exemplo, ciclos de lançamento e manutenção, final de ano, feriados, processamento no final do mês)?
Com essas considerações, trace as ondas em um plano. Para acelerar o processo de migração, recomendamos a sobreposição de ondas sempre que possível. A chave para ondas sobrepostas é definir e considerar o que acontece dentro de uma onda. Normalmente, as atividades de implantação, a validação da infraestrutura de destino e a sincronização de dados ocorrerão durante a primeira metade de uma onda. A segunda metade se concentrará na migração real, nos testes e na transferência operacional. Isso significa que equipes diferentes estão envolvidas em cada metade do processo e que você pode obter alguma eficiência. Por exemplo, assim que a equipe envolvida na preparação da infraestrutura alvo concluir seu trabalho, ela poderá começar a trabalhar nos requisitos da próxima onda. Em geral, é preferível que a maioria das ondas tenha comprimento e estrutura semelhantes para facilitar uma abordagem de migração semelhante à de uma fábrica. No entanto, durante o processo de planejamento de ondas, o tamanho de uma determinada onda pode ser estendido para atender às dependências ou aos requisitos operacionais.
Em seguida, com base nos grupos de dependência identificados, determine o tamanho máximo de uma onda em termos do número de grupos de dependência que ela pode conter. O tamanho da onda geralmente é determinado pelo apetite pelo risco (por exemplo, quanta mudança paralela pode ser tolerada) e pela disponibilidade de recursos (por exemplo, quanta mudança paralela pode ser realizada com os recursos, habilidades e orçamento disponíveis). No entanto, durante o planejamento inicial, não se limite aos requisitos e à disponibilidade de recursos. Ondas que contêm mais de um grupo de dependências podem ser decompostas em ondas menores em iterações futuras.
Depois que os grupos de dependência de uma determinada onda forem confirmados, revise os requisitos de recursos para migrar a onda. Considere ajustar o tamanho da onda (o número de grupos de dependências que ela contém) com base nos requisitos de recursos. Isso pode levar a ondas menores ou maiores. Repita o plano de ondas conforme necessário até que todas as ondas tenham sido definidas. Considere trabalhar com serviços AWS profissionais ou parceiros de competência em AWS migração, que podem fornecer especialistas para ajudá-lo durante todo o processo.
Gerenciando mudanças
O portfólio de aplicativos e a infraestrutura associada mudarão durante o ciclo de vida dos programas de migração. Long-running os programas de migração coexistem com a evolução e a mudança normais dos negócios. Os aplicativos continuam evoluindo enquanto aguardam a migração. Os servidores são adicionados ou removidos, uma nova infraestrutura é implantada no local. Espera-se que o escopo de uma onda ou grupo de dependência exija mudanças. Mudanças são necessárias especialmente quando, mais perto da data de migração, uma dependência até então desconhecida é identificada ou um novo servidor é incluído no inventário. Às vezes, isso pode acontecer durante a migração em si.
As mudanças no escopo afetam grupos e ondas de dependência. Para lidar com as mudanças e minimizar o impacto, é importante estabelecer um mecanismo de controle de escopo. Um mecanismo de controle de mudança de escopo requer a definição de uma única fonte confiável para o escopo. Isso pode ser uma ferramenta para gerenciar o escopo ou um arquivo.csv, planilha ou banco de dados, conforme definido pela governança do programa de migração. Você deve identificar as mudanças, analisar o impacto e comunicar as mudanças às partes interessadas relevantes para que elas possam agir. Como resultado, o plano de ondas será iterado.
