CapordiaНаписати мінімальний контракт запиту
Придатний до використання запит називає власника, проєкт, доступне вхідне джерело, ідентифіковану команду чи процедуру та очікуваний результат. Він зазначає кількість одночасних карт, пам'ять на карту, орієнтовну тривалість і призначення вихідних даних. Нарешті він уточнює дедлайн, причину цього дедлайну та особу, уповноважену прийняти затримку або скорочення обсягу.
Відсутність цієї інформації не повинна приховуватися високим пріоритетом. Завдання, вхідні дані якого не готові, залишається недопустимим, навіть якщо проєкт важливий. Запитайте, чого бракує, і призначте точку повторного розгляду. Тоді черга стає інструментом рішення: вона не перетворюється на сховище запитів, які неможливо запустити й щодо яких кожен сподівається, що їх опрацюють спонтанно.
Розрізняти допуск, резервування та право проходу
Допуск перевіряє, чи можна розглянути завдання: наявність прав, даних, сумісності, потужностей і процедури. Резервування потім захищає визначений часовий слот або ресурс. Пріоритет обирає порядок серед допустимих запитів, які змагаються за доступний ресурс. Ці три рішення можуть залежати від різних людей; зробіть цей розподіл явним, щоб уникнути неявного схвалення технічної потреби.
Вільна карта не робить усі завдання допустимими. Може бракувати потрібного дискового простору, ліцензія може обмежувати одночасність або може бути потрібен попередній результат. І навпаки, технічно готовий запит може чекати рішення щодо календаря. Показуйте зрозумілу причину та наступну дію, а не простий числовий ранг, який ніхто не вміє тлумачити.
Визначити пріоритети, які не стають привілеями
Виберіть кілька зрозумілих класів, наприклад підтверджений зовнішній дедлайн, поточна робота та дослідження без фіксованої дати. Визначте, хто може призначити клас і який доказ його обґрунтовує. Усередині класу правило давності або ротації може зробити вибір передбачуваним. Запит, розбитий на сто дрібних подань, не повинен механічно отримати у сто разів більше шансів, ніж запит іншої команди.
Slurm, зокрема, розрізняє час допустимого очікування та справедливий розподіл на основі наданих і спожитих ресурсів. Це ілюструє два різні питання: відколи ми чекаємо і яку частку ми вже використали? Ваше правило може залишатися ручним. Не переймайте формулу оцінки, не розуміючи її параметрів; ваги конкретного планувальника не є універсальною нормою справедливості.
Вигаданий приклад: впустити термінову задачу, не виганяючи інших
Вигадана команда «Плани та орієнтири» використовує одну карту. О 9:00 завдання проєкту «Плани» має підтверджений слот до 11:00; його не можна переривати. Очікують два повні запити: «Орієнтири» — сорок хвилин, і «Ескізи» — вісімдесят хвилин. О 9:30 надходить термінова потреба на тридцять хвилин, запитана «Орієнтирами» для перегляду опівдні. Усі ці тривалості є навчальними припущеннями, а не вимірюваннями.
Локальне правило дозволяє підтвердженій терміновій потребі перейти до наступної точки звільнення, не перериваючи вже розпочату роботу. Тож термінова потреба стартує об 11:00 і теоретично завершується об 11:30. Далі команда надає прохід «Ескізам», щоб «Орієнтири», вже обслуговані своєю терміновою потребою, не монополізували чергу. Про цей виняток і новий очікуваний старт «Орієнтирів» повідомлено відповідальним особам.
| Гіпотетичний слот | Проєкт | Причина проходу |
|---|---|---|
| 9 год–11 год | Plans | Слот уже зайнятий, переривання неможливе |
| 11:00–11:30 | Repères, термінова | Підтверджений зовнішній дедлайн до полудня |
| 11:30–12:50 | Esquisses | Ротація після обслуговування термінової задачі Repères |
| 12:50–13:30 | Repères, поточний запит | Наступний допустимий запит |
Запобігти голодуванню довгих завдань
Якщо завжди обслуговувати найкоротший запит, черга виглядатиме плинною, але довге завдання може відкладатися безкінечно. Передбачте зарезервовані вікна або повторний розгляд після оголошеного віку очікування. Цей поріг є внутрішнім правилом, яке потрібно визначити, а не гарантованим строком обслуговування. Якщо довге завдання справді перевищує доступний період, його допуск має призводити до нового розкладу, а не до безвихідного очікування.
Короткі проміжки можуть вмістити завдання, які не відсувають зарезервований запуск. Це рішення передбачає достовірну оцінку, справді сумісний ресурс і можливість завершити в межах вікна. Не заповнюйте всі запаси розкладу новими зобов'язаннями. Резерв, призначений для покриття відхилення, не є безкоштовним слотом; його використання повинно мати відповідального та відомий наслідок.
Передбачити скасування з чітким обсягом
Визначте, хто може скасувати власний запит, запит проєкту або виконання, що стало небезпечним для інших робіт. Для запиту, який ще очікує, підтвердьте його вилучення з порядку черги. Для запущеної роботи спершу перевірте, що можна перервати, що потрібно зберегти і хто очікує на її результати. Повідомлення «скасування запитано» ще не доводить, що ресурс вільний.
Реальний інструмент визначає технічні наслідки. Документація scancel розрізняє завдання та його кроки, а також надсилання сигналу й скасування завдання. Перш ніж використовувати еквівалентний інструмент, перевірте відповідний ідентифікатор і обсяг; уникайте глобального вибору задля зручності. Потім перевірте завершення процесів і призначення часткових результатів. План відновлення даних розглядається в досьє міграції, окремо від цього правила пріоритету.
Обмежити спроби та ізолювати дефектне завдання
Вирішіть до виконання, скільки автоматичних спроб є прийнятними для однієї причини. Некоректні вхідні дані не стануть правильними від перезапуску; тимчасово недоступна залежність може виправдати нову спробу після перевірки. Правило має вказувати максимальну кількість, можливий строк і відповідального за повторний розгляд. Лічильник, що скидається при кожному новому поданні, скасовує цей захист: прив'язуйте послідовні запити до однієї проблеми.
На визначеній межі вилучіть дефектне завдання зі звичайної конкуренції та помістіть його в логічний карантин із зрозумілою причиною. Решта допустимих робіт може продовжуватися. Повернення вимагає виправлення або підтвердженого пояснення, невеликої цільової перевірки та рішення власника; воно не відновлює автоматично пріоритет давньої нагальності. Ця процедура вирішує допуск після збою. Збереження результатів та їх відновлення залишаються в досьє міграції, без вигадування тут нового реєстру станів.
Перевірити політику на чотирьох простих ситуаціях
Дайте керівникам проєктів переглянути правило на чотирьох випадках: два ідентичні запити, нагальність під час неперервної роботи, довге завдання в оточенні коротких запитів і неповний запит, класифікований як нагальний. Для кожного випадку різна людина має дійти того самого наступного запуску або чітко визначити потрібний арбітраж. Правило, яке розуміє лише його автор, не готове до застосування.
Також перевірте, що скасування не надає двічі тієї самої потужності і що заблокована робота не заважає без потреби іншій допустимій роботі. Ці перевірки можна почати на папері; вони не доводять реалізації планувальника. Якщо згодом ви автоматизуєте, відтворіть ті самі сценарії на налаштованому інструменті, перш ніж ставити від них у залежність зобов'язання проєкту.
Виміряти обслуговування, надане чергою
Відстежуйте очікування прийнятних запитів за класом і за проєктом, а також причини блокування. Відокремлюйте очікування, зайнятість і час до прийнятого результату. Єдиний підсумок завершених робіт може приховати команду, яку постійно відсувають, або накопичення термінових завдань. Також вивчайте розбіжності між оціненою та фактичною зайнятістю: вони безпосередньо впливають на майбутні бронювання.
Перегляньте політику в узгоджений з командою строк або після інциденту, який виявить відсутнє правило. Змінюйте по одному правилу за раз і оголошуйте його вплив на вже наявні запити. Очікуваний результат — це пояснюваний порядок проходження, відстежувані винятки та узгоджений календар. Він не замінює ні автентифікацію облікового запису Capordia, ні дозволи машини, і не створює жодних зобов’язань щодо підтримки.
Запитання для ухвалення рішення
Чи завжди терміновість має проходити першою?
Терміновість має бути прийнятною, обґрунтованою та затвердженою згідно із загальним правилом. Вона не робить поточну роботу переривною. Визначте її точку проходження, переміщені запити та особу, яка бере на себе вплив на їхні строки.
Як не допустити, щоб одна команда монополізувала слоти?
Подивіться на вже отримані ресурси та очікування інших проєктів, потім застосуйте ротацію або явне правило розподілу. Сама кількість запитів не є мірою справедливості. Передбачте також опрацювання тривалих робіт.
Чи вимагає цей метод встановлення Slurm?
Ні. Документи Slurm висвітлюють деякі розмежування, але політику можна спершу застосувати в інструменті координації команди. Можлива автоматизація потребує власної конфігурації та перевірок; жоден планувальник не вважається наданим.