Deployment завис у черзі: що перевірити насамперед

Deployment, який завис у черзі — одна з найменш інформативних помилок, які може показати платформа. Нічого не впало. Логи не з’явилися, бо нічого не запускалося. Реліз просто залишається на місці, і після кожного оновлення ви бачите те саме слово.

Найбільше дратує те, що слово «queued» охоплює щонайменше чотири різні ситуації, які не мають між собою нічого спільного. Визначити, у якій саме ви опинилися, можна приблизно за тридцять секунд — і це вирішує, чи варто чекати, повторити спробу або шукати причину зовсім в іншому місці.

Що насправді означає «queued»

Deployment у черзі прийнято та зафіксовано, але йому ще не призначено worker. Між цими двома моментами має виконуватися кілька умов:

• Платформа має отримати ваш source, що зазвичай означає API-виклик до вашого Git provider.
• Build slot має бути вільним.
• Усі prerequisite у релізі мають завершитися — migration step, операція з volume або попередній deployment того самого service.

Якщо щось із цього заблоковано, запис існує, а робота не починається. Ось і весь механізм. Тут немає загадки, але більшість dashboard відображають усі чотири випадки одним і тим самим словом.

Чотири випадки в порядку, у якому їх варто перевіряти

1. У вашого Git provider невдалий день

Це найпоширеніша причина, на яку ви не можете вплинути. Платформа запросила ваш repository й отримала повільну відповідь або помилку. Якщо кілька не пов’язаних між собою services одночасно опинилися в черзі й не мають спільного коду, спільною залежністю є саме provider.

Спершу перевірте status page вашого provider. Deploy, який очікує на upstream API, з часом завершиться сам, а повторна спроба лише додає ще один запис до купи — саме тому одна зависла черга так часто перетворюється на п’ять завислих черг.

2. Щось попереду ще не завершилося

Більшість платформ серіалізують deployments для кожного service, і це правильно: два build, які записують один і той самий image tag, — це не та гонка, яку ви хочете виграти. Якщо попередній deployment цього service усе ще виконується — або, що ще гірше, система вважає, що він виконується, бо worker завершив роботу без звіту, — наступний чекатиме.

У Dockup команда dockup deployments показує історію, починаючи з найновішого запису, а також status кожного з них. Якщо deployment безпосередньо перед вашим релізом у черзі не має terminal state, відповідь знайдено: скасувати його або дочекатися timeout — саме це розблокує чергу.

dockup deployments my-project/my-api --json

Вивід --json містить status і duration кожного deployment, тому ситуацію «попередній так і не завершився» видно одразу — на відміну від одного лише spinner.

3. Немає capacity

Кожна платформа має обмежену кількість build workers. На shared tier сплеск активності на платформі може поставити вас у чергу після build інших користувачів. Це реальна, зазвичай короткочасна ситуація, і саме тут очікування справді є правильним рішенням.

Важливо, чи можете ви це побачити. Позиція в черзі або приблизний час очікування перетворюють досвід, схожий на outage, на звичайну ситуацію. Самого «queued» недостатньо.

4. Deployment узагалі не мав запуститися

Найгірший випадок: запис створено, але те, що мало його підхопити, цього не зробило. Worker завершився аварійно, webhook було втрачено або token завершився між trigger і fetch.

Ознака — час. Очікування в черзі вимірюється секундами або кількома хвилинами. Deployment, який перебуває в черзі десять хвилин і перед ним немає інших релізів, не очікує — він завис, і самостійно не зрушить із місця.

Як відрізнити очікування від зависання

Перш ніж повторювати спробу, з’ясуйте три факти:

1. Чи виконується ще якийсь deployment? Якщо інший реліз того самого service виконується, ви маєте справу з випадком 2, тож краще нічого не змінювати.
2. Скільки часу deployment перебуває в черзі? Менше двох хвилин — нормально. Понад десять — ні.
3. Чи потрапили інші services у чергу одночасно? Якщо не пов’язані між собою services зупинилися в один момент, шукайте причину upstream, а не у своєму коді.

Ці три відповіді майже завжди допомагають відрізнити «почекати» від «діяти».

Чому повторна спроба зазвичай погіршує ситуацію

Коли реліз завис, природна реакція — натиснути deploy ще раз. У serialised pipeline це лише шкодить: ви додаєте другий запис після першого, і якщо перший справді завис, другий успадковує це блокування. Розробники, які стикаються з такою ситуацією, часто отримують цілий стовпчик записів у черзі, жоден із яких не запуститься, доки не звільниться її початок.

Якщо ви все ж плануєте повторити спробу, спочатку скасуйте deployment, який завис. Один deployment у черзі, що явно завершився помилкою, набагато корисніший за п’ять записів, які просто залишаються на місці.

Як ми вирішуємо це в Dockup

Важливе рішення в дизайні полягає в тому, що deployment ніколи не може вважатися таким, що виконується. Кожен deployment має terminal state, і саме його досягнення звільняє чергу. Build, який завершується без звіту, усе одно отримує timeout і звільняє service.

Є ще дві речі, які допомагають більше, ніж може здатися:

Stages мають назви. Deployment у Dockup проходить етапи отримання source, build і health gate, а кожен stage записує власну duration. Коли щось працює повільно, ви бачите, що саме повільне, а не просто спостерігаєте за одним словом. stageTimings є в кожному записі deployment, зокрема й у виводі --json.

За релізом, який уже завершився помилкою, нічого не залишається в черзі. Якщо health check не проходить, deployment завершується — він не займає service, поки ви гадаєте, що відбувається. Попередня версія весь цей час продовжує обслуговувати traffic, і це друга причина, чому завислий реліз у Dockup не означає outage.

# Який поточний стан і скільки часу зайняв кожен stage?
dockup status my-project/my-api --json

# Стежити за build у процесі, а не чекати на підсумок
dockup logs my-project/my-api --build --follow

Загальне правило

Queueing — це не failure mode. Queueing без пояснення причини — так. Будь-яка платформа час від часу змушуватиме вас чекати на Git provider або build slot; різниця між п’ятьма хвилинами роздратування та втраченим днем полягає в тому, чи повідомляє interface, у якому з чотирьох випадків ви опинилися.

Коли ви обираєте, де запускати щось, це варто перевірити навмисно: запустіть deploy і подивіться, що платформа показує в проміжку між його прийняттям і стартом. Якщо відповідь — одне слово без timestamp, рано чи пізно ви витратите на це цілий день.

Поширені запитання

Як довго deployment має залишатися в черзі? Кілька секунд або кілька хвилин на справній платформі. Якщо перед ним нічого немає, а очікування триває понад десять хвилин, вважайте його завислим, а не просто повільним.

Чи варто повторювати queued deployment? Не доки ви його не скасуєте. У serialised pipeline повторна спроба стає в чергу після того, що завис, і успадковує те саме блокування.

Чи може завислий deployment призвести до недоступності мого сайту? Не повинен. На платформі, яка перемикає traffic лише після того, як новий реліз проходить health check, поточна версія продовжує обслуговувати запити. Queued або failed deploy — це реліз, який не відбувся, а не outage.

Чому кілька services одночасно потрапляють у чергу? Тому що вони мають спільну dependency, і майже завжди це Git provider або build fleet, а не щось у вашому коді.