Implantação e teste para cargas de trabalho críticas no Azure

Implantações com falha e versões errôneas são causas comuns para interrupções de aplicativo. Sua abordagem para implantação e teste desempenha um papel crítico na confiabilidade geral de um aplicativo crítico.

A implantação e o teste devem formar a base para todas as operações de aplicativo e infraestrutura para garantir resultados consistentes para cargas de trabalho críticas. Esteja preparado para desdobrar semanalmente, diariamente ou com mais frequência. Projete seus pipelines de CI/CD (integração contínua e implantação contínua) para dar suporte a essas metas.

A estratégia deve implementar:

• Teste de pré-lançamento rigoroso. As atualizações não devem introduzir defeitos, vulnerabilidades ou outros fatores que possam comprometer a integridade do aplicativo.

• Implantações transparentes. Deve ser possível distribuir atualizações a qualquer momento sem afetar os usuários. Os usuários devem poder continuar suas interações com o aplicativo sem interrupção.

• Operações altamente disponíveis. Processos e ferramentas de implantação e teste devem estar altamente disponíveis para dar suporte à confiabilidade geral do aplicativo.

• Processos de implantação consistentes. Os mesmos artefatos e processos de aplicativo devem ser usados para implantar a infraestrutura e o código do aplicativo em ambientes diferentes. A automação de ponta a ponta é obrigatória. As intervenções manuais devem ser evitadas porque podem introduzir riscos de confiabilidade.

Essa área de design fornece recomendações sobre como otimizar os processos de implantação e teste com o objetivo de minimizar o tempo de inatividade e manter a integridade e a disponibilidade do aplicativo.

Implantação sem tempo de inatividade

Exiba o vídeo a seguir para obter uma visão geral da implantação de tempo de inatividade zero.

Alcançar implantações de tempo de inatividade zero é uma meta fundamental para aplicativos críticos. Seu aplicativo precisa estar disponível o dia todo, todos os dias, mesmo quando novas versões são lançadas durante o horário comercial. Invista seus esforços antecipadamente para definir e planejar processos de implantação, a fim de conduzir decisões de design importantes, como tratar os recursos como efêmeros.

Para obter a implantação de tempo de inatividade zero, implante uma nova infraestrutura ao lado da infraestrutura existente, teste-a minuciosamente, faça a transição do tráfego do usuário final e, em seguida, desative a infraestrutura anterior. Outras práticas, como a arquitetura de unidade de escala, também são fundamentais.

As implementações de referência doMission-Critical Online e do Azure Mission-Critical Connected ilustram essa abordagem de implantação, conforme mostrado neste diagrama:

Ambientes do aplicativo

Exiba o vídeo a seguir para obter uma visão geral das recomendações para ambientes de aplicativo.

Você precisa de vários tipos de ambientes para validar e preparar operações de implantação. Os tipos têm diferentes funcionalidades e ciclos de vida. Alguns ambientes podem refletir o ambiente de produção e serem de longa duração, e outros podem ter curta duração e ter menos capacidades do que a produção. A configuração desses ambientes no início do ciclo de desenvolvimento ajuda a garantir agilidade, separação de ativos de produção e pré-produção e testes detalhados de operações antes da liberação para o ambiente de produção. Todos os ambientes devem refletir o ambiente de produção o máximo possível, embora você possa aplicar simplificações a ambientes mais baixos, conforme necessário. Este diagrama mostra uma arquitetura crítica:

Há algumas considerações comuns:

• Os componentes não devem ser compartilhados entre ambientes. As possíveis exceções são dispositivos de segurança downstream, como firewalls e locais de origem para dados de teste sintéticos.

• Todos os ambientes devem usar artefatos de IaC (infraestrutura como código), como o Terraform ou modelos do ARM (Azure Resource Manager).

Ambientes de desenvolvimento

Exiba o vídeo a seguir para obter informações sobre ambientes de desenvolvimento efêmeros e validação automatizada de recursos.

Considerações sobre o design

• Funcionalidades. Requisitos mais baixos de confiabilidade, capacidade e segurança são aceitáveis para ambientes de desenvolvimento.

• Ciclo de vida. Os ambientes de desenvolvimento devem ser criados conforme necessário e existirem por um curto período de tempo. Ciclos de vida mais curtos ajudam a evitar o descompasso de configuração da base de código e a reduzir os custos. Além disso, os ambientes de desenvolvimento geralmente compartilham o ciclo de vida de um branch de funcionalidade.

• Densidade. Equipes precisam de vários ambientes para dar suporte ao desenvolvimento paralelo de funcionalidades. Eles podem coexistir em uma única assinatura.

Recomendações de design

• Mantenha o ambiente em uma subscrição dedicada com a configuração de contexto para fins de desenvolvimento.

• Utilize um processo automatizado para implantar código de um ramo de funcionalidade em um ambiente de desenvolvimento.

Ambientes de teste ou homologação

Esses ambientes são usados para teste e validação. Muitos ciclos de teste são executados para garantir a implantação sem bugs na produção. Os testes apropriados para uma carga de trabalho crítica são descritos na seção de validação e teste contínuas .

Considerações sobre o design

• Funcionalidades. Esses ambientes devem refletir o ambiente de produção para confiabilidade, capacidade e segurança. Na ausência de uma carga de produção, use uma carga de usuário sintética para fornecer métricas realistas e dados valiosos para modelagem de saúde.

• Ciclo de vida. Esses ambientes são de curta duração. Elas devem ser destruídas após a conclusão das validações de teste.

• Densidade. Você pode executar muitos ambientes independentes em uma assinatura. Você também deve considerar o uso de vários ambientes, cada um em uma assinatura dedicada.

Recomendações de design

• Verifique se pelo menos um ambiente de preparo reflete totalmente a produção para habilitar testes e validação semelhantes à produção. A capacidade dentro desse ambiente pode ser flexível com base na execução de atividades de teste.

• Gere carga de usuário sintética para fornecer um caso de teste realista para alterações em um dos ambientes.

  Observação

  A implementação de referência do Mission Critical Online fornece um exemplo de gerador de carga de usuário.

• Defina o número de ambientes de preparo e suas finalidades dentro do ciclo de desenvolvimento e lançamento.

Ambientes de produção

Considerações sobre o design

• Funcionalidades. Os níveis mais altos de confiabilidade, capacidade e funcionalidade de segurança para o aplicativo são necessários.

• Ciclo de vida. Embora o ciclo de vida da carga de trabalho e da infraestrutura permaneça o mesmo, todos os dados, incluindo monitoramento e registro em log, precisam de gerenciamento especial. Por exemplo, o gerenciamento é necessário para backup e recuperação.

• Densidade. Para alguns aplicativos, talvez você queira considerar o uso de ambientes de produção diferentes para atender a diferentes clientes, usuários ou funcionalidades de negócios.

Recomendações de design

Tenha um limite de governança claro para a produção e ambientes mais baixos. Coloque cada tipo de ambiente em uma assinatura dedicada para atingir essa meta. Essa segmentação garante que a utilização de recursos em ambientes inferiores não afete as cotas de produção. Assinaturas dedicadas também definem limites de acesso.

Implantações efêmeras azul/verde

Um modelo de implantação azul/verde requer pelo menos duas implantações idênticas. A implementação azul é a versão ativa que atende ao tráfego de usuários em produção. A implantação verde é a nova que foi preparada e testada para receber tráfego. Depois que a implantação verde for concluída e testada, o tráfego será direcionado gradualmente de azul para verde. Se a transferência de carga for bem-sucedida, a implantação verde se tornará a nova implantação ativa. A antiga implantação azul pode então ser desativada por meio de um processo gradual. No entanto, se houver problemas na nova implantação, ela poderá ser anulada e o tráfego poderá permanecer na implantação azul antiga ou ser redirecionado para ela.

O Mission-Critical do Azure recomenda uma abordagem de implantação azul/verde em que a infraestrutura e os aplicativos são implantados juntos como parte de um carimbo de implantação. Portanto, distribuir uma alteração na infraestrutura ou aplicativo sempre resulta em uma implantação verde que contenha ambas as camadas. Essa abordagem permite que você teste e valide totalmente o efeito da alteração na infraestrutura e no aplicativo de ponta a ponta antes de redirecionar o tráfego do usuário para ela. A abordagem aumenta a confiança na liberação de alterações e permite atualizações sem tempo de inatividade porque as compatibilidades com dependências a jusante, como a plataforma do Azure, provedores de recursos e módulos IaC podem ser verificadas.

Considerações sobre o design

• Recursos de tecnologia. Aproveite os recursos de implantação internos nos serviços do Azure. Por exemplo, o Serviço de Aplicativo do Azure fornece slots de implantação secundários que podem ser trocados após uma implantação. Com o AKS (Serviço de Kubernetes do Azure), você pode usar uma implantação de pod separada em cada nó e atualizar a definição de serviço.

• Duração da implantação. A implantação pode levar mais tempo para ser concluída porque o carimbo contém a infraestrutura e o aplicativo, em vez de apenas o componente alterado. Isso, no entanto, é aceitável porque o risco de todos os componentes não funcionarem conforme o esperado substitui as preocupações de tempo.

• Impacto no custo. Há um custo adicional devido às duas implantações lado a lado, que devem coexistir até que a implantação seja concluída.

• Transição de tráfego. Depois que a nova implantação for validada, o tráfego deverá ser transferido do ambiente azul para o verde. Essa transição requer a orquestração do tráfego de usuário entre os ambientes. A transição deve ser totalmente automatizada.

• Ciclo de vida. Os selos de implantação críticos devem ser considerados efêmeros. O uso de selos de curta duração cria um novo início a cada vez, antes que os recursos sejam provisionados.

Recomendações de design

• Adote uma abordagem de implantação azul/verde para liberar todas as alterações de produção. Implante toda a infraestrutura e o aplicativo sempre, para qualquer tipo de alteração, para obter um estado consistente e um tempo de inatividade zero. Embora você possa reutilizar ambientes, não recomendamos isso para cargas de trabalho críticas. Trate cada selo de implantação regional como efêmero, com um ciclo de vida vinculado ao ciclo de vida de uma única versão.

• Use um balanceador de carga global, como o Azure Front Door, para orquestrar a transição automatizada do tráfego de usuário entre os ambientes azul e verde.

• Para transferir o tráfego, adicione um ponto de extremidade de back-end verde que utilize um peso de volume baixo, como 10% do tráfego. Depois de verificar se o baixo volume de tráfego na implantação verde funciona e fornece a integridade esperada do aplicativo, aumente gradualmente o tráfego. Ao fazer isso, aplique um curto período de ramp-up para detectar falhas que podem não ser imediatamente aparentes.

  Depois que todo o tráfego for transferido, remova o back-end azul das conexões existentes. Por exemplo, remova o back-end do serviço de balanceador de carga global, escorra filas e desanexe outras associações. Isso ajuda a otimizar o custo de manutenção da infraestrutura de produção secundária e garantir que novos ambientes estejam livres de descompasso de configuração.

  Neste ponto, desative o ambiente azul antigo e agora inativo. Para a próxima implantação, repita o processo com azul e verde invertidos.

Implantação restrita a assinatura

Dependendo dos requisitos de escala do seu aplicativo, você pode precisar de várias assinaturas de produção para servir como unidades de escala.

Exiba o vídeo a seguir para obter uma visão geral das recomendações para definir o escopo das assinaturas de um aplicativo de missão crítica.

Considerações sobre o design

• Escalabilidade. Para cenários de aplicativo de alta escala com volumes significativos de tráfego, projete a solução para dimensionar em várias assinaturas do Azure para que os limites de escala de uma única assinatura não restrinjam a escalabilidade.

  Importante

  O uso de várias assinaturas requer complexidade adicional de CI/CD, que deve ser gerenciada adequadamente. Portanto, recomendamos várias assinaturas apenas em cenários de escala extrema, em que os limites de uma única assinatura provavelmente se tornarão uma limitação.

• Limites de ambiente. Implante ambientes de produção, desenvolvimento e teste em assinaturas separadas. Essa prática garante que ambientes inferiores não contribuam para limites de escala. Também reduz o risco de atualizações de ambiente de menor nível poluírem a produção, fornecendo um limite claro de gerenciamento e identidade.

• de Governança . Quando você precisar de várias assinaturas de produção, considere usar um grupo de gerenciamento de aplicativos dedicado para simplificar a atribuição de políticas por meio de uma estrutura de agregação de políticas.

Recomendações de design

• Implante cada selo de implantação regional em uma assinatura dedicada para garantir que os limites de assinatura se apliquem somente no contexto de um único carimbo de implantação e não em todo o aplicativo. Quando apropriado, você pode considerar o uso de vários selos de implantação em uma única região, mas deve implantá-los em assinaturas independentes.

• Coloque recursos compartilhados globais em uma assinatura dedicada para habilitar a implantação de assinatura regional consistente. Evite usar uma implantação especializada para a região primária.

Validação e testes contínuos

O teste é uma atividade crítica que permite validar totalmente a integridade do código e da infraestrutura do aplicativo. Mais especificamente, o teste permite que você atenda aos seus padrões de confiabilidade, desempenho, disponibilidade, segurança, qualidade e escala. O teste deve ser bem definido e aplicado como parte do design do aplicativo e da estratégia de DevOps. O teste é uma preocupação importante durante o processo do desenvolvedor local (o loop interno) e como parte do ciclo de vida completo do DevOps (o loop externo), que é quando o código começa no caminho dos processos de pipeline de lançamento em direção ao ambiente de produção.

Exiba o vídeo a seguir para obter uma visão geral da validação e do teste contínuos.

Esta seção se concentra no teste de loop externo. Ele descreve vários tipos de testes.

Considerações sobre o design

• Automação. O teste automatizado é essencial para validar as alterações de aplicativo ou de infraestrutura de maneira oportuna e repetível.

• Ordem de teste. A ordem na qual os testes são realizados é uma consideração crítica devido a várias dependências, como a necessidade de ter um ambiente de aplicativo em execução. A duração do teste também influencia a ordem. Os testes com tempos de execução mais curtos devem ser executados no início do ciclo, quando possível, para aumentar a eficiência do teste.

• Limites de escalabilidade. Os serviços do Azure têm limites flexíveis e rígidos diferentes. Considere usar o teste de carga para determinar se um sistema corre o risco de excedê-los durante a carga de produção esperada. O teste de carga também pode ser útil para definir os limites apropriados para dimensionamento automático. Para serviços que não dão suporte ao dimensionamento automático, o teste de carga pode ajudá-lo a ajustar os procedimentos operacionais automatizados.

  A incapacidade de componentes do sistema, como componentes de rede ativos/passivos ou bancos de dados, de dimensionar adequadamente pode ser restritiva. O teste de estresse pode ajudar a identificar limitações.

• Análise do modo de falha. Introduzir falhas no aplicativo e na infraestrutura subjacente e avaliar o efeito é essencial para avaliar os mecanismos de redundância da solução. Durante essa análise, identifique o risco, o impacto e a amplitude do impacto (interrupção parcial ou total). Para uma análise de exemplo que foi criada para a implementação de referência do Mission Critical Online, veja Riscos de interrupção de componentes individuais.

• Monitoramento. Você deve capturar e analisar os resultados do teste individualmente e também agregá-los para avaliar tendências ao longo do tempo. Você deve avaliar continuamente os resultados do teste para precisão e cobertura.

Recomendações de design

Exiba o vídeo a seguir para ver como o teste de resiliência pode ser integrado aos pipelines de CI/CD do Azure DevOps.

• Garanta a consistência automatizando todos os testes em componentes de infraestrutura e aplicativo. Integre os testes em pipelines de CI/CD para orquestrar e executá-los quando aplicável. Para obter informações sobre opções de tecnologia, consulte as ferramentas de DevOps.

• Trate todos os artefatos de teste como código. Eles devem ser mantidos e sob controle de versão junto com outros artefatos do código do aplicativo.

• Alinhe o SLA da infraestrutura de teste com o SLA para ciclos de implantação e teste.

• Execute testes de fumaça como parte de cada implantação. Execute também testes de carga extensivos, juntamente com testes de estresse e caos para validar se o desempenho e a operabilidade do aplicativo são mantidos.

  • Use perfis de carga que reflitam padrões reais de uso de pico.
  • Execute os experimentos de caos e testes de injeção de falha ao mesmo tempo que os testes de carga.

  Dica

  O Azure Chaos Studio é um conjunto nativo de ferramentas de experimentação do caos. As ferramentas facilitam a realização de experimentos de caos e injetam falhas nos serviços do Azure e nos componentes do aplicativo.

  O Chaos Studio fornece experimentos internos de caos para cenários de falha comuns e dá suporte a experimentos personalizados direcionados à infraestrutura e aos componentes do aplicativo.

• Se interações de banco de dados, como a criação de registros, forem necessárias para testes de carga ou de fumaça, use contas de teste com privilégios reduzidos e torne os dados de teste separados do conteúdo real do usuário.

• Verifique e rastreie a cadeia de fornecimento de software de ponta a ponta e as dependências dos pacotes para vulnerabilidades conhecidas.

  • Use o Dependabot para repositórios do GitHub para garantir que o repositório esteja atualizado automaticamente com as versões mais recentes de pacotes e aplicativos dos quais ele depende.

Infraestrutura como implantações de código

A Infraestrutura como Código (IaC) trata as definições de infraestrutura como código-fonte que são controladas por versionamento junto a outros artefatos da aplicação. O uso da IaC promove a consistência de código entre ambientes, elimina o risco de erro humano durante implantações automatizadas e fornece rastreabilidade e reversão. Para implantações azul/verde, o uso de IaC com implantações totalmente automatizadas é imperativo.

Um repositório IaC de missão crítica possui duas definições distintas que são mapeadas para recursos globais e regionais. Para obter informações sobre esses tipos de recursos, consulte o padrão de arquitetura principal.

Considerações sobre o design

• Infraestrutura repetível. Implante cargas de trabalho críticas de uma maneira que gere o mesmo ambiente todas as vezes. IaC deve ser o modelo primário.

• Automação. Todas as implantações devem ser totalmente automatizadas. Processos humanos são propensos a erros.

Recomendações de design

• Aplique IaC, garantindo que todos os recursos do Azure sejam definidos em modelos declarativos e mantidos em um repositório de controle do código-fonte. Os modelos são implantados e os recursos são provisionados automaticamente do controle do código-fonte por meio de pipelines de CI/CD. Não recomendamos o uso de scripts imperativos.

• Proibir operações manuais em todos os ambientes. A única exceção são ambientes de desenvolvedor totalmente independentes.

Ferramentas de DevOps

O uso efetivo das ferramentas de implantação é fundamental para a confiabilidade geral porque os processos de DevOps afetam a função geral e o design do aplicativo. Por exemplo, as operações de failover e dimensionamento podem depender da automação fornecida pelas ferramentas de DevOps. As equipes de engenharia devem entender o efeito da indisponibilidade de um serviço de implantação em relação à carga de trabalho geral. As ferramentas de implantação devem ser confiáveis e altamente disponíveis.

A Microsoft fornece dois conjuntos de ferramentas nativos do Azure, GitHub Actions e Azure Pipelines, que podem implantar e gerenciar efetivamente um aplicativo crítico.

Considerações sobre o design

• Recursos de tecnologia. Os recursos do GitHub e do Azure DevOps se sobrepõem. Você pode usá-los juntos para obter o melhor de ambos. Uma abordagem comum é armazenar repositórios de código no GitHub.com ou no GitHub AE ao usar o Azure Pipelines para implantação.

  Lembre-se da complexidade adicionada ao usar várias tecnologias. Avalie um conjunto de recursos avançado em relação à confiabilidade geral.

• Disponibilidade regional. Em termos de confiabilidade máxima, a dependência em uma única região do Azure representa um risco operacional.

  Por exemplo, digamos que o tráfego esteja distribuído em duas regiões: Região 1 e Região 2. A Região 2 hospeda a instância de ferramentas do Azure DevOps. Suponha que haja uma interrupção na Região 2 e a instância não esteja disponível. A Região 1 lida automaticamente com todo o tráfego e precisa implantar unidades de escala extra para fornecer uma boa experiência de failover. Mas ele não será capaz devido à dependência do Azure DevOps na Região 2.

• Replicação de dados. Os dados, incluindo metadados, pipelines e código-fonte, devem ser replicados entre regiões.

Recomendações de design

• Ambas as tecnologias são hospedadas em uma única região do Azure, o que pode tornar sua estratégia de recuperação de desastre restritiva.

  O GitHub Actions é adequado para tarefas de build (integração contínua), mas pode não ter recursos para tarefas de implantação complexas (implantação contínua). Considerando o conjunto de recursos avançado do Azure DevOps, recomendamos isso para implantações críticas. No entanto, você deve fazer uma escolha depois de avaliar as compensações.

• Defina um SLA de disponibilidade para ferramentas de implantação e garanta o alinhamento com requisitos mais amplos de confiabilidade do aplicativo.

• Para cenários de várias regiões que usam uma configuração de implantação ativa/passiva ou ativa/ativa, verifique se as operações de orquestração e dimensionamento de failover podem continuar funcionando mesmo que os conjuntos de ferramentas de implantação de hospedagem da região primária fiquem indisponíveis.

Estratégia de ramificação

Há muitas abordagens válidas para ramificação. Você deve escolher uma estratégia que garanta a confiabilidade máxima. Uma boa estratégia permite o desenvolvimento paralelo, fornece um caminho claro do desenvolvimento para a produção e dá suporte a versões rápidas.

Considerações sobre o design

• Minimizar o acesso. Os desenvolvedores devem fazer seu trabalho nas branches feature/* e fix/*. Esses ramos se tornam pontos de entrada para mudanças. As restrições baseadas em função devem ser aplicadas a ramificações como parte da estratégia de ramificação. Por exemplo, permitir apenas que os administradores criem ramificações de liberação ou imponham padrões de nomenclatura para ramificações.

• Processo acelerado para emergências. A estratégia de ramificação deve permitir que os hotfixes sejam mesclados para main o mais rápido possível. Dessa forma, versões futuras contêm a correção e a recorrência do problema é evitada. Use esse processo apenas para pequenas alterações que resolvam problemas urgentes e use-o com contenção.

Recomendações de design

• Priorize o uso do GitHub para controle do código-fonte.

  Importante

  Crie uma estratégia de ramificação que detalhe, no mínimo, o trabalho de recurso e as versões, e use políticas e permissões de branch para garantir que a estratégia seja aplicada adequadamente.

• Inicie um processo de teste automatizado para validar as contribuições de alteração de código antes de serem aceitas. Os membros da equipe também devem examinar as alterações.

• Trate o main branch como uma ramificação contínua e estável que é usada principalmente para testes de integração.

  • Certifique-se de que as alterações em main sejam feitas somente por meio de PRs. Utilize uma política de ramificação para proibir confirmações diretas.
  • Sempre que uma PR é mesclada main, ela deve iniciar automaticamente uma implantação em um ambiente de integração.
  • O main ramo deve ser considerado estável. Deve ser seguro criar uma versão de main em qualquer momento.

• Use ramos dedicados release/* criados a partir do ramo main e usados para implantar em ambientes de produção. release/* as ramificações devem permanecer no repositório e podem ser usadas para corrigir uma versão.

• Documente um processo de hotfix e use-o somente quando necessário. Crie hotfixes em um fix/* branch para mesclagem subsequente no branch de lançamento e implantação em produção.

IA para DevOps

Você pode aplicar metodologias de AIOps em pipelines de CI/CD para aprimorar práticas de teste tradicionais. Isso permite a detecção de possíveis regressões ou degradações e permite que as implantações sejam interrompidas preventivamente para evitar possíveis impactos negativos.

Considerações sobre o design

• Volume de dados de telemetria. Os pipelines de CI/CD e os processos de DevOps emitem uma ampla variedade de telemetria para modelos de machine learning. A telemetria varia de resultados de teste e resultados de implantação a dados operacionais sobre componentes de teste de estágios de implantação composta.

• Escalabilidade. Abordagens tradicionais de processamento de dados como Extração, Transformação, Carga (ETL) podem não ser capazes de dimensionar a taxa de transferência para acompanhar o crescimento da telemetria de implantação e dos dados de observabilidade do aplicativo. Você pode usar abordagens de análise modernas que não exigem ETL e movimentação de dados, como virtualização de dados, para habilitar a análise contínua por modelos do AIOps.

• Alterações de implantação. As alterações na implantação precisam ser armazenadas para análise automatizada e correlação aos resultados da implantação.

Recomendações de design

• Defina os dados do processo de DevOps a serem coletados e como analisá-los. A telemetria, como métricas de execução de teste e dados de série temporal de alterações em cada implantação, é importante.

  • Exponha os dados de observabilidade do aplicativo de ambientes de preparo, teste e produção para análise e correlação em modelos do AIOps.

• Adote o fluxo de trabalho do MLOps.

• Desenvolva modelos analíticos com reconhecimento de contexto e com reconhecimento de dependência para fornecer previsões com engenharia de recursos automatizada para lidar com alterações de esquema e comportamento.

• Torne operacionais os modelos registrando e implantando os modelos mais bem treinados em fluxos de implantação.

Próxima etapa

Examine as considerações de segurança.