Entendendo os requisitos de dados de avaliação inicial - AWS Orientação prescritiva

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á.

Entendendo os requisitos de dados de avaliação inicial

A coleta de dados pode levar um tempo significativo e facilmente se tornar um bloqueador quando não há clareza sobre quais dados são necessários e quando são necessários. A chave é entender o equilíbrio entre o que é pouco e o que é muita informação para os resultados dessa etapa. Para se concentrar nos dados e no nível de fidelidade necessários para esse estágio inicial da avaliação do portfólio, adote uma abordagem iterativa para a coleta de dados.

Fontes de dados e requisitos de dados

A primeira etapa é identificar suas fontes de dados. Comece identificando as principais partes interessadas em sua organização que podem atender aos requisitos de dados. Normalmente, são membros das equipes de gerenciamento de serviços, operações, planejamento de capacidade, monitoramento e suporte, além dos proprietários dos aplicativos. Estabeleça sessões de trabalho com membros desses grupos. Comunique os requisitos de dados e obtenha uma lista de ferramentas e documentação existente que podem fornecer os dados.

Para orientar essas conversas, use o seguinte conjunto de perguntas:

  • Quão preciso e atualizado é o inventário atual de infraestrutura e aplicativos? Por exemplo, para o banco de dados de gerenciamento de configuração da empresa (CMDB), já sabemos onde estão as lacunas?

  • Temos ferramentas e processos ativos que mantêm o CMDB (ou equivalente) atualizado? Em caso afirmativo, com que frequência ele é atualizado? Qual é a data de atualização mais recente?

  • O inventário atual, como o CMDB, contém application-to-infrastructure mapeamento? Cada ativo de infraestrutura está associado a um aplicativo? Cada aplicativo está mapeado para a infraestrutura?

  • O inventário contém um catálogo de licenças e contratos de licenciamento para cada produto?

  • O inventário contém dados de dependência? Observe a existência de dados de comunicação, como servidor para servidor, aplicativo para aplicativo, aplicativo ou servidor para banco de dados.

  • Quais outras ferramentas que podem fornecer informações sobre aplicativos e infraestrutura estão disponíveis no ambiente? Observe a existência de ferramentas de desempenho, monitoramento e gerenciamento que podem ser usadas como fonte de dados.

  • Quais são os diferentes locais, como data centers, que hospedam nossos aplicativos e infraestrutura?

Depois que essas perguntas forem respondidas, liste suas fontes de dados identificadas. Em seguida, atribua um nível de fidelidade, ou nível de confiança, a cada um deles. Os dados validados recentemente (dentro de 30 dias) a partir de fontes programáticas ativas, como ferramentas, têm o mais alto nível de fidelidade. Os dados estáticos são considerados de menor fidelidade e menos confiáveis. Exemplos de dados estáticos são documentos, pastas de trabalho, CMDBs atualizados manualmente ou qualquer outro conjunto de dados não mantido de forma programática ou cuja data da última atualização seja anterior a 60 dias.

Os níveis de fidelidade de dados na tabela a seguir são fornecidos como exemplos. Recomendamos que você avalie os requisitos de sua organização em termos de tolerância máxima às suposições e ao risco associado para determinar qual é o nível adequado de fidelidade. Na tabela, o conhecimento institucional se refere a qualquer informação sobre aplicativos e infraestrutura que não esteja documentada.

Fontes de dados

Nível de fidelidade

Cobertura do portfólio

Comentários

Conhecimento institucional

Baixo - Até 25% dos dados precisos, 75% dos valores assumidos ou os dados têm mais de 150 dias.

Baixo

Escasso, focado em aplicações críticas

Base de conhecimento

Médio-baixo - 35-40% dos dados precisos, 65-60% dos valores assumidos ou os dados têm 120-150 dias.

Médio

Níveis de detalhes inconsistentes e mantidos manualmente

CMDB

Médio - ~ 50% de dados precisos, ~ 50% de valores assumidos ou dados com 90 a 120 dias.

Médio

Contém dados de fontes mistas, várias lacunas de dados

Exportações do VMware vCenter

Médio-alto - 75-80% de dados precisos, 25-20% de valores assumidos ou dados com 60 a 90 dias.

Alta

Cobre 90% da propriedade virtualizada

Monitoramento do desempenho de aplicativos

Alto - Dados geralmente precisos, ~ 5% dos valores ou dados presumidos têm de 0 a 60 dias.

Baixo

Limitado a sistemas de produção críticos (cobre 15% do portfólio de aplicativos)

As tabelas a seguir especificam os atributos de dados obrigatórios e opcionais para cada classe de ativo (aplicativos, infraestrutura, redes e migração), a atividade específica (inventário ou caso de negócios) e a fidelidade de dados recomendada para esse estágio de avaliação. As tabelas usam as seguintes abreviações:

  • R, se necessário

  • (D), para casos de negócios direcionais, necessários para comparações de custo total de propriedade (TCO) e casos de negócios direcionais

  • (F), para um caso de negócios direcional completo, necessário para comparação de TCO e casos de negócios direcionais que incluem custos de migração e modernização

  • O, para opcional

  • N/A, se não aplicável

Aplicativos

Nome do atributo

Descrição

Inventário e priorização

Caso de negócios

Nível de fidelidade recomendado (mínimo)

Identificador exclusivo

Por exemplo, ID do aplicativo. Normalmente disponível em CMDBs existentes ou em outros inventários internos e sistemas de controle. Considere criar IDs exclusivos sempre que eles não estiverem definidos em sua organização.

R

R (D)

Alta

Nome da aplicação

Nome pelo qual esse aplicativo é conhecido pela sua organização. Inclua o nome comercial off-the-shelf (COTS) do fornecedor e do produto quando aplicável.

R

R (D)

Médio-alto

É COTS?

Sim ou não. Seja um aplicativo comercial ou um desenvolvimento interno

R

R (D)

Médio-alto

Produto e versão COTS

Nome e versão do produto de software comercial

R

R (D)

Médio

Descrição

Função e contexto primários do aplicativo

R

O

Médio

Criticidade

Por exemplo, aplicativo estratégico ou gerador de receita ou suporte a uma função crítica

R

O

Médio-alto

Tipo

Por exemplo, banco de dados, gerenciamento de relacionamento com o cliente (CRM), aplicativo web, multimídia, serviço compartilhado de TI

R

O

Médio

Ambiente

Por exemplo, produção, pré-produção, desenvolvimento, teste, sandbox

R

R (D)

Médio-alto

Conformidade e regulamentação

Estruturas aplicáveis à carga de trabalho (por exemplo, HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e aos requisitos normativos

R

R (D)

Médio-alto

Dependências

Dependências ascendentes e posteriores de aplicativos ou serviços internos e externos. Dependências não técnicas, como elementos operacionais (por exemplo, ciclos de manutenção)

O

O

Médio-baixo

Mapeamento de infraestrutura

Mapeamento para ativos físicos e/ou virtuais que compõem o aplicativo

O

O

Médio

Licença

Tipo de licença de software comum (por exemplo, Microsoft SQL Server Enterprise)

O

R

Médio-alto

Custo

Custos de licença de software, operações e manutenção de software

N/D

O

Médio

Infraestrutura

Nome do atributo

Descrição

Inventário e priorização

Caso de negócios

Nível de fidelidade recomendado (mínimo)

Identificador exclusivo

Por exemplo, ID do servidor. Normalmente disponível em CMDBs existentes ou em outros inventários internos e sistemas de controle. Considere criar IDs exclusivos sempre que eles não estiverem definidos em sua organização.

R

R

Alta

Nome da rede

Nome do ativo na rede (por exemplo, nome do host)

R

O

Médio-alto

Nome DNS (nome de domínio totalmente qualificado ou FQDN)

Nome DNS

O

O

Médio

Endereço IP e máscara de rede

Endereços IP internos e/ou públicos

R

O

Médio-alto

Asset type (Tipo de ativo)

Servidor físico ou virtual, hipervisor, contêiner, dispositivo, instância de banco de dados etc.

R

R

Médio-alto

Nome do produto

Fornecedor comercial e nome do produto (por exemplo, VMware ESXi, IBM Power Systems, Exadata)

R

R

Médio

Sistema operacional

Por exemplo, REHL 8, Windows Server 2019, AIX 6.1

R

R

Médio-alto

Configuração

CPU alocada, número de núcleos, threads por núcleo, memória total, armazenamento, placas de rede

R

R

Médio-alto

Utilização

Pico e média de CPU, memória e armazenamento. Taxa de transferência da instância de banco de dados.

R

O

Médio-alto

Licença

Tipo de licença de mercadoria (por exemplo, RHEL Standard)

R

R

Médio

A infraestrutura é compartilhada?

Sim ou Não para indicar serviços de infraestrutura que fornecem serviços compartilhados, como provedor de autenticação, sistemas de monitoramento, serviços de backup e serviços similares

R

R (D)

Médio

Mapeamento de aplicativos

Aplicativos ou componentes de aplicativos que são executados nessa infraestrutura

O

O

Médio

Custo

Custos totalmente elevados de servidores bare-metal, incluindo hardware, manutenção, operações, armazenamento (SAN, NAS, objeto), licença do sistema operacional, participação no espaço em rack e despesas gerais do data center

N/D

O

Médio-alto

Redes

Nome do atributo

Descrição

Inventário e priorização

Caso de negócios

Nível de fidelidade recomendado (mínimo)

Tamanho do tubo (MB/s), redundância (Y/N)

Especificações atuais do link WAN (por exemplo, redundante de 1000 MB/s)

O

R

Médio

Utilização do link

Utilização máxima e média, transferência de dados de saída (GB/mês)

O

R

Médio

Latência (ms)

Latência atual entre locais conectados.

O

O

Médio

Custo

Custo atual por mês

N/D

O

Médio

Migração

Nome do atributo

Descrição

Inventário e priorização

Caso de negócios

Nível de fidelidade recomendado (mínimo)

Redefinir a hospedagem

Esforço do cliente e do parceiro para cada carga de trabalho (pessoa-dia), taxas de custo do cliente e do parceiro por dia, custo da ferramenta, número de cargas de trabalho

N/D

R (F)

Médio-alto

Redefinir a plataforma

Esforço do cliente e do parceiro para cada carga de trabalho (pessoa-dia), taxas de custo de clientes e parceiros por dia, número de cargas de trabalho

N/D

R (F)

Médio-alto

Refatorar

Esforço do cliente e do parceiro para cada carga de trabalho (pessoa-dia), taxas de custo de clientes e parceiros por dia, número de cargas de trabalho

N/D

O

Médio-alto

Retirada

Número de servidores, custo médio de desativação

N/D

O

Médio-alto

Zona de pouso

Reutilização existente (S/N), lista de AWS regiões necessárias, custo

N/D

R (F)

Médio-alto

Pessoas e mudança

Número de funcionários a serem treinados em operações e desenvolvimento em nuvem, custo do treinamento por pessoa, custo do tempo de treinamento por pessoa

N/D

R (F)

Médio-alto

Duração

Duração da migração da carga de trabalho dentro do escopo (meses)

O

R (F)

Médio-alto

Custo paralelo

Prazo e taxa em que os custos no estado em que se encontram podem ser removidos durante a migração

N/D

O

Médio-alto

Prazo e taxa em que AWS produtos e serviços e outros custos de infraestrutura são introduzidos durante a migração

N/D

O

Médio-alto

Avaliando a necessidade de ferramentas de descoberta

Sua organização precisa de ferramentas de descoberta? A avaliação do portfólio exige up-to-date dados de alta confiança sobre aplicativos e infraestrutura. Os estágios iniciais da avaliação do portfólio podem usar suposições para preencher lacunas de dados.

No entanto, à medida que o progresso é feito, os dados de alta fidelidade permitem a criação de planos de migração bem-sucedidos e a estimativa correta da infraestrutura de destino para reduzir custos e maximizar os benefícios. Também reduz o risco ao permitir implementações que consideram dependências e evitam armadilhas de migração. O principal caso de uso das ferramentas de descoberta em programas de migração para a nuvem é reduzir o risco e aumentar os níveis de confiança nos dados por meio do seguinte:

  • Coleta de dados automatizada ou programática, resultando em dados validados e altamente confiáveis

  • Aceleração da taxa na qual os dados são obtidos, melhorando a velocidade do projeto e reduzindo os custos

  • Níveis aumentados de integridade de dados, incluindo dados de comunicação e dependências que normalmente não estão disponíveis em CMDBs

  • Obter insights como identificação automatizada de aplicativos, análise de TCO, taxas de execução projetadas e recomendações de otimização

  • Planejamento de ondas de migração de alta confiança

Quando há incerteza sobre a existência de sistemas em um determinado local, a maioria das ferramentas de descoberta pode escanear sub-redes de rede e descobrir os sistemas que respondem a solicitações de ping ou SNMP (Simple Network Management Protocol). Observe que nem todas as configurações de rede ou sistemas permitirão tráfego de ping ou SNMP. Discuta essas opções com sua rede e equipes técnicas.

Outros estágios de avaliação e migração do portfólio de aplicativos dependem muito de informações precisas de mapeamento de dependências. O mapeamento de dependências fornece uma compreensão da infraestrutura e da configuração que serão necessárias AWS (como grupos de segurança, tipos de instância, posicionamento da conta e roteamento de rede). Também ajuda a agrupar aplicativos que devem ser movidos ao mesmo tempo (como aplicativos que precisam se comunicar em redes de baixa latência). Além disso, o mapeamento de dependências fornece informações para a evolução do caso de negócios.

Ao decidir sobre uma ferramenta de descoberta, é importante considerar todas as etapas do processo de avaliação e antecipar os requisitos de dados. As lacunas de dados têm o potencial de se tornarem bloqueadoras, por isso é fundamental antecipá-las analisando os requisitos e fontes de dados futuros. A experiência na área determina que a maioria dos projetos de migração paralisados tem um conjunto de dados limitado no qual os aplicativos no escopo, na infraestrutura associada e suas dependências não são claramente identificados. Essa falta de identificação pode levar a métricas, decisões e atrasos incorretos. Obter up-to-date dados é a primeira etapa para projetos de migração bem-sucedidos.

Como selecionar uma ferramenta de descoberta?

Várias ferramentas de descoberta no mercado oferecem recursos e capacidades diferentes. Considere seus requisitos. E escolha a opção mais adequada para sua organização. Os fatores mais comuns ao decidir sobre uma ferramenta de descoberta para migrações são os seguintes:

Segurança

  • Qual é o método de autenticação para acessar o repositório de dados da ferramenta ou os mecanismos de análise?

  • Quem pode acessar os dados e quais são os controles de segurança para acessar a ferramenta?

  • Como a ferramenta coleta dados? Ele precisa de credenciais dedicadas?

  • Quais credenciais e nível de acesso a ferramenta precisa para acessar meus sistemas e obter dados?

  • Como os dados são transferidos entre os componentes da ferramenta?

  • A ferramenta oferece suporte à criptografia de dados em repouso e em trânsito?

  • Os dados estão centralizados em um único componente dentro ou fora do meu ambiente?

  • Quais são os requisitos de rede e firewall?

Garanta que as equipes de segurança estejam envolvidas nas primeiras conversas sobre ferramentas de descoberta.

Soberania de dados

  • Onde os dados são armazenados e processados?

  • A ferramenta usa um modelo de software como serviço (SaaS)?

  • Ele tem a possibilidade de reter todos os dados dentro dos limites do meu ambiente?

  • Os dados podem ser examinados antes de deixarem os limites da minha organização?

Considere as necessidades da sua organização em termos de requisitos de residência de dados.

Arquitetura

  • Qual infraestrutura é necessária e quais são os diferentes componentes?

  • Há mais de uma arquitetura disponível?

  • A ferramenta suporta a instalação de componentes em zonas de segurança bloqueadas?

Desempenho

  • Qual é o impacto da coleta de dados em meus sistemas?

Compatibilidade e escopo

  • A ferramenta é compatível com todos ou a maioria dos meus produtos e versões? Revise a documentação da ferramenta para verificar as plataformas suportadas em relação às informações atuais sobre seu escopo.

  • A maioria dos meus sistemas operacionais é compatível com a coleta de dados? Se você não conhece as versões do seu sistema operacional, tente restringir a lista de ferramentas de descoberta para aquelas com a maior variedade de sistemas compatíveis.

Métodos de coleta

  • A ferramenta exige a instalação de um agente em cada sistema de destino?

  • Ele oferece suporte a implantações sem agentes?

  • O agente e o sem agente fornecem os mesmos recursos?

  • Qual é o processo de coleta?

Atributos

  • Quais são os recursos disponíveis?

  • Ele pode calcular o custo total de propriedade (TCO) e a taxa estimada de execução AWS da nuvem?

  • Ele oferece suporte ao planejamento da migração?

  • Ele mede o desempenho?

  • Ele pode recomendar a AWS infraestrutura alvo?

  • Ele executa mapeamento de dependências?

  • Que nível de mapeamento de dependências ele fornece?

  • Ele fornece acesso à API? (por exemplo, ele pode ser acessado programaticamente para obter dados?)

Considere ferramentas com funções robustas de mapeamento de dependências de aplicativos e infraestrutura e aquelas que possam inferir aplicativos a partir de padrões de comunicação.

Custos

  • Qual é o modelo de licenciamento?

  • Quanto custa o licenciamento?

  • O preço é para cada servidor? É um preço diferenciado?

  • Há alguma opção com recursos limitados que pode ser licenciada sob demanda?

Normalmente, as ferramentas de descoberta são usadas em todo o ciclo de vida dos projetos de migração. Se seu orçamento for limitado, considere pelo menos 6 meses. No entanto, a ausência de ferramentas de descoberta normalmente leva a um maior esforço manual e custos internos.

Modelo de suporte

  • Quais níveis de suporte são fornecidos por padrão?

  • Há algum plano de suporte disponível?

  • Quais são os tempos de resposta a incidentes?

Serviços profissionais

  • O fornecedor oferece serviços profissionais para analisar os resultados da descoberta?

  • Eles podem abordar os elementos deste guia?

  • Existem descontos ou pacotes para ferramentas e serviços?

Recursos recomendados para a ferramenta de descoberta

Para evitar o provisionamento e a combinação de dados de várias ferramentas ao longo do tempo, uma ferramenta de descoberta deve abranger os seguintes recursos mínimos:

  • Software — a ferramenta de descoberta deve ser capaz de identificar os processos em execução e o software instalado.

  • Mapeamento de dependências — Ele deve ser capaz de coletar informações de conexão de rede e criar mapas de dependência de entrada e saída dos servidores e aplicativos em execução. Além disso, a ferramenta de descoberta deve ser capaz de inferir aplicativos de grupos de infraestrutura com base em padrões de comunicação.

  • Descoberta de perfil e configuração — Ele deve ser capaz de relatar o perfil da infraestrutura, como família de CPU (por exemplo, x86, PowerPC), número de núcleos de CPU, tamanho da memória, número de discos e tamanho e interfaces de rede.

  • Descoberta de armazenamento em rede — Ele deve ser capaz de detectar e traçar o perfil de compartilhamentos de rede a partir do armazenamento conectado à rede (NAS).

  • Desempenho — Ele deve ser capaz de relatar o pico e a média de utilização da CPU, memória, disco e rede.

  • Análise de lacunas — Deve ser capaz de fornecer informações sobre a quantidade e a fidelidade dos dados.

  • Escaneamento de rede — Ele deve ser capaz de escanear sub-redes de rede e descobrir ativos de infraestrutura desconhecidos.

  • Relatórios — Ele deve ser capaz de fornecer o status de coleta e análise.

  • Acesso à API — Deve ser capaz de fornecer meios programáticos para acessar os dados coletados.

Recursos adicionais a serem considerados

  • Análise de TCO para fornecer uma comparação de custos entre o custo local atual e o custo projetado AWS .

  • Recomendações de análise e otimização de licenciamento para sistemas Microsoft SQL Server e Oracle em cenários de rehospedagem e replataforma.

  • Recomendação da estratégia de migração (a ferramenta de descoberta pode fazer recomendações padrão do tipo R de migração com base na tecnologia atual?)

  • Exportação de inventário (para CSV ou formato similar)

  • Recomendação de dimensionamento correto (por exemplo, ela pode mapear uma AWS infraestrutura alvo recomendada?)

  • Visualização de dependências (por exemplo, o mapeamento de dependências pode ser visualizado em modo gráfico?)

  • Visualização arquitetônica (por exemplo, diagramas arquitetônicos podem ser produzidos automaticamente?)

  • Priorização de aplicativos (é possível atribuir peso ou relevância aos atributos do aplicativo e da infraestrutura para criar critérios de priorização para a migração?)

  • Planejamento de ondas (por exemplo, grupos recomendados de aplicativos e a capacidade de criar planos de ondas de migração)

  • Estimativa do custo de migração (estimativa do esforço para migrar)

Considerações de implantação

Depois de selecionar e adquirir uma ferramenta de descoberta, considere as seguintes perguntas para conduzir conversas com as equipes responsáveis pela implantação da ferramenta em sua organização:

  • Os servidores ou aplicativos são operados por terceiros? Isso pode determinar as equipes a serem envolvidas e os processos a serem seguidos.

  • Qual é o processo de alto nível para obter aprovação para implantar ferramentas de descoberta?

  • Qual é o principal processo de autenticação para acessar sistemas como servidores, contêineres, armazenamento e bancos de dados? As credenciais do servidor são locais ou centralizadas? Qual é o processo para obter credenciais? Serão necessárias credenciais para coletar dados de seus sistemas (por exemplo, contêineres, servidores virtuais ou físicos, hipervisores e bancos de dados). Obter credenciais para que a ferramenta de descoberta se conecte a cada ativo pode ser um desafio, especialmente quando esses ativos não estão centralizados.

  • Qual é o esboço das zonas de segurança da rede? Os diagramas de rede estão disponíveis?

  • Qual é o processo para solicitar regras de firewall nos data centers?

  • Quais são os contratos de nível de serviço (SLAs) de suporte atuais em relação às operações do data center (instalação de ferramentas de descoberta, solicitações de firewall)?