APRENDER. PRATICAR. EVOLUIR.Escolher o mecanismo pela intenção
Numa frota fictícia de middleware, três tarefas parecem semelhantes: manter um agente configurado, aplicar uma correção pontual e instalar patches numa janela. Define primeiro o estado desejado, o âmbito e a frequência. State Manager associa configuração a alvos e calendário; Run Command envia comandos e devolve resultados por invocação; Automation encadeia passos e decisões. Maintenance Windows organiza execução em períodos definidos. Combinar serviços não elimina a necessidade de um contrato de resultado. Para cada tarefa, indica versão do documento, parâmetros, identidade, alvos esperados, pré-condições e validação posterior. Um comando que termina com código zero ainda pode não demonstrar que o serviço de negócio recuperou.
Tratar a associação como uma mudança
Criar uma associação não é necessariamente preparar algo inerte para domingo. A execução imediata é predefinida; para um calendário cron, ApplyOnlyAtCronInterval permite limitar esse comportamento. O parâmetro não suporta expressões rate. A versão do documento também importa: DEFAULT e LATEST são referências móveis, e alterações na mesma conta podem provocar nova aplicação. Decide se a mudança precisa de uma versão numérica fixada e de promoção explícita. Antes de guardar a associação, confirma alvos reais e janela autorizada. Se alguns nós já mudaram, corrigir o calendário não os recupera automaticamente. Contém novas alterações, recolhe o inventário parcial e decide a recuperação segundo o impacto observado.
Observar envio, execução e efeito
Run Command reporta estados de plugins, invocações e comando agregado. Um Success com zero nós selecionados não cumpre um pedido para configurar doze servidores. Compara o conjunto esperado com os resultados e investiga Delivery Timed Out na camada de entrega antes de atribuir a falha ao script. A API tem consistência eventual; uma leitura logo após o envio pode ainda não mostrar a invocação. Volta a consultar o mesmo identificador com espera limitada, em vez de lançar repetidamente trabalho possivelmente em curso. O limite de erros impede novos envios após ultrapassado, mas invocações já lançadas podem continuar. Regista o efeito final e a saúde funcional, não apenas a aceitação da chamada.
Construir automação que conserva a falha
Uma automação pode precisar de continuar após uma falha para recolher logs ou libertar recursos temporários. Se a alteração é crítica, exprime explicitamente isCritical e o fluxo onFailure; não permitas que a limpeza bem-sucedida esconda o insucesso principal. Em executeScript, chamadas sujeitas a throttling precisam de retry no próprio código, com limites e operações seguras para repetição. A ação tem um tempo máximo, pelo que ciclos sem limite não são uma estratégia de recuperação. Distingue falhas transitórias de erros de autorização ou de entrada que pedem correção. No exercício operacional, pede ao colega para explicar que efeitos podem já existir antes de repetir um passo e onde fica a prova.
Separar instalação, ativação e continuidade
Começa patching por Scan quando o objetivo é conhecer a conformidade sem instalar. Antes de Install, confirma a baseline, dependências, capacidade alternativa e critérios de regresso ao serviço. Fora de Maintenance Windows, um Snapshot-ID comum para a mesma baseline e operação ajuda a manter o conjunto aprovado consistente entre nós. NoReboot controla reinício do sistema operativo, mas pacotes podem reiniciar serviços. Não uses essa opção como garantia de disponibilidade. Um estado InstalledPendingReboot mantém uma ação pendente; programa o reboot e novo Scan, sem alterar ficheiros de tracking para produzir um painel verde. A aceitação inclui atualização ativa, saúde do serviço e evidência de todos os nós previstos.
Exercício: rever a margem da janela
O modelo local calcula o limite de novos arranques a partir do início UTC, duração e cutoff. Também compara uma estimativa de tarefa com o tempo até ao fim, como revisão interna adicional. Não reproduz o scheduler AWS nem promete cancelar processos no fim. Experimenta uma tarefa iniciada antes do cutoff mas demasiado longa, uma proposta depois do cutoff e uma estimativa que cabe. No plano real, explicita ScheduleTimezone, próximas execuções, lotes, margem para recuperação e responsável pela decisão de parar. A estimativa não é uma garantia: uma manutenção que se prolonga exige comunicação e controlo do estado em curso, não a declaração de sucesso apenas porque terminou a janela.
# Original local planning review, not an AWS scheduler or cancellation guarantee.
from datetime import datetime, timedelta, timezone
def review_start(start, duration_hours, cutoff_hours, proposed, estimate_minutes):
if start.tzinfo is None or proposed.tzinfo is None:
raise ValueError("timezone-aware timestamps required")
if not 0 <= cutoff_hours < duration_hours or estimate_minutes <= 0:
raise ValueError("invalid planning inputs")
end = start + timedelta(hours=duration_hours)
deadline = end - timedelta(hours=cutoff_hours)
# This educational policy treats the exact cutoff instant as closed.
if not start <= proposed < deadline:
return "outside local start interval"
if proposed + timedelta(minutes=estimate_minutes) > end:
return "estimate exceeds window; review scope or timing"
return "fits estimate; authorization and recovery margin still required"
start = datetime(2026, 10, 11, 2, tzinfo=timezone.utc)
assert review_start(start, 4, 1, start + timedelta(hours=2), 60).startswith("fits")
assert review_start(start, 4, 1, start + timedelta(hours=2, minutes=50), 90).startswith("estimate exceeds")
assert review_start(start, 4, 1, start + timedelta(hours=3, minutes=1), 10).startswith("outside")
assert review_start(start, 4, 1, start - timedelta(minutes=1), 10).startswith("outside")
try:
review_start(start.replace(tzinfo=None), 4, 1, start, 10)
except ValueError:
pass
else:
raise AssertionError("naive timestamp accepted")
Criar a associação na sexta-feira iniciou alterações previstas para domingo; conter novos arranques não recupera por si só os nós já afetados.
Armadilhas comuns
Cron como garantia de espera inicial; Success sem alvos; reenvio por leitura precoce; Continue a esconder falha; NoReboot como ausência de impacto.
Tópicos relacionados: StackSets: âmbito e resultados por destino
A manutenção termina quando o estado pretendido e a saúde funcional estão demonstrados, não apenas quando a chamada ou a janela termina.
Referência: State Manager execution behavior · DOP-C02