CapordiaВизначте, що має захищати графік
Почніть із рішення, яке вже не може чекати: перегляд результатів, передавання іншій команді або завершення періоду оренди. Назвіть для кожного проєкту особу, уповноважену прийняти його результат. Дата здачі — це не просто дата завершення обчислень: перевірка та отримання файлів теж мають знайти в ній своє місце.
Далі розрізняйте доступність машини й доступність людей. Обчислення іноді можуть просуватися вночі, але вашій команді може знадобитися присутність для першого запуску чи затвердження. Запишіть це обмеження, замість того щоб вважати всі години пакета взаємозамінними робочими годинами. Графік — це внутрішня домовленість, яку потрібно підтвердити, а не зобов'язання Capordia щодо надання.
Зібрати придатну для використання оцінку разом із її походженням
Для кожного завдання зафіксуйте очікувані вхідні дані, час, коли вони будуть фактично готові, кількість одночасних карт, пам'ять на карту та потреби в передачі. Додайте оцінку зайнятості ресурсу від початку завантаження до його звільнення. Відокремте підготовчі дії, які можна виконати до цієї зайнятості: це дозволяє не резервувати карту під час адміністративного очікування.
Зазначте, чи походить оцінка з порівнюваного випробування, з екстраполяції чи з простого припущення. Попередня тривалість є порівнюваною лише за умови, що дані, версії, налаштування та використовувані ресурси є достатньо близькими. За відсутності вимірювань позначте діапазон, який потрібно підтвердити; не вказуйте точність до хвилини, яка б свідчила про вимірювання. Передбачте невелике кваліфікаційне випробування, якщо його результат змінює вибір календарного плану.
Перехід від загального обсягу до здійсненних часових слотів
Підсумуйте заплановану зайнятість, щоб виявити очевидне перевантаження, а потім розмістіть кожне завдання на часовій шкалі. Неподільний чотиригодинний процес не вміщується у два проміжки по дві години, якщо не підтверджено можливість переривання та відновлення. Два завдання, які одночасно потребують того самого диска або тієї самої людини, також можуть заважати одне одному, навіть коли залишається вільна карта.
Документація Slurm показує, чому заповнення слотів залежить від тривалості та запитаних ресурсів: менш пріоритетне завдання може запуститися, якщо воно не затримує запланований старт пріоритетного завдання. Ця логіка допомагає читати ваш план; вона не свідчить про наявність Slurm у пропозиції Capordia. Будь-яке використання планувальника передбачає його реальну конфігурацію та політику, визначену вашою командою.
Вигаданий приклад: три проєкти за два дні
Вигадана команда «Бюро креслень» має для цієї вправи лише одну доступну карту з 9:00 до 17:00 протягом двох днів, Д1 і Д2. Жодне завдання не ділить карту, і кожне використання охоплює завантаження, обчислення та експорт. Наведені нижче тривалості є навчальними припущеннями: вони не походять ні з GPU з каталогу, ні з бенчмарку. Спільна підготовка займає одну годину на початку Д1.
Atlas потребує чотирьох годин і має бути зданий до Д2, 13:00. Balise потребує трьох годин; її вхідні дані надходять Д1 о 11:00, а здача запланована на Д1 о 18:00. Cadastre потребує п'яти годин; він стає готовим до роботи Д2 о 9:00 і має бути зданий до 18:00. Потреба становить 4 + 3 + 5 = 12 годин. З однією спільною годиною та трьома вільними годинами план використовує всі шістнадцять відкритих годин.
| Слот | Запланована зайнятість | Тривалість | Умова |
|---|---|---|---|
| J1, 9 год–10 год | Спільна підготовка та контроль | 1 год | Вхідні дані та версії доступні |
| Д1, 10:00–14:00 | Atlas | 4 год | Робота готова о 10:00 |
| Д1, 14:00–17:00 | Balise | 3 год | Отримано запитів об 11 год |
| Д2, 9:00–14:00 | Cadastre | 5 год | Вхідні дані отримано о 9:00 |
| Д2, 14:00–17:00 | Непризначений резерв | 3 год | Запас доступний лише на J2 |
Розміщуйте запас перед ризиком, який він має поглинути
Три вільні години становлять 25 % від дванадцяти годин робіт. Однак цього відсотка недостатньо, щоб забезпечити Balise: його запас припадає на день після здачі. Якщо Atlas займе п'ять годин замість чотирьох, Balise не зможе завершити до 17:00 у дозволеному вікні. На папері план тримається, але його перший день залишається крихким. Це прочитання корисніше за простий середній відсоток заповнення.
Тоді команда може частково або повністю перенести Atlas в інше вікно, якщо це дозволяють його обмеження, отримати додаткове вікно або скоротити прийнятний обсяг. Друга карта — це варіант для розгляду, а не автоматичний висновок: вона має бути доступною, сумісною та супроводжуватися потрібними хостовими ресурсами. Без підтвердженого рішення керівник змінює зобов'язання проєкту до запуску, а не називає «запасом» непридатний резерв.
Розв'язання конфлікту за допомогою оголошеного правила
Підготуйте арбітраж, перш ніж двоє відповідальних претендуватимуть на той самий слот. Просте правило може надавати перевагу спершу підтвердженому зовнішньому дедлайну, потім роботі, чиї вхідні дані готові, а вже потім давності запиту. Уточніть, хто може відступити від цього правила і яка команда витримає зсув. Терміновість повинна мати явний наслідок для плану, а не ставати новим постійним пріоритетом для того, хто її заявив.
Зберігайте базовий календарний план і причини змін: вхідні дані надійшли пізно, спостережувана тривалість виявилася довшою або обсяг розширено. Посібник із черги робіт стосується рішення про наступний запуск; календарний план натомість захищає дедлайни кількох проєктів. Їхній взаємозв’язок дає змогу пояснити, чому карта, яка на мить звільнилася, не обов’язково доступна для тривалої додаткової обробки.
Перевірити план і переглянути його з правильними відхиленнями
Перегляньте один день, рухаючись від слота до слота. Кожен запуск повинен мати доступні вхідні дані, доступи, обсяг пам’яті та відповідальну особу. Перевірте фінальне передавання та час на вичитку перед здачею. Потім змоделюйте найімовірнішу затримку і перевірте, який запас насправді її поглинає. Якщо через єдине відхилення зривається важливий дедлайн, подайте план як умовний.
Після фактичного виконання розмежуйте очікування перед запуском, зайнятість карти та час до прийнятого результату. Скоригуйте наступну оцінку з урахуванням цього розподілу. Затримка передавання сама по собі не виправдовує потужнішої карти; забута ручна підготовка не виправляється збільшенням запасу на обчислення. Моніторинг має допомагати усувати причину відхилення, а не шукати винного за ізольованим підсумком.
Пов’язати календарний план із пакетом, не плутаючи одиниці
Восьмигодинний день у цьому прикладі — це вікно організації, а не тариф на вісім годин. Каталог Capordia пропонує фіксовані періоди на 3, 7 або 30 днів і ціни за повний лот. Перевіряйте окремо тривалість оренди, кількість карт у лоті та робочий календар. Додаткова карта не скасовує ні підготовки, ні людської валідації.
Корисний результат — це затверджений календарний план з його припущеннями, розміщеними запасами та рішеннями на випадок відхилень. Його ще належить підтвердити фактично наданими ресурсами та репрезентативною пробою. Не перетворюйте ні шістнадцять годин із цієї вправи, ні її відсоток резерву на гарантований строк чи універсальне правило розрахунку потужності.
Запитання для ухвалення рішення
Чи можу я поділити заплановані години на кількість GPU?
Лише якщо роботи можуть виконуватися паралельно і якщо це дозволяють інші ресурси. Неподільний процес, залежність або етап вичитки можуть обмежити календарний план. Виявте ці обмеження, перш ніж перетворювати загальні години на кількість карт.
Який запас слід зарезервувати?
Запас залежить від імовірних відхилень та їхнього місця в календарному плані. Три години з прикладу є вигаданими й не захищають усі дедлайни. Розмістіть резерв перед здачею, яку він має убезпечити, а потім обґрунтуйте його своїми спостереженнями.
Чи замінює планування приймання машини?
Ні. Воно передбачає наявність придатних до використання ресурсів і застосунку. Приймання має перевірити це припущення, перш ніж вважати слоти придатними до використання. Якщо якась умова залишається невідомою, календарний план повинен зберігати проміжний статус і рішення про запасний варіант.