Как расследовать сбой Jira Automation по журналу и истории задачи

Начните с проверяемого симптома

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

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

Разделите отсутствие события и отказ условия

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

Если выполнение есть, но действий нет, последовательно проверьте условия. Выполните используемый JQL вручную для контрольной задачи с учётом текущего состояния. Помните, что состояние сейчас может отличаться от состояния в момент события; сравнивайте с историей. Для каждого условия сформулируйте простое объяснение: какая задача должна проходить и какая должна останавливаться. Условие, смысл которого владелец не может объяснить, трудно сопровождать безопасно.

Покажите вычисленные значения

Log action позволяет вывести результат smart values в журнал. Для проверки контекста обычно достаточно ключа текущей и исходной задачи, наличия поля и короткого рассчитанного значения. Используйте отдельные подписи для каждого значения, чтобы пустая строка была заметна. Например, CURRENT={{issue.key}}; ORIGIN={{triggerIssue.key}} помогает увидеть переключение контекста в связанных ветках. Сначала проверьте один компонент, затем добавляйте остальные.

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

Создайте контролируемый стенд

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

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

Исправление, возврат и контроль после запуска

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

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

Короткая карточка расследования

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