CapordiaВизначити, що мігрує, а що має зачекати
Цей посібник призначено для людини, яка координує обчислення, дані та експлуатацію. Лот тут означає ідентифікований пакет роботи, відмінний від лота карт GPU з каталогу. Метод насамперед підходить для вихідних даних, які можна перевірити до прийняття. Для сервісу, що приймає запити без зупинки, передбачте, де чекатимуть нові вхідні дані, скільки часу це очікування є прийнятним і як вони приєднаються до цільової системи. Лише скопійований комплект не визначає цю політику допуску.
Запропонована вправа працює із закритим набором із восьми синтетичних лотів. Вона не надсилає жодного мережевого запиту й не задіює ні GPU, ні обліковий запис Capordia. Вона навчає логіки відновлення на одному робочому місці та в одному робочому процесі. Вона не підтверджує роботу розподіленої черги, безперервність відкритого сервісу чи перенесення обчислень на ходу. Перед реальною міграцією ваша команда має кваліфікувати ці елементи з обраним застосунком і обладнанням.
Створити інвентар, який дозволяє відтворити
Зберіть код та його версію, залежності, параметри, моделі, вхідні дані, заплановані завдання та призначення вихідних даних. Для кожного вкажіть власника, метод відтворення та очікуваний контроль на цільовій системі. Занотуйте назви секретів та спосіб їх надання, не розміщуючи їхні значення у спільному реєстрі. Ручне встановлення або завдання, що запускається під час старту, може бути відсутнім у простій копії каталогу проєкту.
Відокремте вхідні файли, прийняті результати та стан, необхідний для перезапуску. Для навчання цей стан може перевищувати ваги моделі: підручник PyTorch зі збереження загального чекпойнта охоплює, зокрема, стан оптимізатора та прогрес. Потрібний вміст залежить від вашого коду. Відновіть його в новому процесі, а потім порівняйте вихідні дані за допуском, визначеним до випробування; не робіть висновку про універсальну числову ідентичність з одного вдалого перезапуску.
Розподіл рішення, передавання та приймання
Призначте ролі перед тим, як визначати вікно. В невеликій команді одна й та сама людина може виконувати кілька ролей, але рішення залишаються роздільними. Відповідальний за перемикання підтверджує зупинку старого обробника та дозволяє запуск цільового. Відповідальний за дані контролює інвентаризацію, відбитки та вихідні результати. Власник обробки оцінює функціональну якість. Експлуатація веде журнал змін і готує передавання.
Картка перемикання має відповідати на чотири конкретні запитання: хто може зупинити вхідні потоки, хто встановлює, що старий обробник більше не публікує результати, хто приймає перші результати і хто ухвалює рішення про повернення. Також укажіть граничний час для ухвалення рішення та способи зв’язку з цими людьми. «Повернутися за потреби» недостатньо, якщо цільовий обробник уже створив результати, про які старий реєстр не знає.
Вести реєстр, який розрізняє розпочате та прийняте
Призначте кожному пакету стабільний ідентифікатор і прив’яжіть його до конкретної версії даних. Зберігайте його стан, кількість спроб, розташування результату та перевірку, яка дозволяє його прийняти. Пакет у процесі не є завершеним лише тому, що існує вихідний файл: цей файл може бути частковим або походити з попередньої спроби. Процедура має чітко визначати, що буде збережено, що буде перераховано і що залишиться в карантині для перевірки.
У вправі локальний реєстр SQLite зберігає стан і приймання результату разом в одній транзакції. Його стани — termine, en_cours і a_reprendre; останній також охоплює пакет, який ще не запускався. Цільовий обробник підхоплює непідтверджені пакети замість того, щоб навмання перезапускати всі вісім входів. Експорти JSON і CSV роблять відстеження наочним. Порожній CSV супроводжує вашу підготовку та ручний огляд; він не замінює механізм координації реального застосунку.
| Пакети | Стан на межі | Рішення перед відновленням |
|---|---|---|
| LOT-001至LOT-003 | termine | Зберегти результати та перевірити їхню цілісність |
| LOT-004 | en_cours, результат не прийнято | Явно підготувати нову спробу |
| LOT-005至LOT-008 | a_reprendre, жодної спроби | Запустити на цільовому обробнику після дозволу |
Завантажити та запустити вправу з переривання і відновлення
Підготуйте Python 3.10 або новіший із модулем sqlite3 та локальний каталог із правом запису. Завантажте повний архів і розпакуйте його, зберігаючи скрипт, каталог даних і маніфест разом. Файл README детально описує доступні команди. Жодних драйверів, обчислювальних пакетів чи моделей встановлювати не потрібно. Прочитайте скрипт перед запуском, а потім використайте новий каталог вихідних даних, щоб докази кількох спроб не змішувалися.
Із каталогу, що містить exercice.py, наведена нижче команда створює безперервний еталон, перервану обробку, копію для перемикання та відновлення, порівняне з еталоном. Вісім файлів CSV містять 48 вигаданих вимірювальних даних зразків, виражених у цілих мікрометрах і створених для цього матеріалу. Жодного реального промислового контролю не представлено. Обчислення на CPU слугує для вивчення керування пакетами, а не для оцінки пропускної здатності GPU чи тривалості міграції ваших даних.
python exercice.py demonstration --dossier essai-capordiaПрочитати докази відновлення, пакет за пакетом
Приклад Capordia: команда готує вісім пакетів файлів для обробки. Еталон обробляє їх без переривання. На іншому шляху зупинка залишає три завершені пакети, LOT-004 у процесі та чотири пакети до відновлення без спроб. Відповідальний за перемикання не просить «відновити до половини»: він указує LOT-004. Підготовка відновлення повертає його до стану a_reprendre: тоді три пакети завершено, а п’ять потрібно виконати. Уже прийняті пакети не потрібно перераховувати.
Перегляньте etat.json для ідентифікаторів, станів і спроб, registre-lots.csv для огляду, resultats.json для вихідних даних, а потім rapport-verification.json для перевірок. Під час локального запуску 24 вересня 2026 року в Windows AMD64, Python 3.14.6 і SQLite 3.50.4 усі 16 перевірок із 37 запусків скрипту були успішними: вісім повторно використаних результатів відповідають еталону, завершені партії не перераховуються, а повторне прийняття тієї самої партії відхиляється. Змінені вхідні дані, дубльовані ідентифікатори та пошкоджені вихідні дані також виявляються.
Копіювання узгодженого стану та перевірка його цілісності
У разі реального перемикання зупиніть приймання або помістіть нові записи в явно передбачену чергу. Дочекайтеся завершення поточної роботи або зафіксуйте перервані партії згідно з вашим правилом відновлення. Потім підтвердьте, що старий екземпляр більше не може публікувати. Блокування джерела в цій вправі не дає скрипту повторно використати його як продюсера. Це залишається локальним захистом сценарію, а не взаємним виключенням між кількома машинами, кожна з яких мала б власну копію стану.
Для копіювання бази SQLite, яку використовує застосунок, її документація пропонує API резервного копіювання, що створює узгоджений знімок. Тож звичайне копіювання файлу бази під час запису не є процедурою, яку можна імпровізувати. Перевірте також маніфест переданих файлів. Відбитки SHA-256, доступні в hashlib, допомагають тут виявити розбіжність вмісту; вони не говорять, чи є результат правильним для вашого бізнесу, ані чи заслуговує на довіру еталонний маніфест.
Вирішити, коли відновлювати, а коли повертатися
Дозволяйте роботу з цільовою системою лише тоді, коли збережені вхідні дані, реєстр і результати узгоджуються, старий продюсер зупинено, а програмні передумови виконано. Спочатку запустіть обсяг, вихідні дані якого можна перевірити повторно. Якість приймає власник обробки; відповідальний за дані перевіряє ідентифікатори, відсутні та дубльовані. Успішний запуск без помилок недостатній, якщо корисний результат неповний.
Якщо дефект виявляється до будь-якої нової публікації, залиште цільову систему зупиненою та поверніться до контрольованого вихідного стану згідно з передбаченою процедурою. Після публікації спершу збережіть результати та реєстр цільової системи. Порівняйте завершені нею партії з партіями джерела, а тоді виберіть єдине дозволене відновлення. Повторне ввімкнення обох сторін, щоб заощадити час, може саме й створити ті дублікати, яких мала уникнути міграція.
| Спостереження | Негайне рішення | Умова для продовження |
|---|---|---|
| Відсутній запис або інший відбиток | Призупинити передавання та ізолювати копію | Отримати запис, що відповідає еталонному маніфесту |
| Дубльований ідентифікатор або неочікуваний вихід | Не публікувати відповідну партію | З’ясувати конфлікт і залишити лише одну прийняту версію |
| Непридатний до використання стан відновлення | Зупинити цільову систему та зберегти докази | Відновити відомий стан або застосувати підготовлене повернення |
| Результат поза бізнес-критерієм | Припинити розширення відновлення | Виправити, а тоді повторити функціональну перевірку |
| Досягнуто граничного часу для рішення | Ухвалити рішення про повернення або перенесення | Явна згода відповідальної особи та здатність завершити експорт |
Виміряти все вікно та підготувати передавання
Повторіть встановлення, копіювання, перевірку, відновлення та експорт у їхньому реальному порядку. Зафіксуйте час кожної фази та втручання людей на вибірці, передавання якої дозволено. Для оцінки вашого вікна врахуйте нові записи, які чекатимуть, і здатність подолати це відставання. Найкращий час, спостережений на невеликій теці, не є зобов’язанням щодо більшого обсягу.
Обраний період має охоплювати підготовку, повторення, перемикання, спостереження та відновлення результатів. Пакети Capordia на 3, 7 або 30 днів залишаються періодами, які потрібно організувати; цей посібник не виводить із них жодного часу обчислень. Перед закриттям друга особа має знайти реєстр, відкрити вихідні дані з їхнього місця призначення та вміти перезапустити обробку. Заархівуйте рішення про завершення відкату, прийняті відхилення та залишкові дії, перш ніж скасувати доступи, що стали непотрібними.
Що перевіряє вправа і що ще потрібно кваліфікувати
Цінність цієї справи полягає в зрозумілій процедурі та відтворюваному досвіді відновлення на синтетичних файлах. Той самий набір даних має бути ідентифікованим до зупинки, під час перемикання та після відновлення. Реєстр, порівняння з еталоном і навмисні відмови роблять це правило спостережуваним. Переривання запускається контрольованим винятком у скрипті: жодного випробування відмови живлення не проводилося. Наведена технічна документація пояснює використані механізми; вона не засвідчує ваше майбутнє виробниче середовище.
У сценарії одночасно працює лише один процес. Локальне запечатування не є розподіленим блокуванням; відбиток не є перевіркою якості; результат CPU не є кваліфікацією CUDA, ROCm або multi-GPU. Застосунок, який також записує до зовнішньої бази даних, спільного сховища чи черги, потребує узгодженого правила для всіх цих місць призначення. Перед міграцією реальної обробки затвердьте це правило та ваш план повернення.
Щоб підготувати наступний крок
Резервна копія має давати змогу продовжити роботу.
Відновити в ізольованій цілі та перевірити, що копія справді дозволяє відновити роботу.
Передати естафету зі станом, дією та відповідальним.
Передати дії, обмеження та обов'язки іншій особі.