CapordiaDelimitar o que migra e o que deve esperar
Este guia é destinado à pessoa que coordena o cálculo, os dados e a operação. Um lote designa aqui um pacote de trabalho identificado, distinto de um lote de placas GPU do catálogo. O método convém primeiro às saídas que podem ser controladas antes da aceitação. Para um serviço que recebe solicitações sem parar, preveja onde as novas entradas aguardarão, quanto tempo essa espera é aceitável e como elas se juntarão ao alvo. Um dossiê copiado não define por si só essa política de admissão.
O exercício proposto trabalha sobre um conjunto fechado de oito lotes sintéticos. Ele não envia nenhuma requisição de rede e não solicita nem GPU nem conta Capordia. Ele ensina uma lógica de retomada em um único posto e um único processo de trabalho. Ele não valida uma fila distribuída, a continuidade de um serviço exposto nem a movimentação a quente de um cálculo. Antes de uma migração real, sua equipe deve qualificar esses elementos com a aplicação e o hardware escolhidos.
Constituir um inventário que permita reconstruir
Reúna o código e sua versão, as dependências, os parâmetros, os modelos, as entradas, as tarefas agendadas e os destinos de saída. Para cada um, indique o proprietário, o método de reconstrução e o controle esperado no alvo. Anote o nome dos segredos e seu modo de fornecimento, sem colocar seu valor no registro compartilhado. Uma instalação manual ou uma tarefa acionada na inicialização pode faltar em uma simples cópia do diretório do projeto.
Separe os arquivos de entrada, os resultados aceitos e o estado necessário para reiniciar. Para um treinamento, esse estado pode exceder os pesos do modelo: o tutorial PyTorch de salvamento de um checkpoint geral compreende, entre outros, o estado do otimizador e o avanço. O conteúdo necessário depende do seu código. Restaure-o em um processo novo e depois compare as saídas segundo uma tolerância decidida antes do teste; não deduza uma identidade numérica universal de um único reinício bem-sucedido.
Atribuir a decisão, a transferência e a aceitação
Defina os papéis antes de fixar a janela. Em uma equipe pequena, a mesma pessoa pode acumular vários deles, mas as decisões permanecem distintas. O responsável pela alternância confirma a parada do produtor antigo e autoriza a partida do destino. O responsável pelos dados controla o inventário, as impressões digitais e as saídas. O proprietário do processamento avalia a qualidade funcional. A operação mantém o registro das mudanças e prepara a passagem.
A ficha de alternância deve responder a quatro perguntas concretas: quem pode interromper as entradas, quem constata que o processamento antigo não publica mais, quem aceita os primeiros resultados e quem decide o retorno. Registre também um horário-limite de decisão e os meios de contatar essas pessoas. “Voltar se necessário” não basta quando o destino já produziu resultados que o registro antigo não conhece.
Manter um registro que distinga iniciado e aceito
Atribua um identificador estável a cada lote e vincule-o a uma versão precisa dos dados. Conserve seu estado, o número de tentativas, o local do resultado e o controle que autoriza sua aceitação. Um lote em andamento não está concluído só porque existe um arquivo de saída: esse arquivo pode ser parcial ou vir de uma tentativa anterior. O procedimento deve explicitar o que será conservado, o que será recalculado e o que ficará em quarentena para exame.
No exercício, um registro SQLite local mantém juntos o estado e a aceitação do resultado em uma transação. Seus estados são termine, en_cours e a_reprendre; este último também cobre um lote que ainda não começou. O destino retoma os lotes não validados em vez de relançar indistintamente as oito entradas. As exportações JSON e CSV tornam o acompanhamento legível. O CSV em branco acompanha sua preparação e sua revisão humana; ele não substitui o mecanismo de coordenação de uma aplicação real.
| Lotes | Estado na fronteira | Decisão antes da retomada |
|---|---|---|
| LOT-001 a LOT-003 | termine | Conservar os resultados e verificar sua integridade |
| LOT-004 | en_cours, resultado não aceito | Preparar explicitamente uma nova tentativa |
| LOT-005 a LOT-008 | a_reprendre, nenhuma tentativa | Iniciar no destino após autorização |
Baixar e executar o exercício de interrupção e retomada
Providencie Python 3.10 ou mais recente com o módulo sqlite3, e um diretório local com permissão de escrita. Baixe o arquivo completo e extraia-o mantendo o script, a pasta de dados e o manifesto juntos. O arquivo README detalha os comandos disponíveis. Nenhum driver, pacote de cálculo ou modelo precisa ser instalado. Leia o script antes de executá-lo, depois use uma pasta de saída nova para que as evidências de várias tentativas não se misturem.
A partir do diretório que contém exercice.py, o comando abaixo produz uma referência contínua, um processamento interrompido, uma cópia de alternância e uma retomada comparada à referência. Os oito arquivos CSV contêm 48 medidas dimensionais fictícias de cupons, expressas em micrômetros inteiros e criadas para este dossiê. Nenhum controle industrial real está representado. O cálculo na CPU serve para examinar a gestão dos lotes, não para estimar uma vazão de GPU ou um tempo de migração dos seus dados.
python exercice.py demonstration --dossier essai-capordiaLer as evidências da retomada, lote por lote
Exemplo Capordia: uma equipe prepara oito pacotes de arquivos a processar. A referência os processa sem interrupção. No outro percurso, a parada deixa três lotes concluídos, LOT-004 em andamento e quatro lotes a retomar sem tentativa. O responsável pela alternância não pede “retomar até a metade”: ele designa LOT-004. A preparação de retomada o devolve ao estado a_reprendre: três lotes ficam então concluídos e cinco devem ser executados. Os lotes já aceitos não devem ser recalculados.
Consulte etat.json para os identificadores, estados e tentativas, registre-lots.csv para a revisão, resultats.json para as saídas e, em seguida, rapport-verification.json para os controles. Na execução local de 24 de setembro de 2026 no Windows AMD64, com Python 3.14.6 e SQLite 3.50.4, os 16 controles provenientes de 37 execuções do script passaram: os oito resultados retomados correspondem à referência, os lotes concluídos não são recalculados e uma nova aceitação do mesmo lote é recusada. As entradas alteradas, identificadores duplicados e saídas corrompidas também são detectados.
Copiar um estado consistente e depois controlar sua integridade
Em uma troca real, interrompa a admissão ou coloque as novas entradas em uma fila explicitamente prevista. Aguarde a conclusão do trabalho em andamento ou registre os lotes interrompidos conforme sua regra de retomada. Em seguida, confirme que a instância antiga não pode mais publicar. O selamento da fonte neste exercício impede que o script a reutilize como produtor. Trata-se de uma proteção local do cenário, não de uma exclusão mútua entre várias máquinas que possuiriam cada uma uma cópia do estado.
Para copiar um banco de dados SQLite usado por uma aplicação, sua documentação propõe uma API de backup que produz um instantâneo consistente. Uma cópia comum de um arquivo de banco de dados em processo de escrita não é, portanto, um procedimento a ser improvisado. Verifique também o manifesto dos arquivos transferidos. Os hashes SHA-256, disponíveis em hashlib, ajudam aqui a detectar uma diferença de conteúdo; eles não dizem se o resultado está correto para o seu negócio, nem se o manifesto de referência é confiável.
Decidir quando retomar e quando reverter
Autorize o destino somente quando as entradas, o registro e os resultados preservados estiverem em conformidade, o produtor antigo estiver parado e os pré-requisitos de software forem atendidos. Comece por um escopo cujas saídas possam ser relidas. O proprietário do processamento aceita a qualidade; o responsável pelos dados verifica os identificadores, os ausentes e os duplicados. Uma inicialização sem erros não basta se o resultado útil estiver incompleto.
Se o defeito aparecer antes de qualquer nova publicação, mantenha o destino parado e parta do estado de origem controlado conforme o procedimento previsto. Após uma publicação, preserve primeiro os resultados e o registro do destino. Compare os lotes que ele concluiu com os da origem e, em seguida, escolha uma única retomada autorizada. Reativar os dois lados para ganhar tempo pode justamente criar as duplicatas que a migração deveria evitar.
| Observação | Decisão imediata | Condição para prosseguir |
|---|---|---|
| Entrada ausente ou hash diferente | Suspender a transferência e isolar a cópia | Recuperar uma entrada conforme o manifesto de referência |
| Identificador duplicado ou saída inesperada | Não publicar o lote em questão | Entender o conflito e manter apenas uma versão aceita |
| Estado de retomada inutilizável | Parar o destino e preservar as evidências | Restaurar um estado conhecido ou aplicar o retorno preparado |
| Resultado fora do critério de negócio | Parar a ampliação da retomada | Corrigir e refazer a validação funcional |
| Horário limite de decisão atingido | Acionar a decisão de reversão ou de adiamento | Concordância explícita do responsável e capacidade de concluir a exportação |
Medir toda a janela e preparar a passagem
Repita a instalação, a cópia, a verificação, a retomada e a exportação em sua ordem real. Anote o tempo de cada fase e as intervenções humanas, com uma amostra cuja transferência é autorizada. Para estimar sua janela, leve em conta as novas entradas que ficarão esperando e a capacidade de absorver esse atraso. O melhor tempo observado em uma pequena pasta não é um compromisso para um volume maior.
O período escolhido deve cobrir preparação, ensaio, chaveamento, observação e recuperação dos resultados. Os planos Capordia de 3, 7 ou 30 dias continuam sendo períodos a organizar; este guia não deduz deles nenhum tempo de cálculo. Antes do encerramento, uma segunda pessoa deve localizar o registro, abrir as saídas a partir do seu destino e saber relançar o processamento. Arquive a decisão de fim do repli, as divergências aceitas e as ações restantes antes de retirar os acessos que se tornaram inúteis.
O que o exercício verifica e o que ainda precisa ser qualificado
A contribuição deste dossiê é um procedimento legível e uma experiência reprodutível de retomada sobre arquivos sintéticos. O mesmo lote deve ser identificável antes da parada, durante o chaveamento e após a retomada. O registro, a comparação com uma referência e as recusas provocadas tornam essa regra observável. A interrupção é acionada por uma exceção controlada no script: nenhum teste de falha elétrica foi realizado. A documentação técnica citada explica os mecanismos empregados; ela não certifica o seu futuro ambiente de produção.
Apenas um processo trabalha por vez no cenário. O selo local não é um bloqueio distribuído; uma impressão digital não é um teste de qualidade; um resultado em CPU não é uma qualificação CUDA, ROCm ou multi-GPU. Uma aplicação que também grava em um banco externo, em um armazenamento compartilhado ou em uma fila exige uma regra coerente em todos esses destinos. Faça validar essa regra e o seu plano de reversão antes de migrar o processamento real.
Para preparar o que vem a seguir
Um backup deve permitir retomar o trabalho.
Restaurar num alvo isolado e verificar que a cópia permite realmente retomar.
Passar o turno com um estado, uma ação e um responsável.
Transmitir as ações, os limites e as responsabilidades a outra pessoa.