APRENDER. PRATICAR. EVOLUIR.Duas populações durante a mudança
A segunda parte do laboratório mantém um pedido em A através de um evento controlado pelo script. Enquanto esse pedido está pendente, uma configuração nova dirige os pedidos seguintes para B. O master recebe HUP e o ensaio aguarda a geração nova. Um novo pedido chega a B com sucesso, mas o primeiro ainda está associado a A. É uma forma concreta de observar populações diferentes durante uma mudança. O êxito dos clientes novos não determina, por si só, o resultado dos clientes que já estavam ligados.
O prazo pertence ao worker
O ficheiro inicial configura worker_shutdown_timeout=1s. O valor curto serve para tornar o comportamento observável no laboratório; não é uma recomendação de produção. Quando o worker antigo entra em encerramento, esse prazo limita a espera antes da tentativa de fecho das ligações abertas. Na execução registada, o cliente do pedido mantido recebe RemoteDisconnected enquanto o backend continua à espera do evento. O ensaio desativa retries de upstream e usa proxy_read_timeout superior. A evidência distingue o prazo de encerramento de uma repetição ou de uma conclusão normal.
Perder a resposta não define o resultado
Depois da falha no cliente, o script confirma que o backend iniciou trabalho e ainda não o concluiu. Só então liberta o evento e observa a conclusão. O handler foi deliberadamente escrito para continuar independentemente da socket; não é uma afirmação sobre todas as aplicações. A experiência demonstra que não se pode inferir cancelamento a partir de um erro de transporte. Numa instrução fictícia com efeito de negócio, é necessário consultar o estado pelo identificador e seguir o contrato acordado de cancelamento, deduplicação ou reconciliação.
Escolher prazos com evidência
Antes de retirar instâncias num ambiente real, caracteriza durações, pedidos de longa execução, capacidade remanescente e limites da janela. Identifica também quem pode cancelar trabalho, o que fica durável e como se verifica um resultado após perder a resposta. Aumentar todos os prazos pode prolongar ocupação e manutenção; reduzi-los pode aumentar interrupções. A decisão deve tornar esses compromissos explícitos e incluir critérios de interrupção da mudança. O laboratório oferece um mecanismo reproduzível, mas não mede a carga representativa nem escolhe os valores do teu serviço.
Executar a reunião de go/no-go
Usa a ficha abaixo numa reunião fictícia entre gestor de projeto, APS e desenvolvimento. Uma pessoa apresenta a evidência de tráfego novo, outra explica pedidos antigos e outra valida continuidade do estado. Preenche limites, responsáveis, recuperação e próximo ponto de controlo com dados do exercício ou do ambiente autorizado. O objetivo é praticar decisões, não preencher todos os campos com “OK”. Se os dois resultados incertos não tiverem dono, a passagem para RUN está incompleta. A ficha é uma proposta de exercício; nenhuma sessão humana foi realizada para a validar.
Comunicar e fechar sem omissões
Uma atualização em inglês pode dizer “New traffic is healthy; two outcomes remain under reconciliation with named owners”, seguida dos identificadores permitidos, responsáveis e prazo da próxima atualização. Se houver rollback, confirma a geração efetivamente servida e continua a reconciliar trabalho anterior: repor encaminhamento não desfaz efeitos aplicacionais. Guarda evidência suficiente para a equipa seguinte e protege dados de sessão. No final, distingue o que foi executado no laboratório, o que foi apenas proposto e o que ainda exige ensaio representativo e revisão independente.
DR proposed change rehearsal: affinity and retirement
No human workshop has been performed.
Fictional example; not a BNP Paribas procedure.
1. Record candidate configuration, runtime version and active generation.
2. State the expected journey before and after membership changes.
3. Identify the authoritative state source and its failure behavior.
4. List representative request durations and remaining capacity.
5. Define the drain deadline and treatment of work exceeding it.
6. Observe new traffic and old requests as separate populations.
7. Reconcile uncertain outcomes by approved correlation identifiers.
8. Assign an owner, next checkpoint and escalation for each exception.
9. Confirm rollback generation without assuming business rollback.
10. Let RUN explain and repeat recovery before accepting handover.
Evidence table:
Population | Expected result | Observation | Gap | Owner | Next checkpoint
New requests | ... | ... | ... | ... | ...
Existing sessions | ... | ... | ... | ... | ...
Long requests | ... | ... | ... | ... | ...
Uncertain outcomes | ... | ... | ... | ... | ...
Suggested English update:
New traffic is healthy; two outcomes remain under reconciliation
with named owners. The next update will include confirmed status
or the remaining evidence gap for each identifier.
Recorded lab scope: one NGINX worker, synthetic HTTP loopback requests.
Production deadlines, representative load, durable state and actual
business cancellation remain outside the executed fixture.
Numa janela fictícia, o pedido novo chega a B e o antigo perde a ligação por prazo. APS consulta o ID antes de autorizar repetição e transmite as pendências ao turno seguinte.
Armadilhas comuns
Escolher o prazo pelo exemplo didático, declarar cancelamento por falha TCP ou fechar a mudança apenas com probes novos; confundir rollback do proxy com reversão de efeitos.
Tópicos relacionados: Algoritmos, afinidade e estado · Retries, limites e origem do cliente · Retirada, release e operação
Um drain precisa de critérios para tráfego novo, trabalho antigo e resultados incertos. O prazo de ligação e o resultado de negócio requerem evidências diferentes.
Referência: NGINX worker shutdown deadline · DR load balancing 2026-09; selected NGINX, HAProxy 3.2, Kubernetes and AWS ALB behavior