Estratégias de arquitetura para criar uma estratégia de teste de confiabilidade

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

O teste de confiabilidade captura as fraquezas da arquitetura antes que elas causem interrupções. Sem testar deliberadamente cenários de falha, você não pode saber se seus padrões de resiliência realmente funcionam ou se sua carga de trabalho se recupera dentro de seus destinos definidos.

Você reforça a confiabilidade da carga de trabalho ao testar riscos de segurança que afetam a disponibilidade, problemas de desempenho que tornam o sistema inutilizável e lacunas operacionais que limitam sua resposta a incidentes. Use as estratégias neste artigo para estabelecer uma cadência de teste que valida regularmente sua carga de trabalho em relação aos modos de falha. Evolua seus testes à medida que a arquitetura muda e os incidentes revelam novas fraquezas. Tenha confiança de que sua carga de trabalho pode suportar falhas, escalar para atender à demanda e se recuperar dentro de suas metas de RTO e RPO, ao criar um ciclo de feedback que fortalece sua postura de confiabilidade ao longo do tempo.

As principais estratégias neste artigo baseiam-se nas práticas de teste fundamentais descritas nas estratégias de arquitetura OE:09 para teste. Examine esse artigo primeiro. As recomendações neste guia estão voltadas para a confiabilidade e se concentram em garantir confiança na capacidade da sua carga de trabalho de resistir a falhas e se recuperar dentro das suas metas.

A tabela a seguir define os principais termos de confiabilidade usados ao longo deste artigo.

Definições

Definir o escopo de teste de confiabilidade com base em tipos de serviço

Ao definir o escopo do teste de confiabilidade, considere o modelo de responsabilidade compartilhada dos serviços usados. Cada tipo de serviço (IaaS, PaaS, SaaS) vem com diferentes garantias de confiabilidade e diferentes níveis de controle sobre o tratamento de falhas. Concentre seus testes nos aspectos de confiabilidade que você possui.

• Ajuste a profundidade dos testes ao seu nível de responsabilidade. Para iaaS (serviços de infraestrutura), sua equipe possui a maioria das decisões de confiabilidade, portanto, invista em validação completa por meio da engenharia do caos e da injeção de falhas. Para serviços de PaaS (plataforma) e software (SaaS), o provedor gerencia grande parte da confiabilidade subjacente. Concentre-se na forma como sua carga de trabalho interage com esses serviços, por exemplo, como ela lida com failovers da infraestrutura em PaaS, limitação de taxa, degradação do serviço ou mudanças nos padrões de carga.

• Considere cargas de trabalho com serviços mistos. Quando sua carga de trabalho abrange vários tipos de serviço, as responsabilidades de teste variam entre os componentes. Você pode testar o failover dos seus componentes de infraestrutura baseados em VM durante uma interrupção em uma zona de disponibilidade, mas pode depender das garantias do provedor para um banco de dados em PaaS projetado para alta disponibilidade. Identifique onde estão esses limites e verifique se o teste abrange as lacunas entre eles.

Teste de ponta a ponta em relação às suas metas de confiabilidade

Suas metas de confiabilidade, como SLOs, RTOs e RPOs, definem como sua carga de trabalho deve se comportar em condições de falha. Use-os como critérios de aprovação e reprovação em fluxos críticos completos, não apenas em componentes individuais.

• Valide a recuperação em todo o fluxo. Um único componente pode ser restaurado dentro do seu RTO, mas o tempo geral de recuperação pode exceder sua meta quando as dependências posteriores também precisam ser restauradas. Contabilize o tempo total de recuperação em todo o fluxo, incluindo o tempo para detectar o problema e responder.

• Defina o escopo de teste com SLOs e orçamentos de erro. Seu orçamento de erro representa o investimento que você pode fazer na injeção de falhas. Limite os testes de caos para que fiquem dentro dos seus SLOs e use suas metas de recuperação de fluxo para definir os limites de cada teste.

Criar cenários de confiabilidade com base em fluxos críticos e modos de falha

Comece com os fluxos críticos em sua carga de trabalho e os modos de falha que podem afetá-los. Use sua análise de modos de falha para identificar os cenários de falha de maior impacto e criar testes que validem suas estratégias de resiliência e recuperação.

Priorize por impacto e probabilidade. Nem todo modo de falha garante o mesmo investimento de teste. Concentre-se primeiro em cenários com o maior impacto potencial do usuário e a maior probabilidade de ocorrer. Permita que a análise do modo de falha impulsione essa priorização.

Validar seus mecanismos de tolerância a falhas e recuperação

Concentre-se em cenários que são mais propensos a causar tempo de inatividade ou degradar a experiência do usuário. Use as estratégias nesta seção para criar testes que validem a capacidade da carga de trabalho de lidar com falhas e se recuperar com eficiência.

Backup e restauração

O teste de backup e restauração deve validar que sua abordagem de proteção de dados atende aos seus objetivos de recuperação.

• Estabeleça uma cadência de testes. Determine com que frequência você precisa testar restaurações com base na frequência com que a configuração de backup, o esquema de dados ou a infraestrutura são alterados. Alterações mais frequentes exigem testes de restauração mais frequentes.

• Definir destinos de recuperação. Meça os tempos reais de restauração em comparação com as metas de RPO e RTO para confirmar que sua estratégia de backup atende aos seus objetivos de recuperação.

• Não presuma que o backup esteja completo. Os backups podem ser configurados incorretamente para capturar apenas um subconjunto de seus dados. Valide a integridade e a completude dos dados, não apenas se uma operação de restauração for bem-sucedida.

• Teste isoladamente. Valide as restaurações em um ambiente separado da produção para que você possa executar verificações completas sem interromper cargas de trabalho dinâmicas.

Falhas transitórias

Falhas transitórias, como interrupções momentâneas de rede, indisponibilidade de serviço breve e tempos limite de conexão, são riscos comuns de confiabilidade. Valide se sua carga de trabalho lida com essas falhas sem afetar os usuários. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

• Concentre-se no que você possui. Se seus SDKs ou serviços de plataforma lidarem com novas tentativas e interrupções de circuito automaticamente, teste o que acontece quando esses mecanismos internos são esgotados, como quando todas as tentativas falham ou um disjuntor é aberto.

• Validar configurações de tratamento de falhas. Avalie as configurações de tratamento de falhas da carga de trabalho. Verifique se políticas de repetição, limites de disjuntor e valores de tempo limite se comportam conforme o esperado em condições de falha realistas.

• Teste o limite entre falha transitória e persistente. Valide se sua carga de trabalho faz a transição normalmente de comportamento de repetição para fallback ou degradação quando uma falha persiste além dos limites esperados.

• Leve em conta falhas transitórias causadas por funcionalidades de resiliência. A redundância de zona e arquiteturas semelhantes geralmente podem causar falhas transitórias durante operações normais de failover. Por exemplo, um banco de dados com redundância entre zonas pode causar falhas transitórias de conexão à medida que o tráfego é redirecionado para uma zona saudável durante uma interrupção. Teste se sua carga de trabalho pode lidar com essas falhas transitórias esperadas sem impacto significativo do usuário.

Resposta de carga e escalabilidade

Valide se sua carga de trabalho mantém a confiabilidade durante as alterações de demanda, tanto picos repentinos quanto aumentos graduais. Para obter mais informações, consulte a estratégia de dimensionamento. Para obter diretrizes de teste de carga e estresse, consulte Recomendações para teste.

• Teste tanto a expansão horizontal quanto a redução horizontal. Verifique se a nova capacidade entra em operação com rapidez suficiente e se a redução de escala não provoca perda de solicitações nem deixa recursos órfãos.

• Leve em consideração o atraso de escalonamento. Há sempre um atraso entre atender às condições para disparar o dimensionamento e ter uma nova capacidade pronta. Determine se sua carga de trabalho pode lidar com a demanda durante essa lacuna ou se você precisa pré-provisionar capacidade extra.

Falhas de dependência

Sua carga de trabalho provavelmente depende de serviços fora do controle direto, como APIs de terceiros, serviços de plataforma gerenciada ou serviços internos compartilhados. Valide se sua carga de trabalho lida com falhas nessas dependências sem interrupções significativas para os usuários.

• Categorize dependências por criticidade. Nem todas as dependências justificam o mesmo investimento em testes. Dê prioridade aos testes de dependências presentes nos seus fluxos críticos e que não tenham redundância integrada nem caminhos alternativos de contingência.

• Testar o comportamento de contingência de cada dependência. Quando uma dependência fica indisponível, sua carga de trabalho deve voltar para um caminho ou comportamento alternativo em vez de falhar totalmente. Confirme se cada fallback é ativado corretamente e se essa funcionalidade não relacionada continua funcionando.

• Contabilize falhas parciais e em cascata. As dependências raramente falham de maneiras binárias. Não teste apenas interrupções completas. Cobrir aumentos de latência, erros intermitentes e disponibilidade parcial de dados.

• Validar isolamento e contenção de raio de explosão. Verifique se uma única falha de dependência não causa um efeito em cascata para funcionalidades não relacionadas.

Autopreservação e recuperação

Valide como sua arquitetura de autorrecuperação e autopreservação responde a falhas, inclusive se sua carga de trabalho pode continuar operando com capacidade reduzida quando a recuperação completa não é imediata.

• Teste a recuperação automatizada de ponta a ponta. Avalie seus modelos de saúde para garantir que eles incluam as verificações adequadas. Verifique se essas verificações detectam falhas com precisão, disparam a correção automatizada conforme o esperado e retornam o sistema a um estado íntegro dentro de quadros de tempo aceitáveis.

• Validar procedimentos manuais de recuperação. A recuperação automatizada não abrange todos os cenários. Teste os runbooks manuais em condições realistas para garantir que os operadores possam executá-los sob pressão e dentro de suas metas de tempo de recuperação.

• Valide o comportamento de degradação gradual. Quando um componente falha, sua carga de trabalho deve degradar-se de forma controlada em vez de parar completamente. Teste se ele pode funcionar em um modo reduzido, como colocar solicitações em fila para revisão manual, e se a experiência degradada é aceitável para os usuários. Confirme se sua equipe sabe como operar a carga de trabalho nesse estado e como restaurar a funcionalidade completa.

Incidentes e recuperação de desastre (DR)

Quando ocorre um incidente ou desastre, sua capacidade de detectá-lo e responder efetivamente é crítica. Teste seus planos e processos para garantir que eles resolvam falhas catastróficas e incidentes importantes. Use um ambiente dedicado para testes de DR para evitar afetar cargas de trabalho de produção. Para obter mais informações, consulte o plano de recuperação de desastre.

• Validar mecanismos de detecção de incidentes. Simule incidentes para verificar se os logs de monitoramento capturam as informações necessárias e que os alertas disparam adequadamente. Por exemplo, teste com que rapidez o aumento nas taxas de falha nas solicitações é detectado e com que frequência os dados de monitoramento são amostrados.

• Testar processos de gerenciamento de incidentes. Confirme se sua equipe pode seguir os procedimentos de resposta a incidentes com eficiência. Para obter mais informações, consulte a resposta a incidentes.

• Teste a comutação por falha completa e o retorno após failover. Testar componentes individualmente e de forma isolada pode não detectar falhas de coordenação que só aparecem durante uma comutação real. Valide a sequência completa de failover, incluindo a troca de DNS, a restauração de backups, a consistência da replicação de dados e a reconexão dos clientes. Teste também o retorno para a implantação principal, que geralmente é mais complexo do que a comutação inicial.

• Valide a capacidade no ambiente de failover. Certifique-se de que seu ambiente de failover tenha capacidade pré-provisionada suficiente para lidar com o tráfego imediatamente em caso de failover, sem entrar em colapso sob carga. Teste se o ambiente pode sustentar operações enquanto os mecanismos de dimensionamento ativam e validam sua abordagem de dimensionamento. Para obter mais informações, consulte Resposta de carga e escalabilidade.

• Meça em relação às suas metas. Se um teste de DR não atender ao RTO ou ao RPO, analise as lacunas e atualize o plano de recuperação de desastres conforme necessário.

• Valide as pessoas e o processo. Os testes de recuperação de desastres devem verificar os canais de comunicação, confirmar que os operadores têm os acessos e as permissões necessários para executar os procedimentos de recuperação e garantir que consigam encontrar rapidamente os runbooks específicos de recuperação de desastres sob pressão.

Teste e avalie seu plano com exercícios de simulação de mesa

As simulações de mesa ajudam a identificar falhas nos seus testes de confiabilidade antes que um incidente real as revele. Simulando cenários de falha com sua equipe, você pode identificar condições não testadas e validar se os procedimentos de resposta funcionam conforme o esperado.

• Simule incidentes realistas. Percorra um cenário de falha, como uma interrupção regional ou uma implantação corrompida, e faça com que sua equipe descreva as etapas que seriam tomadas para detectar, responder e se recuperar dela. Essas discussões geralmente revelam suposições sobre o comportamento do sistema que não foram validadas por meio de testes.

• Transforme as descobertas em casos de teste. Use as lacunas e as incógnitas que aparecem durante o exercício para criar novos testes de confiabilidade. Se a equipe descobrir que ninguém sabe como a carga de trabalho se comporta quando uma dependência específica falha, esse é um cenário a ser adicionado à sua estratégia de teste.

Aproveitar as interrupções planejadas e não planejadas

Quando sua carga de trabalho está offline devido à manutenção planejada ou a uma interrupção não planejada, você tem uma oportunidade exclusiva de executar testes e melhorar sua compreensão da carga de trabalho.

Manutenção planejada

Durante as janelas de manutenção para atualizações ou correções, teste componentes e fluxos que não estejam envolvidos no trabalho de manutenção. Você pode executar testes sem o risco de degradar inesperadamente a carga de trabalho ou tirá-la offline. Se você tiver tempo suficiente, teste também os componentes envolvidos na manutenção após a conclusão do trabalho.

Interrupção não planejada

Cada interrupção não planejada é uma oportunidade para fortalecer sua estratégia de teste de confiabilidade. Depois de restaurar o serviço e concluir sua revisão pós-incidente, use suas descobertas para melhorar seus testes.

• Teste suas medidas de mitigação. Se você aplicou uma solução alternativa ou correção temporária, valide se ela pode lidar com a carga esperada antes que a correção permanente esteja em vigor.

• Verifique se há pontos fracos semelhantes. Examine outros componentes para obter os mesmos padrões de configuração ou design que contribuíram para a interrupção. Adicione testes para esses componentes antes que eles falhem da mesma maneira.

Combinar diferentes tipos de testes

Ao executar diferentes tipos de testes juntos, você pode revelar problemas de confiabilidade que não são visíveis quando cada teste é executado isoladamente. Uma carga de trabalho pode suportar uma carga específica em condições normais, mas a mesma carga causa falhas quando uma falha é introduzida.

• Reutilize a infraestrutura de teste existente. Se você já tiver infraestrutura e um cinto de teste para teste de carga, use-o para executar testes de caos simultaneamente. A combinação de carga e injeção de falha na mesma execução de teste mostra como sua carga de trabalho se comporta em condições realistas, em que a demanda e as falhas ocorrem ao mesmo tempo.

• Comece em ambientes de não produção. Inicie o teste de confiabilidade em ambientes de menor risco em que você pode explorar com segurança os modos de falha. Mova para o teste de produção somente depois de esgotar insights de ambientes que não são de produção e ter proteções em vigor para limitar o raio de explosão e reverter rapidamente.

Usar injeção de falhas e engenharia do caos

A injeção de falhas e a engenharia do caos ajudam você a criar confiança na resiliência da carga de trabalho, introduzindo deliberadamente falhas e observando a resposta. Verifique se você tem estratégias de mitigação em vigor antes de executar experimentos.

• Execute experimentos de caos regularmente. Avalie seu escopo de teste. Injete falhas em componentes e fluxos que você supõe serem confiáveis. À medida que sua arquitetura muda, novos modos de falha surgem e suposições anteriores podem não ser mais retensivas. Execute experimentos em uma cadência regular para capturar regressões, validar novas dependências e confirmar que as alterações recentes não introduziram fraquezas.

• Use sua análise de modos de falha para direcionar os experimentos. Cada experimento deve ter como alvo uma falha específica ou um conjunto de falhas e ter uma hipótese clara, como testar a capacidade de um determinado fluxo de suportar a perda de um componente específico. À medida que os experimentos revelam novos modos de falha ou dependências não descobertas, atualize a análise do modo de falha para mantê-la atual.

• Limite o raio de impacto durante os experimentos. Concentre-se nos componentes que você pode recuperar rapidamente e estabeleça expectativas bem fundamentadas sobre o efeito de cada injeção de falhas. Se um experimento ultrapassar o escopo ou produzir resultados inesperados, interrompa-o. Balancee a coleta de dados significativos com a minimização do efeito sobre os usuários.

• Medir em relação às linhas de base. Estabeleça métricas de desempenho e confiabilidade consistentes para os fluxos e componentes em cada experimento. Compare as métricas de estado degradadas com essas linhas de base para entender o efeito completo da falha e determinar se o design de resiliência atende aos seus destinos.

• Alimente os resultados de volta em sua estratégia de teste. Use os resultados do experimento para conduzir novos testes, atualizar planos de recuperação e informar itens de lista de pendências de correção. À medida que comportamentos inesperados surgem, crie testes direcionados para esses comportamentos e projete estratégias de correção.

Compensação: o teste de injeção de falhas na produção pode causar interrupções e pode causar tempo de inatividade. Seja transparente com os stakeholders sobre essa possibilidade. Coloque as proteções em vigor para que você possa parar os experimentos e reverter rapidamente e manter-se flexível sobre quando executar testes ou evitá-los durante períodos confidenciais. Para se proteger contra interrupções não intencionais, planeje redundância suficiente e certifique-se de que seus stakeholders entendam a compensação de custos.

Risco: O teste de confiabilidade pode ampliar a cobertura para muitos modos de falha, mas você deve interrompê-lo quando ele deixar de oferecer valor significativo. Se você já tiver uma lista de problemas de confiabilidade conhecidos, priorize a correção desses problemas em vez de adicionar mais testes.

Suporte ao Azure

Os Planos de Teste do Azure são uma solução de gerenciamento de teste baseada em navegador que fornece todos os recursos necessários para testes manuais planejados, testes de aceitação do usuário, testes exploratórios e coleta de comentários dos stakeholders.

Azure Chaos Studio é um serviço gerenciado que usa testes de caos para ajudá-lo a medir, entender e melhorar sua resiliência de aplicativo e serviço de nuvem.

Teste de Aplicativo do Azure é um serviço que permite executar testes funcionais com o Workspaces do dramaturgo e testes de desempenho usando o Teste de Carga do Azure para identificar problemas em seus aplicativos.

Integridade do Serviço do Azure tem um painel de manutenção planejado que é uma seção dedicada no portal de Azure que o mantém informado sobre as próximas atividades de manutenção. Ele destaca eventos que podem afetar seus recursos de Azure, ajudando você a se preparar com antecedência.

O monitor de conexão é um recurso do Observador de Rede do Azure que você pode usar para monitoramento sintético e teste em tempo real de conectividade de rede em ambientes híbridos e do Azure. Em cenários de engenharia de caos, o monitor de conexão pode ser usado para injetar falhas em componentes de rede direcionados e medir continuamente as principais métricas, como latência e perda de pacotes. Essa funcionalidade permite que as equipes observem como as interrupções afetam a confiabilidade da rede, tanto para componentes de fluxo individuais quanto entre caminhos de rede de ponta a ponta. Para avaliar o impacto das falhas e identificar áreas de melhoria, compare a telemetria do monitor de conexão com as métricas de linha de base.

Links relacionados

• Backup e recuperação de desastre para aplicativos do Azure
• Lista de verificação para testes de confiabilidade
• Testar aplicativos para disponibilidade e resiliência

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.