Применимость: Data Center. Названия пунктов и доступность функций зависят от версии, плана и типа проекта. Проверяйте изменения на тестовом окружении. Описанные рабочие процедуры — предлагаемый подход, а не гарантии поставщика.
Сценарий и границы задачи
Пользователь открывает задачу по прямой ссылке, но не находит её в сохранённом фильтре. Дежурный предлагает немедленно переиндексировать всю Jira. Предлагаемый подход — сначала сузить причину: запрос, права, данные задачи или действительно состояние индекса. Так можно избежать тяжёлой операции, которая не исправит неверный фильтр.
Перед тяжёлой операцией попросите пользователя показать одну конкретную пропавшую задачу и точный запрос. Это резко сокращает область поиска причины. Если проблема касается только одного фильтра, сравнение предикатов и данных обычно информативнее общего предположения об индексах. Начальная диагностика должна оставаться доступной дежурному без опасных изменений.
Модель и договорённости
Соберите ключ задачи, точный JQL, пользователя и время наблюдения. Запишите версию Jira и текущую топологию. Сравнивайте одинаковые запросы под одинаковыми правами, иначе отличия нельзя интерпретировать. Документация в источнике относится к конкретной версии; перед административной операцией откройте аналогичный раздел для своей установленной версии.
Опишите контрольный набор независимо от текущего сохранённого фильтра. Ключи задач и ожидаемые значения помогут отличить изменение самого запроса от изменения поиска. Для кластера фиксируйте доступные диагностические сведения об узле и времени: без них плавающее расхождение может выглядеть случайной ошибкой пользователя.
Порядок внедрения
Найдите задачу по максимально простому запросу с ключом, затем добавляйте условия фильтра по одному. Сверьте реальные значения полей и разрешения пользователя. Если проблема остаётся, изучите журнал ошибок, статус узлов и рекомендации по индексированию своей версии. Решение о переиндексации принимайте после оценки влияния на пользователей и ресурсов.
До планирования индексирования соберите одинаковые контрольные запросы и результаты под выбранной ролью. Запишите состояние системы и инфраструктурные изменения за рассматриваемый период. Если подтверждена необходимость административной операции, выберите документированный для версии режим, оцените ресурсы и согласуйте окно. После завершения повторите исходные пользовательские запросы, а не ограничивайтесь статусом процесса в панели администратора.
Проверки на реальных сценариях
Подготовьте контрольные задачи с разными типами и полями, включая вновь созданную и недавно обновлённую. Проверьте простой поиск и рабочие фильтры до и после действия. Для кластера сравните наблюдение по документированному способу диагностики узлов. Контроль должен показывать правильность результатов, а не только завершение административной операции без ошибки.
Проверьте задачу с пустым полем, изменённым значением и недавно выполненным переходом. Если результаты расходятся только под одной ролью, вернитесь к проверке доступа. Если они отличаются по времени или пути запроса, сохраните наблюдение и журналы до следующего действия, чтобы не уничтожить полезные признаки проблемы.
Ошибки и диагностика
Переиндексация не возвращает доступ, которого нет у пользователя, и не исправляет неверный предикат JQL. Также возможны скрытые ошибки записи индекса из-за недостатка ресурсов. Не повторяйте тяжёлую операцию бесконечно. Зафиксируйте первую ошибку, доступное место, состояние процесса и обстоятельства, при которых результаты начали расходиться.
Если проблема исчезла после изменения фильтра, не приписывайте результат индексу. Фиксируйте подтверждённую причину и избегайте тяжёлых операций, для которых больше нет наблюдаемого основания в контрольных запросах.
Возврат и восстановление
Перед плановой операцией подготовьте регламент восстановления по версии и условия остановки при ухудшении. Если диагностика показала ошибку фильтра, верните его предыдущий текст без вмешательства в индекс. При проблеме после инфраструктурного изменения остановите дальнейшие изменения и восстанавливайте подтверждённую конфигурацию по согласованному плану, сохраняя журналы для разбора.
При ухудшении поиска после операции остановите новые изменения конфигурации и сохраните ошибки индексации. Не пытайтесь исправлять ситуацию удалением файлов индекса по случайной инструкции из другой версии. Используйте согласованный план восстановления и диагностику текущей топологии. После возврата проверьте свежие и старые задачи, чтобы убедиться в полноте восстановленного поиска, а не только в доступности интерфейса.
Приёмка и дальнейший контроль
Оценивайте полноту контрольных выборок, время появления новой задачи в поиске и повторяемость расхождения. В отчёте отдельно запишите подтверждённую причину и выполненное действие. Устойчивый результат — нормальная работа конкретных пользовательских запросов и понятный способ раннего обнаружения следующего отклонения, а не сам факт очередной переиндексации.
В runbook укажите безопасные первые шаги и критерии эскалации специалисту по инфраструктуре. Не включайте универсальную команду переиндексации для любой версии и топологии. После подтверждённого исправления повторяйте тот же набор выборок и сохраняйте результаты, чтобы следующее отклонение можно было сравнить с рабочим эталоном.
Механизм продукта и применимость
Для ускорения поиска Jira создаёт индекс содержимого полей. Необходимость и способ переиндексации после изменений нужно определять по документации установленной версии и характеру изменения.
Источник приведён для Jira Data Center 9.0 и подтверждает назначение поискового индекса. Процедуру для вашей установки нужно открыть в документации соответствующей версии. Статья предлагает порядок диагностики; она не рекомендует конкретный режим переиндексации без знания версии, топологии, объёма данных и наблюдаемой ошибки.
Официальная документация
Применить это к вашей системе
Обсудим контекст, ограничения и безопасный порядок изменений.
Обсудить задачу