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 Bem Arquitetada: Power Platform

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 de carga de trabalho, 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 mitigue falhas de forma eficiente, com o menor impacto possível sobre seus 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. Você também precisa criar uma estratégia padronizada para lidar com implantações com falha 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 testes de fumaça com falha, relatórios de usuários 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 específico de falha.
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 sobre o status à medida que você detecta e trabalha no problema, conforme exigido pelo seu plano de emergência resposta.
5. Postmortem: Postmortems sem culpa oferecem oportunidades para a equipe de carga de trabalho identificar áreas de melhoria e criar planos para aplicar os aprendizados.

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

Duplicatas

Para identificar rapidamente problemas com implantações, você precisa de práticas robustas de teste e monitoramento relacionadas às implantações. Para ajudar a detectar anomalias rapidamente, você pode complementar o monitoramento e o alerta da carga de trabalho usando uma ferramenta de geranciamento de desempenho de aplicativos e registrando 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. Garanta que a equipe de suporte seja treinada sobre como escalar problemas de implantação para roteamento adequado. Os escalonamentos devem estar alinhados com o plano de resposta a emergência da carga de trabalho.

Decisão

Decidir sobre uma estratégia de mitigação apropriada para um problema de implantação envolve considerar 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, implementar um hotfix é a escolha certa para certos 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:

• Rollback: Em um cenário de rollback, você reverter atualizou os sistemas para o último estado de configuração conhecido como bom.

  É importante que toda a equipe de carga de trabalho concorde sobre o significado de "último estado bom conhecido". Essa expressão se refere ao último estado da carga de trabalho que estava íntegro antes do início da implantação, 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.

• Ignore a função ofensiva: se você puder ignorar o problema usando sinalizadores de recursos ou outro tipo de propriedade de configuração de tempo de execução, poderá decidir que continuar com a implementação é a estratégia correta 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 segura. 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 que são apropriados para compartilhamento. Além disso, informe à equipe da carga de trabalho eventuais outros requisitos que se apliquem a esses casos.

Post-mortem

As autópsias devem acompanhar todas as implantações com falha, sem exceção. Toda implantação com falha é uma oportunidade de aprendizado. As análises postmortem podem ajudar você a identificar fraquezas em seus processos de implantação e desenvolvimento, além de 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 da análise post-mortem devem acompanhar com planos para implementar as melhorias identificadas e para adicionar esses planos à carga de trabalho pendente.

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 mudanças pequenas e frequentes em vez de mudanças grandes e pouco frequentes para que a diferença entre suas novas implantações e as últimas em boas condições seja pequena.

Execute uma análise de modo de falha em seus pipelines de integração e entrega contínua (CI/CD) para ajudar a identificar problemas que podem 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ções pontuais podem ajudar com armazenamento e reversões de dados. Ou se você usa máquinas virtuais para hospedar seu aplicativo, pode ser útil restaurar seu ambiente para um ponto de verificação imediatamente anterior ao 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. Engenharia do caos e testes de injeção de falhas podem ser técnicas eficazes para testar sua estratégia de mitigação de implantação.

Facilitação do Power Platform

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

Microsoft Power Platform As ferramentas de construção para Azure DevOps podem ser usadas para automatizar tarefas comuns de construção e implantação relacionadas a aplicativos criados em Power Platform.

Ações do GitHub para Power Platform permitir que os desenvolvedores criem fluxos de trabalho automatizados do ciclo de vida de desenvolvimento de software. 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 ALM Accelerator é uma ferramenta de código aberto que consiste em um conjunto de aplicativos, scripts e pipelines projetados para automatizar o processo de integração contínua/entrega contínua.

Automatize testes com o Azure Pipelines.

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

Variáveis de ambiente em soluções armazenam as chaves e valores dos parâmetros, que então 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.

Power Platform ambientes fornecem funcionalidade de restauração pontual que pode ajudar você a reverter.

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 Power Automate telemetria para fluir para Application Insights; por exemplo, para monitorar execuções de fluxo da nuvem e criar alertas para falhas de execução de fluxo da nuvem.

• Capture dados de telemetria do seu Microsoft Copilot Studio copiloto para uso no Azure Application Insights. Você pode usar essa telemetria para monitorar mensagens registradas e eventos enviados de e para seu copiloto, tópicos a serem acionados 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.