Procedimentos operacionais para cargas de trabalho fundamentais para a missão no Azure

As operações fiáveis e eficazes têm de ser baseadas nos princípios da automatização sempre que possível e na configuração como código. Esta abordagem requer um investimento de engenharia substancial em processos de DevOps. Os pipelines automatizados são utilizados para implementar artefactos de código de aplicação e infraestrutura. As vantagens desta abordagem incluem resultados operacionais consistentes e precisos com procedimentos operacionais manuais mínimos.

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

Importante

Este artigo faz parte da série de cargas de trabalho fundamentais para a missão do Azure Well-Architected Framework . Se não estiver familiarizado com esta série, recomendamos que comece com O que é uma carga de trabalho crítica para a missão?.

Processos de DevOps

O DevOps combina processos operacionais e de desenvolvimento e equipas numa única função de engenharia. Abrange todo o ciclo de vida da aplicação e utiliza ferramentas de automatização e DevOps para realizar operações de implementação de forma rápida, eficiente e fiável. Os processos de DevOps suportam e sustentam a integração contínua e a entrega contínua (CI/CD), ao mesmo tempo que promovem uma cultura de melhoria contínua.

A equipa do DevOps para uma aplicação crítica para a missão tem de ser responsável por estas tarefas:

• Criação e gestão de recursos de aplicações e infraestruturas através da automatização CI/CD.
• Monitorização e observabilidade de aplicações.
• Controlo de acesso baseado em funções (RBAC) do Azure e gestão de identidades para componentes de aplicações.
• Gestão de rede para componentes de aplicações.
• Gestão de custos para recursos da aplicação.

O DevSecOps expande o modelo de DevOps ao integrar a monitorização de segurança, as auditorias de aplicações e a garantia de qualidade com o desenvolvimento e as operações ao longo do ciclo de vida da aplicação. As equipas de DevOps são necessárias para cenários sensíveis à segurança e altamente regulados para garantir que a segurança é incorporada ao longo do ciclo de vida de desenvolvimento e não numa fase ou porta de lançamento específica.

Considerações de design

• Processo de lançamento e atualização. Evite processos manuais para qualquer alteração aos componentes da aplicação ou à infraestrutura subjacente. Os processos manuais podem originar resultados inconsistentes.

• Dependências das equipas de TI centrais. Os processos de DevOps podem ser difíceis de aplicar quando existem dependências rígidas em funções centralizadas, uma vez que estas dependências impedem operações ponto a ponto.

• Gestão de identidades e acessos. As equipas de DevOps podem considerar funções RBAC granulares do Azure para várias funções técnicas, como AppDataOps para gestão de bases de dados. Aplicar um modelo de confiança zero nas funções do DevOps.

Recomendações de conceção

• Defina as definições de configuração e as atualizações como código. Aplique a gestão de alterações através de código para permitir processos de lançamento e atualização consistentes, incluindo tarefas como a rotação de chaves ou segredos e a gestão de permissões. Utilize processos de atualização geridos pelo pipeline, como execuções de pipelines agendadas, em vez de mecanismos de atualização automática incorporados.

• Não utilize processos centrais nem pipelines de aprovisionamento para a instanciação ou gestão de recursos da aplicação. Ao fazê-lo, introduz dependências de aplicações externas e vetores de risco adicionais, como os associados a cenários de vizinhos ruidosos.

  Se precisar de utilizar processos de aprovisionamento centralizados, certifique-se de que os requisitos de disponibilidade das dependências estão totalmente alinhados com os requisitos fundamentais da missão. As equipas centrais têm de fornecer transparência para que a operacionalização holística da aplicação ponto a ponto seja alcançada.

• Dedique uma proporção de capacidade de engenharia durante cada sprint para impulsionar melhorias fundamentais da plataforma e reforçar a fiabilidade. Recomendamos que aloque 20 a 40 por cento da capacidade a estas melhorias.

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

  Também pode utilizar os critérios de engenharia comuns e os artefactos associados, como políticas do Azure e recursos do Terraform para padrões de conceção comuns, entre outras cargas de trabalho no ecossistema de aplicações mais amplo da sua organização.

• Aplicar um modelo de confiança zero em ambientes de aplicações críticos. Utilize tecnologias como Microsoft Entra Privileged Identity Management para garantir que as operações são consistentes e ocorrem apenas através de processos de CI/CD ou procedimentos operacionais automatizados.

  Os membros da equipa não devem ter acesso de escrita permanente a nenhum ambiente. Poderá querer abrir exceções em ambientes de desenvolvimento para permitir testes e depuração mais fáceis.

• Definir processos de emergência para acesso just-in-time a ambientes de produção. Certifique-se de que existem contas break glass em caso de problemas graves com o fornecedor de autenticação.

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

Operações da aplicação

A estrutura da aplicação e as recomendações da plataforma influenciam os procedimentos operacionais. Também existem capacidades operacionais fornecidas por vários serviços do Azure, especialmente para elevada disponibilidade e recuperação.

Considerações de design

• Operações incorporadas dos serviços do Azure. Os serviços do Azure fornecem capacidades incorporadas (ativadas por predefinição) e de plataforma configuráveis, como redundância zonal e georreplicação. A fiabilidade de uma aplicação depende destas operações. Determinadas capacidades configuráveis incorrem num custo adicional, como a configuração de implementação de várias escritas 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 são expostas e acessíveis através da API de Resource Manager do Azure ou do portal do Azure. No entanto, determinadas operações requerem assistência dos engenheiros de suporte. Por exemplo, um restauro a partir de uma cópia de segurança periódica de uma base de dados do Azure Cosmos DB ou a recuperação de um recurso eliminado só pode ser efetuado por suporte do Azure engenheiros através de um pedido de suporte. Esta dependência pode afetar o tempo de inatividade da aplicação. Para recursos sem estado, recomendamos que reimplemente em vez de aguardar que os engenheiros de suporte tentem recuperar recursos eliminados.

• Imposição de política. Azure Policy fornece um quadro para impor e auditar linhas de base de segurança e fiabilidade para garantir a conformidade com critérios de engenharia comuns para aplicações fundamentais para a missão. Mais especificamente, Azure Policy constitui uma parte fundamental do plano de controlo do Azure Resource Manager, complementando o RBAC ao restringir as ações que os utilizadores autorizados podem realizar. Pode utilizar Azure Policy para impor convenções vitais de segurança e fiabilidade em todos os serviços da plataforma.

• Modificação e eliminação de recursos. Pode bloquear os recursos do Azure para impedir que sejam modificados ou eliminados. No entanto, os bloqueios introduzem a sobrecarga de gestão nos pipelines de implementação. Para a maioria dos recursos, recomendamos um processo RBAC robusto com restrições apertadas em vez de bloqueios de recursos.

Recomendações de conceção

• Automatizar os procedimentos de ativação pós-falha. Para um modelo ativo/ativo, utilize um modelo de estado de funcionamento e operações de dimensionamento automatizado para garantir que não é necessária nenhuma intervenção de ativação pós-falha. Para um modelo ativo/passivo, certifique-se de que os procedimentos de ativação pós-falha são automatizados ou, pelo menos, codificados nos pipelines.

• Priorize a utilização do dimensionamento automático nativo do Azure para serviços que o suportam. Para serviços que não suportam o dimensionamento automático nativo, utilize processos operacionais automatizados para dimensionar serviços. Utilize unidades de escala com vários serviços para alcançar a escalabilidade.

• Utilize capacidades nativas da plataforma para cópia de segurança e restauro, garantindo que estão alinhadas com os requisitos de RTO/RPO e retenção de dados. Defina uma estratégia para a retenção de cópias de segurança de longo prazo, conforme necessário.

• Utilize capacidades incorporadas para a gestão e renovação de certificados SSL, como as fornecidas pelo Azure Front Door.

• Para equipas externas, estabeleça um processo de recuperação para recursos que necessitem de assistência. Por exemplo, se a plataforma de dados for modificada ou eliminada incorretamente, os métodos de recuperação devem ser bem compreendidos e deve ser implementado um processo de recuperação. Da mesma forma, estabeleça procedimentos para gerir imagens de contentor desativadas no registo.

• Pratique operações de recuperação antecipadamente, em recursos e dados de não produção, como parte dos preparativos padrão de continuidade do negócio.

• Identifique alertas críticos e defina públicos e sistemas de destino. Defina canais claros para chegar aos intervenientes adequados. Envie apenas alertas acionáveis para evitar ruído em branco e impedir que os intervenientes operacionais ignorem alertas e faltem informações importantes. Implemente melhorias contínuas para otimizar os alertas e remover dados irrelevantes em branco observados.

• Aplique governação e Azure Policy orientadas por políticas para garantir a utilização adequada das capacidades operacionais e uma linha de base de configuração fiável em todos os serviços da aplicação.

• Evite a utilização de bloqueios de recursos em recursos regionais efémeros. Em vez disso, confie na utilização adequada dos pipelines RBAC e CI/CD para controlar as atualizações operacionais. Pode aplicar bloqueios de recursos para impedir a eliminação de recursos globais de longa duração.

Gestão de atualizações

O design crítico da missão apoia fortemente o princípio dos recursos de aplicações sem estado efémeros. Se aplicar este princípio, normalmente pode efetuar uma atualização com uma nova implementação e pipelines de entrega padrão.

Considerações de design

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

• Deteção automática de atualizações. Configure processos para monitorizar e detetar atualizações automaticamente. Utilize ferramentas como o GitHub Dependabot.

• Teste e validação. Teste e valide novas versões de pacotes, componentes e dependências num contexto de produção antes de qualquer lançamento. As 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 à aplicação. As versões mais antigas podem introduzir vulnerabilidades de segurança e podem ter um efeito negativo no desempenho. Monitorize o ambiente de runtime da aplicação e mantenha-o atualizado.

• Higiene e limpeza de componentes. Desativar ou remover recursos que não são utilizados. Por exemplo, monitorize os registos de contentores e elimine versões de imagens antigas que não esteja a utilizar.

Recomendações de conceção

• Monitorize estes recursos e mantenha-os atualizados:

  • A plataforma de alojamento de aplicações. Por exemplo, tem de atualizar regularmente a versão do Kubernetes no Azure Kubernetes Service (AKS), especialmente tendo em conta que o suporte para versões mais antigas não é sustentado. Também tem de atualizar os componentes que são 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).
  • Fornecedores do Terraform.

• Evite alterações operacionais manuais para atualizar componentes. Considere a utilização de alterações manuais apenas em situações de emergência. Certifique-se de que tem um processo para reconciliar quaisquer alterações manuais no repositório de origem para evitar desvios e problemas de periodicidade.

• Estabeleça um procedimento automatizado para remover versões antigas de imagens de Azure Container Registry.

Gestão de segredos

As expirações de chave, segredo e certificado são uma causa comum de indisponibilidade da aplicação. A gestão de segredos de uma aplicação crítica para a missão tem de fornecer a segurança necessária e oferecer um nível de disponibilidade adequado para se alinhar com os seus requisitos de fiabilidade máxima. Tem de efetuar regularmente a rotação de chaves, segredos e certificados através de um serviço gerido ou como parte da gestão de atualizações e aplicar processos para alterações de código e configuração.

Muitos serviços do Azure suportam Microsoft Entra autenticação em vez de dependerem de cadeias de ligação/chaves. Utilizar Microsoft Entra ID reduz significativamente a sobrecarga operacional. Se utilizar uma solução de gestão de segredos, esta deverá ser integrada noutros serviços, suportar redundância zonal e regional e fornecer integração com Microsoft Entra ID para autenticação e autorização. Key Vault fornece estas funcionalidades.

Considerações de design

Existem três abordagens comuns à gestão de segredos. Cada abordagem lê segredos do arquivo de segredos e injeta-os na aplicação num momento diferente.

• Obtenção do tempo de implementação. A vantagem desta abordagem é que a solução de gestão de segredos só tem de estar disponível no momento da implementação porque não existem dependências diretas após esse período. Os exemplos incluem injetar segredos como variáveis de ambiente numa implementação do Kubernetes ou num segredo do Kubernetes.

  Apenas o principal de serviço de implementação tem de conseguir aceder a segredos, o que simplifica as permissões RBAC no sistema de gestão de segredos.

  No entanto, existem desvantagens nesta abordagem. Introduz a complexidade do RBAC nas ferramentas de DevOps no que diz respeito ao controlo do acesso do principal de serviço e na aplicação no que diz respeito à proteção de segredos obtidos. Além disso, os benefícios de segurança da solução de gestão de segredos não são aplicados porque esta abordagem depende apenas do controlo de acesso na plataforma de aplicações.

  Para implementar atualizações secretas ou rotação, tem de efetuar uma reimplementação completa.

• Obtenção do arranque da aplicação. Nesta abordagem, os segredos são obtidos e injetados no arranque da aplicação. O benefício é que pode facilmente atualizar ou rodar segredos. Não precisa de armazenar segredos na plataforma da aplicação. É necessário reiniciar a aplicação para obter o valor mais recente.

  As opções de armazenamento comuns incluem o Fornecedor de Key Vault do Azure para o Controlador CSI do Arquivo de Segredos e akv2k8s. Também está disponível uma solução nativa do Azure, Key Vault definições de aplicações referenciadas.

  Uma desvantagem desta abordagem é criar uma dependência de runtime na solução de gestão de segredos. Se a solução de gestão de segredos sofrer uma falha, os componentes da aplicação já em execução poderão continuar a servir pedidos. Qualquer operação de reinício ou aumento horizontal provavelmente resultaria em falhas.

• Obtenção de tempo de execução. A obtenção de segredos no runtime a partir da própria aplicação é a abordagem mais segura, porque mesmo a plataforma de aplicações nunca tem acesso a segredos. A aplicação tem de se autenticar no sistema de gestão de segredos.

  No entanto, para esta abordagem, os componentes da aplicação requerem uma dependência direta e uma ligação ao sistema de gestão de segredos. Isto dificulta o teste de componentes individualmente e, normalmente, exige a utilização de um SDK.

Recomendações de conceção

• Sempre que possível, utilize Microsoft Entra autenticação para ligar a serviços em vez de utilizar cadeias de ligação ou chaves. Utilize este método de autenticação juntamente com as identidades geridas do Azure para não ter de armazenar segredos na plataforma da aplicação.

• Tire partido da definição de expiração no Key Vault e configure alertas para expirações futuras. Efetue todas as atualizações de chaves, segredos e certificados com o processo de lançamento padrão.

• Implemente Key Vault instâncias como parte de um selo regional para mitigar o efeito potencial de uma falha num único selo de implementação. Utilize uma instância separada para recursos globais. Para obter informações sobre esses recursos, veja o padrão de arquitetura típico para cargas de trabalho fundamentais para a missão.

• Para evitar a necessidade de gerir credenciais do principal de serviço ou chaves de API, utilize identidades geridas em vez de principais de serviço para aceder a Key Vault sempre que possível.

• Implemente padrões de codificação para garantir que os segredos são novamente obtidos quando ocorre uma falha de autorização no runtime.

• Aplique um processo de rotação de chaves totalmente automatizado que é executado periodicamente na solução.

• Utilize a notificação de quase expiração da chave no Azure Key Vault para receber alertas sobre expirações futuras.

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

Se precisar de utilizar VMs IaaS, alguns dos procedimentos e práticas descritos anteriormente neste documento poderão ser diferentes. A utilização de VMs proporciona mais flexibilidade nas opções de configuração, nos sistemas operativos, no acesso ao controlador, no acesso ao sistema operativo de baixo nível e nos tipos de software que pode instalar. As desvantagens são o aumento dos custos operacionais e a responsabilidade pelas tarefas que normalmente são executadas pelo fornecedor de cloud quando utiliza serviços PaaS.

Considerações de design

• As VMs individuais não fornecem elevada disponibilidade, redundância entre zonas ou redundância geográfica.
• As VMs individuais não são atualizadas automaticamente depois de as implementar. Por exemplo, um SQL Server 2019 implementado no Windows Server 2019 não será atualizado automaticamente para uma versão mais recente.
• Os serviços em execução numa VM precisam de tratamento especial e ferramentas adicionais se quiser implementá-los e configurá-los através da infraestrutura como código.
• O Azure atualiza periodicamente a sua plataforma. Estas atualizações podem exigir reinícios da VM. Atualizações que requerem um reinício são normalmente anunciadas com antecedência. Veja Manutenção de máquinas virtuais no Azure e Processar notificações de manutenção planeada.

Recomendações de conceção

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

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

• Certifique-se de que os processos operacionais para a implementação de VMs, atualizações e cópia de segurança e recuperação estão implementados e devidamente testados. Para testar a resiliência, injete falhas na aplicação, anote falhas e mitigue essas falhas.

• Certifique-se de que estão implementadas estratégias para reverter para o último estado de funcionamento conhecido se uma versão mais recente não funcionar corretamente.

• Crie cópias de segurança frequentes para cargas de trabalho com estado, certifique-se de que as tarefas de cópia de segurança funcionam eficazmente e implemente alertas para processos de cópia de segurança com falhas.

• Monitorize as VMs e detete falhas. Os dados não processados para monitorização podem ser provenientes de várias origens. Analise as causas dos problemas.

• Certifique-se de que as cópias de segurança agendadas são executadas conforme esperado e que as cópias de segurança periódicas são criadas conforme necessário. Pode utilizar o Centro de cópias de segurança para obter informações.

• Priorize a utilização de Conjuntos de Dimensionamento de Máquinas Virtuais em vez de VMs para permitir capacidades como dimensionamento, dimensionamento automático e redundância entre zonas.

• Priorize a utilização de imagens padrão de Azure Marketplace em vez de imagens personalizadas que precisam de ser mantidas.

• Utilize o Azure VM Image Builder ou outras ferramentas para automatizar processos de compilação e manutenção para imagens personalizadas, conforme necessário.

Para além destas recomendações específicas, aplique as melhores práticas para procedimentos operacionais para cenários de aplicação críticos para a missão, conforme adequado.

Passo seguinte

Reveja o padrão de arquitetura para cenários de aplicação críticos para a missão:

Padrão de arquitetura