Recomendações para estruturar uma estratégia de mitigação de falhas de implementação
Aplica-se a esta recomendação da lista de verificação do Power Platform Well-Architected Operational Excellence:
| OE:11 | Implemente uma estratégia de mitigação de falhas de implementação que resolva problemas inesperados a meio da implementação com recuperação rápida. Combine várias abordagens, como a reversão, a desativação de funcionalidades ou a utilização das capacidades nativas do seu padrão de implementação. |
|---|
Este guia descreve as recomendações para estruturar uma estratégia padronizada para lidar efetivamente com falhas de implementação. Como 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 tendo uma estratégia intencional bem estruturada para lidar com falhas de implementação. Esta estratégia permite que a sua equipa de carga de trabalho mitigue falhas de forma eficiente com o menor impacto possível nos seus utilizadores.
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 organizacional e da equipa, a confiança do cliente e as finanças.
Principais estratégias de design
Ocasionalmente, apesar da maturidade das suas práticas de desenvolvimento, ocorrem problemas de implementação. A utilização de práticas de implementação seguras e a operação de uma cadeia de fornecimento de carga de trabalho robusta pode ajudá-lo a minimizar a frequência de implementações com falha. Também precisa de conceber uma estratégia padronizada para lidar com implementações falhadas quando acontecem.
Uma estratégia de mitigação de falhas de implementação é composta por cinco fases amplas:
- Deteção: para responder a uma implementação com falha, primeiro tem de detetar a falha. A deteção pode assumir várias formas, como testes de verificação de funcionamento falhados, relatórios de utilizador ou alertas gerados pela sua plataforma de monitorização.
- Decisão: tem de decidir qual é a melhor estratégia de mitigação para o tipo de falha específico.
- Mitigação: tem de realizar a ação de mitigação identificada. A mitigação pode assumir a forma de uma contingência, de uma reversão ou de um rollforward.
- Comunicação: os intervenientes e os utilizadores afetados têm de estar cientes do estado à medida que deteta e resolve o problema, conforme exigido pelo seu plano de resposta a emergências.
- Post mortem: os post mortems sem atribuição de culpas oferecem oportunidades para a equipa de carga de trabalho identificar áreas de melhoria e criar planos para aplicar aprendizagens.
As secções seguintes fornecem recomendações detalhadas para estas fases.
Deteção
Para identificar rapidamente problemas com implementações, precisa de práticas robustas de teste e monitorização relacionadas com implementações. Para ajudar a detetar anomalias rapidamente, pode complementar a monitorização e alerta da carga de trabalho usando uma ferramenta de gestão de desempenho de aplicações e registo por instrumentação.
Testes de verificação de funcionamento e outros testes de qualidade devem ser realizados em cada fase da sua implementação. Os testes bem-sucedidos num grupo de implementação não devem influenciar as decisões para testar nos grupos subsequentes.
Pode implementar telemetria que correlaciona os 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, porque pode ter várias configurações em execução em toda a sua base de utilizadores em qualquer ponto específico da implementação.
Deve estar pronto para responder aos problemas relatados pelos utilizadores imediatamente. Sempre que possível, execute a sua 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 escalar os problemas de implementação para o itinerário adequado. Os escalamentos devem estar alinhados com o seu plano de resposta a emergências de carga de trabalho.
Decisão
Decidir sobre uma estratégia de mitigação apropriada para um problema de implementação envolve considerar fatores como:
O tipo de modelo de exposição progressiva que utiliza. Por exemplo, poderá utilizar um modelo azul-verde ou um modelo canário. Se utilizar um modelo azul-verde, uma ação de contingência é mais prática do que uma reversão. Pode facilmente deslocar o tráfego de volta para a pilha que executa a configuração que não está atualizada. Em seguida, pode corrigir o problema no ambiente problemático e tentar a implementação novamente na altura apropriada.
Os métodos que tem à sua disposição para contornar 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 facilmente ignorar um problema desativando um sinalizador de funcionalidades ou ativando/desativando uma definição. Neste caso, poderá conseguir:
- Prosseguir com a implementação.
- Evitar uma ação de contingência.
- Reverter enquanto corrige o código problemático.
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 uma correção é 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 a empresa devem ser sempre implementadas lado a lado, como num modelo azul-verde, para alcançar implementações sem tempo de inatividade. Como resultado, uma ação de contingência é a estratégia de mitigação preferível para estes tipos de cargas de trabalho.
Mitigação
Seguem-se algumas estratégias de mitigação comuns:
Reversão: num cenário de reversão, reverte os sistemas atualizados para o estado de última configuração em boas condições.
É importante que a toda a equipa 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 em bom estado antes do início da implementação, que não é necessariamente a versão anterior da aplicação.
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. 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 os 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 implementações de proteção, uma ação de contingência pode não ser simples ou até mesmo possível, dependendo da sua infraestrutura e da estrutura das aplicações. Se precisar de efetuar o dimensionamento para processar carga em sistemas que não estão atualizados, efetue este dimensionamento antes da ação de contingência.
Ignorar a função problemática: se puder ignorar o problema usando sinalizadores de caraterísticas 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.
Deve compreender claramente a contrapartida de ignorar a função e deve ser capaz de comunicar esta contrapartida aos intervenientes. Os intervenientes devem aprovar o plano de avanço. Os intervenientes precisam de determinar o período de tempo tolerável para funcionar num estado degradado. Também precisam de ponderar esta determinação em relação à sua estimativa do tempo necessário para corrigir o código problemático e implementá-lo.
Implementação de emergência (correção): se puder abordar o problema a meio da implementação, uma correção pode ser a estratégia de mitigação mais prática.
Como qualquer outro código, as correções precisam de passar pelas suas práticas de implementação segura. Mas com uma correção, 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 precisa de verificar o código da correção em todos os portões de qualidade. Mas pode precisar de reduzir drasticamente os tempos de bake e 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 os testes de garantia de qualidade a um alto grau ajuda a tornar os testes eficientes nesses cenários.
Comunicação
É importante definir claramente as responsabilidades de comunicação 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 a emergências, como o gestor de resposta a emergências.
Defina um padrão de cadência que a equipa de carga de trabalho deve seguir para fornecer as atualizações de estado. Certifique-se de que os intervenientes estão cientes desse padrão, para que saibam quando esperar as atualizações.
Se a equipa da carga de trabalho precisar de comunicar diretamente com os utilizadores, esclareça o tipo de informações e o nível de detalhe apropriados para a partilha. Comunique também à equipa de carga de trabalho quaisquer outros requisitos que se apliquem a estes casos.
Post mortem
Os post mortems devem seguir-se todas as implementações com falha, sem exceção. Cada implementação com falha é uma oportunidade de aprendizagem. O Post mortems pode ajudá-lo a identificar pontos fracos nos seus processos de implementação e desenvolvimento e configurações incorretas na sua infraestrutura.
Os post mortems nunca devem atribuir culpas 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 de Post mortem devem dar seguimento aos planos para implementar as melhorias identificadas e para adicionar estes planos ao registo de tarefas pendentes da carga de trabalho.
Considerações e recomendações gerais
Certifique-se de que o seu pipeline de implementação pode aceitar versões distintas como parâmetros, para que possa implementar facilmente as últimas configurações em boas condições.
Mantenha a consistência com os planos de gestão e de dados à medida que reverte ou efetua um rollforward. As chaves, os segredos, os dados de estado da base de dados e as configurações específicos dos recursos e das políticas têm de estar no âmbito e ser contabilizados. Por exemplo, preste atenção à conceção do dimensionamento da sua infraestrutura na última implementação em boas condições. Determine se precisa de ajustar esta configuração ao reimplementar o seu código.
Prefira alterações pequenas e frequentes a alterações grandes e pouco frequentes, para que a diferença entre as implementações novas e as últimas implementações em boas condições seja pequena.
Execute uma análise do modo de falha nos seus 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 a sua carga de trabalho como um todo, os seus 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 tem uma funcionalidade de reversão automática incorporada. Considere utilizar esta funcionalidade se lhe fornecer um valor tangível.
- Deverá adotar a funcionalidade de reversão automática apenas depois de testar o seu pipeline de forma completa e regular. Certifique-se de que o seu pipeline está maduro o suficiente para introduzir problemas adicionais se for acionada uma reversão automática.
- É preciso confiar que a automatização implementa apenas as alterações necessárias e que é acionada apenas quando é necessário. Estruture os seus acionadores cuidadosamente para cumprir estes requisitos.
Utilize as capacidades fornecidas pela plataforma durante as reversões. Por exemplo, as cópias de segurança e de restauro para um ponto anterior no tempo podem ajudar com armazenamento e reversões de dados. Ou, se usar máquinas virtuais para hospedar 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. Assim como os planos de resposta a emergências e os planos de recuperação após desastre, o seu plano de falha de implementação só será bem-sucedido se a sua equipa receber formação sobre o mesmo e o praticar regularmente. A engenharia de caos e os testes de injeção de falhas podem ser técnicas eficazes para testar a sua estratégia de mitigação de implementação.
Facilitação do Power Platform
Os Pipelines no Power Platform visam democratizar a gestão do ciclo de vida das aplicações (ALM) para os clientes do Power Platform e do Dynamics 365 ao integrar a automatização ALM e as capacidades de integração e entrega contínuas (CI/CD) no serviço.
Podem ser utilizadas Ferramentas de Compilação do Microsoft Power Platform para Azure DevOps para automatizar as tarefas comuns de compilação e implementação relacionadas com as aplicações criadas no Power Platform.
O GitHub Actions para o Power Platform permite aos programadores criar fluxos de trabalho de ciclo de vida de desenvolvimento de software automatizados. Com as Ações GitHub para o Microsoft Power Platform, pode criar fluxos de trabalho no seu repositório para criar, testar, empacotar, lançar e implementar aplicações; executar automatização; e gerir bots e outros componentes criados no Microsoft Power Platform.
O ALM Accelerator é uma ferramenta de código aberto que consiste num conjunto de aplicações, scripts e pipelines estruturados para automatizar o processo de integração contínua/entrega contínua.
Automatizar os testes com Pipelines do Azure.
Use o Kit Power CAT Copilot Studio para configurar agentes e testes. Ao executar testes individuais em relação às APIs do Copilot Studio (Direct Line), as respostas de agente são avaliadas em relação aos resultados esperados.
As variáveis de ambiente em soluções armazenam as chaves e valores dos parâmetros, que depois servem como entrada para outros objetos de aplicação. Separar os parâmetros dos objetos que consomem permite alterar os valores dentro do mesmo ambiente ou quando migra soluções para outros ambientes.
Os ambientes do Power Platform fornecem a funcionalidade de restauro pontual que o pode ajudar a reverter.
O Power Platform integra-se com o Application Insights, que faz parte do ecossistema do Azure Monitor. Utilize esta integração para:
Receber telemetria sobre os diagnósticos e o desempenho capturados pela plataforma do Dataverse no Application Insights. Pode subscrever para receber telemetria sobre as operações que as aplicações realizam na sua base de dados do Dataverse e dentro de aplicações condicionadas por modelo. Esta telemetria fornece informações que pode usar para diagnosticar e resolver problemas relacionados com erros e desempenho.
Ligar as suas aplicações de tela ao Application Insights. Pode utilizar estas análises para diagnosticar problemas e compreender o que os utilizadores fazem com as suas aplicações. Pode recolher informações para o ajudar a impulsionar melhores decisões de negócio e a melhorar a qualidade das suas aplicações.
Configure a telemetria do Power Automate para fluir para o Application Insights, por exemplo, para monitorizar execuções de fluxo de cloud e criar alertas para falhas de execução de fluxo de cloud.
Capture dados de telemetria do seu agente do Microsoft Copilot Studio para utilização no Application Insights do Azure. Pode utilizar esta telemetria para monitorizar mensagens e eventos registados enviados de e para o seu agente, tópicos a acionar durante conversas de utilizador e eventos de telemetria personalizados que podem ser enviados a partir dos seus tópicos.
Lista de verificação de excelência operacional
Consulte o conjunto completo de recomendações.