APRENDER. PRATICAR. EVOLUIR.Separar novas operações do histórico
A reposição da flag faz /ready e uma nova operação responderem positivamente. Os dois efeitos da intenção anterior continuam presentes. Esta combinação é o ponto de partida da segunda aula: existe melhoria funcional observada e existe trabalho de dados por concluir. Uma equipa pode organizar duas frentes, com responsáveis que reportam ao mesmo coordenador. Uma observa a estabilidade e os critérios de retoma; outra reconcilia intenções, resultados e ações necessárias. Não apagues uma linha apenas porque a contagem parece excessiva. Numa aplicação empresarial, o registo pode corresponder a efeitos noutros sistemas e precisar de uma compensação aprovada. O exercício pede que o aluno explicite o que sabe e quem pode decidir sobre o que ainda não sabe.
Retomar o backlog com critérios
O cenário fictício apresenta 600 tentativas sem confirmação, não 600 intenções necessariamente novas. Algumas tentativas podem ser repetições do mesmo trabalho e outras já podem ter resultado confirmado no servidor. Agrupa pela identidade estável, conserva identificadores de tentativa e distingue resultados conhecidos de resultados incertos. Define um ritmo de retoma e um critério de interrupção compatíveis com a capacidade demonstrada. Uma chave de idempotência não elimina carga de rede, consultas ou contenção na base. Se o cut-off não for atingível, comunica a previsão condicionada e o impacto restante. A decisão deve combinar segurança da repetição, capacidade e responsabilidade, em vez de tratar um único controlo como autorização automática para libertar toda a fila.
Comunicar e transferir cada frente
Uma atualização útil pode dizer que novas operações foram validadas às 14:20, enquanto a reconciliação continua atribuída e terá novo ponto de situação definido. A hora de atualização é um compromisso diferente de uma promessa de recuperação total. Na oficina, escreve a mensagem em inglês para um coordenador internacional, identificando âmbito, resultado observado, incerteza e próximo passo. A seguir, prepara o handover. Se a nova equipa só aceitou observar tráfego, não assumes que aceitou também decidir o tratamento dos efeitos repetidos. Regista quem recebeu cada frente e quais critérios permitem concluí-la. O documento apoia a passagem, mas a compreensão e a aceitação humana precisam de ser observadas num exercício acompanhado, ainda não executado aqui.
Transformar a aprendizagem em aceitação
O postmortem não deve terminar numa ação vaga para melhorar retries. O material propõe critérios observáveis para o mecanismo estudado: perder a resposta depois do commit, repetir a mesma intenção, introduzir concorrência e enviar conteúdo divergente para uma chave existente. Verifica efeitos, resultados devolvidos e limites da solução. Num serviço com chamada externa fora da transação SQLite, acrescenta testes dessa fronteira; o resultado local não cobre automaticamente o novo percurso. A oficina também pede a identificação de lacunas de monitorização e comunicação, com responsáveis e evidência de conclusão. Os testes automáticos deste curso verificam o guião e os dados. Não medem a competência de uma equipa em incidente real nem substituem revisão independente por especialista.
# Inspect retained results without starting another server.
python3 - <<'PY'
import json
from pathlib import Path
r=json.loads(Path("content/labs/incident-runtime/evidence.json").read_text())
for k in ["restoredTrafficDoesNotUndoPriorDuplicates",
"reconciliationRetainsDifferentOutcomes"]:
print(k, r["checks"][k])
PYUma nova operação passa após a mitigação, mas os dois efeitos anteriores da mesma intenção continuam na base.
Armadilhas comuns
Apagar duplicados sem decisão, retirar limites de replay porque existe uma chave ou transferir só a monitorização e esquecer a reconciliação.
Tópicos relacionados: Diagnóstico e mitigação · Comunicação e passagem para RUN
A recuperação funcional e a reconciliação precisam de critérios e responsáveis próprios, ligados ao mesmo estado do incidente.
Referência: Managing Incidents · Incident management practices 2026-09; scoped Google SRE, PagerDuty and Atlassian examples