APRENDER. PRATICAR. EVOLUIR.Prontidão não cobre todas as populações
A candidata defeituosa interpreta a configuração, anuncia ready e devolve 22 para ordinary. O mesmo cálculo deveria devolver 22 para critical, mas uma condição deliberada acrescenta uma unidade e produz 23. Não há erro de parsing nem processo parado: existe violação de um resultado funcional. O preflight e a amostra ordinary não detetam essa condição. Antes de expandir uma mudança fictícia de processamento bancário, define populações relevantes e critérios do consumidor. Baixo volume não dispensa uma rota obrigatória quando a consequência é importante. O laboratório não mede uma taxa real de falha nem estabelece tamanhos de canary; mostra por que a escolha do pedido observado limita a conclusão que se pode comunicar.
Recuperar processos e resultados futuros
Voltar current para v1 não muda a configuração da instância v2-bug que continua ativa e devolve 23. Só depois de iniciar uma instância v1 o guião observa novamente 12. Esta sequência não deve ser reduzida a uma caixa marcada como rollback. O plano precisa de selecionar a versão recuperável, definir ativação, gerir instâncias e observar o caminho que receberá pedidos. O laboratório envia diretamente por pipes e não executa balanceador, drenagem de ligações ou gestor de serviços. Para um destino real, esses mecanismos precisam de ensaio próprio. Conserva a dependência de recuperação até haver uma decisão válida para a retirar; libertar espaço apagando a versão antiga pode remover uma opção que o plano ainda exige.
Os efeitos anteriores mantêm uma história própria
Antes da recuperação, o worker defeituoso escreve um recibo sintético com resultado 23 num ficheiro separado. A troca de apontador e o arranque de v1 não alteram esse registo. O guião lê-o novamente e confirma que permanece igual. O recibo representa uma fronteira de efeito; não é um pagamento nem uma mensagem enviada. Numa aplicação real, identifica pedidos afetados, consumidores, estado confirmado e ações autorizadas de reconciliação ou compensação. Não apagues evidência para tornar o histórico parecido com o estado atual. Um fecho técnico pode coexistir com reconciliação pendente apenas quando critérios e responsáveis o permitem explicitamente. A comunicação deve distinguir serviço recuperado, efeitos avaliados e consequências ainda por tratar.
Aceitação operacional com decisões praticáveis
A oficina proposta reúne APS, desenvolvimento, fornecedor e responsável pelo serviço. Os participantes devem explicar em inglês o estado de cada instância, a falha crítica e o recibo persistente, propondo critérios para expandir, recuperar ou suspender. O plano de RUN deve incluir comandos, condições de aplicação, observações esperadas, paragem e escalada. Acesso a ficheiros não demonstra autonomia; um guião escrito não demonstra sessão executada. Treze grupos locais passaram duas vezes, mas a oficina humana e a revisão independente continuam pendentes. Na revisão posterior, separa prevenção, deteção e recuperação: um alerta entregue não implementa preflight nem cobre a rota crítica. Cada ação precisa de responsável e resultado verificável ligado à lacuna que pretende resolver.
python3 content/labs/change-runtime/run.py --output /tmp/dr-change-recovery.json
# Compare readinessAndOneRouteMissDefect and rollbackDoesNotErasePriorEffect.
# Proposed workshop: explain technical recovery versus reconciliation in English.A candidata passa ordinary com 22, mas critical devolve 23. Depois da recuperação, pedidos novos funcionam e o recibo incorreto continua registado.
Armadilhas comuns
Confundir ready com resultado correto, expandir pela média global ou declarar todos os efeitos resolvidos após voltar ao código anterior.
Tópicos relacionados: Canary e critérios de aceitação · Reconciliação e aprendizagem
Recuperação técnica e reconciliação têm critérios distintos; o fecho deve mostrar o estado de ambas e a responsabilidade por pendentes.
Referência: Canarying Releases · DR Change Management 2026.1; independent technical curriculum