Recomendações para práticas de implementação segura

  • Artigo

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

OE:11 Defina claramente as práticas de implementação seguras da carga de trabalho. Realce os ideais de métodos de lançamento pequenos, incrementais e com porta de qualidade. Utilize padrões de implementação modernos e técnicas de exposição progressiva para controlar o risco. Conta para implementações de rotina e implementações de emergência ou correções.

Este guia descreve as recomendações para utilizar práticas de implementação segura (SDP). Os processos e procedimentos de implementação seguros definem como efetuar e implementar alterações com segurança na sua carga de trabalho. A implementação do SDP requer que pense nas implementações através da lente da gestão de riscos. Pode minimizar o risco de erro humano nas suas implementações e limitar os efeitos de implementações problemáticas nos seus utilizadores através da implementação do SDP.

Principais estratégias de conceção

Existem quatro diretrizes importantes a ter em conta ao implementar práticas de implementação seguras:

  • Segurança e consistência: todas as alterações à carga de trabalho de produção são inerentemente arriscadas e têm de ser feitas com foco na segurança e consistência.

  • Exposição progressiva: pode minimizar o raio de explosão potencial dos problemas causados pela implementação ao adotar um modelo de implementação de exposição progressiva.

  • Modelos de estado de funcionamento: as implementações têm de passar por verificações de estado de funcionamento antes de cada fase de exposição progressiva poder começar.

  • Deteção de problemas: quando são detetados problemas, a implementação deve ser interrompida imediatamente e iniciada a recuperação.

As secções seguintes fornecem recomendações detalhadas sobre cada um destes pontos.

Segurança e consistência

Quer esteja a implementar uma atualização no código da aplicação, infraestrutura como código (IaC), sinalizador de funcionalidade ou uma atualização de configuração, está a introduzir riscos para a carga de trabalho. Não existem implementações de baixo risco para produção. Cada implementação tem de seguir um padrão padrão e deve ser automatizada para impor consistência e minimizar o risco de erro humano. É fundamental que a cadeia de fornecimento de cargas de trabalho e os pipelines de implementação sejam fiáveis, seguros e tenham padrões de implementação claramente definidos. Trate todas as implementações como um possível risco e submite todas as implementações para o mesmo nível de gestão de riscos. Apesar dos riscos, deve continuar a implementar alterações regulares na carga de trabalho. A falha na implementação de atualizações regulares apresenta outros riscos, como vulnerabilidades de segurança que têm de ser resolvidas através de implementações. Para obter mais informações, veja Recomendações para conceber uma cadeia de fornecimento de desenvolvimento de cargas de trabalho.

As pequenas implementações frequentes são preferíveis a implementações grandes pouco frequentes. As pequenas alterações são mais fáceis de resolver quando surgem problemas e as implementações frequentes ajudam a sua equipa a criar confiança no processo de implementação. Também é importante que aprenda com a produção ao rever os processos da carga de trabalho quando encontrar uma anomalia durante a implementação. Poderá encontrar pontos fracos na conceção da sua infraestrutura ou implementação. Quando ocorrerem problemas durante as implementações, certifique-se de que as autópsias sem culpa fazem parte do processo do SDP para capturar lições sobre o incidente.

Implementação de exposição progressiva

Quando ocorrem problemas de implementação, o objetivo é apanhá-los o mais cedo possível para minimizar o efeito nos utilizadores finais. Implemente um modelo de implementação de implementação gradual, também conhecido como modelo de exposição progressiva, para alcançar este objetivo. As implementações canary são um exemplo comum de exposição progressiva. Neste modelo de implementação, um pequeno grupo de utilizadores internos ou externos recebe primeiro a nova funcionalidade. Depois de o primeiro grupo executar a nova versão sem problemas, a funcionalidade é implementada em grupos sucessivamente maiores até que toda a população de utilizadores execute a nova versão. Normalmente, os sinalizadores de funcionalidades são utilizados para ativar a nova versão para os utilizadores de destino em implementações canary.

Outro modelo de implementação comum é uma abordagem azul-verde. Neste modelo, são implementados dois conjuntos idênticos, ou conjuntos, da infraestrutura de carga de trabalho. Ambos os conjuntos conseguem processar uma carga de produção completa. O primeiro conjunto (azul) executa a versão atual da implementação onde todos os utilizadores acedem. O segundo conjunto (verde) é atualizado com a nova funcionalidade e testado internamente. Após os testes internos, um subconjunto do tráfego de produção é encaminhado do conjunto azul para o conjunto verde. Tal como as implementações canary, a implementação é progressiva à medida que muda mais do tráfego para o conjunto verde em ondas de lançamento sucessivamente maiores. Depois de concluir a implementação, o conjunto de atualizações torna-se o conjunto azul e o conjunto verde está pronto para a próxima implementação. Os dois conjuntos estão logicamente separados uns dos outros para proteger contra avarias. Pode implementar uma variação do modelo azul-verde numa carga de trabalho que utiliza o padrão de estrutura Carimbos de Implementação ao implementar num carimbo de cada vez.

Em ambos os modelos, o tempo entre cada fase da implementação deve ser suficientemente longo para permitir monitorizar as métricas de estado de funcionamento da carga de trabalho. Deve fornecer bastante tempo de cozer, tempo entre grupos de implementação, para ajudar a garantir que os utilizadores de diferentes regiões ou utilizadores que efetuam tarefas diferentes têm tempo para utilizar a carga de trabalho na sua capacidade normal. Os tempos de cozedura devem ser medidos em horas e dias em vez de minutos. Os tempos de cozedura também devem aumentar para cada grupo de implementação para que possa ter em conta diferentes fusos horários e padrões de utilização ao longo do dia.

Modelos de estado de funcionamento

Desenvolva um modelo de estado de funcionamento robusto como parte das suas estratégias de fiabilidade e plataforma de observabilidade. O modelo de estado de funcionamento deve fornecer visibilidade aprofundada sobre os componentes e o estado de funcionamento geral da carga de trabalho. Durante uma implementação, se receber um alerta sobre uma alteração de estado de funcionamento relacionada com um utilizador final, a implementação deve parar imediatamente e deve ser realizada uma investigação sobre a causa do alerta para ajudar a determinar o próximo curso de ação. Se não existirem problemas comunicados pelos utilizadores finais e todos os indicadores de estado de funcionamento permanecerem verdes durante todo o tempo de cozedura, a implementação deverá continuar. Certifique-se de que inclui métricas de utilização no seu modelo de estado de funcionamento para ajudar a garantir que a falta de problemas comunicados pelo utilizador e os sinais de estado de funcionamento negativos não estão a ocultar um problema. Para obter mais informações, veja Criar um modelo de estado de funcionamento.

Deteção de problemas

Quando a implementação causa um problema num dos grupos de implementação, a implementação tem de parar imediatamente. Uma investigação sobre a causa do problema e a gravidade dos efeitos têm de ser realizadas assim que o alerta for recebido. A recuperação do problema pode incluir:

  • Reverter a implementação ao anular as alterações efetuadas na implementação e reverter para a última configuração de trabalho conhecida.

  • Avançar a implementação ao abordar o problema no meio da implementação. Pode resolver problemas a meio da implementação ao aplicar uma correção ou minimizar o problema.

  • Implementar uma nova infraestrutura com a última configuração de trabalho conhecida.

A reversão das alterações, especialmente da base de dados, do esquema ou de outras alterações de componentes com monitorização de estado, pode ser complexa. As diretrizes do SDP devem fornecer instruções claras sobre como lidar com as alterações de dados de acordo com a estrutura do património de dados da carga de trabalho. Da mesma forma, a implementação deve ser processada cuidadosamente para garantir que o SDP não é negligenciado e que a correção ou outros esforços de minimização são realizados com segurança.

Recomendações gerais do SDP

  • Implemente o controlo de versões nos artefactos de compilação para ajudar a garantir que pode reverter e reverter quando necessário.

  • Utilize um fluxo de versão ou uma estrutura de ramificação baseada em ramais, que impõe uma colaboração fortemente sincronizada na equipa de desenvolvimento, em vez de uma estrutura de ramificação baseada no ambiente ou do Gitflow.

  • Automatize o máximo possível do seu SDP. Para obter orientações detalhadas sobre como automatizar processos de integração contínua de aplicações e integração contínua de aplicações (CI/CD), veja Recomendações para implementar a automatização.

  • Utilize práticas de CI para integrar regularmente alterações de código em repositórios. As práticas de CI podem ajudá-lo a identificar conflitos de integração e a reduzir a probabilidade de intercalações grandes e arriscadas. Para obter mais informações, veja o Guia de integração contínua.

  • Utilize sinalizadores de funcionalidades para ativar ou desativar seletivamente novas funcionalidades ou alterações na produção. Os sinalizadores de funcionalidades podem ajudá-lo a controlar a exposição do novo código e a reverter rapidamente a implementação, caso surjam problemas.

  • Implemente alterações em ambientes de teste que espelham o seu ambiente de produção. Os ambientes de prática permitem-lhe testar as alterações numa definição controlada antes de implementar no ambiente ativo.

  • Estabeleça verificações de predeployment, incluindo revisão de código, análises de segurança e verificações de conformidade, para ajudar a garantir que as alterações são seguras para implementação.

  • Implemente disjuntores para parar automaticamente o tráfego para um serviço que está a ter problemas. Fazê-lo pode ajudar a evitar uma degradação adicional do sistema.

Protocolos SDP de emergência

Estabeleça protocolos prescritivos que definem como o SDP pode ser ajustado para uma correção ou para problemas de emergência, como uma falha de segurança ou exposição a vulnerabilidades. Por exemplo, os protocolos SDP de emergência podem incluir:

  • Aceleração da fase de promoção e aprovação.

  • Teste rápido e aceleração de testes de integração.

  • Redução do tempo de cozedura.

Em alguns casos, a emergência pode limitar as portas de qualidade e teste, mas as portas ainda devem ser executadas o mais rapidamente possível como um exercício fora de banda. Certifique-se de que define quem pode aprovar a aceleração do SDP em caso de emergência e os critérios que têm de ser cumpridos para que a aceleração seja aprovada. Alinhe os protocolos SDP de emergência com o seu plano de resposta de emergência para ajudar a garantir que todas as emergências são tratadas de acordo com os mesmos protocolos.

Considerações

Criar e manter práticas de implementação seguras é complexo. O seu sucesso na implementação de normas robustas depende da maturidade das suas práticas em muitas áreas de desenvolvimento de software. A utilização da automatização, apenas iaC para alterações de infraestrutura, consistência em estratégias de ramificação, utilização de sinalizadores de funcionalidades e muitas outras práticas podem ajudar a garantir uma implementação segura. Utilize este guia para otimizar a carga de trabalho e informar os seus planos de melhoria à medida que as suas práticas evoluem.

Facilitação do Azure

  • Os Pipelines do Azure e GitHub Actions suportam implementações em várias fases através de portas de aprovação, o que pode ajudá-lo a conceber a implementação de exposição progressiva para implementações.

  • Utilize Serviço de Aplicações do Azure blocos de teste para trocar facilmente entre versões de código. Os blocos de teste são úteis para testes em ambientes de teste e podem ser utilizados para implementações verde-azulada.

  • Armazene e faça a gestão dos sinalizadores de funcionalidades da sua aplicação Web no Azure App Configuration. Ao utilizar este serviço, pode criar, alterar e implementar funcionalidades num plano de gestão unificado.

  • Implemente aplicações de carga de trabalho na máquina virtual com Aplicações de VM.

  • Utilize balanceadores de carga do Azure para implementar estratégias de implementação e expor o estado de funcionamento das aplicações de carga de trabalho com recursos nativos.

  • Utilize a extensão do Application Health para comunicar o estado de funcionamento da aplicação a partir de uma instância do Conjunto de Dimensionamento de Máquinas Virtuais. A extensão sonda um ponto final de aplicação local e atualiza o estado de funcionamento com base nas respostas TCP/HTTP(S) recebidas da aplicação.

  • Utilize o Azure Logic Apps para criar uma nova versão da aplicação sempre que for efetuada uma atualização. O Azure mantém um histórico de versões de aplicações e pode reverter ou promover para qualquer versão anterior.

  • Muitos serviços da Base de Dados do Azure fornecem funcionalidades de restauro para um ponto anterior no tempo que podem ajudá-lo a reverter. Os serviços que suportam o restauro para um ponto anterior no tempo incluem:

Exemplo

Veja o guia de arquitetura de implementação azul-verde de clusters do Azure Kubernetes Service (AKS) para obter um exemplo de como utilizar este modelo de implementação.

Lista de verificação de Excelência Operacional

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional