APRENDER. PRATICAR. EVOLUIR.Conceito e mecanismo
Resiliência depende do percurso completo do serviço. Workers em duas AZs continuam vulneráveis se precisam de um servidor único na primeira. Identifica dependências de configuração, dados, nomes e autorização e ensaia o domínio de falha relevante. Distingue processo em execução de serviço saudável: uma task ECS em RUNNING pode falhar verificações do load balancer. Para dimensionar workers de filas, a métrica backlog por instância relaciona mensagens visíveis e instâncias InService. Um alvo inicial pode resultar da espera aceitável dividida pelo tempo médio de processamento. O cálculo é um modelo, não uma promessa sobre cada mensagem nem sobre capacidade imediatamente disponível.
Aplicação guiada
Com 60 segundos de espera aceitável e 0,5 segundos médios por mensagem, o alvo é 120. Uma fila de 960 mensagens com quatro workers tem 240 por worker. Antes de expandir, confirma limites, dependências e efeito real. Protege tarefas longas durante scale-in e liberta essa proteção quando apropriado; não a confundas com proteção contra todas as falhas. Na recuperação, soma as etapas sequenciais até o serviço ficar validado: 18 minutos de restauro, sete de configuração e dez de validação dão 35. AWS Backup restore testing pode apoiar ensaios e validação funcional, mas concluir o job não prova o negócio. Preserva as tags necessárias à limpeza dos recursos de teste e acompanha a conclusão dessa limpeza.
O comité exige RTO de 30 minutos. Um ensaio completo de 35 minutos expõe uma lacuna mesmo que o restauro isolado demore 18.
Armadilhas comuns
Média como SLA; duas AZs como ausência de dependências únicas; restauro como recuperação completa; testes sem limpeza.
Tópicos relacionados: Telemetria e alarmes úteis · Eventos, incidentes e replay
Mede o trabalho por capacidade e a recuperação até ao resultado funcional.
Referência: DOP-C02 domain 3 · DOP-C02