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á. # Disponibilidade com dependências Na seção anterior, mencionamos que hardware, software e potencialmente outros sistemas distribuídos são todos componentes de sua workload. Chamamos esses componentes de *dependências*, as coisas das quais sua workload depende para fornecer sua funcionalidade. Existem dependências *rígidas*, que são aquelas coisas sem as quais sua workload não pode funcionar, e dependências *flexíveis* cuja indisponibilidade pode passar despercebida ou tolerada por algum período de tempo. Dependências rígidas têm um impacto direto na disponibilidade da sua workload. Talvez queiramos tentar calcular a disponibilidade máxima teórica de uma workload. Esse é o produto da disponibilidade de todas as dependências, incluindo o próprio software (*α**n* é a disponibilidade de um único subsistema) porque cada uma deve estar operacional. ![\[Imagem da equação. A = α1 X α2 X ... X αnsubscript>\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png) Os números de disponibilidade usados nesses cálculos geralmente estão associados a itens como SLAs ou objetivos de nível de serviço (SLOs). Os SLAs definem o nível esperado de serviço que os clientes receberão, as métricas pelas quais o serviço é medido e as remediações ou penalidades (geralmente monetárias) caso os níveis de serviço não sejam alcançados. Usando a fórmula acima, podemos concluir que, puramente matematicamente, uma workload não pode estar mais disponível do que qualquer uma de suas dependências. Mas, na realidade, o que normalmente vemos é que esse não é o caso. Uma workload criada usando duas ou três dependências com SLAs de 99,99% de disponibilidade ainda pode atingir 99,99% de disponibilidade sozinha, ou mais. Isso ocorre porque, conforme descrevemos na seção anterior, esses números de disponibilidade são estimativas. Eles estimam ou preveem com que frequência uma falha ocorre e com que rapidez ela pode ser reparada. Eles não são garantia de tempo de inatividade. As dependências frequentemente excedem o SLA ou SLO de disponibilidade declarado. As dependências também podem ter objetivos de disponibilidade interna mais altos em relação aos quais elas visam o desempenho do que os números fornecidos em SLAs públicos. Isso fornece um nível de mitigação de risco no cumprimento dos SLAs quando o desconhecido ou incognoscível acontece. Por fim, sua workload pode ter dependências cujos SLAs não podem ser conhecidos ou não oferecem um SLA ou SLO. Por exemplo, o roteamento mundial da Internet é uma dependência comum para muitas workloads, mas é difícil saber quais provedores de serviços de Internet seu tráfego global está usando, se eles têm SLAs e se são consistentes entre os provedores. O que tudo isso nos diz é que calcular uma disponibilidade teórica máxima provavelmente produzirá apenas um cálculo aproximado da ordem de magnitude, mas, por si só, provavelmente não será preciso ou fornecerá uma visão significativa. O que a matemática nos diz é que quanto menos coisas dependerem de sua workload, reduzirá a probabilidade geral de falha. Quanto menos números menores que um forem multiplicados, maior será o resultado. **Rule3** Reduzir as dependências pode ter um impacto positivo na disponibilidade. A matemática também ajuda a informar o processo de seleção de dependências. O processo de seleção afeta a forma como você projeta sua workload, como você aproveita a redundância nas dependências para melhorar sua disponibilidade e se você considera essas dependências como flexíveis ou rígidas. As dependências que podem afetar sua workload devem ser escolhidas com cuidado. A próxima regra fornece orientação sobre como fazer isso. **Regra 4** Em geral, selecione dependências cujas metas de disponibilidade sejam iguais ou maiores que as metas da sua workload.