Recomendações para projetar uma estratégia de mitigação de falhas de implantação

  • Artigo

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

OE:12 Implemente uma estratégia de mitigação de falhas de implantação que resolva problemas inesperados no meio da implantação com recuperação rápida. Combine várias abordagens, como reversão, desativação de recursos ou usando os recursos nativos do seu padrão de implantação.

Este guia descreve as recomendações para projetar uma estratégia padronizada para lidar efetivamente com falhas de implantação. Como outros problemas de carga de trabalho, as falhas de implantação são uma parte inevitável do ciclo de vida de uma carga de trabalho. Com essa mentalidade, você pode ser proativo tendo uma estratégia bem projetada e intencional para lidar com falhas de implantação. Essa estratégia permite que sua equipe de carga de trabalho mitigue falhas de forma eficiente com o menor impacto possível em seus usuários finais.

A ausência de tal plano pode levar a respostas caóticas e potencialmente prejudiciais a problemas, o que pode afetar significativamente a coesão organizacional e da equipe, a confiança do cliente e as finanças.

Principais estratégias de design

Ocasionalmente, apesar da maturidade de suas práticas de desenvolvimento, ocorrem problemas de implantação. O uso de práticas de implantação seguras e a operação de uma cadeia de suprimentos de carga de trabalho robusta podem ajudá-lo a minimizar a frequência de implantações com falha. Mas você também precisa projetar uma estratégia padronizada para lidar com implantações com falha quando elas acontecem.

Quando você usa um modelo de implantação de exposição progressiva como prática padrão:

  • Você tem a base certa para minimizar os efeitos sobre seus clientes ou usuários internos quando as implantações falham.
  • Você pode mitigar problemas de forma eficiente.

Uma estratégia de mitigação de falhas de implantação é composta por cinco grandes fases:

  1. Deteção: Para responder a uma falha na implantação, você deve primeiro detetar a falha. A deteção pode assumir várias formas, como testes de fumaça com falha, problemas relatados pelo usuário ou alertas gerados pela sua plataforma de monitoramento.

  2. Decisão: Você deve decidir qual é a melhor estratégia de mitigação para o tipo de falha específico.

  3. Mitigação: você executa a ação de mitigação identificada. A atenuação pode assumir a forma de um fallback, rollback, roll forward ou o uso de uma configuração de tempo de execução para ignorar a função ofensiva.

  4. Comunicação: As partes interessadas e os usuários finais afetados devem estar cientes do status à medida que você deteta e resolve o problema, conforme exigido pelo seu plano de resposta a emergências.

  5. Postmortem: Postmortems irrepreensíveis oferecem oportunidades para a equipe de carga de trabalho identificar áreas de melhoria e criar planos para aplicar aprendizados.

As seções a seguir fornecem recomendações detalhadas para essas fases. Essas seções pressupõem que você detete um problema depois de implantar suas alterações em um ou mais grupos de usuários ou sistemas, mas antes de atualizar todos os grupos em seu plano de implantação.

Projetar mecanismos de deteção de falhas

Para identificar rapidamente problemas com implantações, você precisa de práticas robustas de teste e observabilidade relacionadas às implantações. Para ajudar a detetar anomalias rapidamente, você pode complementar o monitoramento e o alerta da carga de trabalho seguindo as seguintes etapas:

  • Use uma ferramenta de gerenciamento de desempenho de aplicativo.
  • Habilite o registro em log por meio de instrumentação.

Testes de fumaça e outros testes de qualidade devem acontecer em cada fase de sua implantação. Testes bem-sucedidos em um grupo de implantação não devem influenciar as decisões de teste em grupos subsequentes.

Você pode implementar a telemetria que correlaciona os problemas do usuário com uma fase de implantação. Em seguida, você pode identificar rapidamente a qual grupo de distribuição um determinado usuário está associado. Essa abordagem é especialmente importante para implantações de exposição progressiva, porque você pode ter várias configurações em execução em sua base de usuários em qualquer ponto da implantação.

Você deve estar pronto para responder aos problemas relatados pelo usuário imediatamente. Sempre que possível, implante sua fase de implantação durante o horário de trabalho, quando tiver uma equipe de suporte completa disponível. Certifique-se de que a equipe de suporte seja treinada sobre como escalar problemas de implantação para roteamento adequado. Os escalonamentos devem estar alinhados com o seu plano de resposta de emergência de carga de trabalho.

Decidir sobre a estratégia de mitigação

Decidir sobre uma estratégia de mitigação apropriada para um determinado problema de implantação envolve considerar muitos fatores, incluindo:

  • O tipo de modelo de exposição progressiva que você usa. Por exemplo, você pode usar um modelo azul-esverdeado ou um modelo canário.

    Se você usa um modelo azul-esverdeado, recuar é mais prático do que reverter. Você pode facilmente deslocar o tráfego de volta para a pilha que executa a configuração que não está atualizada. Em seguida, você pode corrigir o problema no ambiente problemático e tentar sua implantação novamente em um momento apropriado.

  • Os métodos que você tem à sua disposição para contornar o problema. Os exemplos incluem o uso de sinalizadores de recursos, variáveis ambientais ou qualquer outro tipo de propriedade de configuração de tempo de execução que você pode ativar e desativar.

    Às vezes, você pode facilmente ignorar um problema desativando um sinalizador de recurso ou alternando uma configuração. Neste caso, poderá conseguir:

    • Prossiga com a distribuição.
    • Evite cair para trás.
    • Reverter enquanto corrige o código ofensivo.

  • O nível de esforço necessário para implementar uma correção no código.

    Se o nível de esforço para corrigir o código for baixo, avançar implementando um hot fix é a escolha certa para determinados cenários.

  • O nível de criticidade para a carga de trabalho afetada.

    As cargas de trabalho críticas para os negócios devem ser sempre implantadas lado a lado, como em um modelo azul-verde, para alcançar implantações sem tempo de inatividade. Como resultado, o fallback é a estratégia de mitigação preferível para esses tipos de cargas de trabalho.

  • O tipo de infraestrutura que a carga de trabalho usa — mutável ou imutável.

    Se sua carga de trabalho for projetada para usar uma infraestrutura mutável, a rolagem pode fazer sentido, pois envolve a atualização da infraestrutura instalada. Por outro lado, reverter ou recuar pode fazer sentido quando você usa uma infraestrutura imutável.

Não importa quais escolhas você faça, você deve incluir aprovações apropriadas em seu processo de tomada de decisão e codificá-las em sua árvore de decisão.

Implementar a estratégia de mitigação

  • Reversão: em um cenário de reversão, você reverte os sistemas atualizados para o último estado de configuração em boas condições.

    É importante que toda a equipe de carga de trabalho concorde sobre o significado de último bem conhecido. Esta expressão refere-se ao último estado da carga de trabalho que estava íntegra antes do início da implantação, que não é necessariamente a versão anterior do aplicativo.

    A reversão pode ser complexa, especialmente no que diz respeito a alterações de dados. As alterações de esquema podem tornar a reversão arriscada. A sua implementação segura pode exigir um planeamento considerável. Como recomendação geral, as atualizações de esquema devem ser aditivas. Não devem ser alterações de substituição — os registos não devem ser substituídos por novos registos. Em vez disso, os registros mais antigos devem ser preteridos e devem coexistir com os novos registros até que seja seguro remover os registros preteridos.

  • Fallback: em um cenário de fallback, os sistemas atualizados são removidos do roteamento de tráfego de produção. Todo o tráfego é direcionado para a pilha que não é atualizada. Essa estratégia de baixo risco fornece uma maneira de resolver os problemas em seu código sem introduzir mais interrupções.

    Com implantações canárias, o retorno pode não ser simples ou mesmo possível, dependendo da sua infraestrutura e do design do aplicativo. Se você precisar executar o dimensionamento para lidar com a carga em sistemas que não estão atualizados, execute esse dimensionamento antes de voltar.

  • Ignorar a função ofensiva: Se você puder ignorar o problema usando sinalizadores de recurso ou outro tipo de propriedade de configuração de tempo de execução, poderá decidir que continuar com a distribuição é a estratégia certa para um determinado problema.

    Você deve entender claramente o tradeoff de ignorar a função, e você deve ser capaz de comunicar esse tradeoff às partes interessadas. As partes interessadas devem aprovar o plano de avanço. As partes interessadas precisam determinar o período de tempo tolerável para operar em um estado degradado. Eles também precisam pesar essa determinação em relação à sua estimativa do tempo necessário para corrigir o código ofensivo e implantá-lo.

  • Implantação de emergência (hot fix): se você puder resolver o problema no meio da implantação, um hot fix pode ser a estratégia de mitigação mais prática.

    Como qualquer outro código, os hot fixes precisam passar por suas práticas de implantação seguras. Mas com um hot fix, o cronograma é consideravelmente acelerado. Você precisa usar uma estratégia de promoção de código em todos os seus ambientes. Você também precisa verificar o código de hot fix em todos os portões de qualidade. Mas você pode precisar reduzir drasticamente os tempos de cozimento, e você pode precisar modificar os testes para acelerá-los. Certifique-se de que você possa executar testes completos no código atualizado o mais rápido possível após a implantação. Automatizar os testes de garantia de qualidade em alto grau ajuda a tornar os testes eficientes nesses cenários.

Compensações:

  • Ser capaz de fazer fallback normalmente significa que você precisa de capacidade de infraestrutura suficiente para lidar com duas versões da configuração da sua carga de trabalho ao mesmo tempo. Suas equipes de carga de trabalho também precisam ser capazes de suportar duas versões em produção ao mesmo tempo.
  • Ser capaz de reverter de forma eficaz pode envolver a refatoração de elementos da sua carga de trabalho. Por exemplo, talvez seja necessário desacoplar funções ou alterar o modelo de dados.

Padronizar atualizações de status durante um incidente

É importante ter responsabilidades de comunicação claramente definidas para ajudar a minimizar o caos durante os incidentes. Essas responsabilidades devem estabelecer como a equipe de carga de trabalho se envolve com as equipes de suporte, partes interessadas e pessoal da equipe de resposta a emergências, como o gerente de resposta a emergências.

Padronize a cadência que a equipe de carga de trabalho segue para fornecer atualizações de status. Certifique-se de que as partes interessadas estejam cientes dessa norma para que saibam quando esperar atualizações.

Se a equipe de carga de trabalho precisar se comunicar diretamente com os usuários finais, esclareça o tipo de informações e o nível de detalhe apropriados para compartilhamento com os usuários. Comunique também à equipe de carga de trabalho quaisquer outros requisitos que se apliquem a esses casos.

Conduzir incidentes post mortems

Postmortems devem seguir todas as implantações com falha, sem exceção. Cada implantação falhada é uma oportunidade de aprendizagem. Postmortems pode ajudá-lo a identificar pontos fracos em seus processos de implantação e desenvolvimento. Você também pode identificar configurações incorretas em sua infraestrutura, entre muitas outras possibilidades.

Os post mortems devem ser sempre irrepreensíveis para que os indivíduos envolvidos no incidente se sintam seguros quando partilham as suas perspetivas sobre o que pode ser melhorado. Os líderes post-mortem devem seguir com planos para implementar as melhorias que foram identificadas e adicionar esses planos à lista de pendências de carga de trabalho.

Operacionalizar processos de mitigação

Certifique-se de que seu pipeline de implantação possa aceitar versões distintas como parâmetros para que você possa implantar facilmente as últimas configurações em boas condições.

Mantenha a consistência com os planos de gerenciamento e de dados à medida que você reverte ou avança. Chaves, segredos, dados de estado do banco de dados e configurações específicas de recursos e políticas precisam estar no escopo e ser contabilizados. Por exemplo, preste atenção ao design do dimensionamento da infraestrutura na última implantação em boas condições. Determine se você precisa ajustar essa configuração ao reimplantar seu código.

Prefira alterações pequenas e frequentes em vez de alterações grandes e pouco frequentes, para que o delta entre suas implantações novas e as últimas implantações em boas condições seja pequeno.

Execute uma análise de modo de falha (FMA) em seus pipelines de integração contínua e entrega contínua (CI/CD) para ajudar a identificar problemas que podem complicar as mitigações. Como sua carga de trabalho como um todo, seus pipelines podem ser analisados para identificar áreas que podem ser problemáticas quando você tenta um determinado tipo de mitigação.

Use a funcionalidade de reversão automatizada criteriosamente:

  • Algumas ferramentas de CI/CD, como o Azure DevOps, têm a funcionalidade de reversão automática incorporada. Considere usar essa funcionalidade se ela fornecer valor tangível para você.
  • Você deve adotar a funcionalidade de reversão automática somente depois de testar seu pipeline completa e regularmente. Certifique-se de que seu pipeline esteja maduro o suficiente para introduzir problemas extras se uma reversão automática for acionada.
  • Você precisa confiar que a automação implanta apenas as alterações necessárias e que é acionada apenas quando necessário. Projete seus gatilhos cuidadosamente para atender a esses requisitos.

Use os recursos fornecidos pela plataforma durante as reversões. Por exemplo, backups e restaurações point-in-time podem ajudar com armazenamento e reversões de dados. Ou se você usar máquinas virtuais (VMs) para hospedar seu aplicativo, pode ser útil restaurar seu ambiente para um ponto de verificação imediatamente antes de um incidente.

Teste toda a sua estratégia de mitigação de falhas de implantação com frequência. Assim como os planos de resposta a emergências e os planos de recuperação de desastres, seu plano de falha de implantação só será bem-sucedido se sua equipe for treinada nele e praticá-lo regularmente. A engenharia do caos e o teste de injeção de falhas podem ser técnicas eficazes para testar sua estratégia de mitigação de implantação.

Compensação: Os membros da equipe de suporte precisam ser capazes de desempenhar suas funções normais e também apoiar emergências. Pode ser necessário aumentar o número de funcionários para ajudar a garantir que a equipe de suporte tenha pessoal adequado e seja capaz de realizar todas as tarefas necessárias. Teste implantações completamente ao implantar em ambientes de desenvolvimento inferiores. Essa prática ajuda a detetar bugs e configurações incorretas antes que eles cheguem à produção.

Facilitação do Azure

  • O Azure Pipelines fornece serviços de compilação e lançamento para dar suporte a CI/CD de seus aplicativos.

  • Os Planos de Teste do Azure são uma solução de gerenciamento de teste baseada em navegador que é fácil de usar. Essa solução oferece recursos necessários para testes manuais planejados, testes de aceitação do usuário e testes exploratórios. Os Planos de Teste do Azure também fornecem uma maneira de coletar comentários das partes interessadas.

  • O Azure Monitor é uma solução de monitorização abrangente para recolher, analisar e responder a dados de monitorização a partir da sua nuvem e ambientes locais. O Monitor inclui uma plataforma de alerta robusta. Você pode configurar esse sistema para notificações automáticas e outras ações, como dimensionamento automático e outros mecanismos de autorrecuperação.

  • O Application Insights é uma extensão do Monitor que fornece recursos de monitoramento de desempenho de aplicativos (APM).

  • As Aplicações Lógicas do Azure são uma plataforma baseada na nuvem para executar fluxos de trabalho automatizados que integram aplicações, dados, serviços e sistemas. Você pode usar os Aplicativos Lógicos para criar uma nova versão do seu aplicativo sempre que uma atualização for feita nele. O Azure mantém um histórico das versões e pode reverter ou promover qualquer versão anterior.

  • Muitos serviços de banco de dados do Azure fornecem funcionalidade de restauração point-in-time que pode ajudá-lo quando você precisar reverter:

  • O Azure Chaos Studio Preview é um serviço gerenciado que usa a engenharia do caos para ajudá-lo a medir, entender e melhorar a resiliência do aplicativo e do serviço na nuvem.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional