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

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

Os testes de fiabilidade detetam fraquezas arquitetónicas antes que provoquem falhas. Sem testes deliberados contra cenários de falha, não se pode saber se os seus padrões de resiliência funcionam realmente ou se a sua carga de trabalho recupera dentro dos objetivos definidos.

Reforça a fiabilidade da sua 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 a resposta a incidentes. Use as estratégias deste artigo para estabelecer uma cadência de testes que valide regularmente a sua carga de trabalho contra os seus modos de falha. Evolui os teus testes à medida que a arquitetura muda e os incidentes revelam novas fraquezas. Ganhe a confiança de que a sua carga de trabalho consegue resistir a falhas, escalar para satisfazer a procura e recuperar dentro das suas metas de RTO e RPO, ao mesmo tempo que cria um ciclo de feedback que reforça a sua posição em termos de fiabilidade ao longo do tempo.

As principais estratégias-chave deste artigo baseiam-se nas práticas fundamentais de teste descritas em OE:09 Estratégias de Arquitetura para testes. Veja esse artigo primeiro. As recomendações deste guia estão orientadas para a fiabilidade e focam-se em alcançar confiança na capacidade da sua carga de trabalho para resistir a falhas e recuperar dentro dos seus objetivos.

A tabela seguinte define os termos-chave de fiabilidade utilizados ao longo deste artigo.

Definições

Definir o âmbito dos testes de fiabilidade com base nos tipos de serviço

Ao definir o âmbito dos seus testes de fiabilidade, considere o modelo de responsabilidade partilhada dos serviços que utiliza. Cada tipo de serviço (IaaS, PaaS, SaaS) vem com diferentes garantias de fiabilidade e diferentes níveis de controlo sobre o tratamento de falhas. Foca os teus testes nos aspetos de fiabilidade que possuis.

• Adapte a profundidade dos testes ao seu nível de responsabilidade. Para serviços de infraestrutura (IaaS), a sua equipa detém a maioria das decisões de fiabilidade, por isso invista em validação completa através de engenharia do caos e injeção de falhas. Para serviços de plataforma (PaaS) e software (SaaS), o fornecedor gere grande parte da fiabilidade subjacente. Concentre-se em como a sua carga de trabalho interage com esses serviços, como lidar com failovers de infraestrutura em PaaS, limitação, degradação do serviço ou alterações nos padrões de carga.

• Tenha em conta as cargas de trabalho de serviço misto. Quando a sua carga de trabalho abrange vários tipos de serviço, as responsabilidades de teste variam entre componentes. Pode testar o failover dos seus componentes de infraestrutura baseados em VM durante uma falha de uma zona de disponibilidade, mas confiará nas garantias do fornecedor no caso de uma base de dados PaaS concebida para elevada disponibilidade. Identifica onde estão esses limites e certifica-te de que os teus testes cobrem as lacunas entre eles.

Teste em função dos seus objetivos de fiabilidade de extremo a extremo

Os seus objetivos de fiabilidade, como SLOs, RTOs e RPOs, definem como a sua carga de trabalho deve comportar-se 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 ao longo de todo o fluxo. Um único componente pode ser reposto dentro do seu RTO, mas o tempo total de recuperação pode exceder o seu objetivo quando as dependências a jusante também precisam de ser repostas. Considere o tempo total de recuperação em todo o fluxo, incluindo o tempo para detetar o problema e responder.

• Defina o âmbito de teste com SLOs e orçamentos de erro. O seu orçamento de erro representa o investimento que pode fazer em injeção de falhas. Limite os testes de caos de modo a manter-se dentro dos seus SLOs e use as suas metas de recuperação do fluxo para definir os limites de cada teste.

Construir cenários de fiabilidade a partir de fluxos críticos e modos de falha

Comece pelos fluxos críticos na sua carga de trabalho e pelos modos de falha que podem afetá-los. Use a sua análise do modo de falha para identificar os cenários de falha mais impactantes e construir testes que validem a sua resiliência e estratégias de recuperação.

Prioriza pelo impacto e probabilidade. Nem todos os modos de falha justificam o mesmo investimento em testes. Foque-se primeiro em cenários com maior potencial de impacto no utilizador e maior probabilidade de ocorrer. Deixe que a análise dos modos de falha oriente esta priorização.

Valide a sua tolerância a falhas e mecanismos de recuperação

Foque-se nos cenários que mais provavelmente causarão inatividade ou degradarão a experiência do utilizador. Use as estratégias desta secção para construir testes que validem a capacidade da sua carga de trabalho para lidar com falhas e recuperar eficazmente.

Backup e restauração

Os seus testes de backup e restauro devem validar que a sua abordagem de proteção de dados cumpre os seus objetivos de recuperação.

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

• Defina alvos de recuperação. Meça os tempos reais de restauração em relação aos seus objetivos de RPO e RTO para confirmar que a sua estratégia de backup cumpre os seus objetivos de recuperação.

• Não presumas a integridade das cópias de segurança. Os backups podem ser configurados incorretamente para capturar apenas um subconjunto dos seus dados. Valide a integridade e completude dos dados, não apenas se uma operação de restauro é bem-sucedida.

• Teste isolado. Valida restaurações num ambiente separado da produção para poderes fazer verificações minuciosas sem interromper cargas de trabalho em tempo real.

Falhas transitórias

Falhas transitórias, como interrupções momentâneas da rede, indisponibilidade breve de serviços e tempos de espera da ligação, são riscos comuns de fiabilidade. Valide que a sua carga de trabalho lida com estas falhas sem afetar os utilizadores. Para obter mais informações, consulte Recomendações para o tratamento de falhas transitórias.

• Foca-te no que possuis. Se os seus SDKs ou serviços da plataforma gerirem automaticamente as novas tentativas e os disjuntores, teste o que acontece quando esses mecanismos integrados se esgotam, por exemplo, quando todas as novas tentativas falham ou um disjuntor abre.

• Validar configurações de tratamento de falhas. Avalie as configurações de gestão de falhas da sua carga de trabalho. Verifique se as políticas de repetição, os limiares dos circuit breakers e os valores de tempo limite funcionam como esperado em cenários realistas de falha.

• Teste a fronteira entre falha transitória e persistente. Valide se a sua carga de trabalho passa de forma fluida do comportamento de retentativa para um modo de contingência ou degradação quando uma falha persiste para além dos limiares esperados.

• Tenha em conta falhas transitórias provenientes das características de resiliência. A redundância de zonas e designs semelhantes frequentemente produzem falhas transitórias durante operações normais de failover. Por exemplo, uma base de dados redundante por zona pode causar falhas de ligação transitórias à medida que o tráfego se desloca para uma zona saudável durante uma interrupção. Teste se a sua carga de trabalho consegue lidar com estas falhas transitórias esperadas sem impacto significativo no utilizador.

Resposta à carga e ao dimensionamento

Valide que a sua carga de trabalho mantém a fiabilidade durante alterações de procura, tanto picos súbitos como aumentos graduais. Para mais informações, consulte estratégia de escalabilidade. Para orientações sobre testes de carga e de stress, consulte Recomendações para testes.

• Teste tanto scale-out como scale-in. Verifica se a nova capacidade entra em funcionamento rapidamente e que a escalabilidade não elimina pedidos nem deixa recursos órfãos.

• Tenha em conta o atraso no aumento de escala. Há sempre um atraso entre cumprir as condições para ativar a escalabilidade e ter a nova capacidade pronta. Determine se a sua carga de trabalho consegue suportar a procura durante esse intervalo ou se precisa de pré-provisionar capacidade adicional.

Falhas de dependência

A sua carga de trabalho provavelmente depende de serviços fora do seu controlo direto, como APIs de terceiros, serviços de plataforma gerida ou serviços internos partilhados. Valida que a tua carga de trabalho lida com falhas nessas dependências sem perturbações significativas para os utilizadores.

• Classifique as dependências de acordo com a criticidade. Nem todas as dependências justificam o mesmo investimento em testes. Dá prioridade aos testes de dependências que estão nos teus fluxos críticos e que não têm redundância ou caminhos de recuo incorporados.

• Testar o comportamento de contingência para cada dependência. Quando uma dependência se torna indisponível, a sua carga de trabalho deve recorrer a um caminho ou comportamento alternativo em vez de falhar por completo. Confirme que cada mecanismo de contingência é ativado corretamente e que as funcionalidades não relacionadas continuam a funcionar.

• Tenha em conta falhas parciais e em cascata. As dependências raramente falham de forma binária. Não teste apenas interrupções completas. Aumento da latência de cobertura, erros intermitentes e disponibilidade parcial de dados.

• Valide o isolamento e o raio de contenção da explosão. Verifica se uma única falha de dependência não se propaga para funcionalidades não relacionadas.

Autopreservação e recuperação

Valide como o seu design de auto-cura e autopreservação responde a falhas, incluindo se a sua carga de trabalho pode continuar a funcionar numa capacidade reduzida quando a recuperação total não for imediata.

• Teste a recuperação automatizada de ponta a ponta. Avalie os seus modelos de saúde para garantir que incluem as verificações corretas. Verifique se essas verificações detetam falhas com precisão, acione a remediação automática como esperado e devolva o sistema a um estado saudável dentro dos prazos aceitáveis.

• Validar os procedimentos de recuperação manual. A recuperação automática não cobre todos os cenários. Teste os procedimentos manuais em condições realistas para garantir que os operadores conseguem executá-los sob pressão e dentro dos seus objetivos de tempo de recuperação.

• Valide o comportamento de degradação controlada. Quando um componente falha, a sua carga de trabalho deve degradar-se de forma natural em vez de falhar completamente. Teste se é capaz de operar num modo reduzido, como colocar pedidos em fila para revisão manual, e se a experiência em modo degradado é aceitável para os utilizadores. Confirme que a sua equipa sabe como operar a carga de trabalho neste estado e como restaurar a funcionalidade total.

Incidentes e recuperação de desastres (DR)

Quando ocorre um incidente ou desastre, a sua capacidade de o detetar rapidamente e responder eficazmente é fundamental. Teste os seus planos e processos para garantir que abordam falhas catastróficas e incidentes graves. Use um ambiente dedicado para testes de DR para evitar impactar as cargas de trabalho em produção. Para mais informações, consulte plano de recuperação de desastres.

• Validar os mecanismos de deteção de incidentes. Simule incidentes para verificar se os registos de monitorização captam a informação necessária e que os alertas são acionados adequadamente. Por exemplo, teste com que rapidez é detetado o aumento das taxas de falha dos pedidos e com que frequência é feita a amostragem dos dados de monitorização.

• Testar processos de gestão de incidentes. Confirme que a sua equipa consegue seguir eficazmente os procedimentos de resposta a incidentes. Para mais informações, consulte resposta a incidentes.

• Testa o failover completo e o failback. Testar peças individuais isoladamente pode evitar falhas de coordenação que só aparecem durante uma transição real. Valide toda a sequência de failover, incluindo a troca de DNS, restauração de backups e consistência da replicação de dados, e reconexão do cliente. Teste também a reversão para a implementação primária, que é frequentemente mais complexa do que a comutação inicial.

• Validar a capacidade no ambiente de failover. Determine se o seu ambiente de failover tem capacidade pré-provisionada suficiente para gerir o tráfego imediatamente após o failover, sem colapsar sob carga. Teste se o ambiente consegue sustentar operações enquanto os mecanismos de escalabilidade são ativados e validam a sua abordagem de escalabilidade. Para mais informações, consulte Resposta de carga e escalabilidade.

• Compare com os seus objetivos. Se um teste de DR não corresponder ao teu RTO ou RPO, analisa as lacunas e atualiza o teu plano de DR em conformidade.

• Valida pessoas e processos. Os testes de DR 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 conseguem encontrar rapidamente guias de procedimentos específicos de DR sob pressão.

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

Os exercícios de mesa ajudam-no a identificar lacunas nos testes de fiabilidade antes que um incidente real as exponha. Ao simular cenários de falha com a sua equipa, pode identificar condições não testadas e validar que os seus procedimentos de resposta funcionam conforme esperado.

• Simula incidentes realistas. Percorra um cenário de falha, como uma interrupção regional ou uma implementação corrompida, e peça à sua equipa que descreva os passos que tomaria para detetar, responder e recuperar disso. Estas discussões frequentemente revelam pressupostos sobre o comportamento do sistema que não foram validados através dos testes.

• Transforme os resultados em casos de teste. Usar as lacunas e incertezas que surgem durante o exercício para criar novos testes de fiabilidade. Se a equipa descobrir que ninguém sabe como a carga de trabalho se comporta quando uma dependência específica falha, esse é um cenário a acrescentar à sua estratégia de testes.

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

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

Manutenção planeada

Durante os períodos de manutenção para atualizações ou correções, teste os componentes e os fluxos que não façam parte do trabalho de manutenção. Podes fazer testes sem o risco de degradar inesperadamente a carga de trabalho ou de o desligar. Se tiver tempo suficiente, teste também os componentes envolvidos na manutenção após a conclusão do trabalho.

Interrupção não planeada

Cada interrupção não planeada é uma oportunidade para reforçar a sua estratégia de testes de fiabilidade. Depois de restaurar o serviço e concluir a revisão pós-incidente, utilize as suas conclusões para melhorar os seus testes.

• Testa as tuas medidas de mitigação. Se aplicaste uma solução alternativa ou temporária, valida que consegue lidar com a carga esperada antes de a solução permanente estar implementada.

• Pesquise vulnerabilidades semelhantes. Revise outros componentes para os mesmos padrões de configuração ou design que contribuíram para a falha. Adicione testes para esses componentes antes que falhem da mesma forma.

Combinar diferentes tipos de testes

Quando executas diferentes tipos de testes em conjunto, podes revelar problemas de fiabilidade 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 é introduzida uma falha.

• Reutilizar a infraestrutura de teste existente. Se já tens uma infraestrutura e uma estrutura de testes para realizar testes de carga, usa-as para executar testes de caos em simultâneo. Combinar testes de carga e injeção de falhas na mesma execução de teste permite ver como a carga de trabalho se comporta em condições realistas, em que a carga e as falhas ocorrem ao mesmo tempo.

• Comece em ambientes não produtivos. Comece os testes de fiabilidade em ambientes de menor risco, onde possa explorar com segurança os modos de falha. Passe para testes em produção apenas depois de ter tirado o máximo partido dos ensinamentos obtidos em ambientes não produtivos e de ter mecanismos de proteção implementados para limitar o impacto e reverter rapidamente.

Utilize a injeção de falhas e a engenharia de caos

A injeção de falhas e a engenharia do caos ajudam-no a ganhar confiança na resiliência da sua carga de trabalho ao introduzir deliberadamente falhas e observar a resposta. Certifica-te de que tens estratégias de mitigação antes de fazeres experiências.

• Execute experiências de caos regularmente. Avalie o seu âmbito de teste. Injeta falhas em componentes e fluxos que assumes serem fiáveis. À medida que a sua arquitetura muda, surgem novos modos de falha e as suposições anteriores podem deixar de se confirmar. Faz experiências numa cadência regular para detetar regressões, validar novas dependências e confirmar que as mudanças recentes não introduziram fraquezas.

• Use a análise do modo de falha para focar os experimentos. Cada experimento deve visar uma falha específica ou conjunto de falhas e ter uma hipótese clara, como testar a capacidade de um dado fluxo para suportar a perda de um determinado componente. À medida que as experiências revelam novos modos de falha ou dependências por descobrir, atualize a sua análise de modos de falha para a manter atualizada.

• Contenham o raio de explosão durante os experimentos. Selecione os componentes que consegue recuperar rapidamente e estabeleça expectativas fundamentadas quanto ao efeito de cada injeção de falhas. Se um experimento ultrapassar o âmbito ou produzir resultados inesperados, parem-no. Equilibrar a recolha de dados significativos com a minimização do impacto nos utilizadores.

• Mede em relação às linhas de base. Estabelecer métricas consistentes de fiabilidade e desempenho para os fluxos e componentes em cada experiência. Compare métricas de estado degradado com estas linhas de base para compreender o efeito total da falha e determinar se o seu projeto de resiliência cumpre os seus objetivos.

• Use os resultados para ajustar a sua estratégia de testes. Utilizar os resultados dos experimentos para impulsionar novos testes, atualizar planos de recuperação e informar os itens do atraso de remediação. À medida que surgem comportamentos inesperados, crie testes direcionados para esses comportamentos e desenhe estratégias de remediação.

Compensação: os testes de injeção de falhas na produção podem causar interrupções e potencialmente causar tempo de inatividade. Seja transparente com as partes interessadas sobre esta possibilidade. Implemente salvaguardas para poder parar experiências e reverter rapidamente, e mantenha-se flexível quanto a quando realizar testes ou evitá-los durante períodos sensíveis. Para evitar interrupções indesejadas, planeie redundância suficiente e garanta que as suas partes interessadas compreendem a contrapartida em termos de custo.

Risco: Os testes de fiabilidade podem expandir a cobertura em muitos modos de falha, mas deve parar quando deixarem de fornecer valor significativo. Se já tens um acúmulo de problemas de fiabilidade conhecidos, prioriza corrigir esses problemas em vez de adicionar mais testes.

Facilitação de Serviços do Azure

O Planos de Teste do Azure é uma solução de gestão de testes baseada em navegador que fornece todas as capacidades necessárias para testes manuais planeados, testes de aceitação por utilizadores, testes exploratórios e recolha de feedback das partes interessadas.

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

Teste de aplicativos do Azure é um serviço que permite executar testes funcionais com Espaços de trabalho para dramaturgos e testes de desempenho usando Azure Load Testing para identificar problemas nas suas aplicações.

Azure Service Health tem um painel de manutenção planeada, que é uma secção dedicada no portal Azure que o mantém informado sobre as próximas atividades de manutenção. Destaca eventos que podem afetar os seus recursos no Azure, ajudando-o a preparar-se com antecedência.

O Monitor de Ligação é uma funcionalidade do Observador de Rede do Azure que pode utilizar para monitorização sintética e teste em tempo real da conectividade de rede em ambientes Azure e híbridos. Em cenários de engenharia de caos, o monitor de conexão pode ser usado para injetar falhas em componentes de rede de destino e medir continuamente métricas-chave, como latência e perda de pacotes. Esse recurso 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 para melhorias, compare a telemetria do monitor de conexão com as métricas da linha de base.

Ligações relacionadas

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

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.