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á.
# Noções básicas da disponibilidade
A disponibilidade é uma das principais formas de medir quantitativamente a resiliência. Definimos disponibilidade, *A*, como a porcentagem de tempo em que uma workload está disponível para uso. É uma proporção entre o “tempo de atividade” esperado (disponibilidade) e o tempo total medido (o “tempo de atividade” esperado mais o “tempo de inatividade” esperado).
![\[Imagem da equação. A = tempo de atividade/(tempo de atividade + tempo de inatividade)\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
Para entender melhor essa fórmula, veremos como medir o tempo de atividade e o tempo de inatividade. Primeiro, queremos saber quanto tempo a workload durará sem falhas. Chamamos isso de *tempo médio entre falhas* (MTBF), o tempo médio entre o início da operação normal de uma workload e sua próxima falha. Então, queremos saber quanto tempo levará para se recuperar após a falha.
Chamamos isso de *tempo médio de reparo (ou recuperação)* (MTTR), um período em que a workload não está disponível enquanto o subsistema com defeito é reparado ou retornado ao serviço. Um período de tempo importante no MTTR é o *tempo médio de detecção* (MTTD), a quantidade de tempo entre a ocorrência de uma falha e o início das operações de reparo. O diagrama a seguir demonstra como todas essas métricas estão relacionadas.
![\[Diagrama mostrando a relação entre MTTD, MTTR e MTBF\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
Assim, podemos expressar disponibilidade, *A*, usando MTBF, quando a workload está alta, e MTTR, quando a workload está inativa.
![\[Imagem da equação. A = MTBF / ( MTBF + MTTR)\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
E a probabilidade de a workload estar “inativa” (ou seja, não disponível) é a probabilidade de falha, *F*.
![\[Imagem da equação. F = 1 - A\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
[Confiabilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html) é a capacidade de uma workload fazer a coisa certa, quando solicitada, dentro do tempo de resposta especificado. É isso que a disponibilidade mede. Ter uma workload falhar com menos frequência (MTBF mais longo) ou ter um tempo de reparo mais curto (MTTR mais curto) melhora sua disponibilidade.
**Rule1**
Falhas menos frequentes (MTBF mais longo), tempos de detecção de falhas mais curtos (MTTD mais curto) e tempos de reparo mais curtos (MTTR mais curto) são os três fatores usados para melhorar a disponibilidade em sistemas distribuídos.
**Topics**
+ [Disponibilidade do sistema distribuído](distributed-system-availability.md)
+ [Disponibilidade com dependências](availability-with-dependencies.md)
+ [Disponibilidade com redundância](availability-with-redundancy.md)
+ [Teorema CAP](cap-theorem.md)
+ [Tolerância a falhas e isolamento de falhas](fault-tolerance-and-fault-isolation.md)
# Disponibilidade do sistema distribuído
Os sistemas distribuídos são compostos por componentes de software e componentes de hardware. Alguns dos componentes do software podem ser, eles próprios, outro sistema distribuído. A disponibilidade dos componentes subjacentes de hardware e software afeta a disponibilidade resultante de sua workload.
O cálculo da disponibilidade usando MTBF e MTTR tem suas raízes nos sistemas de hardware. No entanto, os sistemas distribuídos falham por motivos muito diferentes dos de um hardware. Quando um fabricante pode calcular consistentemente o tempo médio antes que um componente de hardware se desgaste, o mesmo teste não pode ser aplicado aos componentes de software de um sistema distribuído. O hardware normalmente segue a curva “banhada” da taxa de falhas, enquanto o software segue uma curva escalonada produzida por defeitos adicionais que são introduzidos a cada nova versão (consulte [Confiabilidade do software](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability)).
![\[Diagrama mostrando as taxas de falha de hardware e software\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
Além disso, o software em sistemas distribuídos normalmente muda a taxas exponencialmente maiores do que o hardware. Por exemplo, um disco rígido magnético padrão pode ter uma taxa média de falha anualizada (AFR) de 0,93%, o que, na prática, para um HDD, pode significar uma vida útil de pelo menos 3 a 5 anos antes de atingir o período de desgaste, potencialmente mais longa (consulte [Dados e estatísticas do disco rígido Backblaze, 2020).](https://www.backblaze.com/b2/hard-drive-test-data.html) O disco rígido não muda materialmente durante essa vida útil, onde, em 3 a 5 anos, por exemplo, a Amazon pode implantar mais de 450 a 750 milhões de alterações em seus sistemas de software. (Consulte [Amazon Builders' Library — Automatização de implantações seguras e sem intervenção](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/).)
O hardware também está sujeito ao conceito de obsolescência planejada, ou seja, tem uma vida útil integrada e precisará ser substituído após um determinado período de tempo. (Veja [A Grande Conspiração da Lâmpada](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy).) O software, teoricamente, não está sujeito a essa restrição, não tem um período de desgaste e pode ser operado indefinidamente.
Tudo isso significa que os mesmos modelos de teste e previsão usados pelo hardware para gerar números MTBF e MTTR não se aplicam ao software. Houve centenas de tentativas de criar modelos para resolver esse problema desde a década de 1970, mas todas elas geralmente se enquadram em duas categorias: modelagem de previsão e modelagem de estimativa. (Consulte a [lista de modelos de confiabilidade de software](https://en.wikipedia.org/wiki/List_of_software_reliability_models).)
Assim, o cálculo de um MTBF e MTTR prospectivos para sistemas distribuídos e, portanto, de uma disponibilidade prospectiva, sempre será derivado de algum tipo de previsão ou previsão. Eles podem ser gerados por meio de modelagem preditiva, simulação estocástica, análise histórica ou testes rigorosos, mas esses cálculos não garantem tempo de atividade ou inatividade.
Os motivos pelos quais um sistema distribuído falhou no passado podem nunca mais ocorrer. As razões pelas quais ele falhará no futuro provavelmente serão diferentes e possivelmente desconhecidas. Os mecanismos de recuperação necessários também podem ser diferentes para futuras falhas dos usados no passado e levar períodos de tempo significativamente diferentes.
Além disso, MTBF e MTTR são médias. Haverá alguma variação do valor médio em relação aos valores reais vistos (o desvio padrão, σ, mede essa variação). Assim, as workloads podem passar por um tempo menor ou maior entre falhas e tempos de recuperação no uso real da produção.
Dito isso, a disponibilidade dos componentes de software que compõem um sistema distribuído ainda é importante. O software pode falhar por vários motivos (discutidos mais na próxima seção) e afetar a disponibilidade da workload. Assim, para sistemas distribuídos de alta disponibilidade, o mesmo foco no cálculo, medição e melhoria da disponibilidade dos componentes de software deve ser dado ao hardware e aos subsistemas externos de software.
**Rule2**
A disponibilidade do software em sua workload é um fator importante da disponibilidade geral de sua workload e deve receber o mesmo foco que outros componentes.
É importante observar que, apesar de serem difíceis de prever o MTBF e o MTTR para sistemas distribuídos, eles ainda fornecem informações importantes sobre como melhorar a disponibilidade. Reduzir a frequência de falhas (MTBF mais alto) e diminuir o tempo de recuperação após a ocorrência da falha (MTTR mais baixo) levarão a uma maior disponibilidade empírica.
## Tipos de falhas em sistemas distribuídos
Geralmente, há duas classes de bugs em sistemas distribuídos que afetam a disponibilidade, carinhosamente chamadas de *Bohrbug* e *Heisenbug* (consulte [“Uma conversa com Bruce Lindsay”, ACM Queue vol. 2, nº 8 – novembro de 2004](http://queue.acm.org/detail.cfm?id=1036486).)
Um Bohrbug é um problema repetível de software funcional. Com a mesma entrada, o bug produzirá consistentemente a mesma saída incorreta (como o modelo determinístico do átomo de Bohr, que é sólido e facilmente detectado). Esses tipos de bugs são raros quando uma workload chega à produção.
Um Heisenbug é um bug transitório, o que significa que só ocorre em condições específicas e incomuns. Essas condições geralmente estão relacionadas a coisas como hardware (por exemplo, uma falha transitória do dispositivo ou especificidades da implementação de hardware, como tamanho do registro), otimizações do compilador e implementação da linguagem, condições de limite (por exemplo, temporariamente fora do armazenamento) ou condições de corrida (por exemplo, não usar um semáforo para operações com vários processos).
Os Heisenbugs compõem a maioria dos bugs em produção e são difíceis de encontrar porque são ilusórios e parecem mudar de comportamento ou desaparecer quando você tenta observá-los ou depurá-los. No entanto, se você reiniciar o programa, a operação com falha provavelmente será bem-sucedida porque o ambiente operacional é um pouco diferente, eliminando as condições que introduziram o Heisenbug.
Assim, a maioria das falhas na produção são transitórias e, quando a operação é repetida, é improvável que falhe novamente. Para serem resilientes, os sistemas distribuídos precisam ser tolerantes a falhas da Heisenbugs. Exploraremos como isso pode ser feito na seção [Aumentando o MTBF do sistema distribuído](increasing-mtbf.md#increasing-mtbf.title).
# 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.
# Disponibilidade com redundância
Quando uma workload utiliza subsistemas múltiplos, independentes e redundantes, ela pode atingir um nível mais alto de disponibilidade teórica do que usando um único subsistema. Por exemplo, considere uma workload composta por dois subsistemas idênticos. Ele pode estar completamente operacional se o subsistema um ou o subsistema dois estiverem operacionais. Para que todo o sistema fique inativo, os dois subsistemas devem estar inativos ao mesmo tempo.
Se a probabilidade de falha de um subsistema for 1 − *α*, então a probabilidade de dois subsistemas redundantes estarem inativos ao mesmo tempo é o produto da probabilidade de falha de cada subsistema, *F* = (1−*α*1) × (1−*α*2). Para uma workload com dois subsistemas redundantes, usando a Equação *(3)*, isso fornece uma disponibilidade definida como:
![\[Imagem de três equações\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)
Portanto, para dois subsistemas cuja disponibilidade é de 99%, a probabilidade de um falhar é de 1% e a probabilidade de ambos falharem é (1−99%) × (1−99%) = 0,01%. Isso torna a disponibilidade usando dois subsistemas redundantes de 99,99%.
Isso também pode ser generalizado para incorporar peças de reposição redundantes adicionais *s**.* Na Equação *(5)*, assumimos apenas uma única peça de reposição, mas uma workload pode ter duas, três ou mais peças de reposição para que possa sobreviver à perda simultânea de vários subsistemas sem afetar a disponibilidade. Se uma workload tem três subsistemas e dois são de reposição, a probabilidade de que todos os três subsistemas falhem ao mesmo tempo é (1−*α*) × (1−*α*) × (1−*α*) or (1−*α*)3. Em geral, uma workload com *s* peças de reposição só falhará se os subsistemas *s* \$1 1 falharem.
Para uma workload com *n* subsistemas e *s* peças de reposição, *f* é o número de modos de falha ou as maneiras pelas quais os subsistemas *s* \$11 podem falhar a partir de *n*.
Isso é efetivamente o teorema binomial, a matemática combinatória de escolher *k* elementos de um conjunto de *n*, ou *“**n* *escolher* *k**”*. Nesse caso, *k* é *s* \$1 1.
![\[Imagem de quatro equações\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)
Podemos então produzir uma aproximação de disponibilidade generalizada que incorpora o número de modos de falha e a economia. (Para entender por que isso é uma aproximação, consulte o Apêndice 2 de Highleyman, et al. [Quebrando a barreira da disponibilidade](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331).)
![\[Imagem de quatro equações\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)
A economia pode ser aplicada a qualquer dependência que forneça recursos que falhem de forma independente. Instâncias do Amazon EC2 em diferentes AZs ou buckets do Amazon S3 em Regiões da AWS diferentes são exemplos disso. O uso de peças de reposição ajuda essa dependência a alcançar uma maior disponibilidade total para suportar as metas de disponibilidade da workload.
**Regra 5**
Use a economia para aumentar a disponibilidade das dependências em uma workload.
No entanto, economizar tem um custo. Cada reposição adicional custa o mesmo que o módulo original, aumentando o custo pelo menos linearmente. Criar uma workload que possa usar peças de reposição também aumenta sua complexidade. Ele deve saber como identificar falhas de dependência, transformar o trabalho em um recurso saudável e gerenciar a capacidade geral da workload.
A redundância é um problema de otimização. Poucas peças de reposição e a workload pode falhar com mais frequência do que o desejado, muitas peças sobressalentes e a workload custa muito para ser executada. Há um limite no qual adicionar mais peças de reposição custará mais do que a disponibilidade adicional que elas obtêm garante.
Usando nossa fórmula de disponibilidade geral com peças de reposição, Equação *(7)*, para um subsistema que tem uma disponibilidade de 99,5%, com duas peças de reposição, a disponibilidade da workload é *A* ≈ 1 − (1) (1−0,95) 3 = 99,9999875% (aproximadamente 3,94 segundos de tempo de inatividade por ano), e com 10 peças de reposição, obtemos *A* ≈ 1 − (1) (1−0,995) 11 = 25,5 9′*s* (o tempo de inatividade aproximado seria 1,26252 × 10 −15*m**s* por ano, efetivamente 0). Ao comparar essas duas workloads, incorremos em um aumento de 5 vezes no custo de economia para obter quatro segundos a menos de tempo de inatividade por ano. Para a maioria das workloads, o aumento no custo seria injustificado devido a esse aumento na disponibilidade. A figura a seguir mostra essa relação.
![\[Diagrama mostrando retornos decrescentes decorrentes do aumento da poupança\]](http://docs.aws.amazon.com/pt_br/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)
Com três peças de reposição ou mais, o resultado são frações de segundo do tempo de inatividade esperado por ano, o que significa que, após esse ponto, você atinge a área de retornos decrescentes. Pode haver uma necessidade de “adicionar mais” para alcançar níveis mais altos de disponibilidade, mas, na realidade, o custo-benefício desaparece muito rapidamente. O uso de mais de três peças de reposição não fornece um ganho material perceptível para quase todas as workloads quando o próprio subsistema tem pelo menos 99% de disponibilidade.
**Regra 6**
Há um limite superior para a eficiência de custos da poupança. Utilize o mínimo de peças de reposição necessárias para alcançar a disponibilidade necessária.
Você deve considerar a unidade de falha ao selecionar o número correto de peças de reposição. Por exemplo, vamos examinar uma workload que requer 10 instâncias do EC2 para lidar com a capacidade de pico e elas são implantadas em uma única AZ.
Como as AZs foram projetadas para serem limites de isolamento de falhas, a unidade de falha não é apenas uma única instância do EC2, porque uma AZ inteira de instâncias do EC2 pode falhar em conjunto. Nesse caso, você desejará [adicionar redundância com outra AZ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html), implantando 10 instâncias EC2 adicionais para lidar com a carga em caso de falha de AZ, totalizando 20 instâncias EC2 (seguindo o padrão de estabilidade estática).
Embora pareçam ser 10 instâncias extras do EC2, na verdade é apenas uma única AZ sobressalente, portanto, não excedemos o ponto de retornos decrescentes. No entanto, você pode ser ainda mais econômico e, ao mesmo tempo, aumentar sua disponibilidade utilizando três AZs e implantando cinco instâncias EC2 por AZ.
Isso fornece uma AZ extra com um total de 15 instâncias EC2 (versus duas AZs com 20 instâncias), ainda fornecendo o total de 10 instâncias necessárias para atender à capacidade máxima durante um evento que afeta uma única AZ. Portanto, você deve incorporar o sparing para ser tolerante a falhas em todos os limites de isolamento de falhas usados pela workload (instância, célula, AZ e região).
# Teorema CAP
Outra forma de pensarmos sobre a disponibilidade é em relação ao teorema CAP. O teorema afirma que um sistema distribuído, composto por vários nós que armazenam dados, não pode fornecer simultaneamente mais de duas das três garantias a seguir:
+ **C**onsistência: cada solicitação de leitura recebe a gravação mais recente ou um erro quando a consistência não pode ser garantida.
+ **D**isponibilidade: cada solicitação recebe uma resposta sem erros, mesmo quando os nós estão inativos ou indisponíveis.
+ **T**olerância à partição: o sistema continua operando apesar da perda de um número arbitrário de mensagens entre os nós.
(Para obter mais detalhes, consulte Seth Gilbert e Nancy Lynch, [http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970), *ACM SIGACT News*, Volume 33, Edição 2 (2002), pág. 51–59.)
A maioria dos sistemas distribuídos precisa tolerar falhas de rede e, portanto, o particionamento de rede deve ser permitido. Isso significa que essas workloads precisam escolher entre consistência e disponibilidade quando ocorre uma partição de rede. Se a workload escolher a disponibilidade, ela sempre retornará uma resposta, mas com dados potencialmente inconsistentes. Se escolher a consistência, então, durante uma partição de rede, ele retornará um erro, pois a workload não pode ter certeza sobre a consistência dos dados.
Para workloads cujo objetivo é fornecer níveis mais altos de disponibilidade, elas podem escolher Disponibilidade e Tolerância à Partição (AP) para evitar o retorno de erros (estar indisponível) durante uma partição de rede. Isso resulta na necessidade de um [modelo de consistência](https://en.wikipedia.org/wiki/Consistency_model) mais relaxado, como consistência eventual ou consistência monotônica.
# Tolerância a falhas e isolamento de falhas
Esses são dois conceitos importantes quando pensamos em disponibilidade. A tolerância a falhas é a capacidade de [resistir a falhas do subsistema](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) e manter a disponibilidade (fazendo a coisa certa dentro de um SLA estabelecido). Para implementar a tolerância a falhas, as workloads usam subsistemas sobressalentes (ou redundantes). Quando um dos subsistemas em um conjunto redundante falha, outro retoma seu trabalho, normalmente quase sem problemas. Nesse caso, as peças de reposição são realmente capacidade ociosa; elas estão disponíveis para assumir 100% do trabalho do subsistema com falha. Com peças de reposição verdadeiras, várias falhas no subsistema são necessárias para produzir um impacto adverso na workload.
O isolamento de falhas minimiza o escopo do impacto quando ocorre uma falha. Isso normalmente é implementado com modularização. As workloads são divididas em pequenos subsistemas que falham de forma independente e podem ser reparados isoladamente. A falha de um módulo [não se propaga além do módulo](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html). Essa ideia se estende tanto verticalmente, em diferentes funcionalidades em uma workload, quanto horizontalmente, em vários subsistemas que fornecem a mesma funcionalidade. Esses módulos atuam como contêineres de falhas que limitam o escopo do impacto durante um evento.
Os padrões arquitetônicos de ambientes de gerenciamento, planos de dados e estabilidade estática apoiam diretamente a implementação de tolerância e isolamento de falhas. O artigo [Estabilidade estática usando zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) da Amazon Builders' Library fornece boas definições para esses termos e como eles se aplicam à criação de workloads resilientes e altamente disponíveis. Este whitepaper usa esses padrões na seção [Projetando sistemas distribuídos altamente disponíveis no AWS,](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title) e também resumimos suas definições aqui.
+ **Ambiente de gerenciamento** — A parte da workload envolvida na realização de alterações: adição de recursos, exclusão de recursos, modificação de recursos e propagação dessas alterações para onde elas são necessárias. Os ambientes de gerenciamento geralmente são mais complexos e têm mais partes móveis do que os planos de dados e, portanto, são estatisticamente mais propensos a falhar e ter menores disponibilidades.
+ **Plano de dados** — A parte da workload que fornece a funcionalidade comercial diária. Os planos de dados tendem a ser mais simples e operar em volumes maiores do que os ambientes de gerenciamento, levando a maiores disponibilidades.
+ **Estabilidade estática** — A capacidade de uma workload continuar operando corretamente apesar das deficiências de dependência. Um método de implementação é remover as dependências do ambiente de gerenciamento dos planos de dados. Outro método é acoplar vagamente as dependências da workload. Talvez a workload não veja nenhuma informação atualizada (como coisas novas, coisas excluídas ou coisas modificadas) que sua dependência deveria ter fornecido. No entanto, tudo o que estava fazendo antes de a dependência ser prejudicada continua funcionando.
Quando pensamos no comprometimento de uma workload, há duas abordagens de alto nível que podemos considerar para a recuperação. O primeiro método é responder a essa deficiência depois que ela acontece, talvez usando o AWS Auto Scaling para adicionar nova capacidade. O segundo método é se preparar para essas deficiências antes que elas aconteçam, talvez superprovisionando a infraestrutura de uma workload para que ela possa continuar operando corretamente sem precisar de recursos adicionais.
Um sistema estaticamente estável usa a última abordagem. Ele pré-provisiona a capacidade não utilizada para estar disponível durante a falha. Esse método evita criar uma dependência em um ambiente de gerenciamento no caminho de recuperação da workload para provisionar nova capacidade de recuperação da falha. Além disso, o provisionamento de nova capacidade para vários recursos leva tempo. Enquanto espera por uma nova capacidade, sua workload pode ser sobrecarregada pela demanda existente e sofrer uma maior degradação, levando ao “esgotamento” ou à perda total da disponibilidade. No entanto, você também deve considerar as implicações de custo da utilização da capacidade pré-provisionada em relação às suas metas de disponibilidade.
A estabilidade estática fornece as próximas duas regras para workloads de alta disponibilidade.
**Regra 7**
Não use dependências em ambientes de gerenciamento em seu plano de dados, especialmente durante a recuperação.
**Regra 8**
Acople as dependências de forma flexível para que sua workload possa operar corretamente apesar do comprometimento da dependência, sempre que possível.