APRENDER. PRATICAR. EVOLUIR.Definir o contrato da recuperação
Uma equipa fictícia automatiza recuperação de conectividade após um alerta. O fluxo identifica o serviço, espera aprovação, altera uma rota e valida uma operação funcional. Antes de escolher serviços, escreve o resultado pretendido, prazo, autoridade, efeitos permitidos e evidência de fecho. Uma espera humana pode ultrapassar o limite de um workflow Express; Standard permite um desenho durável com padrões de integração adequados. Isso não elimina a responsabilidade de controlar mudanças externas. O histórico da execução deve permitir descobrir qual versão decidiu, sobre que recurso e com que input. Também é necessário definir o que acontece quando a aprovação nunca chega ou a validação não consegue observar o resultado.
Separar pedido, execução e efeito
O cliente pode perder a resposta de arranque enquanto a execução já corre. Preserva identidade e observa o mesmo trabalho antes de lançar outro. A idempotência de StartExecution em Standard tem condições específicas de nome, input e estado; não deve ser generalizada a Express ou a toda a operação de negócio. Dentro do workflow, Request Response espera a resposta da API e pode avançar antes de um job terminar. Usa um padrão compatível com a necessidade de esperar, como .sync nos serviços suportados. Se a execução for parada, confirma também o destino: cancelar trabalho externo é uma tentativa que pode falhar. Um estado final no orquestrador não fecha automaticamente a investigação dos efeitos.
Limitar retries e manter contexto
Classifica a falha antes de decidir repetição. Indisponibilidade transitória pode justificar backoff, jitter e limites; um contrato de input inválido exige correção. Conta a chamada inicial além das repetições autorizadas e considera o tempo total, não só a espera individual. O tratamento de erros tem fronteiras: States.ALL não resolve um States.Runtime causado por processamento inválido de dados. No caminho de diagnóstico, preserva a identidade do recurso e o contexto necessário. Num workflow JSONPath, ResultPath no Catch pode juntar o erro ao input em vez de o substituir. Regista a falha principal mesmo quando a recolha de diagnóstico termina bem. A limpeza não deve transformar uma mudança falhada num sucesso aparente.
Escolher como retomar trabalho parcial
Uma Task pode aplicar uma alteração e falhar antes de comunicar sucesso. O redrive volta ao passo sem sucesso, preservando resultados anteriores e a definição original. Publicar uma definição corrigida ou mover um alias não faz esse redrive usar automaticamente a nova lógica. Se a correção da definição for necessária, avalia nova execução e reconcilia primeiro o que já aconteceu. No exemplo da rota, consulta a configuração e testa tráfego antes de repetir a escrita. Usa uma identidade de operação estável quando o destino a suporta e define compensação quando a repetição não é segura. Elegibilidade técnica para redrive não equivale a autorização de mudança ou prova de ausência de efeitos parciais.
Validar pré-condições da remediation
AWS Config pode iniciar correção a partir de um snapshot que já não representa o recurso. Uma intervenção manual legítima pode ter resolvido a propriedade entretanto. O runbook deve ler o estado atual, confirmar identidade e âmbito, e evitar alteração desnecessária quando o objetivo já está satisfeito. Configura explicitamente a role de automação e as permissões exigidas pela ação. Limites de concorrência e erros ajudam a conter exposição, mas não substituem uma pré-condição correta nem a validação posterior. Testa estados conformes, não conformes, indisponíveis e em mudança concorrente. Se a leitura falhar, não assumes não conformidade para justificar uma escrita. Regista a decisão de não alterar como resultado observável e explicável.
Exercício: decidir antes de escrever
O modelo local separa três decisões: não há autorização, falta evidência atual ou existe uma diferença que justifica preparar uma mudança. Não chama AWS, não garante exclusão mútua e não protege sozinho contra alterações entre leitura e escrita. Executa os casos e descreve como o sistema real voltaria a validar versão ou pré-condição no momento da alteração. Fecha o exercício com o resultado funcional esperado e o registo necessário para o turno seguinte. Express com logs best effort ou eventos de estado fora de ordem não fornece, por si só, um livro completo e ordenado de decisões. Escolhe persistência e reconciliação que satisfaçam o requisito de evidência da operação.
# Original local decision exercise, not an AWS remediation engine or atomic write guard.
def plan_change(expected_id, current, desired, authorized):
if not authorized:
return "hold: authorization required"
if current is None:
return "hold: current state unknown"
if current["id"] != expected_id:
return "hold: resource identity mismatch"
if current["value"] == desired:
return "no change: retain current-state evidence"
return "prepare change: revalidate version before writing"
state = {"id": "route-a", "value": "healthy-path", "version": 7}
assert plan_change("route-a", state, "healthy-path", True).startswith("no change")
assert plan_change("route-a", state, "alternate-path", True).startswith("prepare change")
assert plan_change("route-a", None, "healthy-path", True) == "hold: current state unknown"
assert plan_change("route-b", state, "healthy-path", True) == "hold: resource identity mismatch"
assert plan_change("route-a", state, "alternate-path", False) == "hold: authorization required"
# Another actor can change version 7 after this read. Real writes need concurrency protection.
Exemplo fictício: um trigger antigo pede correção de uma propriedade já conforme. O runbook relê o recurso, regista a evidência e evita um restart desnecessário.
Armadilhas comuns
Erros comuns: repetir sem identificar efeitos, confundir HTTP 200 com job concluído, perder input no Catch, assumir nova definição no redrive e reiniciar com base apenas num snapshot antigo.
Tópicos relacionados: Investigação de logs e cobertura da evidência
Recuperar exige conhecer o que já aconteceu, limitar o que pode voltar a acontecer e provar o estado obtido.
Referência: DOP-C02 incident and event response objectives · DOP-C02