1. Зафіксуйте стан, перш ніж натиснути перезапуск
Припиніть додавати роботу та переконайтеся, що жодне виконання того самого пакета більше не активне. Втрачене з’єднання не завжди означає, що програма зупинилася. Перегляньте її стан, коли це можливо: запуск другої копії може створити дублікати або записати в ті самі призначення.
Збережіть журнал, список вхідних файлів, налаштування та повідомлення про помилку. Зробіть копію таблиці відстеження перед її виправленням. Тримайте сумнівні результати в окремому місці, не перезаписуючи оригінали чи вже прийняті результати. Якщо місце призначення заповнене, підготуйте вільне місце або інше призначення, попередньо визначивши, що потрібно зберегти.
2. Дайте кожному елементу стабільну ідентичність
Один рядок має представляти одну очікувану задачу, наприклад IMG-017, пов’язаний з catalogue/chaise-face.png. Лише шлях може стати неоднозначним після переміщення; коротка назва, як-от photo.png, може існувати в кількох папках. Зберігайте унікальний ідентифікатор і відповідність до початкового вхідного елемента.
Додайте ідентифікатор конфігурації, шлях виведення, стан, номер спроби та коротку причину. Цей журнал може бути звичайною таблицею або CSV вашого проєкту. Він не повинен містити зображення, паролі чи весь технічний журнал машини. Людина має мати змогу знайти правильний запис і пояснити, чому він потрапив до відновлення.
Не змінюйте оригінал за ідентифікатором, який уже прийнято. Новий запис або інше перетворення вимагає нової версії з чіткою позначкою. Інакше той самий ідентифікатор зрештою позначатиме дві несумісні роботи, і журнал більше не дозволить вирішити, що завершено.
| ID | Конфігурація | Стан | Виведення або причина |
|---|---|---|---|
| IMG-017 | essai-02 | Прийнято | IMG-017.png відкрито та перевірено |
| IMG-018 | essai-02 | Потрібно перевірити | Файл наявний, перевірку не завершено |
| IMG-019 | essai-02 | Збій | Нестача пам'яті під час обробки |
| IMG-020 | essai-02 | До виконання | Очікуваний результат не знайдено |
3. Зіставте журнал і реальні файли
Для кожного запланованого ідентифікатора знайдіть очікуваний результат. Перевірте формат, розміри або вміст, потрібні для вашого використання, а потім відкрийте файл у цільовій програмі. Результати, які вже прийнято і які досі наявні, до списку повторної обробки не входять. Якщо результат відсутній, хоч у журналі зазначено «прийнято», спершу пошукайте збережену копію, перш ніж вирішувати перерахувати його.
Віднесіть елементи зі статусом «у процесі» на момент зупинки до тих, що потребують перевірки. Деякі з них можуть бути повними, інші — лише частковими. Дата або розмір файлу є підказкою, а не підтвердженням. Додатковий файл без відомого ідентифікатора залишається окремо, доки ви не з'ясуєте його походження.
Щодо зображень, Pillow розрізняє ідентифікацію файлу, зчитування його пікселів і перевірку його структури. Тому програма, яка лише відкриває заголовок, не контролює все. Автоматична перевірка може виявити деякі пошкодження; вона не визначає, чи текст читабельний або чи кольори відповідають результату.
4. Відокремте незавершений елемент від відхиленого результату
Частковий результат потрібно переробити або відновити з повної копії. Повний, але неприйнятний результат вимагає спочатку зрозуміти дефект. Повторний запуск із тими самими параметрами на нечитабельному вхідному файлі або на випадку, якому систематично бракує пам’яті, ймовірно, повторить проблему. Запишіть виправлення, перш ніж повертати цей ідентифікатор у чергу.
Тримайте небагато станів: до виконання, у процесі, на перевірці, прийнято та невдача. Перехід до «прийнято» відбувається після перевірки, а не під час запуску обчислення. Якщо ви вирішуєте виключити елемент, додайте стан «відхилено» із причиною та відповідною згодою проєкту. Він не повинен зникати безслідно із загальної очікуваної кількості.
Не рахуйте нову спробу як нове завдання. IMG-019 може мати три спроби і лише один прийнятий результат. Це розрізнення допомагає не плутати шістдесят запусків із шістдесятьма різними результатами.
Приклад: відновити дев'ятнадцять елементів, які ще потрібні
Цей ілюстративний сценарій стосується шістдесяти незалежних зображень. Після переривання та перевірки сорок один результат прийнято, чотири часткові, шість зазнали невдачі, а дев'ять відсутні. Журнал охоплює 41 + 4 + 6 + 9 = 60 ідентифікаторів. Відновлення стосується дев'ятнадцяти елементів, за умови усунення причин шести невдач.
Відповідальна особа відновлює список із дев'ятнадцяти ідентифікаторів, а потім розрізняє чотири часткові файли, шість помилок і дев'ять завдань без виводу. Вона спершу бере виправлений запис і відсутній запис. Вона також підтверджує, що зображення, яке вже було прийнято, не входить до вибірки. Ця невелика перевірка затверджує список перед рештою обробки.
Якщо згодом приймаються ще вісімнадцять елементів, а один вихідний файл залишається нечитабельним, підсумок становить п'ятдесят дев'ять прийнятих і одну пояснену невдачу. Пакет не оголошується завершеним на шістдесят. Наступний крок — знайти правильний запис або затвердити його виключення, а не приховувати рядок.
| Стан після перевірки | Кількість ідентифікаторів | Запропонована обробка |
|---|---|---|
| Прийнято й вивід знайдено | 41 | Зберегти; без повторних спроб |
| Частковий вивід | 4 | Зберегти окремо, потім переробити |
| Збій виявлено | 6 | Виправте причину перед повторною спробою |
| Вихідні дані відсутні | 9 | Відновити з вхідних даних |
| Усього для відновлення | 19 | 4 + 6 + 9, без дублікатів |
5. Створіть відновлену копію в окремому місці
Підготуйте теку для відновлення роботи лише з тими ідентифікаторами, які було збережено, або скористайтеся явним вибором у вашому програмному забезпеченні. Перегляньте список перед запуском. Якщо інструмент пропонує «ігнорувати наявні файли», перевірте, що це означає: через наявність часткового файлу його може бути помилково проігноровано. Перевірений журнал залишається вашим орієнтиром.
Створюйте нові результати в окремій теці, разом з їхньою конфігурацією та спробою. Затверджуйте їх, перш ніж замінювати попередню версію. Деякі скрипти можуть перезаписати наявний файл без запиту на підтвердження; Python, зокрема, документує це для os.replace. Сама лише домовленість про іменування не захищає від заміни.
Якщо налаштування змінюються, щоб виправити дефект, залишайте цю зміну видимою. Ви можете зберегти результати з двох конфігурацій, якщо вони відповідають тим самим критеріям і якщо таке поєднання є прийнятним для проєкту. Для візуально однорідної серії також порівняйте нові результати зі старими, перш ніж об’єднувати теки.
6. Перевіряйте підсумок за ідентифікатором, а не лише за кількістю
Наприкінці кожен очікуваний ідентифікатор повинен мати пояснений стан. Дві копії IMG-017 не компенсують відсутність IMG-020. Перевірте унікальність назв, відповідність вхідним даним і конфігурацію затверджених результатів. Відкрийте перероблені файли та перевірте моменти, які стали причиною їхнього доопрацювання.
Завершена тека містить прийняті результати, оновлений журнал, налаштування та список можливих відхилених або ще заблокованих елементів. Збережіть цей набір із перевіреною копією. Рядок «прийнято» не замінює ні файл, ні його резервну копію.
Цей метод підхоплює незалежні завдання з їхнього початку. Він не дає змоги автоматично продовжити симуляцію, рендеринг чи навчання з тієї самої інструкції, на якій стався збій. Для таких робіт потрібен стан відновлення, властивий конкретному програмному забезпеченню. Також не припускайте, що теку, яка залишилася на орендованому середовищі, буде збережено після завершення періоду: підготуйте власну копію.