Share via

Recomendações para conceber uma estratégia de mitigação de falhas de implementaçã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 implementação que resolve problemas inesperados de implementação intermédia com a recuperação rápida. Combine várias abordagens, como reversão, desativação de funcionalidades ou utilização das capacidades nativas do padrão de implementação.

Este guia descreve as recomendações para conceber uma estratégia padronizada para lidar eficazmente com falhas de implementação. À semelhança de outros problemas de carga de trabalho, as falhas de implementação são uma parte inevitável do ciclo de vida de uma carga de trabalho. Com esta mentalidade, pode ser proativo ao ter uma estratégia bem concebida e intencional para lidar com falhas de implementação. Esta estratégia permite à sua equipa de cargas de trabalho mitigar falhas de forma eficiente com o menor impacto possível nos seus utilizadores finais.

A ausência de tal plano pode levar a respostas caóticas e potencialmente prejudiciais a questões, que podem afetar significativamente a coesão da equipa e da organização, a confiança dos clientes e as finanças.

Principais estratégias de design

Ocasionalmente, apesar da maturidade das suas práticas de desenvolvimento, ocorrem problemas de implementação. Utilizar práticas de implementação seguras e operar uma cadeia de fornecimento de cargas de trabalho robustas pode ajudá-lo a minimizar a frequência de implementações falhadas. Mas também tem de conceber uma estratégia padronizada para lidar com implementações falhadas quando ocorrem.

Quando utiliza um modelo de implementação de exposição progressiva como prática padrão:

  • Tem a base certa para minimizar os efeitos nos seus clientes ou utilizadores internos quando as implementações falham.
  • Pode mitigar os problemas de forma eficiente.

Uma estratégia de mitigação de falhas de implementação é composta por cinco fases gerais:

  1. Deteção: para responder a uma implementação com falhas, primeiro tem de detetar a falha. A deteção pode assumir várias formas, como testes de fumo falhados, problemas comunicados pelo utilizador ou alertas gerados pela plataforma de monitorização.

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

  3. Mitigação: executa a ação de mitigação identificada. A mitigação pode assumir a forma de uma contingência, reversão, reversão, reversão ou utilização de uma configuração de runtime para ignorar a função ofensiva.

  4. Comunicação: os intervenientes e os utilizadores finais afetados têm de estar cientes do estado à medida que deteta e trabalha através do problema, conforme exigido pelo seu plano de resposta de emergência.

  5. Postmortem: as postmortems sem culpa proporcionam oportunidades para a equipa de carga de trabalho identificar áreas para melhorar e criar planos para aplicar aprendizagens.

As secções seguintes fornecem recomendações detalhadas para estas fases. Estas secções partem do princípio de que deteta um problema depois de implementar as alterações a um ou mais grupos de utilizadores ou sistemas, mas antes de atualizar todos os grupos no seu plano de implementação.

Deteção

Para identificar rapidamente problemas com implementações, precisa de práticas robustas de teste e de observabilidade , uma vez que estão relacionadas com implementações. Para ajudar a detetar anomalias rapidamente, pode complementar a monitorização e os alertas da carga de trabalho ao seguir os seguintes passos:

  • Utilize uma ferramenta de gestão de desempenho de aplicações.
  • Ativar o registo através da instrumentação.

Os testes de fumo e outros testes de qualidade devem ocorrer em cada fase da sua implementação. Os testes bem-sucedidos num grupo de implementação não devem influenciar as decisões de teste em grupos subsequentes.

Pode implementar telemetria que correlaciona problemas de utilizador com uma fase de implementação. Em seguida, pode identificar rapidamente a que grupo de implementação um determinado utilizador está associado. Esta abordagem é especialmente importante para implementações de exposição progressiva, uma vez que pode ter várias configurações em execução na sua base de utilizadores em qualquer ponto da implementação.

Deve estar pronto para responder imediatamente aos problemas comunicados pelo utilizador. Sempre que for prático, implemente a fase de implementação durante o horário de trabalho, quando tiver uma equipa de suporte completa disponível. Certifique-se de que a equipa de suporte está preparada para como escalar os problemas de implementação para o encaminhamento adequado. Os escalamentos devem estar alinhados com o plano de resposta de emergência da carga de trabalho.

Decisão

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

  • O tipo de modelo de exposição progressiva que utiliza. Por exemplo, pode utilizar um modelo azul-verde ou um modelo canário.

    Se utilizar um modelo azul-verde, recuar é mais prático do que reverter. Pode transferir facilmente o tráfego para a pilha que executa a configuração que não é atualizada. Em seguida, pode corrigir o problema no ambiente problemático e tentar a sua implementação novamente num momento adequado.

  • Os métodos que tem à sua disposição para ignorar o problema. Os exemplos incluem a utilização de sinalizadores de funcionalidades, variáveis ambientais ou qualquer outro tipo de propriedade de configuração de runtime que possa ativar e desativar.

    Por vezes, pode ignorar facilmente um problema ao desativar um sinalizador de funcionalidade ou ao alternar uma definição. Neste caso, poderá conseguir:

    • Prossiga com a implementaçã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 ao implementar uma correção frequente é a escolha certa para determinados cenários.

  • O nível de criticidade da carga de trabalho afetada.

    As cargas de trabalho críticas para a empresa devem ser sempre implementadas lado a lado, como num modelo azul-verde, para alcançar implementações de tempo de inatividade zero. Como resultado, recuar é a estratégia de mitigação preferível para estes tipos de cargas de trabalho.

  • O tipo de infraestrutura que a carga de trabalho utiliza: mutável ou imutável.

    Se a carga de trabalho for concebida para utilizar uma infraestrutura mutável, avançar pode fazer sentido, porque envolve atualizar a infraestrutura em vigor. Por outro lado, reverter ou recuar pode fazer sentido quando utiliza uma infraestrutura imutável.

Independentemente das escolhas que fizer, deve incluir aprovações adequadas no seu processo de tomada de decisão e codificá-las na árvore de decisões.

Mitigação

  • Reversão: num cenário de reversão, reverte os sistemas atualizados para o último estado de configuração bem conhecido.

    É importante que toda a equipa de cargas de trabalho concorde com o significado do último bem conhecido. Esta expressão refere-se ao último estado da carga de trabalho que estava em bom estado de funcionamento antes do início da implementação, que não é necessariamente a versão anterior da aplicação.

    Reverter pode ser complexo, especialmente porque se relaciona com as alterações de dados. As alterações de esquema podem tornar a reversão arriscada. Implementá-los em segurança 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 registos mais antigos devem ser preteridos e devem coexistir com novos registos até que seja seguro remover os registos preteridos.

  • Contingência: num cenário de contingência, os sistemas atualizados são removidos do encaminhamento de tráfego de produção. Todo o tráfego é direcionado para a pilha que não é atualizada. Esta estratégia de baixo risco fornece uma forma de resolver os problemas no seu código sem introduzir mais interrupções.

    Com as implementações canary, a reativação pode não ser simples ou mesmo possível, dependendo da infraestrutura e da estrutura da aplicação. Se precisar de efetuar o dimensionamento para processar a carga em sistemas que não são atualizados, efetue esse dimensionamento antes de recuar.

  • Ignorar a função ofensiva: se conseguir contornar o problema utilizando sinalizadores de funcionalidades ou outro tipo de propriedade de configuração de runtime, poderá decidir que continuar com a implementação é a estratégia certa para um determinado problema.

    Deve compreender claramente a desvantagem de ignorar a função e deve conseguir comunicar essa troca aos intervenientes. Os intervenientes devem aprovar o plano de avanço. Os intervenientes têm de determinar o período de tempo tolerável para operar num estado degradado. Também precisam de ponderar essa determinação em relação à estimativa do tempo necessário para corrigir o código ofensivo e implementá-lo.

  • Implementação de emergência (correção frequente): se conseguir resolver o problema a meio da implementação, uma correção frequente poderá ser a estratégia de mitigação mais prática.

    Como qualquer outro código, as correções frequentes têm de passar pelas suas práticas de implementação seguras. Mas com uma correção frequente, a linha cronológica é consideravelmente acelerada. Tem de utilizar uma estratégia de promoção de código em todos os seus ambientes. Também tem de verificar o código de correção frequente em todas as portas de qualidade. Mas poderá ter de encurtar drasticamente os tempos de cozedura e poderá ter de modificar os testes para os acelerar. Certifique-se de que pode executar testes completos no código atualizado o mais rapidamente possível após a implementação. Automatizar testes de garantia de qualidade em alto grau ajuda a tornar os testes eficientes nestes cenários.

Vantagens:

  • Ser capaz de recuar normalmente significa que precisa de capacidade de infraestrutura suficiente para lidar com duas versões da configuração da carga de trabalho ao mesmo tempo. As suas equipas de carga de trabalho também precisam de conseguir suportar duas versões em produção ao mesmo tempo.
  • Ser capaz de reverter eficazmente pode envolver a refatorização de elementos da sua carga de trabalho. Por exemplo, poderá ter de desassociar funções ou alterar o modelo de dados.

Comunicação

É importante ter responsabilidades de comunicação claramente definidas para ajudar a minimizar o caos durante os incidentes. Estas responsabilidades devem estabelecer a forma como a equipa de carga de trabalho interage com as equipas de suporte, os intervenientes e o pessoal da equipa de resposta de emergência, como o gestor de resposta de emergência.

Uniformize a cadência que a equipa de carga de trabalho segue para fornecer atualizações de estado. Certifique-se de que os intervenientes estão cientes desta norma para que saibam quando devem esperar atualizações.

Se a equipa da carga de trabalho precisar de comunicar diretamente com os utilizadores finais, esclareça o tipo de informações e o nível de detalhe adequados para partilhar com os utilizadores. Comunique também à equipa de cargas de trabalho quaisquer outros requisitos que se apliquem a estes casos.

Autópsia

As autópsias devem seguir todas as implementações falhadas, sem exceção. Cada implementação falhada é uma oportunidade de aprendizagem. As autópsias podem ajudá-lo a identificar pontos fracos nos processos de implementação e desenvolvimento. Também pode identificar configurações incorretas na sua infraestrutura, entre muitas outras possibilidades.

As autópsias devem ser sempre inocentes para que os indivíduos envolvidos no incidente se sintam seguros quando partilham as suas perspectivas sobre o que pode ser melhorado. Os líderes pós-morte devem acompanhar os planos para implementar as melhorias que foram identificadas e adicionar estes planos ao registo de tarefas pendentes da carga de trabalho.

Considerações e recomendações gerais

Certifique-se de que o pipeline de implementação pode aceitar versões distintas como parâmetros para que possa facilmente implementar as configurações mais recentes e adequadas.

Mantenha a consistência com os planos de gestão e dados à medida que reverte ou avança. As chaves, os segredos, os dados de estado da base de dados e as configurações específicas dos recursos e das políticas têm de estar no âmbito e contabilizadas. Por exemplo, preste atenção à conceção do dimensionamento da sua infraestrutura na última implementação bem conhecida. Determine se precisa de ajustar essa configuração quando reimplementar o código.

Prefere alterações pequenas e frequentes em vez de alterações grandes e pouco frequentes para que o delta entre as suas novas e últimas implementações conhecidas seja pequeno.

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

Utilize a funcionalidade de reversão automatizada criteriosamente:

  • Algumas ferramentas de CI/CD, como o Azure DevOps, têm funcionalidades de reversão automática incorporadas. Considere utilizar esta funcionalidade se lhe fornecer valor tangível.
  • Só deve adotar a funcionalidade de reversão automática depois de testar o pipeline de forma completa e regular. Certifique-se de que o pipeline é suficientemente maduro para introduzir problemas adicionais se for acionada uma reversão automática.
  • Tem de confiar que a automatização implementa apenas as alterações necessárias e que é acionada apenas quando necessário. Crie cuidadosamente os seus acionadores para cumprir estes requisitos.

Utilize as capacidades fornecidas pela plataforma durante as reversões. Por exemplo, as cópias de segurança e os restauros para um ponto anterior no tempo podem ajudar com o armazenamento e as reversões de dados. Em alternativa, se utilizar máquinas virtuais (VMs) para alojar a sua aplicação, pode ser útil restaurar o seu ambiente para um ponto de verificação imediatamente antes de um incidente.

Teste com frequência toda a estratégia de mitigação de falhas de implementação. Tal como os planos de resposta de emergência e os planos de recuperação após desastre, o seu plano de falha de implementação só é bem-sucedido se a sua equipa tiver formação sobre o mesmo e o praticar regularmente. Os testes de engenharia de caos e injeção de falhas podem ser técnicas eficazes para testar a sua estratégia de mitigação de implementação.

Compromisso: Os membros da equipa de apoio precisam de ser capazes de desempenhar as suas funções normais e também apoiar emergências. Poderá ter de aumentar a contagem de cabeças para ajudar a garantir que a equipa de suporte tem pessoal adequado e pode desempenhar todas as funções necessárias. Teste cuidadosamente as implementações quando implementa em ambientes de desenvolvimento mais baixos. Esta prática ajuda-o a detetar erros e configurações incorretas antes de chegarem à produção.

Facilitação do Azure

  • O Azure Pipelines fornece serviços de compilação e versão para suportar CI/CD das suas aplicações.

  • Os Planos de Teste do Azure são uma solução de gestão de testes baseada no browser que é fácil de utilizar. Esta solução oferece capacidades necessárias para testes manuais planeados, testes de aceitação do utilizador e testes exploratórios. Os Planos de Teste do Azure também fornecem uma forma de recolher feedback dos intervenientes.

  • O Azure Monitor é uma solução de monitorização abrangente para recolher, analisar e responder a dados de monitorização dos seus ambientes na cloud e no local. O monitor inclui uma plataforma de alertas robusta. Pode configurar esse sistema para notificações automáticas e outras ações, como o dimensionamento automático e outros mecanismos de autorrecuperação.

  • O Application Insights é uma extensão do Monitor que fornece funcionalidades de monitorização do desempenho de aplicações (APM).

  • O Azure Logic Apps é uma plataforma baseada na cloud para executar fluxos de trabalho automatizados que integram aplicações, dados, serviços e sistemas. Pode utilizar o Logic Apps para criar uma nova versão da sua aplicação sempre que lhe for feita uma atualização. O Azure mantém um histórico das versões e pode reverter ou promover qualquer versão anterior.

  • Muitos serviços de bases de dados do Azure fornecem funcionalidades de restauro para um ponto anterior no tempo que o podem ajudar quando precisar de reverter:

  • O Azure Chaos Studio Preview é um serviço gerido que utiliza a engenharia de caos para o ajudar a medir, compreender e melhorar a resiliência da sua aplicação na cloud e do serviço.

Lista de verificação de Excelência Operacional

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional