As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Entendendo as compensações e os riscos
As arquiteturas resilientes devem usar alguns mecanismos bem testados, simples e confiáveis para responder às falhas. Para alcançar os mais altos níveis de resiliência, as cargas de trabalho devem detectar e se recuperar automaticamente do maior número possível de modos de falha. Fazer isso requer um grande investimento na realização de análises de resiliência. Isso significa que alcançar níveis mais altos de resiliência envolve fazer concessões. No entanto, à medida que você continua fazendo concessões, você atinge um ponto de retornos decrescentes em relação aos seus objetivos de resiliência. Aqui estão as vantagens e desvantagens mais comuns:
-
Custo — Componentes redundantes, observabilidade aprimorada, ferramentas adicionais ou maior utilização de recursos resultarão em maiores custos.
-
Complexidade do sistema — Detectar e responder aos modos de falha, incluindo as soluções de mitigação, e a possibilidade de não usar serviços gerenciados resultam em maior complexidade do sistema.
-
Esforço de engenharia — São necessárias horas adicionais de desenvolvimento para criar soluções que detectem e respondam aos modos de falha.
-
Sobrecarga operacional — Monitorar e operar um sistema que lida com mais modos de falha pode aumentar a sobrecarga operacional, especialmente quando você não pode usar serviços gerenciados para mitigar modos de falha específicos.
-
Latência e consistência — A criação de sistemas distribuídos que favoreçam a disponibilidade exige compensações entre consistência e latência, conforme descrito no teorema PACELC.
Ao considerar as mitigações para os modos de falha identificados na história do usuário, considere as compensações que você precisa fazer. Assim como acontece com a segurança, a resiliência é um problema de otimização. Você precisa decidir se deseja evitar, mitigar, transferir ou aceitar os riscos apresentados pela falha identificada. Pode haver alguns modos de falha que você pode evitar, um conjunto que você aceita e alguns que você pode transferir. Você pode optar por mitigar muitos dos modos de falha identificados. Para determinar qual abordagem adotar, faça uma avaliação fazendo duas perguntas: Qual é a probabilidade de que a falha ocorra? Qual é o impacto na carga de trabalho se ela ocorrer?
A probabilidade é o quão plausível é que um evento ocorra. Por exemplo, se a história do usuário tiver um componente que opera em uma única instância do Amazon Elastic Compute Cloud (Amazon EC2), o componente pode ser interrompido em algum momento durante a operação do sistema, talvez devido a procedimentos de correção ou erros do sistema operacional. Como alternativa, um banco de dados gerenciado pelo Amazon Relational Database Service (Amazon RDS) que sincroniza dados entre suas instâncias primária e secundária tem baixa plausibilidade de ficar completamente indisponível.
O impacto é uma estimativa dos danos que um evento pode causar. Ela deve ser avaliada tanto do ponto de vista financeiro quanto da reputação e é relativa ao valor das histórias de usuário que ela impacta. Por exemplo, um banco de dados sobrecarregado pode ter um impacto significativo na capacidade de um sistema de comércio eletrônico de aceitar novos pedidos. No entanto, a perda de uma única instância de uma frota de 20 instâncias atrás de um balanceador de carga provavelmente teria muito pouco impacto.
Você pode comparar as respostas a essas perguntas com o custo das compensações que você precisa fazer para mitigar o risco. Quando você considera essas informações tendo em vista seu limite de risco e seus objetivos de resiliência, elas informam sua decisão sobre quais modos de falha você planeja mitigar ativamente.
