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

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

OE:11	Implemente uma estratégia de mitigação de falhas na implantação que resolva problemas inesperados no meio do rollout com recuperação rápida. Integre várias abordagens, como rollback, desabilitação de recurso ou uso dos recursos nativos do padrão de implantação.

Este guia descreve as recomendações para projetar uma estratégia padronizada a fim de resolver falhas de implantação com eficiência. Assim como outros problemas relacionados à 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 ter proatividade tendo uma estratégia intencional bem projetada para resolver falhas na implantação. Essa estratégia permite que sua equipe de carga de trabalho reduza as falhas com o menor impacto possível sobre os usuários.

A ausência desse plano pode acarretar respostas caóticas e potencialmente prejudiciais aos problemas, o que pode afetar significativamente a equipe e a coesão organizacional, além da confiança do cliente e das finanças.

Estratégias-chave de design

Às vezes, apesar da maturidade das práticas de desenvolvimento, ocorrem problemas na implantação. O uso de práticas de implantação seguras e a operação de uma cadeia de fornecedores da carga de trabalho robusta podem ajudar você a minimizar a frequência de implantações com falha. Também é necessário criar uma estratégia padronizada para lidar com falhas de implantação quando elas ocorrerem.

Uma estratégia de mitigação de falha na implantação é composta por cinco fases abrangentes:

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 smoke tests com falha, relatórios de usuários 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ê deve executar a ação de mitigação identificada. A mitigação pode assumir a forma de fallback, rollback ou roll forward.
4. Comunicação: as partes interessadas e os usuários afetados devem ser informados 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 irrepreensíveis dão chances para que a equipe da carga de trabalho identifique áreas de melhoria e crie planos para aplicar aprendizados.

As seções a seguir fazem recomendações detalhadas para essas fases.

Duplicatas

Para identificar rapidamente problemas nas implantações, é essencial contar com práticas robustas de teste e monitoramento específicos para esse processo. Para ajudar a detectar anomalias rapidamente, é necessário complementar o monitoramento e o alerta da carga de trabalho usando uma ferramenta de gerenciamento de desempenho de aplicativo e registrando em log por meio de instrumentação.

Smoke tests e outros testes de qualidade devem acontecer a cada fase da 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 problemas do usuário com uma fase de implantação. Em seguida, você pode identificar rapidamente a qual grupo de distribuição um usuário em especial está associado. Essa abordagem é especialmente importante para implantações de exposição progressiva, porque você pode ter várias configurações em execução na base de usuários em qualquer ponto da implantação.

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

Decisão

Escolher a estratégia de mitigação adequada para um problema de implantação envolve levar em conta fatores como:

• O tipo de modelo de exposição progressiva usado por você. Por exemplo, você pode usar um modelo azul-verde ou um modelo canário. Se você usar um modelo azul-verde, o fallback é mais prático do que a reversão. Você pode transferir facilmente o tráfego de volta para a pilha que executa a configuração não atualizada. Assim, você pode acabar corrigindo o fato no ambiente problemático e repetindo a implantação em um momento indicado.

• Os métodos que você tem à disposição para o bypass do problema. Entre os exemplos estão o uso de sinalizadores de recurso, variáveis ambientais ou qualquer outro tipo de propriedade de configuração de runtime que você pode ativar e desativar. Às vezes, você pode ignorar facilmente um problema desativando um sinalizador de recurso ou alternando uma configuração. Nesse caso, convém:

  • Dar continuidade à distribuição.
  • Evitar o fallback.
  • Reverter enquanto você 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 hotfix é a escolha certa para determinados cenários.

• O nível de gravidade para a carga de trabalho afetada. As cargas de trabalho críticas de negócios devem sempre ser implantadas lado a lado, como em um modelo azul-verde, para obter implantações com tempo de inatividade zero. Assim, o fallback é a estratégia de mitigação preferível para esses tipos de cargas de trabalho.

Mitigação

Estas são algumas das estratégias de mitigação comuns:

• Reversão: em um cenário de reversão, você reverte sistemas atualizados para o estado de configuração de último bom estado conhecido.

  É importante que toda a equipe de carga de trabalho concorde sobre o significado de "última versão estável conhecida". 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 em relação a alterações de dados. As alterações feitas no esquema podem tornar a reversão algo arriscado. A implementação delas com segurança pode exigir um planejamento considerável. Como recomendação geral, as atualizações feitas no esquema devem ser aditivas. Os registros não devem ser substituídos por novos registros. Em vez disso, os registros anteriores devem ser preteridos e coexistir com registros novos até que seja seguro removê-los.

• 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 oferece uma maneira de resolver os problemas no código sem introduzir mais interrupções.

  Com implantações canário, o fallback talvez não seja simples ou mesmo possível, dependendo da infraestrutura e do design do aplicativo. Se você precisar realizar a escala para lidar com a carga em sistemas que não estejam atualizados, realize essa escala antes do fallback.

• Contornar a função incorreta: se você puder contornar o problema usando sinalizadores de recurso ou outro tipo de propriedade de configuração de runtime, poderá decidir que continuar com a distribuição é a estratégia certa para um problema.

  Você deve compreender claramente a compensação do bypass da função e ser capaz de comunicar essa compensação aos stakeholders. Os stakeholders devem aprovar o plano de aprovação. Os stakeholders precisam determinar o período tolerável de operação em um estado degradado. Eles também precisam ponderar essa determinação em relação à estimativa do tempo necessário para corrigir o código ofensivo e implantá-lo.

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

  Como qualquer outro código, os hotfixes precisam passar por suas práticas de implantação seguras. Mas com um hotfix, o cronograma é consideravelmente acelerado. Você precisa usar uma estratégia de promoção do código em todos os ambientes. Você também precisa verificar o código de hotfix em todos os portões de qualidade. Mas, talvez seja necessário reduzir drasticamente os tempos de bake, e convém modificar os testes para agilizá-los. Verifique se você consegue executar testes completos no código atualizado o mais rápido possível após a implantação. A automatização dos testes de controle de qualidade em alto grau ajuda a deixar os testes eficientes nesses cenários.

Comunicação

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

Padronize a cadência seguida pela equipe da carga de trabalho para apresentar atualizações de status. Verifique se os stakeholders têm ciência desse padrão, de maneira que eles saibam quando esperar atualizações.

Se a equipe de carga de trabalho precisar se comunicar diretamente com os usuários, esclareça o tipo de informação e o nível de detalhes apropriados para compartilhamento. Além disso, informe à equipe da carga de trabalho eventuais outros requisitos que se apliquem a esses casos.

Post-mortem

Os post-mortems devem seguir todas as implantações com falha, sem exceção. Toda implantação com falha é uma oportunidade de aprendizado. Postmortems pode ajudá-lo a identificar fraquezas em seus processos de implantação e desenvolvimento e configurações incorretas em sua infraestrutura.

Os post-mortems devem ser sempre irrepreensíveis, de maneira que os indivíduos envolvidos no incidente se sintam seguros ao compartilhar as perspectivas sobre o que pode ser melhorado. Os líderes de post-mortem devem seguir com planos para implementar as melhorias identificadas e para adicionar esses planos ao backlog de carga de trabalho.

Considerações e recomendações gerais

Verifique se o pipeline de implantação consegue aceitar versões distintas como parâmetros, de maneira que você possa implantar facilmente as configurações de último bom estado conhecido.

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

Prefira alterações pequenas e frequentes em vez de alterações infrequentes e grandes, para que a diferença entre suas implantações novas e as últimas em boas condições seja pequena.

Realize 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 possam complicar os esforços de mitigação. Assim como acontece com 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 de maneira criteriosa:

• Algumas ferramentas de CI/CD como o Azure DevOps têm a funcionalidade de reversão automática integrada. Leve em consideração o uso dessa funcionalidade caso agregue um valor tangível para você.
• Você só deverá adotar a funcionalidade de reversão automática depois de testar o pipeline na íntegra e regularmente. Verifique se o pipeline está maduro o suficiente para apresentar problemas extras em caso de disparo de uma reversão automática.
• Você precisa confiar que a automação só implanta as alterações necessárias e que ela só é disparada quando necessário. Projete os gatilhos com cuidado para cumprir esses requisitos.

Use capacidades oferecidas pela plataforma durante as reversões. Por exemplo, backups e restauração pontual podem ajudar com armazenamento e reversões de dados. Ou se você usar 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 estratégia de mitigação de falhas na implantação com frequência. Assim como os planos de resposta a emergências e os planos de recuperação de desastres, o plano de falha na implantação só será bem-sucedido se a equipe tiver treinamento nele e praticá-lo regularmente. A engenharia do caos e os testes de injeção de falha podem ser técnicas eficazes para testar a estratégia de mitigação da implantação.

Facilitação do Power Platform

Os pipelines no Power Platform visam democratizar o gerenciamento do ciclo de vida do aplicativo (ALM) para clientes do Power Platform e do Dynamics 365, trazendo automação do ALM e recursos de integração contínua e entrega contínua (CI/CD) para o serviço.

O Microsoft Power Platform Build Tools para Azure DevOps pode ser usado para automatizar tarefas comuns de compilação e implantação relacionadas a aplicativos criados no Power Platform.

GitHub Actions para Power Platform permitem que os desenvolvedores criem fluxos de trabalho de ciclo de vida de desenvolvimento de software automatizados. Com o GitHub Actions para Microsoft Power Platform, é possível criar fluxos de trabalho no repositório para compilar, testar, empacotar, lançar e implantar aplicativos; realizar automação e gerenciar bots e outros componentes compilados no Microsoft Power Platform.

O Acelerador do ALM é uma ferramenta de código aberto que consiste em um conjunto de aplicativos, scripts e pipelines projetados para automatizar o processo de integração/entrega contínua.

Automatizar testes com Azure Pipelines.

Use oKit do Copilot Studio do Power CAT para configurar agentes e testes. Ao executar testes individuais nas APIs DO Copilot Studio (Direct Line), as respostas do agente são avaliadas em relação aos resultados esperados.

As variáveis de ambiente em soluções armazenam as chaves e os valores dos parâmetros, que servem como entrada para outros objetos do aplicativo. Separar os parâmetros dos objetos de consumo permite alterar os valores dentro do mesmo ambiente ou ao migrar soluções para outros ambientes.

Os ambientes do Power Platform fornecem funcionalidade de restauração pontual que pode ajudar você a fazer reversões.

O Power Platform se integra ao Application Insights, que faz parte do ecossistema do Azure Monitor. Use essa integração para:

• Receber telemetria sobre diagnóstico e desempenho capturados pela plataforma do Dataverse no Application Insights. É possível assinar para receber telemetria sobre operações realizadas pelos aplicativos no banco de dados do Dataverse e em aplicativos baseados em modelo. Essa telemetria fornece informações que é possível usar para realizar o diagnóstico e solucionar problemas relacionados aos erros e ao desempenho.

• Conectar os aplicativos de tela ao Application Insights. Você pode usar essa análise para realizar o diagnóstico de problemas e compreender o que os usuários fazem com os aplicativos. É possível coletar informações para a tomar decisões comerciais melhores e aprimorar a qualidade de seus aplicativos.

• Configure a Telemetria do Power Automate para fluir no Application Insights, por exemplo, para monitorar execuções de fluxo de nuvem e criar alertas para falhas de execução de fluxo da nuvem.

• Capture dados de telemetria do seu agente do Microsoft Copilot Studio para uso no Azure Application Insights. Você pode usar essa telemetria para monitorar mensagens registradas e eventos enviados de e para o agente, tópicos a serem disparados durante conversas do usuário e eventos de telemetria personalizados que podem ser enviados de seus tópicos.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional