Compartilhar via

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

  • Artigo

Aplica-se a esta recomendação da lista de verificação do Azure Well-Architected Framework Operational Excellence:

OE: 12 Implemente uma estratégia de mitigação de falhas de implantação que resolva problemas inesperados no meio da distribuição com recuperação rápida. Combine várias abordagens, como reversão, desabilitação de recursos ou uso dos recursos nativos do 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 intencional e bem projetada para lidar com falhas de implantação. Essa estratégia permite que sua equipe de carga de trabalho reduza falhas com eficiência com o mínimo de impacto possível em seus usuários finais.

A ausência de tal plano pode levar a respostas caóticas e potencialmente prejudiciais aos problemas, o que pode afetar significativamente a coesão da equipe e da organização, 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 sua 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 com eficiência.

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

  1. Detecção: para responder a uma implantação com falha, você deve primeiro detectar a falha. A detecção pode assumir várias formas, como testes de fumaça com falha, problemas relatados pelo usuário ou alertas gerados por 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 mitigação pode assumir a forma de fallback, rollback, roll forward ou o uso de uma configuração de runtime 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ê detecta e trabalha com o problema, conforme exigido pelo seu plano de resposta a emergências.

  5. Post-mortem: Post-mortems sem culpa 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ê detecte 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 distribuição.

Projetar mecanismos de detecçã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 detectar anomalias rapidamente, você pode complementar o monitoramento e os alertas da carga de trabalho executando as seguintes etapas:

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

Testes de fumaça e outros testes de qualidade devem acontecer em cada fase de sua distribuiçã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, pois 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 a problemas relatados pelo usuário imediatamente. Sempre que possível, implante sua fase de distribuição durante o horário de trabalho, quando você 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 seu plano de resposta a emergências de carga de trabalho.

Decida 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-verde ou um modelo canário.

    Se você usar um modelo azul-esverdeado, recuar é mais prático do que reverter. Você pode facilmente transferir 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 no 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. Nesse caso, você pode ser capaz de:

    • Prossiga com a distribuição.
    • Evite recuar.
    • Reverta 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 sempre devem ser implantadas lado a lado, como em um modelo azul-verde, para obter implantações com tempo de inatividade zero. 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 infraestrutura mutável, o rollforward pode fazer sentido, pois envolve a atualização da infraestrutura local. Por outro lado, reverter ou retroceder pode fazer sentido quando você usa uma infraestrutura imutável.

Não importa quais escolhas você faça, você deve incluir as 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 válido.

    É importante que toda a equipe de carga de trabalho concorde sobre o significado de último bem conhecido. Essa expressão refere-se ao último estado da carga de trabalho que estava íntegro 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 se refere a alterações de dados. As alterações de esquema podem tornar a reversão arriscada. Implementá-los com segurança pode exigir um planejamento considerável. Como recomendação geral, as atualizações de esquema devem ser aditivas. Eles não devem ser alterações de substituição - os registros não devem ser substituídos por novos registros. Em vez disso, os registros mais antigos devem ser preteridos e devem coexistir com 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 está 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 fallback pode não ser simples ou mesmo possível, dependendo da 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 fazer fallback.

  • 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 a compensação de ignorar a função e deve ser capaz de comunicar essa compensação à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 distribuiçã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 uma solução quente, 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 talvez seja necessário reduzir drasticamente os tempos de cozimento e 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 de sua configuração de carga de trabalho ao mesmo tempo. Suas equipes de carga de trabalho também precisam ser capazes de dar suporte a duas versões em produção ao mesmo tempo.
  • Ser capaz de reverter efetivamente pode envolver a refatoração de elementos de sua carga de trabalho. Por exemplo, talvez seja necessário desacoplar funções ou alterar seu 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, as partes interessadas e o 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 desse padrão 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ção e o nível de detalhes apropriados para compartilhamento com os usuários. Comunique também à equipe de carga de trabalho quaisquer outros requisitos que se apliquem a esses casos.

Realizar autópsias de incidentes

As autópsias devem seguir todas as implantações com falha, sem exceção. Cada implantação fracassada é uma oportunidade de aprendizado. As autópsias podem 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.

As autópsias devem sempre ser inocentes para que os indivíduos envolvidos no incidente se sintam seguros ao compartilhar suas perspectivas sobre o que pode ser melhorado. Os líderes de análise retrospectiva devem acompanhar os planos para implementar as melhorias que foram identificadas e adicionar esses planos ao backlog da carga de trabalho.

Operacionalizar processos de mitigação

Verifique se o pipeline de implantação pode aceitar versões distintas como parâmetros para que você possa implantar facilmente as últimas configurações válidas.

Mantenha a consistência com os planos de gerenciamento e de dados à medida que você retrocede ou avança. Chaves, segredos, dados de estado do banco de dados e configurações específicas para recursos e políticas precisam estar no escopo e ser contabilizados. Por exemplo, preste atenção ao design do dimensionamento de sua infraestrutura em sua última implantação válida. 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 em boas condições seja pequeno.

Execute uma FMA (análise de modo de falha) em seus pipelines de CI/CD (integração contínua e entrega contínua) 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 interna. 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 disparada.
  • Você precisa confiar que a automação implanta apenas as alterações necessárias e que é acionada apenas quando necessário. Projete seus gatilhos com cuidado para atender a esses requisitos.

Use recursos fornecidos pela plataforma durante reversões. Por exemplo, backups e restaurações pontuais podem ajudar com reversões de armazenamento e dados. Ou, se você usar VMs (máquinas virtuais) 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 de 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 uma equipe adequada e seja capaz de realizar todas as tarefas necessárias. Teste as implantações minuciosamente ao implantar em ambientes de desenvolvimento inferiores. Essa prática ajuda a detectar bugs e configurações incorretas antes que eles cheguem à produção.

Facilitação do Azure

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

  • O Azure Test Plans é 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 dos stakeholders.

  • O Azure Monitor é uma solução de monitoramento abrangente para coletar, analisar e responder a dados de monitoramento de seus ambientes locais e de nuvem. 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 autocorreção.

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

  • Os Aplicativos Lógicos do Azure são uma plataforma baseada em nuvem para executar fluxos de trabalho automatizados que integram aplicativos, 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 pontual que pode ajudá-lo quando você precisar reverter:

  • A Versão Prévia do Azure Chaos Studio é um serviço gerenciado que usa a engenharia do caos para ajudar você a avaliar, entender e melhorar a resiliência de aplicativos e serviços de nuvem.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional