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á.
# Projetando sistemas distribuídos de alta disponibilidade em AWS
As seções anteriores trataram principalmente da disponibilidade teórica das workloads e do que elas podem alcançar. São um conjunto importante de conceitos que você deve ter em mente ao criar sistemas distribuídos. Elas ajudarão a informar seu processo de seleção de dependências e como implementar a redundância.
Também analisamos a relação deMTTD,MTTR, e MTBF com a disponibilidade. Esta seção apresentará orientações práticas com base na teoria anterior. Em resumo, as cargas de trabalho de engenharia para alta disponibilidade visam aumentar MTBF e diminuir oMTTR, bem como o. MTTD
Embora eliminar todas as falhas seja o ideal, isso não é realista. Em grandes sistemas distribuídos com dependências profundamente empilhadas, ocorrerão falhas. “Tudo falha o tempo todo” (veja Werner Vogels, Amazon.comCTO, [10 lições de 10 anos de Amazon Web Services](https://www.allthingsdistributed.com/2016/03/10-lessons-from-10-years-of-aws.html).) e “você não pode legislar contra falhas [então] foque na detecção e resposta rápidas”. (consulte Chris Pinkham, membro fundador da EC2 equipe da Amazon, [ARC335Designing for failure: Architecting](https://d1.awsstatic.com/events/reinvent/2019/REPEAT_1_Designing_for_failure_Architecting_resilient_systems_on_AWS_ARC335-R1.pdf) resilient systems on) AWS
O que isso significa é que, frequentemente, você não tem controle sobre se a falha acontece. O que você pode controlar é a rapidez com que detecta a falha e faz algo a respeito. Portanto, embora o aumento ainda MTBF seja um componente importante da alta disponibilidade, as mudanças mais significativas que os clientes têm sob seu controle são a redução MTTD MTTR e.
**Topics**
+ [Reduzindo MTTD](reducing-mttd.md)
+ [Reduzindo MTTR](reducing-mttr.md)
+ [Aumentando MTBF](increasing-mtbf.md)
# Reduzindo MTTD
Reduzir a MTTD ocorrência de uma falha significa descobrir a falha o mais rápido possível. Encurtar o MTTD é baseado na observabilidade ou em como você instrumentou sua carga de trabalho para entender seu estado. Os clientes devem monitorar suas métricas de *experiência do cliente* nos subsistemas críticos da carga de trabalho como forma de identificar proativamente quando ocorre um problema (consulte o [Apêndice 1) — MTTD e as métricas MTTR críticas para obter mais informações sobre essas métricas](appendix-1-mttd-and-mttr-critical-metrics.md). ). Os clientes podem usar o [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) para criar *canários* que monitoram você APIs e os consoles para medir proativamente a experiência do usuário. Há vários outros mecanismos de verificação de saúde que podem ser usados para minimizá-losMTTD, como verificações de saúde do [Elastic Load Balancing (ELB), verificações de saúde](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-add-elb-healthcheck.html) do [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/health-checks-types.html) e muito mais. (Consulte [Amazon Builders' Library: Como implementar verificações de integridade](https://aws.amazon.com/builders-library/implementing-health-checks/).)
Seu monitoramento também precisa ser capaz de detectar falhas parciais do sistema como um todo e em seus subsistemas individuais. Suas métricas de disponibilidade, falha e latência devem usar a dimensionalidade dos limites de isolamento de falhas como dimensões [CloudWatch métricas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Dimension). Por exemplo, considere uma única EC2 instância que faz parte de uma arquitetura baseada em células, na AZ use1-az1, na região us-east-1, que faz parte da atualização da carga de trabalho que faz parte do subsistema do plano de controle. API Quando o servidor envia suas métricas, ele pode usar o ID da instância, AZ, região, API nome e nome do subsistema como dimensões. Isso permite que você tenha observabilidade e defina alarmes em cada uma dessas dimensões para detectar falhas.
# Reduzindo MTTR
Depois que uma falha é descoberta, o restante do MTTR tempo é o reparo real ou a mitigação do impacto. Para reparar ou mitigar uma falha, você precisa saber qual é o problema. Há dois grupos principais de métricas que fornecem informações durante essa fase: 1/ métricas de *Avaliação de Impacto* e 2/ métricas de *Saúde Operacional*. O primeiro grupo informa o escopo do impacto durante uma falha, medindo o número ou a porcentagem dos clientes, recursos ou workloads afetados. O segundo grupo ajuda a identificar *por que* há impacto. Depois que o motivo é descoberto, os operadores e a automação podem responder e resolver a falha. Consulte o [Apêndice 1 — MTTD e as métricas MTTR críticas](appendix-1-mttd-and-mttr-critical-metrics.md) para obter mais informações sobre essas métricas.
**Regra 9**
A observabilidade e a instrumentação são essenciais para reduzir e. MTTD MTTR
## Rota para contornar falhas
A abordagem mais rápida para mitigar o impacto é por meio de subsistemas de antecipar-se à falha. Essa abordagem usa redundância para reduzir, MTTR transferindo rapidamente o trabalho de um subsistema com falha para um sobressalente. A redundância pode variar de processos de software a EC2 instâncias, de várias a várias AZs regiões.
Subsistemas de reposição podem MTTR reduzir o valor para quase zero. O tempo de recuperação é apenas o necessário para redirecionar o trabalho para o sobressalente em espera. Isso geralmente acontece com latência mínima e permite que o trabalho seja concluído dentro do definidoSLA, mantendo a disponibilidade do sistema. MTTRsIsso produz atrasos leves, talvez até imperceptíveis, em vez de períodos prolongados de indisponibilidade.
Por exemplo, se seu serviço utiliza EC2 instâncias por trás de um Application Load Balancer ALB (), você pode configurar verificações de saúde em um intervalo de até cinco segundos e exigir apenas duas verificações de saúde com falha antes que um destino seja marcado como não íntegro. Isso significa que, em 10 segundos, você pode detectar uma falha e parar de enviar tráfego para o host não íntegro. Nesse caso, MTTR é efetivamente igual ao, MTTD pois assim que a falha é detectada, ela também é mitigada.
É isso que as workloads *de alta disponibilidade* ou *disponibilidade contínua* estão tentando alcançar. Queremos contornar rapidamente as falhas na workload detectando rapidamente os subsistemas com falha, marcando-os como falhados, parando de enviar tráfego para eles e, em vez disso, enviá-lo para um subsistema redundante.
Observe que o uso desse tipo de mecanismo para antecipar-se à falha torna sua workload muito sensível a erros transitórios. No exemplo fornecido, certifique-se de que as verificações de integridade do balanceador de carga estejam realizando verificações de integridade *superficiais* ou [https://aws.amazon.com/builders-library/implementing-health-checks/](https://aws.amazon.com/builders-library/implementing-health-checks/) apenas da instância, sem testar dependências ou fluxos de trabalho (geralmente chamados de verificações de integridade *profundas*). Isso ajudará a evitar a substituição desnecessária de instâncias durante erros transitórios que afetam a workload.
A observabilidade e a capacidade de detectar falhas em subsistemas são essenciais para que o roteamento em torno da falha seja bem-sucedido. Você precisa conhecer o escopo do impacto para que os recursos afetados possam ser marcados como insalubres ou com falha e retirados de serviço para que possam ser encaminhados. Por exemplo, se uma única AZ apresentar uma deficiência parcial no serviço, sua instrumentação precisará ser capaz de identificar que há um problema localizado na AZ para contornar todos os recursos dessa AZ até que ela se recupere.
Ser capaz de contornar falhas também pode exigir ferramentas adicionais, dependendo do ambiente. Usando o exemplo anterior com EC2 instâncias atrás de umaALB, imagine que instâncias em uma AZ possam estar passando por verificações de saúde locais, mas uma deficiência isolada de AZ esteja fazendo com que elas não consigam se conectar ao banco de dados em outra AZ. Nesse caso, as verificações de integridade do balanceamento de carga não tirarão essas instâncias de serviço. Seria necessário um mecanismo automatizado diferente para [remover a AZ do balanceador de carga](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-subnets.html) ou forçar as instâncias a falharem nas verificações de integridade, o que depende da identificação de que o escopo do impacto é uma AZ. Para workloads que não estão usando um balanceador de carga, seria necessário um método semelhante para impedir que recursos em uma AZ específica aceitassem unidades de trabalho ou removessem completamente a capacidade da AZ.
Em alguns casos, a mudança de trabalho para um subsistema redundante não pode ser automatizada, como o failover de um banco de dados primário para o secundário, em que a tecnologia não fornece sua própria eleição de líder. Esse é um cenário comum para [arquiteturas multirregionais da AWS](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-i-strategies-for-recovery-in-the-cloud/). Como esses tipos de failovers exigem algum tempo de inatividade para serem realizados, não podem ser revertidos imediatamente e deixam a workload sem redundância por um período de tempo, é importante ter uma pessoa no processo de tomada de decisão.
As cargas de trabalho que podem adotar um modelo de consistência menos rigoroso podem ser reduzidas MTTRs usando a automação de failover em várias regiões para contornar as falhas. Recursos como a [replicação entre regiões do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html) ou as [tabelas globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/) fornecem recursos multirregionais por meio de replicação eventualmente consistente. Além disso, usar um modelo de consistência relaxado é benéfico quando consideramos o CAP teorema. Durante falhas de rede que afetam a conectividade com subsistemas com estado, se a workload escolher a disponibilidade em vez da consistência, ela ainda poderá fornecer respostas sem erros, outra forma de contornar a falha.
O roteamento em caso de falha pode ser implementado com duas estratégias diferentes. A primeira estratégia é implementar a estabilidade estática pré-provisionando recursos suficientes para lidar com a carga completa do subsistema com falha. Isso pode ser uma única EC2 instância ou uma capacidade total de AZ. A tentativa de provisionar novos recursos durante uma falha aumenta MTTR e adiciona uma dependência a um plano de controle em seu caminho de recuperação. No entanto, isso tem um custo adicional.
A segunda estratégia é rotear parte do tráfego do subsistema com falha para outros e [eliminar a carga do excesso de tráfego](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload) que não pode ser tratado pela capacidade restante. Durante esse período de degradação, você pode ampliar novos recursos para substituir a capacidade com falha. Essa abordagem é mais longa MTTR e cria uma dependência de um plano de controle, mas custa menos em capacidade ociosa em espera.
## Retorne a um bom estado conhecido
Outra abordagem comum para mitigação durante o reparo é retornar a workload a um estado anterior conhecido como bom. Se uma alteração recente pode ter causado a falha, reverter essa alteração é uma forma de retornar ao estado anterior.
Em outros casos, condições transitórias podem ter causado a falha; nesse caso, reiniciar a workload pode mitigar o impacto. Vamos examinar esses dois cenários.
Durante uma implantação, minimizar o MTTD e MTTR depende da observabilidade e da automação. Seu processo de implantação deve observar continuamente a workload para detectar a introdução de maiores taxas de erro, maior latência ou anomalias. Depois que eles forem reconhecidos, o processo de implantação deverá ser interrompido.
Existem várias [estratégias de implantação](https://docs.aws.amazon.com/whitepapers/latest/overview-deployment-options/deployment-strategies.html), como implantações no local, implantações azul/verdes e implantações contínuas. Cada um deles pode usar um mecanismo diferente para retornar a um estado em boas condições. Ele pode voltar automaticamente para o estado anterior, mudar o tráfego de volta para o ambiente azul ou exigir intervenção manual.
CloudFormation [oferece a capacidade de reverter automaticamente](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html) como parte de suas operações de criação e atualização da pilha, assim como acontece. [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html#deployments-rollback-and-redeploy-automatic-rollbacks) CodeDeploy também suporta implantações em azul/verde e contínuas.
Para aproveitar esses recursos e minimizar seusMTTR, considere automatizar todas as suas implantações de infraestrutura e código por meio desses serviços. Em cenários em que você não pode usar esses serviços, considere implementar o [padrão de saga](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-the-serverless-saga-pattern-by-using-aws-step-functions.html) AWS Step Functions para reverter implantações com falha.
Ao considerar a *reinicialização*, existem várias abordagens diferentes. Elas variam desde a reinicialização de um servidor, a tarefa mais longa, até a reinicialização de um thread, a tarefa mais curta. Aqui está uma tabela que descreve algumas das abordagens de reinicialização e os tempos aproximados de conclusão (representativos da diferença de ordens de magnitude, eles não são exatos).
| Mecanismo de recuperação de falhas | Estimado MTTR |
| --- | --- |
| Iniciar e configurar o novo servidor virtual | 15 minutos |
| Reimplantar o software | 10 minutos |
| Reinicializar servidor | 5 minutos |
| Reiniciar ou iniciar o contêiner | 2 segundos |
| Invocar nova função sem servidor | 100 ms |
| Reiniciar processo | 10 ms |
| Reiniciar thread | 10 μs |
Analisando a tabela, há alguns benefícios claros MTTR em usar contêineres e funções sem servidor (como). [AWS Lambda](https://aws.amazon.com/lambda/) MTTRÉ muito mais rápido do que reiniciar uma máquina virtual ou lançar uma nova. No entanto, usar o isolamento de falhas por meio da modularidade do software também é benéfico. Se você puder conter falhas em um único processo ou thread, a recuperação dessa falha é muito mais rápida do que reiniciar um contêiner ou servidor.
Como abordagem geral para a recuperação, você pode passar de baixo para cima: 1/Reiniciar, 2/reboot, 3/Reimagem/Reimplantar, 4/Substituir. No entanto, quando você chega à etapa de reinicialização, contornar a falha geralmente é uma abordagem mais rápida (geralmente levando no máximo de 3 a 4 minutos). Portanto, para mitigar o impacto mais rapidamente após uma tentativa de reinicialização, contorne a falha e, em segundo plano, continue o processo de recuperação para devolver a capacidade à sua workload.
**Regra 10**
Concentre-se na mitigação do impacto, não na resolução de problemas. Escolha o caminho mais rápido de volta à operação normal.
## Diagnóstico de falhas
Parte do processo de reparo após a detecção é o período de diagnóstico. Esse é o período em que os operadores tentam determinar qual é o problema. Esse processo pode envolver a consulta de registros, a revisão de métricas de saúde operacional ou o login em hosts para solucionar problemas. Todas essas ações exigem tempo, portanto, criar ferramentas e runbooks para agilizar essas ações também pode ajudar a MTTR reduzi-las.
## Runbooks e automação
Da mesma forma, depois de determinar qual é o problema e qual curso de ação reparará a workload, os operadores normalmente precisam executar um conjunto de etapas para fazer isso. Por exemplo, após uma falha, a maneira mais rápida de reparar a workload pode ser reiniciá-la, o que pode envolver várias etapas ordenadas. A utilização de um runbook que automatize essas etapas ou forneça orientação específica a um operador agilizará o processo e ajudará a reduzir o risco de ações inadvertidas.
# Aumentando MTBF
O componente final para melhorar a disponibilidade é aumentar MTBF o. Isso pode se aplicar tanto ao software quanto aos AWS serviços usados para executá-lo.
## Aumentando o sistema distribuído MTBF
Uma forma de aumentar MTBF é reduzir os defeitos no software. Há várias maneiras de fazer isso. Os clientes podem usar ferramentas como o [Amazon CodeGuru Reviewer](https://aws.amazon.com/codeguru/) para encontrar e corrigir erros comuns. Você também deve realizar análises abrangentes de código por pares, testes unitários, testes de integração, testes de regressão e testes de carga no software antes que ele seja implantado na produção. Aumentar a quantidade de cobertura de código nos testes ajudará a garantir que até mesmo caminhos incomuns de execução de código sejam testados.
A implantação de mudanças menores também pode ajudar a evitar resultados inesperados, reduzindo a complexidade da mudança. Cada atividade oferece a oportunidade de identificar e corrigir defeitos antes que eles possam ser invocados.
Outra abordagem para evitar falhas são os [testes regulares](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html). A implementação de um programa de engenharia de caos pode ajudar a testar como sua workload falha, validar procedimentos de recuperação e ajudar a encontrar e corrigir os modos de falha antes que eles ocorram na produção. Os clientes podem usar a [AWS Fault Injection Simulator](https://aws.amazon.com/fis/) como parte de seu conjunto de ferramentas para experimentos de engenharia do caos.
A tolerância a falhas é outra forma de evitar falhas em um sistema distribuído. Módulos para antecipar-se à falha, novas tentativas com instabilidade e recuo exponencial, transações e idempotência são técnicas para ajudar a tornar as workloads tolerantes a falhas.
As transações são um grupo de operações que aderem às ACID propriedades. Eles são os seguintes:
+ **Atomicidade** — Ou todas as ações acontecem ou nenhuma delas acontecerá.
+ **Consistência** — Cada transação deixa a workload em um estado válido.
+ **Isolamento** — As transações realizadas simultaneamente deixam a workload no mesmo estado como se tivessem sido executadas sequencialmente.
+ **Durabilidade** — Depois que uma transação é confirmada, todos os seus efeitos são preservados mesmo no caso de falha na workload.
Novas tentativas com [recuo exponencial e instabilidade](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) permitem que você supere falhas transitórias causadas por Heisenbugs, sobrecarga ou outras condições. Quando as transações são idempotentes, elas podem ser repetidas várias vezes sem efeitos colaterais.
Se considerarmos o efeito de um Heisenbug em uma configuração de hardware tolerante a falhas, não nos preocuparíamos, pois a probabilidade de o Heisenbug aparecer tanto no subsistema primário quanto no redundante é infinitesimalmente pequena. (Veja Jim Gray, "[Por que os computadores param e o que pode ser feito a respeito?](https://pages.cs.wisc.edu/~remzi/Classes/739/Fall2018/Papers/gray85-easy.pdf) “, junho de 1985, Relatório Técnico Tandem 85.7.) Em sistemas distribuídos, queremos alcançar os mesmos resultados com nosso software.
Quando um Heisenbug é invocado, é fundamental que o software detecte rapidamente a operação incorreta e falhe para que possa ser tentado novamente. Isso é obtido por meio de programação defensiva e validação de entradas, resultados intermediários e saídas. Além disso, os processos são isolados e não compartilham nenhum estado com outros processos.
Essa abordagem modular garante que o escopo do impacto durante a falha seja limitado. Os processos falham de forma independente. Quando um processo falha, o software deve usar “pares de processos” para repetir o trabalho, o que significa que um novo processo pode assumir o trabalho de um que falhou. Para manter a confiabilidade e a integridade da carga de trabalho, cada operação deve ser tratada como uma ACID transação.
Isso permite que um processo falhe sem corromper o estado da workload, abortando a transação e revertendo as alterações feitas. Isso permite que o processo de recuperação repita a transação a partir de um estado em boas condições e reinicie normalmente. É assim que o software pode ser tolerante a falhas para a Heisenbugs.
No entanto, você não deve tentar tornar o software tolerante a falhas para Bohrbugs. Esses defeitos devem ser encontrados e removidos antes que a workload entre em produção, pois nenhum nível de redundância jamais alcançará o resultado correto. (Veja Jim Gray, "[Por que os computadores param e o que pode ser feito a respeito?](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) “, junho de 1985, Relatório Técnico Tandem 85.7.)
A maneira final de aumentar MTBF é reduzir o escopo do impacto da falha. Usar o [isolamento de falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) por meio da modularização para criar contêineres de falhas é a principal maneira de fazer isso, conforme descrito anteriormente em *Tolerância e isolamento de falhas*. Reduzir a taxa de falhas melhora a disponibilidade. AWS usa técnicas como divisão de serviços em planos de controle e planos de dados, [independência da zona de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) (AZI), [isolamento regional](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/), [arquiteturas baseadas em células](https://www.youtube.com/watch?v=swQbA4zub20) e fragmentação [aleatória](https://aws.amazon.com/builders-library/workload-isolation-using-shuffle-sharding) para fornecer isolamento de falhas. Esses também são padrões que também podem ser usados pelos AWS clientes.
Por exemplo, vamos analisar um cenário em que uma workload colocava os clientes em diferentes contêineres de falhas de sua infraestrutura, atendendo no máximo 5% do total de clientes. Um desses contêineres de falhas passa por um evento que aumenta a latência além do tempo limite do cliente em 10% das solicitações. Durante esse evento, para 95% dos clientes, o serviço estava 100% disponível. Para os outros 5%, o serviço parecia estar 90% disponível. Isso resulta em uma disponibilidade de 1 − (5% *d**o**s* *c**l**i**e**n**t**e**s* × 10% *d*e** *s**u**a*s* **s****o**l***i****cita**ções**) = 99,5% em vez de 10% das solicitações falharem para 100% dos clientes (resultando em uma disponibilidade de 90%).
**Regra 11**
O isolamento de falhas diminui o escopo do impacto e aumenta a carga MTBF de trabalho ao reduzir a taxa geral de falhas.
## Aumento da dependência MTBF
O primeiro método para aumentar sua AWS dependência MTBF é usar o [isolamento de falhas](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html). Muitos AWS serviços oferecem um nível de isolamento na AZ, o que significa que uma falha em uma AZ não afeta o serviço em outra AZ.
O uso de EC2 instâncias redundantes em várias AZs aumenta a disponibilidade do subsistema. AZIfornece uma capacidade econômica dentro de uma única região, permitindo que você aumente sua disponibilidade de AZI serviços.
No entanto, nem todos os AWS serviços operam no nível AZ. Muitos outros oferecem isolamento regional. Nesse caso, em que a disponibilidade projetada do serviço regional não oferece suporte à disponibilidade geral necessária para sua workload, você pode considerar uma abordagem multirregional. Cada região oferece uma instanciação isolada do serviço, equivalente à economia.
Existem vários serviços que ajudam a facilitar a criação de um serviço multirregional. Por exemplo:
+ [Amazon Aurora Global Database](https://aws.amazon.com/rds/aurora/global-database/)
+ [Tabelas globais do Amazon DynamoDB](https://aws.amazon.com/dynamodb/global-tables/)
+ [Amazon ElastiCache (RedisOSS) — Armazenamento de dados global](https://aws.amazon.com/elasticache/redis/global-datastore/)
+ [AWS Acelerador global](https://aws.amazon.com/global-accelerator/)
+ [Replicação entre regiões do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+ [Amazon Route 53 Application Recovery Controller](https://aws.amazon.com/route53/application-recovery-controller/)
Este documento não aborda as estratégias de criação de workloads multirregionais, mas você deve avaliar os benefícios de disponibilidade das arquiteturas multirregionais com o custo adicional, a complexidade e as práticas operacionais necessárias para atingir as metas de disponibilidade desejadas.
O próximo método para aumentar a dependência MTBF é projetar sua carga de trabalho para ser estaticamente estável. Por exemplo, você tem uma workload que fornece informações do produto. Quando seus clientes fazem uma solicitação de um produto, seu serviço faz uma solicitação a um serviço externo de metadados para recuperar os detalhes do produto. Em seguida, sua workload retorna todas essas informações para o usuário.
No entanto, se o serviço de metadados não estiver disponível, as solicitações feitas por seus clientes falharão. Em vez disso, você pode extrair ou enviar de forma assíncrona os metadados localmente para o seu serviço para serem usados para responder às solicitações. Isso elimina a chamada síncrona para o serviço de metadados do seu caminho crítico.
Além disso, como seu serviço ainda está disponível mesmo quando o serviço de metadados não está, você pode removê-lo como uma dependência no cálculo de disponibilidade. Esse exemplo depende da suposição de que os metadados não mudam com frequência e que veicular metadados obsoletos é melhor do que a falha na solicitação. Outro exemplo semelhante é o [serve-stale](https://www.rfc-editor.org/rfc/rfc8767), pois permite DNS que os dados sejam mantidos no cache após a TTL expiração e usados para respostas quando uma resposta atualizada não está prontamente disponível.
O método final para aumentar a dependência MTBF é reduzir o escopo do impacto da falha. Conforme discutido anteriormente, a falha não é um evento binário, há graus de falha. Esse é o efeito da modularização; a falha está contida apenas nas solicitações ou usuários atendidos por esse contêiner.
Isso resulta em menos falhas durante um evento, o que, em última análise, aumenta a disponibilidade da workload geral ao limitar o escopo do impacto.
## Como reduzir fontes comuns de impacto
Em 1985, Jim Gray descobriu, durante um estudo na Tandem Computers, que a falha era causada principalmente por duas coisas: software e operações. (Veja Jim Gray, "[Por que os computadores param e o que pode ser feito a respeito?](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) “, junho de 1985, Relatório Técnico Tandem 85.7.) Mesmo depois de 36 anos, isso continua sendo verdade. Apesar dos avanços na tecnologia, não há uma solução fácil para esses problemas, e as principais fontes de falha não mudaram. O tratamento de falhas no software foi discutido no início desta seção, portanto, o foco aqui será as operações e a redução da frequência de falhas.
### Estabilidade em comparação com os recursos
Se nos referirmos às taxas de falha do gráfico de software e hardware na seção[Disponibilidade do sistema distribuído](distributed-system-availability.md), podemos observar que defeitos são adicionados em cada versão do software. Isso significa que qualquer alteração na workload aumenta o risco de falha. Essas mudanças geralmente são coisas como novos recursos, o que fornece um corolário. Workloads com maior disponibilidade favorecerão a estabilidade em relação aos novos recursos. Assim, uma das maneiras mais simples de melhorar a disponibilidade é implantar com menos frequência ou fornecer menos recursos. As workloads implantadas com mais frequência terão inerentemente uma disponibilidade menor do que aquelas que não o fazem. No entanto, as workloads que não adicionam recursos não atendem à demanda do cliente e podem se tornar menos úteis com o tempo.
Então, como continuamos inovando e lançando recursos com segurança? A resposta é padronização. Qual é a maneira correta de implantar? Como você solicita implantações? Quais são os padrões para testes? Quanto tempo você espera entre os estágios? Seus testes de unidade abrangem o suficiente do código do software? Essas são perguntas que a padronização responderá e evitará problemas causados por coisas como não testar a carga, pular estágios de implantação ou implantar muito rapidamente em muitos hosts.
A forma como você implementa a padronização é por meio da automação. Ele reduz a chance de erros humanos e permite que os computadores façam aquilo em que são bons, ou seja, fazer sempre a mesma coisa da mesma maneira. A maneira de unir padronização e automação é definir metas. Objetivos como a ausência de alterações manuais, o acesso ao host somente por meio de sistemas de autorização contingente, a criação de testes de carga para cada um API deles e assim por diante. A excelência operacional é uma norma cultural que pode exigir mudanças substanciais. Estabelecer e monitorar o desempenho em relação a uma meta ajuda a impulsionar uma mudança cultural que terá um amplo impacto na disponibilidade da workload. O pilar [AWS Well-Architected Operational Excellence](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html) fornece as melhores práticas abrangentes para a excelência operacional.
### Segurança do operador
O outro grande contribuinte para eventos operacionais que introduzem falhas são as pessoas. Humanos cometem erros. Eles podem usar as credenciais erradas, digitar o comando errado, pressionar Enter muito cedo ou perder uma etapa crítica. Realizar ações manuais de forma consistente resulta em erro, resultando em falha.
Uma das principais causas de erros do operador são interfaces de usuário confusas, não intuitivas ou inconsistentes. Jim Gray também observou em seu estudo de 1985 que “as interfaces que pedem informações ao operador ou que ele execute alguma função devem ser simples, consistentes e tolerantes a falhas do operador”. (Veja Jim Gray, "[Por que os computadores param e o que pode ser feito a respeito?](https://www.hpl.hp.com/techreports/tandem/TR-85.7.pdf) “, junho de 1985, Relatório Técnico Tandem 85.7.) Essa percepção continua sendo verdadeira hoje. Nas últimas três décadas, existem vários exemplos em todo o setor em que uma interface de usuário confusa ou complexa, a falta de confirmação ou instruções ou até mesmo uma linguagem humana hostil fizeram com que um operador fizesse a coisa errada.
**Regra 12**
Faça com que seja fácil para os operadores fazerem a coisa certa.
### Prevenir sobrecarga
O último colaborador comum de impacto são seus clientes, os usuários reais de sua workload. Workloads bem-sucedidas tendem a ser muito usadas, mas às vezes esse uso supera a capacidade de escalabilidade da workload. Muitas coisas podem acontecer: os discos podem ficar cheios, os pools de threads podem se esgotar, a largura de banda da rede pode ficar saturada ou os limites de conexão do banco de dados podem ser atingidos.
Não há um método à prova de falhas para eliminá-las, mas o monitoramento proativo da capacidade e da utilização por meio de métricas da Operational Health fornecerá avisos antecipados quando essas falhas puderem ocorrer. Técnicas como [redução de carga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload), [disjuntores](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html) e [repetição](https://aws.amazon.com/builders-library/timeouts-retries-and-backoff-with-jitter/) com recuo exponencial e instabilidade podem ajudar a minimizar o impacto e aumentar a taxa de sucesso, mas essas situações ainda representam falha. O escalonamento automatizado com base nas métricas da Operational Health pode ajudar a reduzir a frequência de falhas devido à sobrecarga, mas pode não ser capaz de responder com rapidez suficiente às mudanças na utilização.
Se você precisar garantir a capacidade continuamente disponível para os clientes, precisará fazer concessões quanto à disponibilidade e ao custo. Uma forma de garantir que a falta de capacidade não leve à indisponibilidade é fornecer uma cota a cada cliente e garantir que a capacidade de sua workload seja escalada para fornecer 100% das cotas alocadas. Quando os clientes excedem sua cota, eles são limitados, o que não é uma falha e não conta para a disponibilidade. Você também precisará acompanhar de perto sua base de clientes e prever a utilização futura para manter a capacidade suficiente provisionada. Isso garante que sua workload não seja direcionada a cenários de falha devido ao consumo excessivo de seus clientes.
+ [Amazon Builders' Library — Como usar a redução de carga para evitar sobrecarga](https://aws.amazon.com/builders-library/using-load-shedding-to-avoid-overload/)
+ [Amazon Builders' Library — Imparcialidade em sistemas multilocatários](https://aws.amazon.com/builders-library/fairness-in-multi-tenant-systems)
Por exemplo, vamos examinar uma workload que fornece um serviço de armazenamento. Cada servidor na workload pode suportar 100 downloads por segundo, os clientes recebem uma cota de 200 downloads por segundo e há 500 clientes. Para poder suportar esse volume de clientes, o serviço precisa fornecer capacidade para 100.000 downloads por segundo, o que requer 1.000 servidores. Se algum cliente exceder sua cota, ele será limitado, o que garante capacidade suficiente para todos os outros clientes. Este é um exemplo simples de uma forma de evitar a sobrecarga sem rejeitar unidades de trabalho.