Aplicação do framework - Recomendações da AWS

Aplicação do framework

A melhor maneira de aplicar o framework de análise de resiliência é começar com um conjunto padrão de perguntas, organizado por categoria de falha, que você deve fazer sobre cada componente da história do usuário que você está analisando. Se algumas perguntas não se aplicarem a todos os componentes da sua workload, use as perguntas mais aplicáveis.

Você pode abordar o pensamento sobre os modos de falha sob duas perspectivas:

  • Como a falha afeta a capacidade do componente de apoiar a história do usuário?

  • Como a falha afeta as interações do componente com os outros componentes?

Por exemplo, ao considerar armazenamentos de dados e carga excessiva, você pode pensar em modos de falha em que o banco de dados está sob carga excessiva e as consultas atingem o tempo limite. Você também pode pensar em como seu cliente de banco de dados pode sobrecarregar o banco de dados com novas tentativas ou falhar ao encerrar as conexões do banco de dados, esgotando o grupo de conexões. Outro exemplo é um processo de autenticação, que pode incluir várias etapas. Você precisa pensar em como a falha de uma aplicação de autenticação multifator (MFA) ou de um provedor de identidades (IdP) terceiro pode afetar a história do usuário nesse sistema de autenticação.

Ao responder às perguntas a seguir, você deve considerar a origem da falha. Por exemplo, a sobrecarga foi causada por um aumento de clientes ou por um operador humano que retirou muitos nós de operação durante uma atividade de manutenção? Talvez você consiga identificar várias fontes de falha em cada pergunta, o que pode exigir mitigações diferentes. Ao fazer as perguntas, mantenha um registro dos possíveis modos de falha descobertos, a quais componentes eles se aplicam e a origem de cada falha.

Pontos únicos de falha

  • O componente foi projetado para redundância?

  • O que acontece se o componente falhar?

  • Sua aplicação pode tolerar a perda parcial ou total de uma única zona de disponibilidade?

Latência excessiva

  • O que acontecerá se esse componente apresentar maior latência ou se um componente com o qual ele interage tiver maior latência (ou interrupções na rede, como redefinições de TCP)?

  • Você configurou adequadamente os tempos limite com uma estratégia de repetição?

  • A falha é rápida ou lenta? Existem efeitos em cascata, como o envio involuntário de todo o tráfego para um recurso comprometido devido ao seu comportamento de falha rápida?

  • Quais são as solicitações mais caras feitas a esse componente?

Carga excessiva

  • O que pode sobrecarregar esse componente? Como esse componente pode sobrecarregar outros componentes?

  • Como você pode evitar o desperdício de recursos em trabalhos que nunca terão êxito?

  • Você tem um disjuntor configurado para o componente?

  • Existe algo que pode criar um backlog insuperável?

  • Onde esse componente pode ter um comportamento bimodal?

  • Quais limites ou cotas de serviço podem ser excedidos (incluindo a capacidade de armazenamento)?

  • Como o componente é escalado sob carga?

Configuração incorreta e bugs

  • Como você evita que configurações incorretas e bugs sejam implantados na produção?

  • É possível reverter automaticamente uma implantação ruim ou desviar o tráfego do contêiner com falha onde a atualização ou alteração foi implantada?

  • Quais barreiras de proteção você tem para evitar erros do operador?

  • Quais itens (como credenciais ou certificados) podem expirar?

Destino compartilhado

  • Quais são suas delimitações de isolamento contra falhas?

  • As alterações feitas nas unidades de implantação são, no mínimo, tão pequenas quanto as delimitações de isolamento contra falhas pretendidas, mas de preferência menores, como um ambiente one-box (uma única instância na delimitação de isolamento contra falhas)?

  • Esse componente é compartilhado entre histórias de usuários ou outras workloads?

  • Quais outros componentes estão firmemente acoplados a esse componente?

  • O que acontecerá se esse componente ou suas dependências apresentarem uma falha parcial ou cinza?

Depois de fazer essas perguntas, você também pode usar o SEEMS para desenvolver outras perguntas específicas para sua workload e para cada componente. O SEEMS é melhor usado como uma forma estruturada de pensar sobre os modos de falha e como fonte de inspiração ao realizar uma análise de resiliência. Não é uma taxonomia rígida. Não perca tempo se preocupando com a categoria em que um determinado modo de falha se encaixa, pois isso não é importante. O importante é que você considerou a falha e a registrou. Não há respostas erradas. Ser criativo e buscar soluções não convencionais é vantajoso. Além disso, não presuma que um modo de falha já esteja mitigado. Inclua todos os modos de falha em potencial que você possa imaginar.

É improvável que você antecipe todos os modos de falha em potencial em seu primeiro exercício. Várias iterações do framework ajudam você a gerar um modelo mais completo, para que você não precise tentar resolver tudo na primeira tentativa. Você pode executar a análise em uma cadência regular, semanal ou quinzenal. Em cada sessão, concentre-se em um modo ou componente de falha específico. Isso pode ajudar a progredir de forma constante e incremental na melhoria da resiliência de sua workload. Depois de coletar uma lista de possíveis modos de falha para uma história de usuário, você pode decidir o que fazer com eles.