Планирование мощности для фоновых задач на маленькой команде

Почему ночные задания переходят в рабочий день

Ночные задания обычно не укладываются в окно, потому что мелкие задержки накапливаются. Батч стартует на 40 минут позже из‑за долгого импорта. Несколько задач выполняются вдвое дольше из‑за загруженной базы. Затем повторные попытки возвращаются после таймаутов или лимитов. Кажется, что каждая проблема мала по отдельности. Вместе они выталкивают очередь на утро.

По этой причине планирование мощности для фоновых задач не может начинаться с грубой оценки числа воркеров. Нужно защитить фиксированное ночное окно. Если безопасное окно с 22:00 до 6:00, это восемь часов. Поздний старт урезает его до семи. Медленная обработка режет дальше. Повторы добавляют работы поверх исходной нагрузки.

Большинство команд замечают перетекание раньше, чем понимают причину. Поддержка слышит, что дашборды устарели, выгрузки пропали, или письма пришли с опозданием. Сотрудники заходят в систему, где очередь ещё оттекает, и утренние задачи начинают конкурировать с недоделанным ночным объёмом. Клиенты это чувствуют как лаг, устаревшие данные или случайные задержки. Команда чувствует спешку в начале дня.

Разовый пиковый случай отличается от паттерна. Если партнёр присылает огромный файл раз в месяц и это единичное длинное событие, это исключение. Если задачи заканчивают в 8:30 утра три раза в неделю, это проблема ёмкости, даже если ничего не падает окончательно.

Паттерн обычно исходит из нескольких причин: задачи приходят всплеском вместо равномерного распределения, одна медленная задача блокирует много коротких, повторные попытки дают больше работы, чем считали, и воркеры простаивают в одни периоды, но задыхаются в другие.

Утренние боли часто начинаются ещё ночью. Сначала защитите ночное окно, затем рассчитайте систему так, чтобы она успевала в плохую ночь, а не только в среднюю.

Что измерить прежде чем гадать

Нельзя рассчитывать число воркеров по суточной сумме. Очередь с 120 000 задач в сутки может выглядеть безопасно на бумаге, но реальная проблема часто прячется в двухчасовом всплеске после полуночи. Измеряйте приходы по часам и по более мелким срезам, если трафик взрывной. Суточное среднее скрывает момент, когда очередь начинает расти.

Время выполнения требует того же внимания. Измерьте среднее, но не останавливайтесь на этом. Нужны также времена медленного случая, например 95‑й или 99‑й перцентиль, потому что небольшая группа медленных задач может занять воркеров надолго после завершения быстрых задач. Если большинство задач длится 8 секунд, но некоторые — 90, именно эти медленные задачи решают, очистится ли очередь до входа людей.

Повторы меняют математику сильнее, чем команды ожидают. 5% повторов звучит мало, пока сбои не кластеризуются в одном окне и не возвращаются несколько минут спустя. Отслеживайте оба числа: сколько задач повторяется и сколько система ждёт перед повторной попыткой. Без этой задержки нельзя понять, равномерно ли распределяют повторы нагрузку или создают второй всплеск прямо перед рабочими часами.

Короткий проход измерений обычно достаточен. Считайте новые задачи по часам, а не только за день. Фиксируйте среднее время выполнения и время в медленном случае. Отслеживайте частоту повторов и задержку перед ними. Затем отметьте одновременность воркеров, пропускную способность базы данных и любые внешние API‑лимиты.

Последний пункт важен, потому что воркеры — не единое ограничение. Можно удвоить число воркеров и всё равно закончить позже, если база начнёт блокироваться, диск‑I/O исчерпается или внешний API позволяет фиксированную скорость запросов. Команды часто винят очередь, когда реальное узкое место где‑то ещё.

Если нужна простая правило — измеряйте самый загруженный час, а не спокойный. Эти числа надёжнее, когда вы подбираете число воркеров и решаете, нужны ли ещё машины, меньше повторов или другое расписание задач.

Разбейте задачи по типу и дедлайну

Команды попадают в беду, когда относятся ко всем фоновых задачам одинаково по срочности. Это не так. Письмо для сброса пароля, ночной отчёт продаж и задача очистки могут оказаться в одной очереди, но у них разные дедлайны.

Начните с простого разделения на группы, понятные людям. В большинстве систем это импорты, письма, отчёты, очистка и вебхуки. Держите первый проход простым. Если задача попадает в две группы, положите её туда, где задержка причиняет больше вреда.

Затем пометьте каждую группу дедлайном. Задайте прямой вопрос: что должно завершиться до прихода сотрудников? Обычно это ночные импорты, питающие дашборды, отчёты, которые читают финансы утром, и любые синки, поддерживающие актуальность данных клиентов. Если эти задачи проскальзывают в утро, люди быстро это заметят.

Некоторая работа может подождать. Очистка, архивирование, большие выгрузки и несрочные отчёты лучше запускать в часы с меньшей загрузкой. Перенос низкоприоритетной работы не исправит медленную систему, но не даст ей блокировать то, что действительно нужно людям.

Ещё одно деление важно. Группируйте задачи по ресурсу, к которому они обращаются. Если пять типов задач давят на одну и ту же таблицу базы или на один и тот же сторонний API, они конкурируют, даже если на бумаге очередь выглядит сбалансированной. Здесь планирование мощности часто даёт сбой: команды считают задачи, но не учитывают конкуренцию за ресурсы.

Простая таблица помогает: тип задачи, крайний срок завершения, может ли она подождать, какую таблицу или API затрагивает чаще всего и что ломается при её задержке.

Небольшой пример иллюстрирует мысль. Допустим, приложение отправляет счета, строит отчёты, обрабатывает вебхуки и удаляет старые логи ночью. Вебхуки и письма со счетами должны быть готовы до 9:00. Отчёты — к 8:00. Очистку логов можно отложить до полудня. Если отчёты и очистка нагружают один и тот же read‑реплику, разделите их ещё до того, как добавлять воркеры.

Этот шаг кажется базовым, но он спасает от многих ошибок в расчётах.

Прогнозируйте рост очереди почасово

Ночная очередь редко ломается сразу целиком. Она растёт в одном часу, уменьшается в другом, а потом висит дольше, чем кто‑то ожидал. Чистый способ увидеть это прост: отслеживайте каждый час и вычитайте выполненные из пришедших.

Используйте эту формулу для каждого часа:

end backlog = start backlog + arrivals - completions

Если результат ниже нуля, установите его в ноль. Очередь не может быть меньше пустой.

Делайте расчёт по самой тяжёлой реальной ночи, а не по средней. Средние значения успокаивают зрение: если один запуск импорта, синк партнёра или расчёт биллинга создаёт намного более тяжелую ночь, планируйте под неё.

Прогнозу для каждого часа нужны всего четыре числа: пришедшие задачи, сколько задач воркеры завершили, бэклог в конце часа и начались ли рабочие часы.

Два момента важнее остальных. Первое — когда бэклог начинается: первый час, когда приходов больше, чем возможностей воркеров. Второе — когда бэклог очищается. Разница между этими точками показывает, как долго очередь реально живёт.

Небольшой пример поможет. Допустим, в 23:00 поступает 2000 задач, в 00:00 — 4000, в 01:00 — 3000, в 02:00 — 1000. Если воркеры выполняют 2500 задач в час, бэклог в конце часов будет: 0, затем 1500, затем 2000, затем 500. Очередь сохраняется после 02:00 и очистится только в следующем часе.

Именно это команды часто упускают. Они смотрят на суммарный ночной объём и предполагают, что всё уложится до утра. Почасовая математика показывает, пересекает ли очередь границу бизнес‑часов. Как только это происходит, клиенты, поддержка и on‑call команда всё почувствуют.

Для этого не нужна сложная программа — простая таблица в спредшите достаточна. Для планирования числа воркеров форма ночи важнее одной суточной суммы.

Добавьте нагрузку от повторов в расчёт

Повторы могут тихо съесть ту мощность, которую вы думали, что имеете. Очередь с 100 000 запланированных задач — уже не 100 000, если падения возвращаются всю ночь.

Начните с числа задач, которые упали при первой попытке. Затем посчитайте, сколько из них упали снова и сколько вернулось для третьей попытки. Команды часто останавливаются на первых повторах, и это скрывает реальную часть нагрузки.

Простой пример оценки выглядит так:

• запланировано задач: 100 000
• ошибки при первой попытке: 4 000
• ошибки при второй попытке: 1 600
• ошибки при третьей попытке: 400

Такая очередь обрабатывает не 100 000 попыток, а 106 000. Если воркеры и так были близки к пределу ночью, эти дополнительные 6 000 попыток могут подтолкнуть работу в утро.

Используйте реальные показатели повторов из логов, а не надежды на тихую неделю. По возможности делите числа по типам задач. Отправка писем, генерация отчётов, импорты и синки через API обычно падают по разным причинам и возвращаются с разной частотой.

Одна плохая зависимость может разрушить весь прогноз. Медленный платёжный API, заблокированная таблица базы или поставщик с лимитами могут сделать тысячи задач неудачными в короткий период. Тогда повторы приходят не как мелкий ручеёк, а как плотный поток и конкурируют со свежей работой.

Политика задержек меняет форму этой кучи. Фиксированные задержки проще считать, но они часто создают волны. Задержка в 5 минут значит, что всплеск в 1:00 вернётся как другой всплеск в 1:05.

Экспоненциальный бэкофф лучше растягивает нагрузку и даёт времени восстановиться сломанной зависимости. Но он может сдвинуть работу за предел дедлайна задачи, поэтому проверяйте компромисс. Отчёт, который должен быть готов к 8:00, не может ждать через длинные паузы повтора.

При расчёте воркеров считайте ожидаемые попытки, а не только исходные задачи. Это небольшое изменение делает ночной план честнее.

Как шаг за шагом рассчитать число воркеров

Начинайте с дедлайна, а не с текущего числа воркеров. Если очередь должна быть пуста к 8:00, а задачи начинаются в 0:00, у вас восемь часов на завершение. Не считайте все восемь часов как полезное время: оставьте запас на медленные запросы, краткие простои и обычный ночной хаос.

Хорошее правило — планировать на 70–80% использования воркеров. При восьмичасовом окне и уровне безопасности 75% один воркер даёт примерно шесть часов надёжной работы, или 21 600 секунд.

Затем оцените, сколько работы приходит ночью в «секундах задач». Умножьте число задач на среднее время выполнения для каждого типа задач. Если одна группа работает значительно дольше остальных, считайте её отдельно. Простое среднее может скрыть проблему.

Поток расчёта:

1. Установите время завершения и посчитайте доступные часы.
2. Урежьте окно до безопасного рабочего времени воркера.
3. Посчитайте суммарные «секунды задач» за ночь.
4. Добавьте нагрузку от повторов и пиков.
5. Разделите на безопасные секунды на воркера и округлите вверх.

Допустим, ночью приходит 18 000 задач, среднее время выполнения 2,4 секунды. Это даёт 43 200 секунд работы. Добавим повторы: если 6% задач повторяются один раз и 1% — дважды, реальная нагрузка выше примерно на 8%, то есть 46 656 секунд.

Добавьте запас после этого, а не до. Буфер 10–20% обычно покрывает медленные задачи, неравномерные приходы и небольшие ошибки прогноза. При буфере 15% нагрузка становится 53 654 секунды. Разделите на 21 600 безопасных секунд на воркера и получите 2,48. Округлите вверх до 3 воркеров.

Сделайте ещё одну проверку перед тем, как доверять числу. Прогоните этот расчёт через лимиты базы, пула соединений и внешних API. Дополнительные воркеры не помогут, если база уже перегружена или API начинает отказывать. В таком случае сначала исправьте узкое место, затем пересчитайте.

Простой пример с реальными числами

Команда запускает импорт вендора в 23:00 и пакет отчётов в 2:00. В нормальную ночь 12 воркеров хватает.

• В импортной очереди в 23:00 приходит 300 000 задач.
• Каждый воркер обычно выполняет 4 импорт‑задачи в секунду.
• В 2:00 очередь отчётов получает 60 000 задач.
• Каждый воркер отчётов обрабатывает 2 отчётные задачи в секунду.

С общим пулом из 12 воркеров импорт заканчивается около 00:44. Батч отчётов тогда завершается примерно через 42 минуты после старта, задолго до утра.

Теперь изменим одно условие. API вендора замедляется, и каждый импорт‑воркер падает с 4 задач/с до 1. Это снижает импортную пропускную способность с 172 800 задач/час до 43 200.

Повторы усугубляют отставание. Если 25% импортных задач падают однажды и 10% требуют второй попытки, очередь уже не хранит 300 000 попыток, а 405 000.

К 2:00 воркеры обработали только 129 600 импортных попыток. Осталось 275 400 импортных попыток. Когда приходят 60 000 отчётных задач, общий бэклог вырастает до 335 400 задач.

При одном общем FIFO‑пуле отчёты оказываются за импортным бэклогом. Импортная очередь закончится примерно через 6,4 часа, около 8:22. Только затем начнутся отчёты, и последний отчёт появится около 9:04. Так ночные пакетные задания переходят в рабочий день.

Разделение очередей меняет эффект. Отдайте импортам 9 воркеров, отчётам — 3. Теперь импорт идёт медленнее и закончится около 11:30 (что плохо), но очередь отчётов защищена: 3 воркера обработают 60 000 отчётов примерно за 2 часа 47 минут, поэтому отчёты по‑прежнему завершатся около 4:47.

Если импорт тоже должен завершиться к 6:00, рассчитывайте число воркеров из худшего случая, а не из нормального. От 23:00 до 6:00 у вас семь часов на обработку 405 000 импортных попыток. Это около 57 900 задач в час. При 1 задаче/с на воркера нужно примерно 17 импортных воркеров, а не 12.

Вот почему планирование мощности должно начинаться с оценки замедлений и нагрузки от повторов. Большой общий пул выглядит эффективно на бумаге, но две очереди часто защищают настоящие дедлайны.

Ошибки, создающие ложную уверенность

Ложная уверенность часто начинается с чистых средних. Дашборд говорит, что очередь очищается за шесть часов, но среднее скрывает час, когда приходы всплеском настигают воркеров и они отстают. Если планировать по суточным суммам вместо самого загруженного часа, ночные пакетные задания будут продолжать течь в утро.

Команды также переоценивают воркеров. Десять воркеров не означают, что одновременно выполняется десять задач, если база данных, внешний API или раннер задач позволяют одновременно только два‑три. На бумаге мощность в порядке, на проде воркеры простаивают или ждут одного общего узкого места.

Редкие медленные задачи наносят больше вреда, чем многие команды ожидают. Если 95% задач завершаются за 10 секунд, это кажется безопасным. Но 5%, которые занимают 4–5 минут, могут держать воркеры настолько долго, что задержат всё, что за ними следует, особенно если они попадают ближе к концу ночного окна.

Повторы создают ещё одно ложное чувство безопасности. Высокий процент повторов делает графики успешных задач более «чистыми», потому что больше задач в итоге проходят. Но это также может удвоить или утроить нагрузку. Если 1000 задач попали в нестабильную зависимость и даже 8% повторяются несколько раз, вы уже не обработали 1000 задач — вы обработали гораздо больше попыток и потратили воркер‑время на один и тот же шаг.

Добавление воркеров на горячую базу часто ухудшает ситуацию. Больше воркеров даёт больше чтений, больше записей и больше блокировок в слабом звене. Очередное время может упасть на несколько минут, затем снова вырасти, когда запросы замедляются, и повторные попытки накапливаются. Планирование мощности должно включать запас базы данных, а не только число воркеров.

Небольшая проверка здравомыслия помогает. Сравните мощность с самым загруженным часом, а не с днём в целом. Посчитайте, сколько задач каждого типа может выполняться одновременно. Измерьте, сколько задач существенно дольше медианы. Учтите повторы как реальную нагрузку. Проследите время ожидания в базе при росте числа воркеров.

Небольшой пример показывает риск. Пусть команда видит 12 000 задач в ночь и 20 воркеров. Звучит нормально. Но если пиковый час получает 4 000 задач, один медленный класс задач занимает шесть воркеров, повторы добавляют 15% попыток, а база начинает строить очередь записей после полуночи, то план никогда не был безопасен. Число воркеров казалось достаточным, потому что модель опустила части, которые реально задают время завершения.

Если очередь базы растёт, когда воркеры «просыпаются», остановитесь. Следующий воркер не спасёт утренний прогон.

Быстрая проверка перед добавлением воркеров

Добавление воркеров кажется очевидным решением, но часто оно скрывает проблему с трафиком, а не решает её. Короткий аудит покажет, застряли ли задачи на общем ресурсе, в паттерне повторов или плохом расписании.

Проверьте, куда уходит время

Начните с самых медленных задач. Если многие из них читают или пишут в одну таблицу, дополнительные воркеры лишь создадут длинную очередь. То же самое произойдёт, если несколько типов задач звонят в один внешний API. Новые воркеры мало помогут, если они все будут ждать одного и того же узкого места.

Полезно разделить время задачи на несколько простых бакетов: время выполнения полезной работы, время ожидания блокировок базы, время ожидания лимитов API, время сна перед повтором и время, когда задача стоит за старой задачей.

Такой разбор быстро меняет разговор. Если воркеры 40% ночи ждут лимитов, покупка дополнительной мощности — слабое решение.

Посмотрите на повторы. Команды часто дают всем провалившимся задачам одинаковую задержку, и тогда все они возвращаются одной острой волной. В 2:00 очередь кажется нормальной, а в 2:15 сотни повторов просыпаются одновременно и вытесняют свежую работу. Разбросайте повторы, прежде чем добавлять хотя бы одного воркера.

Отделите срочную работу от массовой

Очередь может казаться занятой по не той причине. Если срочные задачи стоят за массовыми импортами, генерацией отчётов или очисткой, пользователи почувствуют задержку, даже если общая пропускная способность в порядке. Зарезервируйте воркеров для срочных задач или вынесите массовую работу в отдельную очередь с более свободным дедлайном.

Небольшое изменение расписания часто решает больше, чем команды ожидают. Попробуйте сдвинуть один тяжёлый батч на 20–30 минут позже, после завершения другой семейства задач. Или запускайте повторы в другую минуту, чем самый большой ночной импорт. Одна тестовая ночь покажет, приходит ли перетекание из‑за низкой мощности или из‑за плохого тайминга.

Простой пример: письма со счетами пропускают окно, потому что синхронизация продукта стартует в ту же минуту и давит на один API. Добавление четырёх воркеров может ничего не поменять. Сдвиг синка на полчаса может убрать весь утренний бэклог.

Если воркеры в основном ждут, собираются или борются за один ресурс, сначала исправьте это. Добавляйте воркеров, когда уверены, что они будут работать, а не стоять в очереди.

Следующие шаги для небольшой команды

Если задачи всё ещё текут в рабочие часы, прекратите гадать и запишите числа, которые решают исход. Для каждой группы задач фиксируйте скорость прихода, время выполнения, частоту повторов и крайний срок. Не смешивайте всё в одно среднее. Импорты, отчёты, письма и медиа по‑разному нагружают очередь.

Простая таблица в начале достаточна. Разбейте приходы по часам, затем сравните нагрузку с рабочим временем, которое ваши воркеры действительно могут дать ночью. Если у группы жёсткий утренний дедлайн, воспринимайте её отдельно. Так низкоприоритетный батч не скроет реальный риск.

Простая еженедельная рутина работает хорошо:

• обновить подсчёт приходов для каждой группы задач
• проверить медианное и медленное время выполнения, а не только среднее
• пересчитать нагрузку от повторов после изменений кода или инфраструктуры
• сравнить суммарную ночную работу с часами, которые воркеры могут дать
• отметить группы, которые не успевают до дедлайна

Настройте оповещение не только по ошибкам, но и по утреннему бэклогу. Если очередь всё ещё оттекает в 6:00 или 7:00 — это уже продакшен‑проблема, даже если задачи в итоге завершаются. Второе оповещение по всплескам повторов полезно, потому что штормы повторов часто появляются до того, как очередь пропустит дедлайн.

Для маленькой команды цель проста: знать, когда начинается бэклог, понимать, почему он растёт, и знать, какие задачи никогда не должны ждать за массовой работой. Как только эти числа есть, планирование числа воркеров становится значительно проще.

Если команда маленькая и одновременно разбирается в поведении очереди, лимитах базы и шторме повторов, внешний аудит может сэкономить много проб и ошибок. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями по архитектуре, инфраструктуре и AI‑первым операциям разработки; анализ узких мест такого рода часто окупает короткую консультацию.