Применимость: Cloud. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Выберите задачу, подходящую для расписания
Каждое утро команда хочет сверять владельцев сервисов Jira с корпоративным справочником. Это фоновая задача, для которой допустима задержка в пределах согласованного периода. Scheduled Jobs ScriptRunner Cloud позволяют выполнять скрипты по расписанию, но не следует использовать их как точный секундный таймер. В документации описана очередь и отсутствие гарантии одинаковой минуты запуска. Если нужен немедленный отклик на событие, рассмотрите событийный механизм и оставьте расписание для контрольной сверки.
Определите источник истины, область сервисов и допустимое время устаревания. Внешний справочник может быть временно недоступен, поэтому отсутствие ответа не должно автоматически очищать всех владельцев Jira. Различайте пустое бизнес-значение и технический отказ чтения. Владелец процесса должен решить, как долго можно использовать последние известные данные и кому сообщать о невозможности обновления.
Порции и сохранение прогресса
Разделите работу на ограниченные порции. За один запуск обрабатывайте только согласованное число объектов, учитывая реальные ограничения выполнения скриптов и вызываемых API. Храните прогресс в устойчивом месте, подходящем для архитектуры интеграции. Локальная переменная скрипта не является хранилищем между запусками. Если нужен курсор внешнего API, учитывайте его срок действия и возможность повторно прочитать последнюю порцию после сбоя.
Перед записью сравнивайте текущего и требуемого владельца. Уже совпадающие значения не нужно обновлять. Для каждой изменённой задачи сохраняйте безопасный идентификатор и причину изменения. Не помещайте в журнал полный ответ корпоративного справочника. Если справочник возвращает удалённого или недоступного пользователя, направьте случай на ручное рассмотрение, а не подставляйте первого пользователя с похожим отображаемым именем.
Исполнитель и расписание
В настройке job укажите пользователя, от имени которого выполняется работа, и проверьте необходимые права на тестовых задачах. Выбирайте область доступа по назначению интеграции. Правило не должно зависеть от персональной учётной записи администратора, если для процесса предусмотрена отдельная модель владения. До включения сохраните имя владельца job, назначение, зависимые проекты и способ отключения.
Сверьте минимальный интервал и порядок выполнения с актуальной документацией Cloud. Не переносите cron-пример из Data Center без проверки. Выберите окно, в котором фоновые изменения не мешают ручной работе и нагрузке других интеграций. Если один запуск приближается к ограничению времени, уменьшите порцию и упростите запросы. Увеличение частоты без контроля очереди может только увеличить задержку и число повторов.
Ручной тест до включения
Используйте Run Now сначала в режиме планирования: скрипт читает данные и сообщает предполагаемые изменения, но не записывает их. Выберите пять случаев: владелец совпадает, владелец изменился, пользователь отсутствует, внешний ответ пустой по правилам и внешний сервис недоступен. Для каждого случая проверьте решение, а затем включите запись только на ограниченной группе задач.
Повторите тот же запуск и убедитесь, что второе выполнение не создаёт новых изменений при неизменном справочнике. Имитируйте сбой после части порции и проверьте восстановление прогресса. Если job создаёт объекты, простой повтор должен находить уже созданные по устойчивому внешнему идентификатору. Строгая защита от конкурентного создания может потребовать промежуточного сервиса: локальный поиск перед созданием не гарантирует атомарность.
Мониторинг результата и откат
Наблюдайте не только успешность выполнения, но и возраст последней полной сверки, число обработанных объектов и число исключений. Нулевое количество изменений может означать как стабильные данные, так и сломанный фильтр. Контрольная запись с заранее известным ожидаемым результатом помогает различить эти ситуации. Сигнал о сбое должен иметь адресата, который способен остановить интеграцию и проверить источник.
Для отката отключите job, сохраните курсор и список последних изменений. Восстанавливайте владельцев по прежним значениям только там, где их не исправили вручную после синхронизации. Если источник прислал ошибочный массовый ответ, сначала исправьте источник или правила проверки, затем запускайте сверку. Возобновление должно учитывать уже выполненные порции. Приёмка — устойчивое продолжение после частичного сбоя и понятная свежесть данных, а не совпадение времени запуска с минутой на часах.
Проверка полного цикла сверки
Перед промышленным запуском выполните несколько порций до полного обхода тестового справочника. Проверьте, что последняя неполная порция обрабатывается, завершение цикла фиксируется и следующий цикл начинается корректно. Добавьте новый объект во время обхода и удалите один существующий, чтобы увидеть поведение курсора. Решите, когда такие изменения должны попасть в Jira. Сохраните ожидаемую длительность полной сверки и ответственного за её превышение. Проверка одной успешной порции не показывает, что система когда-либо дойдёт до конца большого набора или правильно начнёт следующий проход после завершения.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу