Производительность Jira Automation: уменьшаем выборку до нужных задач

Почему маленькое правило становится тяжёлым

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

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

Сузьте JQL до полезной области

Добавьте проект, тип, рабочее состояние и временной диапазон, соответствующий требованию. Используйте обычный поиск Jira для проверки: покажите результаты владельцу процесса и убедитесь, что нужные задачи не потеряны. Фильтр updated > -1w подходит только тогда, когда недельного окна действительно достаточно; это не универсальный рецепт. Для редкого изменения старой задачи нужно предусмотреть отдельное событие или регулярную контрольную сверку.

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

Уберите ветки, используемые вместо условий

Если нужно только проверить тип текущей задачи, используйте условие или If/else, а не поиск связанных задач с тем же признаком. Ветка предназначена для действий над другим набором объектов. Каждая лишняя ветка усложняет контекст и может увеличить очередь. Перед изменением проверьте, не рассчитывает ли дальнейшая логика на контекст найденной задачи; механическая замена ветки условием иногда меняет смысл правила.

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

Проверяйте ограничения, не запоминайте вечные числа

Atlassian публикует ограничения поиска, связанных объектов, очередей и времени обработки. Эти параметры могут меняться, поэтому перед масштабированием сверяйте актуальную документацию. Журнал помогает увидеть признаки THROTTLED и сообщения о превышении лимитов. Не пытайтесь обойти проблему бесконечным увеличением частоты: это может ещё сильнее загрузить очередь. Сначала уменьшите объём одного запуска и число ненужных действий.

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

Пилот, измерения и возврат

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

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

Показатели для ежемесячного просмотра

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