APRENDER. PRATICAR. EVOLUIR.Retomar a partir do estado efetivo
Perder um log local não faz desaparecer as alterações já aplicadas. Se ADD COLUMN terminou e o executor repete todo o script, uma falha posterior pode coexistir com passos anteriores confirmados. Antes de retomar, consulta o estado efetivo, o registo de migrações e as evidências disponíveis. Classifica cada passo como concluído, falhado ou incerto e escolhe uma sequência compatível. Idempotência é uma propriedade a demonstrar para a operação e as condições concretas; não acompanha automaticamente qualquer DDL. Preserva dados e evita apagar objetos para forçar um recomeço. Quando o resultado está incerto, reconciliar é parte da recuperação, não um atraso dispensável para cumprir a janela.
Delimitar o alcance de uma transação
O último grupo muda dispatch de pending para sent dentro de uma transação e escreve um recibo num ficheiro temporário. Depois executa ROLLBACK. A base volta a pending, mas o recibo permanece porque não participa na transação SQLite. O ficheiro representa um efeito externo sem enviar uma mensagem real. Num fluxo de produção, não concluas que pending significa ausência de execução no destinatário. Antes de repetir, procura o resultado por um mecanismo fiável e define retoma ou compensação. Mudar a identidade pode criar uma segunda operação em vez de resolver a primeira. Inclui esta fronteira no plano de recuperação e nos critérios de reconciliação, sobretudo em fluxos financeiros.
Verificar integridade e significado separadamente
O resultado ok de integrity_check é útil, mas não conhece automaticamente a regra de que amount_cents deve corresponder a cem vezes amount_units. O fixture mantém um ficheiro válido e uma relação de negócio incorreta. A aceitação precisa de verificações ligadas ao significado: valores, contagens, identidades e efeitos esperados, segundo os critérios do serviço. Não substituas esta reconciliação por uma probe HTTP ou por médias que escondam divergências. Regista a população verificada e os caminhos de escrita que a produziram. Um resultado fisicamente íntegro pode ser semanticamente errado; um teste funcional limitado também não demonstra todas as propriedades físicas ou operacionais. Cada evidência deve conservar o seu âmbito.
Mapear evidência aos critérios de entrada e saída
Uma matriz simples liga cada critério à observação necessária, resultado, versão, data e responsável. Se o plano exige leitura antiga, escrita nova e reconciliação, vinte checks HTTP verdes não preenchem essas três linhas. Usa estados claros: passou, falhou, não executado ou inconclusivo, com a respetiva evidência. Uma falha conhecida não deve ser reclassificada como não executada para melhorar o relatório. Se reconciliação sem diferenças é obrigatória, uma média de 98% não revoga o requisito. Uma alteração de critério precisa de decisão válida e impacto explícito. Este modelo torna possível comunicar progresso real sem declarar aceitação onde a informação ainda não a sustenta.
Atualizar as opções de recuperação após cada fase
Antes da contração, a versão antiga pode continuar a ler a coluna que conhece. Depois da remoção, essa opção falha no laboratório. Por isso, um runbook deve indicar em que fase cada estratégia continua válida e que dados precisam de reconciliação. Guardar o binário v1 não resolve a incompatibilidade criada. Pode existir outra opção ensaiada, como uma correção em frente ou uma recuperação de estado com reconciliação, mas não deve ser inventada durante o incidente sem avaliação. Na passagem ao RUN, mostra a matriz de compatibilidade e os resultados dos ensaios relevantes. A equipa de turno precisa de saber o que pode executar, quem decide e quais limites impedem continuar.
Entregar um registo que outra equipa consiga usar
O laboratório guarda versão de Python e SQLite, dez grupos, resultados e hash do script. Foram executadas instruções reais numa base descartável; os controlos de aprovação e calendário são modelos locais com regras explícitas. Não houve acesso a pipelines, identidades reais, ambientes bancários ou destinos remotos. Usa a mesma disciplina de âmbito ao entregar evidência operacional: artefacto, configuração efetiva, instantes, resultados, desvios e pendentes com responsável. Se uma condição obrigatória continuar sem prova, comunica a lacuna e a decisão necessária. O objetivo é permitir que o RUN mantenha o serviço e compreenda as opções reais, não apenas que encontre um ticket com o estado fechado.
-- The local file effect is outside this SQLite transaction.
BEGIN IMMEDIATE;
UPDATE dispatch SET state='sent' WHERE id='demo-1';
-- Python writes a synthetic receipt to a temporary file here.
ROLLBACK;
-- Database: pending. Receipt file: still present.As probes passam e o ficheiro da base está íntegro, mas o runbook promete uma versão antiga cuja consulta falha no schema atual. A equipa entrega a incompatibilidade e a decisão pendente ao responsável operacional.
Armadilhas comuns
Repetir passos incertos sem inspeção, tratar pending como ausência de efeito, confundir integridade física com negócio correto ou fechar com uma promessa de rollback desatualizada.
Tópicos relacionados: Application Production Support · Problem Management · Release Management
A mudança está pronta para aceitação quando a evidência responde aos critérios aplicáveis e o RUN conhece estado, limites e recuperação realmente disponíveis.
Referência: Architecture strategies for safe deployment practices · DR Change Management 2026.1; independent technical curriculum