Execute uma VM Linux no Azure

Azure Backup
Azure Bastion
Armazenamento de Blobs do Azure
Azure Resource Manager
Armazenamento do Azure
Máquinas Virtuais do Microsoft Azure

Provisionar uma máquina virtual (VM) no Azure requer componentes adicionais além da própria VM, incluindo recursos de rede e armazenamento. Este artigo mostra as melhores práticas para correr uma VM Linux segura no Azure.

Arquitetura

Diagrama que mostra uma VM Linux em Azure.

Descarregue um ficheiro Visio desta arquitetura.

Workflow

Este exemplo mostra uma implementação básica usando uma única máquina virtual com os componentes necessários. A máquina virtual pode executar cargas de trabalho, é gerível e pode comunicar com a internet pública. Foi concebido para evitar a exposição direta a ameaças externas.

  • Quaisquer cargas de trabalho a correr na máquina virtual não são expostas externamente, sendo acessíveis apenas a partir da mesma rede ou de uma rede virtual peered, como numa configuração hub and spoke.
  • O acesso de gestão à máquina virtual é demonstrado através do Azure Bastion via Secure Shell (SSH), e não é permitido diretamente a partir da internet pública.
  • O acesso externo à internet de saída é fornecido através do Gateway de Tradução de Endereços de Rede (NAT) e do seu endereço IP Público associado.

Componentes

Grupo de recursos

Um grupo de recursos é um contentor lógico que contém recursos Azure relacionados. Em geral, agrupe os recursos com base em seu tempo de vida e quem irá gerenciá-los.

Implementar recursos estreitamente associados que partilham o mesmo ciclo de vida no mesmo grupo de recursos. Os grupos de recursos permitem-lhe implementar e monitorizar recursos como um grupo e monitorizar os custos de faturação por grupo de recursos. Você também pode excluir recursos como um conjunto, o que é útil para implantações de teste. Atribua nomes significativos aos recursos para simplificar a localização de um recurso específico e compreender a sua função. Para mais informações, consulte Convenções de Nomenclatura Recomendadas para Recursos Azure.

Máquina virtual

Pode provisionar uma VM a partir de uma lista de imagens publicadas, ou a partir de uma imagem gerida personalizada ou ficheiro de disco rígido virtual (VHD) carregado para o armazenamento Blob do Azure. O Azure suporta a execução de várias distribuições Linux populares, incluindo Debian, Red Hat Enterprise Linux (RHEL) e Ubuntu. Para mais informações, veja Azure e Linux.

Azure fornece muitos tamanhos diferentes de máquinas virtuais. Se mover uma carga de trabalho existente para o Azure, comece pelo tamanho da VM que corresponde mais aos seus servidores locais. Em seguida, meça o desempenho da sua carga de trabalho real em termos de CPU, memória e operações de entrada/saída de disco por segundo (IOPS) e ajuste o tamanho conforme necessário.

De um modo geral, escolha uma região do Azure que esteja mais próxima dos seus utilizadores internos ou clientes. Nem todos os tamanhos de VM estão disponíveis em todas as regiões. Para obter mais informações, veja Serviços por região. Para uma lista dos tamanhos de VM disponíveis numa região específica, execute o seguinte comando a partir da CLI do Azure:

az vm list-sizes --location <location>

Para informações sobre como escolher uma imagem de VM publicada, veja Encontrar imagens de VM Linux.

Discos

Para o melhor desempenho de I/O de disco, recomendamos SSDs Premium, que armazenam dados em discos de estado sólido (SSDs). O custo tem por base a capacidade do disco aprovisionado. O IOPS e o débito (ou seja, a velocidade de transferência de dados) também dependem do tamanho do disco, pelo que, quando aprovisionar um disco, considere os três fatores (capacidade, IOPS e débito). Os SSDs premium apresentam free bursting que, combinado com uma compreensão dos padrões de carga de trabalho, oferece uma estratégia eficaz de seleção de SKU e otimização de custos para a infraestrutura IaaS. Isto permite um desempenho elevado sem sobre-provisionamento excessivo e minimizando o custo da capacidade não utilizada.

Nota

Atualmente, os discos Premium SSD v2 e Ultra só podem ser usados para discos de dados. Não são suportados para discos do sistema operativo.

Managed Disks simplifica a gestão de discos ao tratar do armazenamento por ti. Discos geridos não exigem uma conta de armazenamento. Você especifica o tamanho e o tipo de disco e ele é implantado como um recurso altamente disponível. Os Managed disks também oferecem otimização de custos, proporcionando o desempenho desejado sem necessidade de sobreprovisionamento, tendo em conta padrões de carga de trabalho flutuantes e minimizando a capacidade provisionada não utilizada.

Por defeito, o disco do sistema operativo é um disco gerido armazenado em Armazenamento de Discos do Azure, pelo que persiste mesmo quando a máquina anfitriã está fora de serviço. No caso de cargas de trabalho sem estado, onde se deseja provisão rápida e sem persistência do sistema operativo, recomendam-se discos efémeros do sistema operativo . Estes discos colocam a imagem do SO no armazenamento local do host da VM em vez do Armazenamento do Azure remoto, reduzindo a latência de leitura, acelerando a reimagem e eliminando o custo gerido do disco. No entanto, todos os dados num disco efémero do sistema operativo são perdidos em eventos de paragem (desalocar), reimagem ou manutenção do host. Os discos efémeros do sistema operativo não suportam snapshots nem Azure Backup. Use discos efémeros do sistema operativo apenas quando as VMs estiverem completamente reimplantáveis a partir da automação.

Muitas imagens Linux não configuram espaço de swap por padrão. Se a tua carga de trabalho precisar de swap, cria-a no disco temporário usando cloud-init em vez de no disco do sistema operativo ou num disco de dados.

Recomendamos a criação de um ou mais discos de dados para os dados da aplicação. Os discos de dados são discos geridos persistentes, suportados pelo Armazenamento do Azure.

Quando crias um disco, não está formatado. Aceda à VM para formatar o disco. No shell do Linux, os discos de dados são apresentados como /dev/sdc, /dev/sdd, e letras posteriores na série. Pode executar lsblk para listar os dispositivos de bloqueio, incluindo os discos. Para utilizar um disco de dados, crie uma partição e um sistema de ficheiros e monte o disco. Por exemplo:

# Create a partition.

sudo fdisk /dev/sdc     # Enter 'n' to partition, 'w' to write the change.

# Create a file system.

sudo mkfs -t ext3 /dev/sdc1

# Mount the drive.

sudo mkdir /data1
sudo mount /dev/sdc1 /data1

Quando adiciona um disco de dados, é-lhe atribuído um número de unidade lógica (LUN). Opcionalmente, você pode especificar a ID do LUN — por exemplo, se estiver substituindo um disco e quiser manter a mesma ID do LUN ou se tiver um aplicativo que procure um ID de LUN específico. Contudo, lembre-se de que os IDs de LUNs têm de ser exclusivos para cada disco.

Pode querer alterar o agendador de I/O para otimizar o desempenho em SSDs ao usar discos Armazenamento Premium. Uma recomendação comum é usar o agendador No Operation (NOOP) para SSDs, mas deve usar uma ferramenta como o iostat para monitorizar o desempenho da I/O do disco para a sua carga de trabalho.

Muitas VMs são criadas com um disco temporário, que é armazenado numa unidade física na máquina anfitriã. É não guardado em Armazenamento do Azure e pode ser eliminado durante reinícios e outros eventos do ciclo de vida da VM. Utilize este disco apenas para dados temporários, tais como ficheiros de paginação ou de troca. Para as VMs do Linux, o disco temporário é /dev/disk/azure/resource-part1 e está montado em /mnt/resource ou em /mnt.

Rede

Os componentes de rede incluem os seguintes recursos:

  • Rede virtual. Cada VM é implementada numa virtual network que é segmentada em sub-redes.

  • Interface de rede (NIC). A NIC permite que a VM comunique com a virtual network. Se precisar de múltiplas NICs para a sua VM, é definido um número máximo de NIC para cada tamanho da VM.

  • Endereço IP público. Um endereço IP público pode ser usado para comunicar com a VM a partir de fora Azure via SSH. No entanto, isto é desencorajado, pois representa um potencial risco de segurança.

    Warning

    Anexar diretamente um endereço IP público representa um potencial risco de segurança. Deve ser feito apenas em circunstâncias extremas e apenas em conjunto com outros métodos de segurança, como filtrar tráfego usando Grupos de Segurança de Rede.

    Para acesso de gestão a uma máquina virtual, recomendamos que utilize o Azure Bastion ou internamente quando ligado através de uma VPN ou Azure ExpressRoute.

    • O endereço IP público pode ser dinâmico ou estático. Por predefinição, é dinâmico. Reserve um endereço IP estático se precisar de um endereço IP fixo que não mude — por exemplo, se precisar de criar um registo DNS 'A' ou adicionar o endereço IP a uma lista segura.
    • Também pode criar um nome de domínio completamente qualificado (FQDN) para o endereço IP. Depois, pode registar um registo CNAME no DNS que aponte para o FQDN. Para mais informações, veja Criar um nome de domínio totalmente qualificado no portal Azure.

  • Grupo de Segurança de Rede (NSG). Os grupos de segurança de rede são usados para permitir ou negar tráfego de rede a VMs e/ou sub-redes. Podem estar associadas às sub-redes ou a placas de interface de rede (NICs) individuais ligadas a VMs.

    • Todos os NSGs contêm um conjunto de regras predefinidas, incluindo uma regra que bloqueia todo o tráfego de entrada da Internet. Não é possível eliminar as regras predefinidas, mas estas podem ser substituídas por outras. Por exemplo, para permitir o tráfego da Internet, crie regras que permitam o tráfego de entrada para portas específicas — como a porta 443 para HTTPS.

  • Azure Gateway de Tradução de Endereços de Rede (NAT)Os gateways de Tradução de Endereços de Rede (NAT) permitem que todas as instâncias de uma sub-rede privada se conectem à saída à internet, mantendo-se totalmente privadas. Somente os pacotes que chegam como pacotes de resposta a uma conexão de saída podem passar por um gateway NAT. Não são permitidas ligações de entrada não solicitadas a partir da Internet.

    Nota

    Para melhorar a segurança padrão, o acesso implícito à Internet para saída está a ser descontinuado para todas as novas redes virtuais. A conectividade à internet de saída terá de ser explicitamente configurada através do uso de outros recursos, como NAT Gateways, Azure Standard Load Balancers ou firewalls. Consulte Acesso de saída predeterminado em Azure para mais detalhes.

  • Azure Bastion.Azure Bastion é uma solução totalmente gerida de plataforma como serviço que fornece acesso seguro a VMs através de endereços IP privados. Com essa configuração, as VMs não precisam de um endereço IP público que as exponha à internet, o que aumenta sua postura de segurança. O Azure Bastion fornece conectividade segura Ambiente de Trabalho Remoto Protocol (RDP) ou SSH às suas VMs diretamente através da Transport Layer Security (TLS) através de vários métodos, incluindo o portal Azure ou clientes nativos SSH ou RDP.

Operações

SSH. Antes de criar uma VM do Linux, gere um par de chaves públicas-privadas de RSA 2048 bits. Utilize o ficheiro de chave pública quando criar a VM. Para mais informações, veja Como Usar SSH com Linux e Mac em Azure.

Diagnósticos. Permitir monitorização e diagnósticos, incluindo métricas básicas de estado, registos da infraestrutura de diagnóstico e diagnósticos de arranque. Os diagnósticos de arranque poderão ajudá-lo a diagnosticar falhas no arranque se a VM não estiver no estado de arranque. Cria uma conta no Armazenamento do Azure para armazenar os registos. Uma conta padrão de armazenamento localmente redundante (LRS) é suficiente para os registos de diagnóstico. Para mais informações, consulte Ativar monitorização e diagnóstico.

Disponibilidade. A sua VM pode ser afetada por manutenção planeada ou inatividade não planeada. Pode utilizar registos de reinício de VM para determinar se o reinício de uma VM foi provocado por uma manutenção planeada. Para maior disponibilidade, implemente múltiplas VMs em zonas de disponibilidade dentro de uma região. Isto proporciona um acordo de nível de serviço (SLA) mais elevado. Quando as zonas de disponibilidade não são suportadas, os conjuntos de disponibilidade podem ajudar a fornecer proteção contra falhas ou atualizações do host. No entanto, as zonas de disponibilidade são a opção recomendada sempre que possível.

Backups. Para proteger contra perda acidental de dados, use o serviço Azure Backup para fazer backup das suas VMs no armazenamento. Dependendo da região, podes usar armazenamento geo-redundante ou redundante por zona para backups. O Azure Backup fornece backups consistentes com a aplicação. Para cargas de trabalho sensíveis ao desempenho ou distribuições Linux especializadas que não suportam agentes de backup tradicionais, use a funcionalidade de cópia de segurança consistente em caso de falha, multi-disco e sem agentes, que permite a proteção automática de cópias de segurança sem afetar o desempenho das aplicações.

Desligar uma VM. Azure faz uma distinção entre os estados "parado" e "desalocado". Quando o estado da VM é "parado", há cobrança, mas não quando o estado é "desalocada". No portal Azure, o botão Stop desaloca a VM. Se encerrar através do SO enquanto estiver com sessão iniciada, a VM será parada, mas não será desalocada, portanto, os custos continuarão a ser cobrados.

Eliminar uma VM. Se você excluir uma VM, terá a opção de excluir ou manter seus discos. Isto significa que pode eliminar em segurança a VM sem perder dados. No entanto, você ainda será cobrado pelos discos. Podes eliminar discos geridos como qualquer outro recurso do Azure. Para impedir a eliminação acidental, utilize um bloqueio de recursos para bloquear o grupo de recursos inteiro ou bloqueie recursos individuais, como a VM.

Alternatives

  • Conjuntos de escala de máquinas virtuais – cargas de trabalho críticas para as operações empresariais nunca devem depender de uma única máquina virtual. Os conjuntos de escala proporcionam a capacidade de distribuir cargas de trabalho entre nós de computação e podem escalar para fora em períodos de maior tráfego ou escalar para dentro, quando o tráfego é mínimo, para ajudar a minimizar custos.

  • Balanceador de Carga do Azure seria útil para fornecer balanceamento de carga entre múltiplas máquinas virtuais ou um conjunto de escala de máquina virtual. Pode também ser usado como alternativa a um NAT Gateway para permitir o acesso a uma carga de trabalho a partir da internet, ao mesmo tempo que suporta o acesso de saída.

  • Application Gateway forneceria funcionalidade de balanceamento de carga ao Balanceador de Carga do Azure para cargas de trabalho HTTP/HTTPS dentro de uma região Azure.

  • Para uma implementação ao nível empresarial, veja arquitetura base das Máquinas Virtuais do Azure numa zona de apresentação Azure.

Detalhes do cenário

No diagrama acima, este cenário seria útil para fornecer uma carga de trabalho não crítica que seja útil para utilizadores apenas internos.

Potenciais casos de utilização

Uma única implementação de VM poderia ser usada para alojar uma aplicação simples que não precisa de ser exposta à internet e pode suportar algum tempo de inatividade. Por exemplo, isto pode ser uma aplicação básica de relatórios internos.

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para mais informações, consulte Microsoft Azure Well-Architected Framework.

Reliability

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Como esta arquitetura é apenas um exemplo simples usando uma única máquina virtual, tem um nível mínimo de fiabilidade. Qualquer problema com a própria máquina virtual ou com o host onde está a correr causará uma falha, resultando em quaisquer cargas de trabalho alojadas indisponíveis. Para qualquer carga de trabalho que exija maior disponibilidade, devem ser implementadas múltiplas máquinas virtuais que contenham a mesma carga de trabalho, com essas instâncias atrás de uma solução de balanceamento de carga adequada. Se estas estiverem na mesma região, essas VMs devem ser implementadas em várias zonas de disponibilidade (onde suportadas) e adicionadas ao backend de um Azure Balanceador de Carga Standard ou de um Application Gateway se a carga de trabalho for baseada em HTTP/HTTPS. Isto permite que a carga de trabalho continue disponível caso uma única máquina virtual no backend esteja fora de serviço.

Os conjuntos de escala de máquinas virtuais são outra opção para ajudar a simplificar a gestão de cargas de trabalho que envolvem múltiplos nós e necessitam da capacidade de escalar automaticamente o número de instâncias para cima ou para baixo, dependendo de várias métricas, por exemplo, o consumo de CPU e/ou memória.

Alta Disponibilidade/Recuperação de Desastres (HA/DR)

Para um "raio de explosão" reduzido, o trabalho deve ser distribuído em múltiplas regiões e aproveitar a orientação Azure Landing Zone. Pode estar numa configuração Ativo-Passivo, com transição para a região secundária caso a região primária se torne indisponível, ou numa arquitetura Ativo-Ativo onde ambas as regiões fornecem tráfego aos consumidores. Para um exemplo, veja Aplicação web Multi-layer construída para HA/DR em Próximos Passos abaixo.

O exemplo desse artigo utiliza Azure Site Recovery para replicar os discos de máquinas virtuais individuais para uma região secundária, onde o Site Recovery pode ser usado para efetuar a transferência dessas máquinas virtuais para a região secundária com um Objetivo de Ponto de Recuperação (RPO) e Objetivo de Tempo de Recuperação (RTO) baixos.

Certifica-te de avaliar a tua arquitetura para cumprir os requisitos de HA/DR em todos os componentes, não apenas nas máquinas virtuais. Em todas estas decisões, incluem-se considerações como redes, identidade e dados.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Use Microsoft Defender para a Cloud para obter uma visão central do estado de segurança dos seus recursos Azure. O Defender para a Cloud monitoriza potenciais problemas de segurança e fornece uma imagem abrangente do estado de funcionamento da segurança da sua implementação. O Defender para a Cloud é configurado por subscrição do Azure. Ative a recolha de dados de segurança conforme descrito em Conecte as suas subscrições de Azure. Quando a coleta de dados está habilitada, o Defender para a Cloud verifica automaticamente todas as VMs criadas sob essa assinatura.

Gestão de patches. Se ativado, o Defender para a Cloud verifica se faltam atualizações críticas e de segurança.

Antimalware. Se estiver ativado, o Defender para a Cloud verifica se o software anti-malware está instalado. Também pode usar o Defender para a Cloud para instalar software anti-malware a partir do portal do Azure.

Controlo de acessos. Use Azure controle de acesso baseado em funções (Azure RBAC) para controlar o acesso aos recursos da Azure. O Azure RBAC permite-lhe atribuir funções de autorização aos membros da sua equipa DevOps. Por exemplo, o papel Leitor pode visualizar recursos do Azure mas não criar, gerir ou eliminar os recursos. Algumas permissões são específicas para um tipo de recurso Azure. Por exemplo, o papel de Contribuidor de Máquina Virtual pode reiniciar ou desalocar uma VM, redefinir a palavra-passe do administrador e criar uma nova VM. Outros papéis incorporados que podem ser úteis para esta arquitetura incluem DevTest Labs User e Network Contributor.

Nota

O Azure RBAC não limita as ações que um utilizador com sessão iniciada numa VM pode realizar. Estas permissões são determinadas pelo tipo de conta no SO convidado.

Logs de auditoria. Use os registos de auditoria para ver ações de provisionamento e outros eventos da VM.

Encriptação de dados. Ative a encriptação no host para conseguir encriptação de ponta a ponta para os dados da sua VM, incluindo discos temporários e caches de disco. A encriptação no host trata da encriptação na infraestrutura do host da VM e não consome recursos da CPU da VM, ao contrário da encriptação baseada em convidados. Pode usar chaves geridas pelo cliente com Azure Key Vault para sistemas operativos persistentes e discos de dados. Os discos temporários e os discos efémeros do sistema operativo são encriptados com chaves geridas pela plataforma. Verifique se o tamanho da VM selecionado suporta encriptação no host antes de provisionar a VM.

Otimização de Custos

A Otimização de Custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

Há várias opções para tamanhos de VM, dependendo do uso e da carga de trabalho. A gama inclui a opção mais económica da série Bs até às mais recentes VMs de GPU otimizadas para machine learning. Para informações sobre as opções disponíveis, consulte preços das VMs Linux no Azure.

Para cargas de trabalho previsíveis, use o Azure Reservations e o Azure savings plan for compute com contrato de um ou três anos, e obtenha poupanças significativas em preços de pagamento conforme o uso. Para cargas de trabalho sem tempo previsível de conclusão ou consumo de recursos, considere a opção Pagar à medida que usa.

Use VMs Azure Spot para executar cargas de trabalho que podem ser interrompidas e não exigem ser concluídas dentro de um prazo ou de um SLA predeterminado. O Azure implementa VMs Spot se houver capacidade disponível e despeja quando precisa de recuperar essa capacidade. Os custos associados às virtual machines Spot são significativamente mais baixos. Considere VMs Spot para estas tarefas:

  • Cenários de computação de alto desempenho, tarefas de processamento em lotes ou aplicações de composição visual.
  • Ambientes de teste, incluindo integração contínua e cargas de trabalho de entrega contínua.
  • Aplicações sem estado de grande escala.

Use a Calculadora de Preços Azure para estimar custos.

Para mais informações, consulte a secção de custos em Microsoft Azure Well-Architected Framework.

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.

Use modelos Infrastructure-as-Code (IaC) para provisionar recursos do Azure e as suas dependências. Estes podem ser escritos usando modelos Bicep, modelos Azure Resource Manager (modelos ARM) ou Terraform, dependendo da sua preferência e das escolhas de ferramentas estabelecidas. Estes modelos permitem um processo de Integração Contínua/Implantação Contínua (CI/CD) como parte de uma metodologia automatizada de implementação para implementar e configurar recursos. Esta abordagem permite a versionação das arquiteturas e garante consistência entre os ambientes, bem como reforça a reprodutibilidade, segurança e conformidade.

Para ajudar a monitorizar e diagnosticar problemas, assegure que os registos de diagnóstico estão ativados nos seus recursos e disponibilizados ao Azure Monitor para ajudar na análise e otimização dos seus recursos. Estes registos podem ser usados para implementar alertas e notificações de eventos críticos e, em alguns casos, permitem a remediação automática ou o registo de um ticket no seu sistema de Gestão de Serviços de TI (ITSM).

Eficiência de desempenho

A Performance Efficiency foca-se na otimização das cargas de trabalho na cloud para velocidade, capacidade de resposta e escalabilidade. Para mais informações, consulte a lista de verificação de revisão de design para Eficiência de Desempenho.

Alguns dos principais objetivos incluem minimizar a latência, garantir arquiteturas escaláveis, otimizar a utilização de recursos e melhorar continuamente o desempenho do sistema.

Como mencionado acima, as decisões tomadas relativamente à arquitetura da carga de trabalho, SKU de VM e configurações do disco podem ter um grande impacto no desempenho da sua carga de trabalho. Fazer as escolhas corretas pode evitar ter de rearquitetar a solução no futuro, acrescentando flexibilidade e poupando custos.

Certifique-se de considerar estes pontos ao desenvolver a sua arquitetura:

  • Use conjuntos de escalas de máquinas virtuais se a carga de trabalho tiver uma carga dinâmica. Por exemplo, escala em períodos de grande volume de tráfego e depois reduz quando o tráfego diminui. Isto garantirá poder de processamento adequado, mantendo os custos sob controlo.
  • Escolha as VMs e SKUs de disco apropriadas para cumprir os IOPS exigidos durante o processamento. Configure o cache para melhorar ainda mais o desempenho.
  • Se a sua carga de trabalho for invulgarmente sensível à latência, utilize Grupos de Colocação por Proximidade (PPGs) para garantir que várias VMs estão fisicamente próximas umas das outras para obter melhor desempenho. Os PPGs também podem ser usados em conjunto com conjuntos de disponibilidade para combinar baixa latência com alta disponibilidade num único centro de dados físico.
  • Sempre que possível, permita a rede acelerada para minimizar a latência entre componentes.
  • Projetar arquitetura de rede para minimizar saltos desnecessários.
  • Use o Azure Monitor, VM Insights e outras ferramentas para analisar continuamente métricas e criar bases de desempenho atualizadas. Use a informação de desempenho para determinar onde implementar alterações e depois teste contra essas linhas de base.

Contributors

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Próximos passos