Procedimentos operacionais para cargas de trabalho críticas no Azure

Operações confiáveis e eficazes devem ser baseadas nos princípios da automação sempre que possível e na configuração como código. Essa abordagem requer um investimento substancial em engenharia em processos de DevOps. Pipelines automatizados são usados para implantar artefatos de código de aplicativo e infraestrutura. Os benefícios dessa abordagem incluem resultados operacionais consistentes e precisos com procedimentos operacionais manuais mínimos.

Essa área de design explora como implementar procedimentos operacionais eficazes e consistentes.

Importante

Este artigo faz parte da série Workload de missão crítica do Azure Well-Architected Framework. Se você não estiver familiarizado com esta série, recomendamos que comece com O que é um workload de missão crítica?.

Processos de DevOps

O DevOps combina processos operacionais e de desenvolvimento e equipes em uma única função de engenharia. Ele abrange todo o ciclo de vida do aplicativo e usa a automação e as ferramentas de DevOps para conduzir operações de implantação de maneira rápida, eficiente e confiável. Os processos de DevOps dão suporte e sustentam a CI/CD (integração contínua e entrega contínua) ao mesmo tempo em que promovem uma cultura de melhoria contínua.

A equipe de DevOps de um aplicativo crítico deve ser responsável por estas tarefas:

• Criação e gerenciamento de recursos de aplicativo e infraestrutura por meio da automação de CI/CD.
• Monitoramento e observabilidade do aplicativo.
• RBAC (controle de acesso baseado em função) do Azure e gerenciamento de identidade para componentes de aplicativo.
• Gerenciamento de rede para componentes de aplicativo.
• Gerenciamento de custos para recursos de aplicativo.

O DevSecOps expande o modelo DevOps integrando monitoramento de segurança, auditorias de aplicativos e garantia de qualidade com desenvolvimento e operações em todo o ciclo de vida do aplicativo. As equipes de DevOps são necessárias para cenários altamente regulamentados e sensíveis à segurança para garantir que a segurança seja incorporada em todo o ciclo de vida de desenvolvimento, em vez de em um estágio de lançamento ou portão específico.

Considerações sobre o design

• Processo de versão e atualização. Evite processos manuais para qualquer alteração nos componentes do aplicativo ou na infraestrutura subjacente. Processos manuais podem levar a resultados inconsistentes.

• Dependências em equipes de TI centrais. Os processos de DevOps podem ser difíceis de aplicar quando há dependências rígidas em funções centralizadas porque essas dependências impedem operações de ponta a ponta.

• Gerenciamento de identidade e acesso. As equipes do DevOps podem considerar funções granulares do RBAC do Azure para várias funções técnicas, como AppDataOps para gerenciamento de banco de dados. Aplique um modelo de confiança zero em funções DevOps.

Recomendações de design

• Defina as configurações e as atualizações como código. Aplique o gerenciamento de alterações por meio do código para habilitar processos de versão e atualização consistentes, incluindo tarefas como rotação de chaves ou segredo e gerenciamento de permissões. Use processos de atualização gerenciados por pipeline, como execuções de pipeline agendadas, em vez de mecanismos internos de atualização automática.

• Não use processos centrais ou pipelines de provisionamento para a instanciação ou gerenciamento de recursos de aplicativo. Isso introduz dependências de aplicativos externos e vetores de risco adicionais, como aqueles associados a cenários de vizinhos barulhentos.

  Se você precisar usar processos de provisionamento centralizados, verifique se os requisitos de disponibilidade das dependências estão totalmente alinhados com os requisitos críticos da missão. As equipes centrais devem fornecer transparência para que a operacionalização holística do aplicativo de ponta a ponta seja obtida.

• Dedique uma proporção da capacidade de engenharia durante cada sprint para impulsionar melhorias fundamentais da plataforma e reforçar a confiabilidade. Recomendamos que você aloque de 20 a 40% da capacidade para essas melhorias.

• Desenvolva critérios comuns de engenharia, arquiteturas de referência e bibliotecas alinhadas com princípios de design principais. Imponha uma configuração de linha de base consistente para confiabilidade, segurança e operações por meio de uma abordagem orientada por políticas que usa o Azure Policy.

  Você também pode usar os critérios comuns de engenharia e artefatos associados, como políticas do Azure e recursos do Terraform para padrões de design comuns, em outras cargas de trabalho dentro do ecossistema de aplicativos mais amplo da sua organização.

• Aplique um modelo de confiança zero em ambientes de aplicativo críticos. Use tecnologias como o Microsoft Entra Privileged Identity Management para garantir que as operações sejam consistentes e ocorram somente por meio de processos de CI/CD ou procedimentos operacionais automatizados.

  Os membros da equipe não devem ter acesso de gravação contínuo a nenhum ambiente. Talvez você queira criar exceções em ambientes de desenvolvimento para facilitar o teste e a depuração.

• Defina processos de emergência para acesso em tempo real a ambientes de produção. Garanta que contas de emergência existam em caso de problemas graves com o provedor de autenticação.

• Considere o uso do AIOps para melhorar continuamente os procedimentos operacionais e acionadores.

Operações de aplicativo

As recomendações de design e plataforma do aplicativo influenciam os procedimentos operacionais. Há também recursos operacionais fornecidos por vários serviços do Azure, especialmente para alta disponibilidade e recuperação.

Considerações sobre o design

• Operações internas dos serviços do Azure. Os serviços do Azure fornecem funcionalidades internas (habilitadas por padrão) e de plataforma configuráveis, como redundância zonal e replicação geográfica. A confiabilidade de um aplicativo depende dessas operações. Certas funcionalidades configuráveis geram um custo adicional, como a configuração de implantação para gravação múltipla no Azure Cosmos DB. Evite criar soluções personalizadas, a menos que você precise.

• Acesso operacional e tempo de execução. A maioria das operações necessárias é exposta e acessível por meio da API do Azure Resource Manager ou do portal do Azure. No entanto, determinadas operações exigem assistência de engenheiros de suporte. Por exemplo, uma restauração de um backup periódico de um banco de dados do Azure Cosmos DB ou a recuperação de um recurso excluído pode ser executada somente por engenheiros de suporte do Azure por meio de um caso de suporte. Essa dependência pode afetar o tempo de inatividade do aplicativo. Para recursos sem estado, recomendamos que você faça uma nova implantação, em vez de esperar que os engenheiros de suporte tentem recuperar recursos excluídos.

• Aplicação de política. O Azure Policy fornece uma estrutura para impor e auditar linhas de base de segurança e confiabilidade para garantir a conformidade com critérios comuns de engenharia para aplicativos críticos. Mais especificamente, o Azure Policy forma uma parte fundamental do plano de controle do Azure Resource Manager, complementando o RBAC restringindo as ações que os usuários autorizados podem executar. Você pode usar o Azure Policy para impor convenções vitais de segurança e confiabilidade em serviços de plataforma.

• Modificação e exclusão de recursos. Você pode bloquear os recursos do Azure para impedir que eles sejam modificados ou excluídos. No entanto, os bloqueios introduzem sobrecarga de gerenciamento em pipelines de implantação. Para a maioria dos recursos, recomendamos um processo RBAC robusto com restrições rígidas em vez de bloqueios de recursos.

Recomendações de design

• Automatizar procedimentos de failover. Para um modelo ativo/ativo, use um modelo de integridade e operações de escala automatizadas para garantir que nenhuma intervenção de failover seja necessária. Para um modelo ativo/passivo, verifique se os procedimentos de failover são automatizados ou pelo menos codificados em pipelines.

• Priorize o uso do dimensionamento automático nativo do Azure para serviços que dão suporte a ele. Para serviços que não dão suporte ao dimensionamento automático nativo, use processos operacionais automatizados para dimensionar serviços. Use unidades de escala com vários serviços para obter escalabilidade.

• Use recursos nativos de plataforma para backup e restauração, garantindo que eles estejam alinhados com seus requisitos de RTO/RPO e retenção de dados. Defina uma estratégia para retenção de backup de longo prazo, conforme necessário.

• Aproveite os recursos internos para o gerenciamento e a renovação de certificados SSL, como os fornecidos pelo Azure Front Door.

• Para equipes externas, estabeleça um processo de recuperação para recursos que precisam de assistência. Por exemplo, se a plataforma de dados for modificada ou excluída incorretamente, os métodos de recuperação deverão ser bem compreendidos e um processo de recuperação deverá estar em vigor. Da mesma forma, estabeleça procedimentos para gerenciar imagens de contêiner desativadas no repositório.

• Pratique as operações de recuperação com antecedência, em dados e recursos de não produção, como parte das preparações padrão de continuidade dos negócios.

• Identifique alertas críticos e defina os públicos e sistemas de destino. Defina canais claros para alcançar as partes interessadas relevantes. Envie apenas alertas acionáveis, evitando ruído de fundo e impedindo que as partes interessadas operacionais ignorem alertas e percam informações importantes. Implemente a melhoria contínua para otimizar o sistema de alertas e remover o ruído de fundo observado.

• Aplique a governança controlada por políticas e o Azure Policy para garantir o uso apropriado de recursos operacionais e uma linha de base de configuração confiável em todos os serviços de aplicativo.

• Evite o uso de bloqueios de recursos em recursos regionais efêmeros. Em vez disso, conte com o uso apropriado de RBAC e pipelines de CI/CD para controlar as atualizações operacionais. Você pode aplicar bloqueios de recursos para impedir a exclusão de recursos globais de longa duração.

Gerenciamento de atualizações

O design de missão crítica endossa fortemente o princípio dos recursos de aplicativo efêmeros e sem estado. Se você aplicar esse princípio, normalmente poderá executar uma atualização usando uma nova implantação e pipelines de entrega padrão.

Considerações sobre o design

• Alinhamento com os roteiros do Azure. Alinhe sua carga de trabalho com os roteiros do Azure para que os recursos da plataforma e as dependências de runtime sejam atualizados regularmente.

• Detecção automática de atualizações. Configure processos para monitorar e detectar atualizações automaticamente. Use ferramentas como o GitHub Dependabot.

• Teste e validação. Teste e valide novas versões de pacotes, componentes e dependências em um contexto de produção antes de qualquer versão. Novas versões podem conter alterações significativas.

• Dependências de runtime. Trate dependências de runtime como qualquer outra alteração no aplicativo. Versões mais antigas podem introduzir vulnerabilidades de segurança e podem ter um efeito negativo no desempenho. Monitore o ambiente de runtime do aplicativo e mantenha-o atualizado.

• Higiene e limpeza de componentes. Desativar ou remover recursos que não são usados. Por exemplo, monitore os registros de contêiner e exclua versões de imagem antigas que você não está usando.

Recomendações de design

• Monitore esses recursos e mantenha-os atualizados:

  • A plataforma de hospedagem de aplicativos. Por exemplo, você precisa atualizar a versão do Kubernetes no AKS (Serviço de Kubernetes do Azure) regularmente, especialmente considerando que o suporte para versões mais antigas não é mantido. Você também precisa atualizar os componentes executados no Kubernetes, como o cert-manager e o CSI do Azure Key Vault, e alinhá-los com a versão do Kubernetes no AKS.
  • Bibliotecas externas e SDKs (.NET, Java, Python).
  • Provedores Terraform.

• Evite alterações operacionais manuais para atualizar componentes. Considere o uso de alterações manuais somente em situações de emergência. Certifique-se de que você tem um processo para reconciliar as alterações manuais de volta no repositório de origem para evitar desvios e recorrência de problemas.

• Estabeleça um procedimento automatizado para remover versões antigas de imagens do Registro de Contêiner do Azure.

Gerenciamento de segredos

As expirações de chave, segredo e certificado são uma causa comum de interrupção do aplicativo. O gerenciamento de segredos para um aplicativo crítico deve fornecer a segurança necessária e oferecer um nível apropriado de disponibilidade para se alinhar aos seus requisitos de confiabilidade máxima. Você precisa executar a rotação de chave, segredo e certificado regularmente usando um serviço gerenciado ou como parte do gerenciamento de atualizações e aplicar processos para alterações de código e configuração.

Muitos serviços do Azure dão suporte à autenticação do Microsoft Entra em vez de depender de cadeias de conexão/chaves. O uso da ID do Microsoft Entra reduz consideravelmente a sobrecarga operacional. Se você usar uma solução de gerenciamento de segredo, ela deverá se integrar a outros serviços, dar suporte à redundância zonal e regional e fornecer integração com a ID do Microsoft Entra para autenticação e autorização. O Key Vault fornece esses recursos.

Considerações sobre o design

Há três abordagens comuns para o gerenciamento de segredos. Cada abordagem lê segredos do repositório de segredos e os injeta no aplicativo em um momento diferente.

• Recuperação no momento da implantação. A vantagem dessa abordagem é que a solução de gerenciamento de segredos só precisa estar disponível no momento da implantação porque não há dependências diretas após esse período. Exemplos incluem inserir segredos como variáveis de ambiente em uma implantação do Kubernetes ou em um segredo do Kubernetes.

  Somente o deployment service principal precisa ser capaz de acessar segredos, o que simplifica as permissões RBAC dentro do sistema de gerenciamento de segredos.

  Há, no entanto, desvantagens nessa abordagem. Ele apresenta a complexidade RBAC nas ferramentas de DevOps no que diz respeito ao controle do acesso ao princípio de serviço e na aplicação no que diz respeito à proteção de segredos recuperados. Além disso, os benefícios de segurança da solução de gerenciamento de segredos não são aplicados porque essa abordagem depende apenas do controle de acesso na plataforma de aplicativos.

  Para implementar atualizações de segredos ou rotação, você precisa executar uma redistribuição completa.

• Recuperação de inicialização de aplicativo. Nessa abordagem, os segredos são recuperados e injetados na inicialização do aplicativo. O benefício é que você pode atualizar ou alternar segredos com facilidade. Você não precisa armazenar segredos na plataforma do aplicativo. Uma reinicialização do aplicativo é necessária para buscar o valor mais recente.

  As opções de armazenamento comuns incluem o Azure Key Vault Provider for Secrets Store CSI Driver e akv2k8s. Uma solução nativa do Azure, as configurações de aplicativo referenciadas pelo Key Vault, também está disponível.

  Uma desvantagem dessa abordagem é que ela cria uma dependência de runtime na solução de gerenciamento de segredo. Se a solução de gerenciamento de segredos sofrer uma interrupção, os componentes do aplicativo já em execução poderão continuar atendendo solicitações. Qualquer operação de reinicialização ou expansão provavelmente resultaria em falha.

• Recuperação de runtime. Recuperar segredos em runtime de dentro do próprio aplicativo é a abordagem mais segura porque até mesmo a plataforma de aplicativos nunca tem acesso a segredos. O aplicativo precisa se autenticar no sistema de gerenciamento de segredos.

  No entanto, para essa abordagem, os componentes do aplicativo exigem uma dependência direta e uma conexão com o sistema de gerenciamento de segredos. Isso torna mais difícil testar componentes individualmente e geralmente exige o uso de um SDK.

Recomendações de design

• Quando possível, use a autenticação do Microsoft Entra para se conectar aos serviços em vez de usar cadeias de conexão ou chaves. Use esse método de autenticação junto com identidades gerenciadas do Azure para que você não precise armazenar segredos na plataforma do aplicativo.

• Aproveite a configuração de expiração no Key Vault e configure alertas para expirações futuras. Execute todas as atualizações de chave, segredo e certificado usando o processo de versão padrão.

• Implante instâncias do Key Vault como parte de um carimbo regional para atenuar o efeito potencial de uma falha em um único carimbo de implantação. Use uma instância separada para recursos globais. Para obter informações sobre esses recursos, consulte o padrão de arquitetura típico para cargas de trabalho críticas.

• Para evitar a necessidade de gerenciar credenciais de entidade de serviço ou chaves de API, use identidades gerenciadas em vez de entidades de serviço para acessar o Key Vault sempre que possível.

• Implemente padrões de codificação para garantir que os segredos sejam recuperados novamente quando ocorrer uma falha de autorização em runtime.

• Aplique um processo de rotação de chave totalmente automatizado que é executado periodicamente dentro da solução.

• Use a chave perto da notificação de expiração no Azure Key Vault para obter alertas sobre as expirações futuras.

Considerações específicas de IaaS ao usar VMs

Se você precisar usar VMs IaaS, alguns dos procedimentos e práticas descritos anteriormente neste documento poderão ser diferentes. O uso de VMs fornece mais flexibilidade em opções de configuração, sistemas operacionais, acesso ao driver, acesso a sistemas operacionais de baixo nível e os tipos de software que você pode instalar. As desvantagens são o aumento dos custos operacionais e a responsabilidade por tarefas que geralmente são executadas pelo provedor de nuvem quando você usa serviços de PaaS.

Considerações sobre o design

• VMs individuais não fornecem alta disponibilidade, redundância de zona ou redundância geográfica.
• As VMs individuais não são atualizadas automaticamente depois de implantá-las. Por exemplo, um SQL Server 2019 implantado no Windows Server 2019 não será atualizado automaticamente para uma versão mais recente.
• Os serviços em execução em uma VM precisam de tratamento especial e ferramentas adicionais se você quiser implantá-los e configurá-los por meio da infraestrutura como código.
• O Azure atualiza periodicamente sua plataforma. Essas atualizações podem exigir reinicializações de VM. As atualizações que exigem uma reinicialização geralmente são anunciadas com antecedência. Consulte Manutenção para máquinas virtuais no Azure e Notificações de manutenção planejada.

Recomendações de design

• Evite operações manuais em VMs e implemente processos adequados para implantar e distribuir alterações.

  • Automatize o provisionamento de recursos do Azure usando soluções de infraestrutura como código, como modelos do ARM (Azure Resource Manager), Bicep, Terraform ou outras soluções.

• Verifique se os processos operacionais para implantação de VMs, atualizações e backup e recuperação estão em vigor e testados corretamente. Para testar a resiliência, injete falhas no aplicativo, observe falhas e reduza essas falhas.

• Verifique se as estratégias estão em vigor para reverter para o último estado íntegro conhecido se uma versão mais recente não funcionar corretamente.

• Crie backups frequentes para workloads com estado preservado, certifique-se de que as tarefas de backup funcionem efetivamente e implemente alertas para processos de backup com falha.

• Monitorar VMs e detectar falhas. Os dados brutos para monitoramento podem vir de várias fontes. Analise as causas dos problemas.

• Verifique se os backups agendados são executados conforme o esperado e se os backups periódicos são criados conforme necessário. Você pode usar o Centro de Backup para obter insights.

• Priorize o uso de Conjuntos de Dimensionamento de Máquinas Virtuais em vez de VMs para habilitar recursos como escala, dimensionamento automático e redundância de zona.

• Priorize o uso de imagens padrão do Azure Marketplace em vez de imagens personalizadas que precisam ser mantidas.

• Use o Construtor de Imagens de VM do Azure ou outras ferramentas para automatizar processos de compilação e manutenção para imagens personalizadas, conforme necessário.

Além dessas recomendações específicas, aplique as práticas recomendadas para procedimentos operacionais para cenários de aplicativos críticos, conforme apropriado.

Próxima etapa

Examine o padrão de arquitetura para cenários de aplicativo críticos:

Padrão de arquitetura