Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
Ночная выгрузка работает быстро на небольшом проекте, но после расширения начинает получать 429. Разработчик увеличивает число параллельных потоков, и ситуация ухудшается. Требуется согласованно управлять скоростью всех worker, сохраняя прогресс и не повторяя небезопасные операции без проверки результата.
Проверьте нагрузку не только своей утилиты, но и других интеграций того же сайта. Ограничение может проявляться лишь в общем ночном окне. Разнесение тяжёлых операций по времени иногда помогает больше, чем усложнение повторов. При этом клиент всё равно обязан корректно обрабатывать отказ сервера.
Модель и договорённости
Разделите чтение, запись и обновление одной горячей задачи. Задайте ограничение одновременных запросов и общую координацию паузы для одного сайта. Не зашивайте в бизнес-логику случайно наблюдаемое значение лимита: модель ограничений и условия конкретного метода могут измениться. Решение должно опираться на документированные ответы сервера.
Храните состояние паузы на уровне, доступном всем соответствующим worker. Если каждый процесс видит только собственные ответы, суммарная нагрузка остаётся неконтролируемой. Для разных сайтов и классов операций предусмотрите отдельные очереди, чтобы один перегруженный источник не задерживал несвязанную полезную работу.
Порядок внедрения
Поставьте запросы в очередь с контрольной точкой выгрузки. При 429 прочитайте Retry-After, перенесите выполнение и добавьте управляемое увеличение задержки с разбросом. Ограничьте число повторов и общий срок операции. Снизьте лишнее чтение: запрашивайте нужные поля и не перечитывайте одинаковые данные каждым параллельным обработчиком без необходимости.
Выпускайте новую стратегию с ограниченным числом worker и наблюдайте один полный цикл выгрузки. Сравните фактическое время бизнес-операции с возрастом очереди и долей повторов. Если нагрузка увеличивается, сначала регулируйте параллелизм, а не число попыток. Для крупных выгрузок сохраняйте контрольные точки чаще, чтобы перезапуск не превращался в полный повтор чтения.
Проверки на реальных сценариях
Используйте тестовый HTTP-сервер для ответов 429 с разной задержкой, временных сетевых ошибок и последующего успеха. Проверьте, что worker не начинают одновременно после одной паузы. Перезапустите процесс посередине выгрузки и подтвердите продолжение с контрольной точки. Для записи отдельно проверьте неопределённый результат после таймаута.
Добавьте ответ без ожидаемого заголовка и убедитесь, что клиент использует ограниченную безопасную стратегию ожидания. Проверьте верхний предел задержки и конечное число попыток. Тест должен подтверждать отсутствие активного цикла запросов во время паузы, а не только наличие вызова функции ожидания.
Ошибки и диагностика
Немедленный повтор создаёт цикл нагрузки. Бесконечный повтор скрывает реальный отказ, а независимые паузы потоков не защищают общий источник. Не превращайте все HTTP-коды в одну стратегию: ошибка данных не исчезнет от ожидания. В журнале различайте ограничения, сетевые проблемы, запреты доступа и неисправимые ошибки входа.
Сохраните класс ограничения и время ожидаемого повтора, но не записывайте авторизационные заголовки. Диагностика нагрузки не требует раскрытия токенов, полного содержимого задач или других защищённых данных интеграции.
Возврат и восстановление
Если новая стратегия нарушает сроки обработки, сначала уменьшите параллелизм и сохраните очередь. Верните предыдущую конфигурацию worker, сохранив контрольные точки и историю попыток. Не запускайте полную выгрузку заново поверх незавершённой. При необходимости дайте оператору возможность остановить отдельный сайт, не блокируя остальные интеграции.
При возврате настроек worker сохраните общий статус паузы и отложенные попытки. Немедленный выпуск накопленных запросов способен повторно вызвать ограничение сразу после исправления. Проверьте, что отменённые операции не возвращаются в активную очередь, а незавершённые сохраняют прежний идентификатор. Для записи сначала подтвердите фактический результат, затем решайте вопрос повтора.
Приёмка и дальнейший контроль
Следите за долей 429, временем ожидания, длиной очереди и фактическим числом завершённых бизнес-операций. Быстрое выполнение HTTP-запросов не равно полезной производительности. Хорошая стратегия демонстрирует контролируемое замедление и восстановление, а не лавину повторов, высокий расход ресурсов и скрытый рост отставания.
Для оператора полезнее оценка отставания бизнес-очереди, чем график количества HTTP-вызовов. Заранее определите, когда задержка становится инцидентом и какие операции можно отложить. После восстановления клиент не должен мгновенно выпускать весь накопленный поток, повторно провоцируя ограничение и увеличивая неопределённость результатов.
Механизм продукта и применимость
Jira Cloud может вернуть HTTP 429 при ограничении запросов. Atlassian рекомендует учитывать Retry-After и применять задержку повторов; ограничения существуют на нескольких уровнях, поэтому одна фиксированная скорость не гарантирует отсутствие отказов.
Ограничения Jira Cloud меняются и могут различаться для типов трафика. Статья не задаёт постоянную допустимую скорость запросов. Используйте актуальную документацию, ответы сервера и наблюдение собственной нагрузки; предложенная очередь и стратегия задержек требуют проверки в конкретной интеграции и сценарии записи.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу