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á.
# Livro de execução de transição
Conforme observado anteriormente, as migrações podem ser complexas, com muitas partes móveis que abrangem hardware, software, pessoas, processos e organização. Para garantir o sucesso, a consistência e a eventual aceleração, um plano bem definido, documentado e aceito por todas as partes interessadas, é essencial em todos os estágios da migração. Esse plano pode ser documentado usando um caderno de execução de transição.
Um runbook de transição abrange todas as atividades que devem ser concluídas para uma determinada migração. É um guia abrangente e detalhado do seguinte:
+ Atividades
+ Cronograma planejado
+ Carimbos de data/hora reais da atividade
+ Critérios de sucesso para cada etapa
+ Propriedade de cada etapa
Ao preparar o caderno de transição, faça a si mesmo as seguintes perguntas e forneça as respostas em seu plano.
| Pergunta | Por que isso é importante |
| --- | --- |
| A transição precisa de um tempo de inatividade? | O tempo de inatividade prolongado afetará a experiência de seus usuários. Ao preparar seu plano de transição, tente minimizar o tempo de inatividade de seu aplicativo ou sistema. |
| Você precisa sincronizar os dados antes da transição? | Se você migrar a camada de armazenamento, como volumes do Amazon Elastic Block Store (Amazon EBS) ou buckets do Amazon Simple Storage Service (Amazon S3) antes da transição sem usar um mecanismo de replicação contínua, a camada de armazenamento poderá ficar fora de sincronia. Nesses casos, certifique-se de fazer uma sincronização final depois de desligar os serviços de origem, mas antes de iniciar a transição. |
| Quem deve estar ciente da transição planejada? | Notifique todas as partes interessadas e usuários sobre o tempo de inatividade planejado. |
| Você quer dividir a migração em partes menores ou migrar tudo de uma vez? | Se você migrar um sistema complicado, faz sentido dividir a migração em fases e realizar várias transições. Por exemplo, você pode migrar primeiro a camada de dados. |
| Você precisa de suporte de algum fornecedor externo? | Talvez seja necessário entrar em contato com os fornecedores externos várias semanas antes da transição planejada para garantir a disponibilidade deles. Consulte o fornecedor sobre quaisquer considerações de licenciamento que você deve conhecer. |
| Você precisa de alguma aprovação especial para alguma parte do processo? | Obtenha todas as aprovações necessárias algumas semanas antes da transição planejada. |
# Modelo de runbook de transição
Um caderno de execução de transição deve incluir todas as atividades que serão realizadas durante a transição. No entanto, é igualmente importante preparar um modelo ou uma lista de verificação de pré-migração. O modelo deve incluir atividades a serem concluídas antes da migração.
Ambos os modelos (que podem ser mesclados em um único documento) devem fornecer as respostas para as seguintes perguntas:
+ Quais atividades devem ser realizadas?
+ Quem vai realizar as atividades?
+ Quando as atividades devem ser realizadas?
Esta seção inclui um exemplo de lista de verificação de pré-migração, um modelo de runbook de transição e um plano de reversão. A tarefa IDs ajuda a tornar a comunicação mais rápida e eficaz.
## Lista de verificação de pré-migração
| ID da tarefa | Tarefa | Dependência | Equipe | Proprietário | Data de conclusão | Status | Observações |
| --- | --- | --- | --- | --- | --- | --- | --- |
| P1 | Documento de arquitetura de destino aprovado. | | | | | | |
| P2 | Existe uma conta de destino para o aplicativo. | | | | | | |
| P3 | Existem uma nuvem privada virtual (VPC) e sub-redes para o aplicativo. | | | | | | |
| P4 | A equipe de migração tem acesso à conta do aplicativo de destino e tem as permissões necessárias AWS Identity and Access Management (IAM). | | | | | | |
| P5 | A equipe do aplicativo tem o acesso necessário à conta do aplicativo de destino e seus recursos. | | | | | | |
| P6 | Solicitação de alteração levantada e aprovada. | | | | | | |
| P7 | Conectividade entre o ambiente de origem e de destino estabelecida e testada. | | | | | | |
| P8 | Lista de contatos da equipe de aplicativos documentada. | | | | | | |
| P9 | Plano de transição revisado com as principais partes interessadas. | | | | | | |
| P10 | As atividades de backup antes da migração foram concluídas. | | | | | | |
| P11 | Confirme se contatos adicionais de suporte devem ser estabelecidos. | | | | | | |
| P12 | Confirme os recursos de cada aplicativo: quem iniciará e encerrará cada aplicativo individual. | | | | | | |
| P13 | Plano final de transição emitido para todas as equipes contribuintes. | | | | | | |
| P14 | Comunicação de início de transição emitida para as principais partes interessadas. | | | | | | |
| P15 | Reunião retrospectiva pós-transição agendada. | | | | | | |
É igualmente importante documentar os itens anteriores em um registro de problemas para manter o controle ou, se algo der errado, retomar o controle.
## Livro de execução de transição
| ID da tarefa | Tarefa | Dependência | Equipe | Proprietário | Data/hora de início planejada | Data/hora de término planejada | Data/hora de início real | Data e hora real de término | Status | Observações |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| C1 | Envie uma nota informativa a todas as partes interessadas informando que o aplicativo ficará inativo conforme especificado no CR. | | | | | | | | | |
| C2 | Confirme o backup dos servidores e bancos de dados de origem. | | | | | | | | | |
| C3 | Interrompa os serviços de aplicativos e de banco de dados nos servidores de origem. | | | | | | | | | |
| C4 | Desligue os servidores de origem. | | | | | | | | | |
| | **Marco 1** **Atividades de pré-transição concluídas** | | | | | | | | | |
| C5 | Execute a migração com base em sua abordagem de migração (como AWS Application Migration Service para lift-and-shift). | | | | | | | | | |
| C6 | Verifique a infraestrutura (servidores de destino em funcionamento). | | | | | | | | | |
| | **Marco 2** **Migração concluída** | | | | | | | | | |
| C7 | Atualize os servidores DNS para apontar para os endpoints recém-criados. | | | | | | | | | |
| C8 | Verifique as alterações de DNS. | | | | | | | | | |
| | **Marco 3** **Atividades pós-migração — Infraestrutura concluída** | | | | | | | | | |
| C9 | Inicie aplicativos e serviços de banco de dados nos servidores de destino. | | | | | | | | | |
| C10 | Aplique alterações de configuração específicas do aplicativo (por exemplo, aponte para novos endereços IP). | | | | | | | | | |
| | **Marco 3** **Atividades pós-migração — Inscrições concluídas** | | | | | | | | | |
| C11 | Realize testes de aplicativos pós-migração — Verificação técnica. | | | | | | | | | |
| C12 | Realize testes de aplicativos após a migração — verificação comercial | | | | | | | | | |
| C13 | Comunique a todas as principais partes interessadas que a migração foi concluída. | | | | | | | | | |
| | **Marco 4** **Teste pós-migração concluído** | | | | | | | | | |
## Plano de reversão
| ID da tarefa | Tarefa | Dependência | Equipe | Proprietário | Status | Observações |
| --- | --- | --- | --- | --- | --- | --- |
| R1 | Interrompa os serviços de aplicativos e de banco de dados nos servidores de destino. | | | | | |
| R2 | Desligue os servidores de destino. | | | | | |
| R3 | Reverta a atualização nos servidores DNS (para apontar de volta para os servidores de origem). | | | | | |
| R4 | Verifique as alterações de DNS. | | | | | |
| R5 | Inicie os servidores de origem. | | | | | |
| R6 | Sincronize os dados de volta aos servidores de origem (se necessário). | | | | | |
| R7 | Inicie aplicativos e serviços de banco de dados em servidores de origem. | | | | | |
| R8 | Realizar testes de aplicativos — Verificação técnica. | | | | | |
| R9 | Realize testes de aplicativos após a migração — verificação comercial. | | | | | |
| R10 | Comunique a todas as principais partes interessadas que a migração foi revertida. | | | | | |
## Modelo de exemplo para a estratégia de rehospedagem
Uma das estratégias de migração do tipo R mais comuns usadas no campo é a estratégia de rehospedagem, com o Application Migration Service como a ferramenta de migração preferida. Você pode usar o [modelo de amostra](samples/cutover-runbook_template.zip) como um documento básico em um cenário de rehospedagem. O modelo incorpora atividades essenciais que foram encontradas durante os compromissos reais com o cliente. Também inclui espaço para as equipes de aplicativos adicionarem suas tarefas e atividades. As etapas na seção anterior podem fornecer orientação inicial para criar seu próprio runbook de transição personalizado, conforme necessário.