Recomendações para práticas de implantação seguras

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 implantação seguras da carga de trabalho. Enfatize os ideais de métodos de versão pequenos, incrementais e com controle de qualidade. Use padrões de implantação modernos e técnicas progressivas de exposição para controlar o risco. Conta para implantações de rotina e implantações de emergência ou hotfix.

Este guia descreve as recomendações para usar práticas de implantação seguras (SDP). Processos e procedimentos de implantação seguros definem como fazer e implantar alterações com segurança em sua carga de trabalho. A implementação do SDP exige que você pense nas implantações por meio da lente do gerenciamento de riscos. Você pode minimizar o risco de erro humano em suas implantações e limitar os efeitos de implantações problemáticas em seus usuários implementando o SDP.

Principais estratégias de design

Há quatro diretrizes importantes para ter em mente ao implementar práticas de implantação seguras:

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

  • Exposição progressiva: você pode minimizar o raio de explosão potencial de problemas causados pela implantação adotando um modelo de implantação de exposição progressiva.

  • Modelos de integridade: as implantações devem passar por verificações de integridade antes que cada fase de exposição progressiva possa começar.

  • Detecção de problemas: quando os problemas são detectados, a implantação deve ser interrompida imediatamente e a recuperação é iniciada.

As seções a seguir fornecem recomendações detalhadas sobre cada um desses pontos.

Segurança e consistência

Se você estiver implantando uma atualização no código do aplicativo, iac (infraestrutura como código), sinalizador de recurso ou uma atualização de configuração, você está introduzindo risco à carga de trabalho. Não há implantações de baixo risco para produção. Cada implantação deve 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 carga de trabalho e os pipelines de implantação sejam confiáveis, seguros e tenham padrões de implantação claramente definidos. Trate cada implantação como um possível risco e submedite cada implantação ao mesmo nível de gerenciamento de riscos. Apesar dos riscos, você deve continuar implantando alterações regulares em sua carga de trabalho. A falha na implantação de atualizações regulares apresenta outros riscos, como vulnerabilidades de segurança que devem ser resolvidas por meio de implantações. Para obter mais informações, consulte Recomendações para criar uma cadeia de fornecimento de desenvolvimento de carga de trabalho.

Implantações pequenas frequentes são preferíveis a implantações grandes pouco frequentes. Pequenas alterações são mais fáceis de resolve quando surgem problemas e implantações frequentes ajudam sua equipe a criar confiança no processo de implantação. Também é importante que você aprenda com a produção examinando seus processos de carga de trabalho quando encontrar uma anomalia durante a implantação. Você pode encontrar pontos fracos no design de sua infraestrutura ou distribuição. Quando ocorrerem problemas durante as implantações, verifique se as postmortems sem culpa fazem parte do processo de SDP para capturar lições sobre o incidente.

Implantação progressiva de exposição

Quando ocorrem problemas de implantação, a meta é pegá-los o mais cedo possível para minimizar o efeito sobre os usuários finais. Implemente um modelo de implantação de distribuição gradual, também conhecido como modelo de exposição progressiva, para atingir essa meta. As implantações canário são um exemplo comum de exposição progressiva. Nesse modelo de implantação, um pequeno grupo de usuários internos ou externos recebe o novo recurso primeiro. Depois que o primeiro grupo executa a nova versão sem problemas, o recurso é implantado em grupos sucessivamente maiores até que toda a população de usuários esteja executando a nova versão. Os sinalizadores de recursos normalmente são usados para habilitar a nova versão para os usuários de destino em implantações canário.

Outro modelo de implantação comum é uma abordagem azul-verde. Nesse modelo, dois conjuntos idênticos, ou pools, de infraestrutura de carga de trabalho são implantados. Ambos os pools são capazes de lidar com uma carga de produção completa. O primeiro pool (azul) executa a versão atual da implantação em que todos os usuários chegam. O segundo pool (verde) é atualizado com o novo recurso e testado internamente. Após o teste interno, um subconjunto do tráfego de produção é roteado do pool azul para o pool verde. Como implantações canário, a distribuição é progressiva à medida que você desloca mais do tráfego para o pool verde em ondas de distribuição sucessivamente maiores. Depois de concluir a distribuição, o pool de atualizações se tornará o pool azul e o pool verde estará pronto para a próxima implantação. Os dois pools são logicamente separados um do outro para proteger contra falhas. Você pode implantar uma variação do modelo azul-verde em uma carga de trabalho que usa o padrão de design Selos de Implantação implantando em um carimbo de cada vez.

Em ambos os modelos, o tempo entre cada fase da distribuição deve ser longo o suficiente para permitir que você monitore as métricas de integridade da carga de trabalho. Você deve fornecer um amplo tempo de bake, tempo entre grupos de distribuição, para ajudar a garantir que usuários de diferentes regiões ou usuários que executam tarefas diferentes tenham tempo para usar a carga de trabalho em sua capacidade normal. Os horários de assar devem ser medidos em horas e dias, em vez de minutos. Os horários de bake também devem aumentar para cada grupo de distribuição para que você possa considerar diferentes fusos horários e padrões de uso ao longo do dia.

Modelos de integridade

Desenvolva um modelo de integridade robusto como parte de sua plataforma de observabilidade e estratégias de confiabilidade. Seu modelo de integridade deve fornecer visibilidade detalhada sobre os componentes e a integridade geral da carga de trabalho. Durante uma distribuição, se você receber um alerta sobre uma alteração de integridade relacionada a um usuário final, a distribuição deverá ser interrompida imediatamente e uma investigação sobre a causa do alerta deverá ser executada para ajudar a determinar o próximo curso de ação. Se não houver problemas relatados pelos usuários finais e todos os indicadores de integridade permanecerem verdes durante todo o tempo de bake, a distribuição deverá continuar. Certifique-se de incluir métricas de uso em seu modelo de integridade para ajudar a garantir que a falta de problemas relatados pelo usuário e sinais de integridade negativos não estejam ocultando um problema. Para obter mais informações, consulte Criando um modelo de integridade.

Detecção de problemas

Quando sua implantação causa um problema em um dos grupos de distribuição, a distribuição deve parar imediatamente. Uma investigação sobre a causa do problema e a gravidade dos efeitos deve ser executada assim que o alerta é recebido. A recuperação do problema pode incluir:

  • Revertendo a implantação desfazendo as alterações feitas na implantação e revertendo para a última configuração de trabalho conhecida.

  • Encaminhar a implantação resolvendo o problema no meio da distribuição. Você pode resolver problemas no meio da distribuição aplicando um hotfix ou minimizando o problema.

  • Implantando uma nova infraestrutura usando a última configuração de trabalho conhecida.

A reversão de alterações, especialmente o banco de dados, o esquema ou outras alterações de componente com estado, pode ser complexa. Suas diretrizes de SDP devem fornecer instruções claras sobre como lidar com alterações de dados de acordo com o design do acervo de dados para sua carga de trabalho. Da mesma forma, o encaminhamento sem interrupção deve ser tratado com cuidado para garantir que o SDP não seja negligenciado e que o hotfix ou outros esforços de minimização sejam executados com segurança.

Recomendações gerais do SDP

  • Implemente o controle de versão em seus artefatos de build para ajudar a garantir que você possa reverter e reverter quando necessário.

  • Use um fluxo de lançamento ou uma estrutura de ramificação baseada em tronco, que impõe a colaboração totalmente sincronizada em toda a equipe de desenvolvimento, em vez de uma estrutura de ramificação baseada em ambiente ou gitflow.

  • Automatize o máximo possível do SDP. Para obter diretrizes detalhadas sobre como automatizar a IaC e os processos de CI/CD (integração contínua e entrega contínua de aplicativos), confira Recomendações para implementar a automação.

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

  • Use sinalizadores de recursos para habilitar ou desabilitar seletivamente novos recursos ou alterações na produção. Os sinalizadores de recursos podem ajudá-lo a controlar a exposição do novo código e reverter rapidamente a implantação se surgirem problemas.

  • Implante alterações em ambientes de preparo que espelho seu ambiente de produção. Os ambientes de prática permitem que você teste as alterações em uma configuração controlada antes de implantar no ambiente ativo.

  • Estabeleça verificações de pré-implantação, incluindo revisão de código, verificações de segurança e verificações de conformidade, para ajudar a garantir que as alterações sejam seguras de implantar.

  • Implemente disjuntores para interromper automaticamente o tráfego para um serviço que está enfrentando problemas. Isso pode ajudar a evitar uma degradação adicional do sistema.

Protocolos SDP de emergência

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

  • Aceleração do estágio de promoção e aprovação.

  • Teste de fumaça e aceleração de teste de integração.

  • Redução de tempo do bake.

Em alguns casos, a emergência pode limitar a qualidade e os portões de teste, mas os portões ainda devem ser executados o mais rápido possível que um exercício fora de banda. Defina quem pode aprovar a aceleração do SDP em uma emergência e os critérios que devem ser atendidos para que a aceleração seja aprovada. Alinhe seus protocolos SDP de emergência com seu plano de resposta de emergência para ajudar a garantir que todas as emergências sejam tratadas de acordo com os mesmos protocolos.

Considerações

A criação e a manutenção de práticas de implantação seguras são complexas. Seu sucesso na implementação completa de padrões robustos depende da maturidade de suas práticas em muitas áreas de desenvolvimento de software. O uso de automação, somente IaC para alterações de infraestrutura, consistência em estratégias de ramificação, uso de sinalizadores de recursos e muitas outras práticas podem ajudar a garantir uma implantação segura. Use este guia para otimizar sua carga de trabalho e informar seus planos de melhoria à medida que suas práticas evoluem.

Facilitação do Azure

Exemplo

Consulte o guia de arquitetura de clusters do AKS (implantação de Serviço de Kubernetes do Azure) azul-verde para obter um exemplo de como usar esse modelo de implantação.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.