# REL11-BP07 Arquitetar o produto para cumprir as metas de disponibilidade e os acordos de serviço (SLAs) de tempo de atividade
Arquitete o produto para cumprir as metas de disponibilidade e os acordos de serviço (SLAs) de tempo de atividade. Se você publicar ou concordar de forma privada com as metas de disponibilidade ou SLAs de tempo de atividade, verifique se sua arquitetura e seus processos operacionais foram projetados para comportá-los.
**Resultado desejado:** cada aplicação tem uma meta definida de disponibilidade e um SLA para métricas de performance, as quais podem ser monitoradas e mantidas para atingir os resultados comerciais.
**Práticas comuns que devem ser evitadas:**
+ Planejar e implantar workloads sem definir SLAs.
+ As métricas de SLA são definidas muito altas sem justificativas ou requisitos comerciais.
+ Definir SLAs sem considerar as dependências e o SLA subjacente.
+ Os designs das aplicações são criados sem considerar o modelo de responsabilidade compartilhada para resiliência.
**Benefícios de implementar esta prática recomendada:** desenvolver aplicações com base nas principais metas de resiliência ajuda a atingir os objetivos de negócios e as expectativas dos clientes. Esses objetivos ajudam a orientar o processo de design da aplicação que avalia diferentes tecnologias e considera as vantagens e desvantagens.
**Nível de risco exposto se esta prática recomendada não for estabelecida:** Médio
## Orientação para implementação
Os designs da aplicação precisam levar em conta um conjunto de requisitos diversos que são derivados de objetivos empresariais, operacionais e financeiros. Nos requisitos operacionais, as workloads precisam ter metas de métricas de resiliência específicas para que possam ser monitorados e comportados adequadamente. As métricas de resiliência não devem ser definidas nem derivadas depois de implantar a workload. Elas devem ser definidas durante a fase de design e ajudar a orientar as diversas decisões e concessões.
+ Cada workload deve ter seu próprio conjunto de métricas de resiliência. Essas métricas podem ser diferentes de outras aplicações empresariais.
+ Reduzir as dependências pode ter um impacto positivo na disponibilidade. Cada workload deve considerar suas dependências e seus SLAs. Em geral, escolha dependências com metas de disponibilidade iguais ou maiores que as metas da workload.
+ Considere designs com acoplamento fraco para que a workload possa operar corretamente apesar do comprometimento da dependência, quando possível.
+ Reduza as dependências do ambiente de gerenciamento, especialmente durante uma recuperação ou degradação. Avalie os designs estaticamente estáveis com relação às workloads essenciais à missão. Use a economia de recursos para aumentar a disponibilidade dessas dependências em uma workload.
+ A capacidade de observação e a instrumentalização são críticas para cumprir os SLAs reduzindo o tempo médio de detecção (MTTD) e o tempo médio de reparo (MTTR).
+ 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.
+ Estabelecer e cumprir métricas de resiliência para uma workload é fundamental para qualquer design eficaz. Esses designs devem levar em consideração as vantagens e desvantagens da complexidade de design, as dependências do serviço, a performance, o ajuste de escala e os custos.
**Etapas de implementação**
+ Analise e documente o design da workload considerando as seguintes questões:
+ Onde os ambientes de gerenciamento são usados na workload?
+ Como a workload implementa tolerância a falhas?
+ Quais são os padrões de design para componentes de ajuste de escala, ajuste de escala automático, redundância e alta disponibilidade?
+ Quais são os requisitos para disponibilidade e consistência de dados?
+ Há considerações quanto à economia de recursos ou estabilidade estática de recursos?
+ Quais são as dependências do serviço?
+ Defina métricas de SLA com base na arquitetura da workload enquanto trabalha com as partes interessadas. Considere os SLAs de todas as dependências usadas pela workload.
+ Quando a meta de SLA for definida, otimize a arquitetura para cumprir o SLA.
+ Quando o design que cumprirá o SLA for definido, implemente mudanças operacionais, automação do processo e runbooks que também terão como foco uma redução de MTTD e MTTR.
+ Depois da implantação, monitore e informe sobre o SLA.
## Recursos
**Práticas recomendadas relacionadas:**
+ [REL03-BP01 Escolher como segmentar a workload](rel_service_architecture_monolith_soa_microservice.md)
+ [REL10-BP01 Implantar a workload em vários locais](rel_fault_isolation_multiaz_region_system.md)
+ [REL11-BP01 Monitorar todos os componentes da workload para detectar falhas](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP03 Automatizar a reparação em todas as camadas](rel_withstand_component_failures_auto_healing_system.md)
+ [REL12-BP04 Testar a resiliência com engenharia do caos](rel_testing_resiliency_failure_injection_resiliency.md)
+ [REL13-BP01 Definir os objetivos de recuperação para tempo de inatividade e perda de dados](rel_planning_for_recovery_objective_defined_recovery.md)
+ [Como a integridade da workload funciona](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-workload-health.html)
**Documentos relacionados:**
+ [Disponibilidade com redundância](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-with-redundancy.html)
+ [Pilar Confiabilidade: disponibilidade](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html)
+ [Como medir a disponibilidade](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/measuring-availability.html)
+ [Limites de isolamento de falhas da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/abstract-and-introduction.html)
+ [Modelo de responsabilidade compartilhada para resiliência](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/shared-responsibility-model-for-resiliency.html)
+ [Estabilidade estática com zonas de disponibilidade](https://aws.amazon.com/builders-library/static-stability-using-availability-zones/)
+ [Acordos de serviço (SLAs) da AWS](https://aws.amazon.com/legal/service-level-agreements/)
+ [Orientação para arquitetura baseada em células na AWS](https://aws.amazon.com/solutions/guidance/cell-based-architecture-on-aws/)
+ [Infraestrutura da AWS](https://docs.aws.amazon.com/whitepapers/latest/aws-fault-isolation-boundaries/aws-infrastructure.html)
+ [Whitepaper Padrões avançados de resiliência multi-AZ](https://docs.aws.amazon.com/whitepapers/latest/advanced-multi-az-resilience-patterns/advanced-multi-az-resilience-patterns.html)
**Serviços relacionados:**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/)