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á. # Práticas recomendadas Escolher retirar aplicativos pode ser uma decisão complexa, especialmente durante uma migração para a AWS nuvem. As seções a seguir fornecem as melhores práticas a serem usadas em seu processo de tomada de decisão. **Topics** + [Considere uma abordagem de fábrica de migração](best-practice-1.md) + [Identifique e retire os aplicativos logo no início de sua migração](best-practice-2.md) + [Seja orientado por dados e use ferramentas de descoberta para evitar interrupções](best-practice-3.md) + [Agende uma parada controlada](best-practice-4.md) + [Reavalie se o aplicativo deve ser migrado](best-practice-5.md) + [Retire o aplicativo](best-practice-6.md) # Considere uma abordagem de fábrica de migração Uma parte importante de qualquer migração em grande escala é estabelecer uma *fábrica de migração* após a migração das cargas de trabalho piloto iniciais. Uma fábrica de migração consiste em equipes, ferramentas e processos que trabalham juntos para agilizar as migrações de forma sistemática, incorporando as lições aprendidas em ondas migratórias anteriores. A fábrica de migração aplica padrões que aceleram as migrações de workload e melhoram o resultado final. Com base no tamanho do portfólio de TI que você precisa retirar, vale a pena considerar se há valor na implementação de uma abordagem de fábrica de migração. As metodologias e princípios descritos neste guia também complementarão essa abordagem e podem ser incorporados em seus mecanismos. Entre 20 e 50% de um portfólio de aplicativos corporativos consiste em padrões repetidos que podem ser otimizados por meio de uma abordagem de fábrica. Para ver um exemplo de padrão, consulte a solução [AWS Cloud Migration Factory](https://aws.amazon.com//solutions/implementations/cloud-migration-factory-on-aws/), que pode ser implementada por uma equipe de migração para coordenar e automatizar as migrações. A equipe deve começar com aplicativos que tenham a menor criticidade comercial, antes de passar gradualmente para sistemas mais críticos. Quando a equipe começar a migrar sistemas essenciais para os negócios, ela terá migrado centenas, se não milhares, de cargas de trabalho e aprendido muitas lições. Antes do início da fase de avaliação, você pode criar um processo para capturar um mês de dados de dependência para aplicativos identificados para serem retirados. Uma equipe é notificada e recebe acesso aos dados quando eles estão prontos. Em seguida, a equipe atribui aos dados uma pontuação com base no potencial de um aplicativo causar impacto. Os proprietários do aplicativo podem então fazer uma análise mais profunda das conexões antes do início das próximas etapas. Para obter mais informações sobre a metodologia da fábrica de migração, consulte o [Guia para grandes migrações do AWS .](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/) # Identifique e retire os aplicativos logo no início de sua migração Identificar e, em seguida, retirar os aplicativos no início do processo de migração é importante e deve ser feito enquanto as cargas de trabalho estão sendo migradas. Os projetos de migração geralmente priorizam a migração de cargas de trabalho, por isso é comum que sistemas identificados para serem retirados (e não migrados) se concentrem no final do projeto. No entanto, existe o risco de que deixar esses aplicativos até o final do projeto deixe muito pouco tempo para incluí-los na migração, caso o aplicativo seja posteriormente considerado importante. A retirada antecipada de workloads durante um projeto de migração reduz o workload das equipes que as mantêm. Por exemplo, retirar os servidores durante as fases iniciais de um projeto de migração significa que as equipes do sistema operacional têm menos servidores para corrigir, atualizar, manter ou dar suporte. Essas equipes podem então se concentrar no projeto de migração em si. Por fim, algumas das melhores práticas deste guia são mais eficazes quando você as segue por longos períodos de tempo. Se você iniciar o processo de retirada mais cedo, mas depois determinar que um aplicativo é realmente exigido por outro serviço, você poderá modificar seu plano de migração e incluí-lo em uma futura onda de migração. # Seja orientado por dados e use ferramentas de descoberta para evitar interrupções Ser orientado por dados é fundamental ao considerar a retirada de aplicativos. Diagramas de arquitetura e conhecimento institucional podem facilmente estar desatualizados ou incompletos. Às vezes, problemas imprevistos também podem surgir, como outro aplicativo se tornando dependente do seu sistema sem um engajamento formal devido a um cenário de falha. Uma abordagem impulsionada por dados fornece a base sobre a qual você pode tomar decisões ou validar uma abordagem. Ao avaliar se um aplicativo pode ser retirado, você deve confirmar se as cargas de trabalho que você está migrando não dependem dele. Migrar essas cargas de trabalho e, em seguida, retirar uma dependência pode causar uma degradação do serviço ou, pior ainda, uma interrupção do serviço. Felizmente, é bastante simples entender essas dependências usando dados para monitorar as conexões de entrada e saída da rede em um servidor que está programado para ser retirado. Conexões de entrada de rede, como um aplicativo se conectando ao seu aplicativo, e conexões de saída, como um upload de arquivo para um compartilhamento do Network File System (NFS), indicam uma possível dependência a montante. Essa dependência precisa ser investigada, porque se uma carga de trabalho que está prestes a ser migrada para a AWS nuvem se conectar ao aplicativo, há um potencial de interrupção do serviço se o aplicativo for retirado posteriormente. Esse processo pode exigir um grande aprofundamento para acompanhar a cadeia de dependências. Seguindo o exemplo anterior, se o aplicativo carregar um arquivo em um compartilhamento NFS, a próxima etapa é determinar qual sistema consome esse arquivo e o status desse aplicativo. Você pode decidir investigar essas conexões e avaliar o nível de impacto. Para fazer isso, você pode usar as ferramentas de descoberta para mostrar as conexões que estão sendo iniciadas em um servidor que está programado para ser retirado. Você pode notar que a maioria das conexões vem de servidores de gerenciamento e pode ser ignorada, pois são ferramentas que coletam métricas de desempenho ou instâncias proxy do administrador do sistema. No entanto, se houver aplicativos conectados ao servidor que estão programados para migração, você deve se aprofundar e verificar o impacto potencial da migração nesse aplicativo. [AWS Application Discovery Service](https://aws.amazon.com/application-discovery/)ajuda os clientes a planejar projetos de migração reunindo informações sobre data centers locais que eles planejam aposentar. Depois de implantar o agente em seus servidores, o Application Discovery Service registra a atividade de rede de entrada e saída de cada servidor, junto com outras informações. Ao usar o [Amazon Athena](https://aws.amazon.com/athena/) para analisar esses dados, você pode identificar se outros aplicativos dependem de servidores que estão planejados para serem desativados. Os [AWS Parceiros de Competência em Migração](https://aws.amazon.com//migration/partner-solutions/) também podem fornecer ferramentas detalhadas de descoberta e planejamento. **nota** O Application Discovery Service não está mais aberto a novos clientes. Como alternativa, use AWS Transform o que fornece recursos semelhantes. Para obter mais informações, consulte [Mudança de disponibilidade do AWS Application Discovery Service](https://docs.aws.amazon.com/application-discovery/latest/userguide/application-discovery-service-availability-change.html). Por exemplo, a ilustração de tela a seguir mostra quatro endereços IP de origem conectados ao servidor na porta 22 (destino = 172.31.1.117). ![\[Exemplo de análise de conexões.\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/migration-retiring-applications/images/best-practices-4.png) Esses são bastion hosts que são usados pelos administradores do sistema e podem ser ignorados. A imagem também mostra dois servidores se conectando a esse aplicativo na porta 80, que estão no escopo de uma migração planejada. Nesse estágio, você precisaria se aprofundar e entender os aplicativos de conexão. Essa análise mais profunda permitirá que você avalie se haverá algum impacto inicial após a retirada. # Agende uma parada controlada Em seu plano de migração, certifique-se de agendar um horário para uma parada controlada durante o processo de migração. Uma parada controlada interrompe o processo de migração para identificar o potencial de rompimento se um aplicativo for retirado. Ele simula a retirada do aplicativo e permite observar as consequências. Quando o período de parada controlado for concluído, a migração poderá ser retomada facilmente. A abordagem de parada controlada varia de acordo com o tipo de aplicativo e os processos associados com os quais você está trabalhando. Os padrões comuns de parada controlada incluem: + Implementação de um firewall baseado em host para bloquear todo o tráfego, o que simula a retirada + Pausando uma máquina virtual + Interrompendo um serviço no host + Bloqueando todo o tráfego usando um firewall externo Os proprietários do projeto de migração e do aplicativo precisam definir a duração de uma parada controlada, dependendo do tipo de aplicativo. Por exemplo, se você estiver retirando um workload baseado em lotes que só é executada uma vez por mês ou uma vez por trimestre, realizar uma parada controlada de uma semana pode não ser suficiente para determinar o impacto em outros sistemas. Continuando com o exemplo da seção anterior, outro aplicativo estava se conectando ao servidor que estava programado para ser retirado. Uma avaliação inicial concluiu que não deveria haver um impacto nos servidores a montante. Agora, uma parada controlada pode ser realizada para entender o impacto. Essa parada controlada seria realizada implementando um firewall baseado em host para bloquear todo o tráfego, simulando o efeito de desligar o servidor. Se isso causar problemas de serviço para aplicativos programados para serem migrados para a AWS nuvem, uma regra de firewall será adicionada e todo o tráfego será retomado. Após a parada controlada, a retirada do servidor é reconsiderada devido à degradação ou interrupção desse serviço. # Reavalie se o aplicativo deve ser migrado As duas últimas melhores práticas que discutimos ajudam a determinar se é apropriado continuar a agir nos sistemas que estão programados para serem retirados. Se essas melhores práticas destacarem um potencial impacto comercial a montante, considere reavaliar o padrão de migração do aplicativo. Ao iniciar o processo de desativação do aplicativo mais cedo, agora você tem tempo suficiente para incluir o aplicativo em uma onda de migração subsequente, caso encontre problemas ou dependências que impossibilitem sua desativação. Se, depois de seguir essas melhores práticas, você não estiver totalmente confiante em retirar o aplicativo, considere se ele deve ser hospedado novamente na AWS nuvem. Isso é particularmente importante se sua migração tiver uma data de término definida, como a expiração do contrato de um datacenter. Serviços como o [Serviço de Migração de Aplicativos AWS](https://aws.amazon.com/application-migration-service/) simplificam a abordagem de migração de redefinir a hospedagem. Ao migrar aplicativos para AWS, você pode tirar um instantâneo diário dos volumes do Amazon Elastic Block Store (Amazon EBS) e encerrar a instância do Amazon Elastic Compute Cloud (Amazon EC2) para reduzir custos e testar a desativação do aplicativo por um longo período de tempo. Se surgir um impacto ou problema, você terá a confiança de poder criar os volumes do EBS com base no snapshot para retomar a instância do EC2. **Importante** Teste esse processo de recuperação antes de encerrar a instância do EC2. # Retire o aplicativo Depois de seguir as cinco melhores práticas anteriores deste guia, você pode ter determinado que é seguro retirar um aplicativo. Você implantou uma abordagem de fábrica de migração, iniciou o processo de retirada mais cedo, usou ferramentas de dados e descoberta para monitorar as conexões de entrada, realizou uma parada controlada bem-sucedida e avaliou se o aplicativo deveria ser retirado. Agora é possível retirar o aplicativo como parte de sua estratégia de migração. Nesse ponto, você deve verificar se o aplicativo contém dados que possam ser úteis no futuro. O machine learning (ML) e a análise deram aos dados mais valor do que nunca. Embora você não esteja desenvolvendo algoritmos de ML agora, dados históricos podem ser benéficos no futuro. Você também pode ter requisitos regulatórios ou de conformidade para armazenar os dados por um período de tempo definido, mesmo que o aplicativo tenha sido retirado. AWS oferece um conjunto abrangente de serviços de armazenamento em nuvem para retenção de longo prazo, conformidade e preservação digital. AWS as soluções de armazenamento para arquivamento de dados ajudam a fornecer escala ilimitada, 99,999999999% de durabilidade, confiabilidade e segurança de dados. Para auxiliar seus esforços de conformidade, obtém AWS regularmente a validação de terceiros para milhares de requisitos globais de conformidade. Eles são monitorados continuamente para ajudá-lo a atender aos padrões de segurança e conformidade para finanças, varejo, saúde, governo e muito mais. Para obter mais informações sobre arquivamento de dados com AWS, consulte [Arquivamento de dados](https://aws.amazon.com//archive/) no AWS site.