APRENDER. PRATICAR. EVOLUIR.Desenhar os estados antes dos temporizadores
Uma aplicação fictícia de posições pede mais instâncias antes do fecho. O sistema operativo arranca, mas o serviço ainda procura configuração, enche caches e abre ligações. Contar instâncias não demonstra que todas conseguem processar pedidos. Desenha uma linha temporal com lançamento, bootstrap, registo no balanceador, saúde, estabilização e saída. Para cada transição, define quem a observa e qual a evidência necessária. Um health check que responde 200 sem verificar a configuração mínima pode admitir capacidade inutilizável. A equipa de projeto deve acordar o contrato de prontidão com APS e desenvolvimento, incluindo o comportamento perante dependências indisponíveis e o responsável por aceitar exceções durante uma janela.
Separar grace period, warmup e hook
Grace period evita substituições prematuras por health checks enquanto uma instância nova inicializa em InService; não bloqueia por si o tráfego do ALB. Também não impede substituição se a instância deixar o estado EC2 running. Default instance warmup trata a estabilização das métricas agregadas usadas por escala dinâmica. Não substitui um gate de bootstrap. Um launch lifecycle hook pode manter a instância em espera antes da admissão. Usa os três conforme o problema observado, sem aumentar todos os tempos à procura de estabilidade. Mede quanto demora configuração e quanto demora a carga a estabilizar, pois esses intervalos podem ser diferentes e ter causas distintas.
Dar ao hook um resultado honesto
Se o bootstrap falha a obter configuração obrigatória, enviar CONTINUE transforma uma falha conhecida em capacidade aparentemente disponível. Conserva diagnóstico e usa o resultado adequado, corrigindo a causa antes de repetir lançamentos sem limite. Heartbeats permitem manter a espera dentro dos prazos, mas não demonstram progresso funcional e existe um prazo global. O runbook precisa de escalada e estado terminal. No término predefinido, sem política adicional de retenção, ABANDON não cancela a eliminação: permite terminar e impede outras ações restantes. A existência de mecanismos adicionais de retenção exige confirmar configuração efetiva. Não transportes a interpretação de uma ação de lançamento para uma ação de término.
Ligar o sinal de saúde à decisão certa
Anexar um target group não significa que o Auto Scaling use resultados ELB para substituir instâncias. Ativa essa integração quando fizer parte do desenho e confirma o significado do endpoint. Uma resposta 401 após uma alteração de autenticação não deve ser escondida alargando o matcher para qualquer código. Investiga acesso e contrato do health check. Considera ainda a falha comum: se todos os targets registados estão unhealthy em todas as AZs ativadas, o ALB pode encaminhar em fail open. Nesse estado, substituir cópias que dependem do mesmo serviço indisponível pode apenas consumir capacidade. Relaciona a causa partilhada com contenção e recuperação do percurso de negócio.
Planear saída e distribuição de carga
Durante deregistration, draining não prova que todos os pedidos terminaram. O processo deve respeitar trabalho em curso e limites, com recuperação para efeitos incompletos. O estado também pode continuar visível até ao timeout mesmo sem pedidos ativos; consulta evidência concreta. Scale-in protection permite escolher instâncias elegíveis para redução, mas não as protege de todas as falhas. Se todas estiverem protegidas, desired capacity pode diminuir enquanto a frota observada continua maior. Para entrada gradual, confirma a combinação de atributos: slow start não é suportado com least outstanding requests ou weighted random. A escolha de algoritmo, prontidão e aquecimento deve ser ensaiada como um conjunto.
Medir margem após uma falha
O modelo local soma capacidade validada por AZ e retira a zona perdida. Com duas instâncias de 100 pedidos/s em cada uma de três zonas, perder uma deixa 400 pedidos/s. Uma carga de 450 excede essa capacidade, mesmo que desired capacity continue a indicar seis instâncias. O exercício não chama AWS nem simula recuperação automática. Usa-o para discutir margem antes de existir capacidade adicional, quotas, tempo de arranque e limites de dependências. Num ensaio real, mede também latência, filas e erros com uma zona indisponível. A conclusão para RUN deve combinar capacidade sobrevivente, comportamento de admissão e saída, e critérios de atuação quando a procura ultrapassa a margem.
# Original local model: assumes validated independent capacity per zone.
def surviving_capacity(zones, lost):
if lost not in zones:
raise ValueError("Unknown failure zone")
if any(type(v) is not int or v < 0 for v in zones.values()):
raise ValueError("Capacity must be a nonnegative integer")
return sum(v for zone, v in zones.items() if zone != lost)
zones = {"zone-a": 200, "zone-b": 200, "zone-c": 200}
assert surviving_capacity(zones, "zone-b") == 400
assert surviving_capacity(zones, "zone-b") < 450
assert surviving_capacity({"only-zone": 200}, "only-zone") == 0
try:
surviving_capacity(zones, "unknown")
raise AssertionError("Unknown zone accepted")
except ValueError:
pass
Uma expansão pede quatro instâncias, mas todas falham a mesma dependência de configuração. Corrigir readiness e bootstrap recupera capacidade útil; contar InService não resolve a falha.
Armadilhas comuns
Confundir grace period com bloqueio de tráfego; usar warmup como bootstrap; interpretar ABANDON como cancelamento de término; confiar apenas no número de instâncias.
Tópicos relacionados: Ensaios de recuperação e evidência funcional
Capacidade utilizável exige configuração, saúde, estabilização e margem. Cada controlo cobre uma parte desse percurso.
Referência: Auto Scaling health check grace period · DOP-C02