

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á.

# Reduzindo MTTD
<a name="reducing-mttd"></a>

 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. 