Procedimentos operacionais para cargas de trabalho críticas no Azure

As 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 de cargas de trabalho de missão crítica do Azure Well-Architected Framework . Se você não estiver familiarizado com esta série, recomendamos que você comece com O que é uma carga de trabalho crítica?.

Processos de DevOps

O DevOps combina processos e equipes operacionais e de desenvolvimento em uma única função de engenharia. Ele abrange todo o ciclo de vida do aplicativo e usa ferramentas de automação e DevOps para realizar 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 lançamento 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 de DevOps podem considerar funções RBAC granulares 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 de DevOps.

Recomendações sobre 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 consistentes de lançamento e atualização, 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 o gerenciamento de recursos de aplicativo. Isso introduz dependências de aplicativos externos e vetores de risco adicionais, como aqueles associados a cenários 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 alcançada.

• 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 aos princípios principais de design. Imponha uma configuração de linha de base consistente para confiabilidade, segurança e operações por meio de uma abordagem controlada por políticas que usa 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 comuns de design, 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 críticos do aplicativo. Use tecnologias como Microsoft Entra Privileged Identity Management para garantir que as operações sejam consistentes e ocorram apenas por meio de processos de CI/CD ou procedimentos operacionais automatizados.

  Os membros da equipe não devem ter acesso de gravação permanente a nenhum ambiente. Talvez você queira fazer exceções em ambientes de desenvolvimento para habilitar testes e depuração mais fáceis.

• Defina processos de emergência para acesso just-in-time a ambientes de produção. Verifique se as contas de quebra de vidro existem em caso de problemas graves com o provedor de autenticação.

• Considere usar a AIOps para melhorar continuamente os procedimentos operacionais e gatilhos.

Operações do aplicativo

As recomendações de design e plataforma do aplicativo influenciam os procedimentos operacionais. Também há 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 recursos internos (habilitados 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. Determinadas funcionalidades configuráveis incorrem em um custo adicional, como a configuração de implantação de várias gravações para o Azure Cosmos DB. Evite criar soluções personalizadas, a menos que seja absolutamente necessário.

• Tempo de execução e acesso operacional. A maioria das operações necessárias é exposta e acessível por meio da API de Resource Manager do Azure 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 só pode ser executada por engenheiros 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ê reimplante em vez de esperar que os engenheiros de suporte tentem recuperar recursos excluídos.

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

• Modificação e exclusão de recursos. Você pode bloquear 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 sobre 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.

• Use recursos internos para o gerenciamento e 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 exigem 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 registro.

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

• Identifique alertas críticos e defina o público-alvo e os sistemas. Defina canais claros para alcançar os stakeholders apropriados. Envie apenas alertas acionáveis para evitar ruídos em branco e impedir que os stakeholders operacionais ignorem alertas e não precisem de informações importantes. Implemente a melhoria contínua para otimizar alertas e remover o ruído em branco observado.

• Aplique governança controlada por políticas e 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, dependa do uso apropriado de pipelines RBAC e CI/CD para controlar as atualizações operacionais. Você pode aplicar bloqueios de recursos para evitar a exclusão de recursos globais de longa duração.

Gerenciamento de atualizações

O design crítico endossa fortemente o princípio dos recursos de aplicativo sem estado efêmero. 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 interruptivas.

• Dependências de runtime. Trate as dependências de runtime como faria com 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 de componentes e manutenção. Desativar ou remover recursos que não são usados. Por exemplo, monitore registros de contêiner e exclua versões de imagem antigas que você não está usando.

Recomendações sobre 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 é sustentado. Você também precisa atualizar os componentes executados no Kubernetes, como o cert-manager e o Azure Key Vault CSI, e alinhá-los com a versão do Kubernetes no AKS.
  • Bibliotecas externas e SDKs (.NET, Java, Python).
  • Provedores do Terraform.

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

• Estabeleça um procedimento automatizado para remover versões antigas de imagens de 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 Microsoft Entra em vez de depender de cadeias de conexão/chaves. Usar Microsoft Entra ID reduz consideravelmente a sobrecarga operacional. Se você usar uma solução de gerenciamento de segredos, ela deverá ser integrada a outros serviços, dar suporte à redundância zonal e regional e fornecer integração com Microsoft Entra ID para autenticação e autorizaçã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 secreto e os injeta no aplicativo em um momento diferente.

• Recuperação em tempo de 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 injetar segredos como variáveis de ambiente em uma implantação do Kubernetes ou em um segredo do Kubernetes.

  Somente a entidade de serviço de implantação precisa ser capaz de acessar segredos, o que simplifica as permissões rbac dentro do sistema de gerenciamento de segredos.

  No entanto, há desvantagens nessa abordagem. Ele apresenta a complexidade do RBAC nas ferramentas de DevOps em relação ao controle do acesso à entidade de serviço e ao aplicativo 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 do aplicativo.

  Para implementar atualizações ou rotação secretas, você precisa executar uma reimplantação completa.

• Recuperação de inicialização do aplicativo. Nessa abordagem, os segredos são recuperados e injetados na inicialização do aplicativo. O benefício é que você pode atualizar ou girar segredos facilmente. 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 Provedor de Key Vault do Azure para Driver CSI do Repositório de Segredos e akv2k8s. Uma solução nativa do Azure, Key Vault configurações de aplicativo referenciadas, também está disponível.

  Uma desvantagem dessa abordagem é que ela cria uma dependência de runtime na solução de gerenciamento de segredos. Se a solução de gerenciamento de segredos sofrer uma interrupção, os componentes do aplicativo já em execução poderão continuar atendendo às 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 aplicativo 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 requer o uso de um SDK.

Recomendações sobre design

• Quando possível, use Microsoft Entra autenticação para se conectar a 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 em 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 Key Vault instâncias como parte de um carimbo regional para atenuar o efeito potencial de uma falha em um único selo 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 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 no runtime.

• Aplique um processo de rotação de chaves 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 próximas expirações.

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 ao sistema operacional 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 pelas tarefas que geralmente são executadas pelo provedor de nuvem quando você usa serviços de PaaS.

Considerações sobre o design

• As 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 que você as implanta. 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. Atualizações que exigem uma reinicialização geralmente são anunciadas com antecedência. Confira Manutenção para máquinas virtuais no Azure e Tratamento de notificações de manutenção planejada.

Recomendações sobre 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 atenue 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 cargas de trabalho com estado, verifique se as tarefas de backup funcionam com eficiência e implemente alertas para processos de backup com falha.

• Monitorar VMs e detectar falhas. Os dados brutos para monitoramento podem vir de uma variedade de 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 de 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 aplicativos críticos:

Padrão de arquitetura