Как мы адаптировали Jira для работы с большими объёмами данных

Юрий Шашкин

Старший инженер-разработчик КРОК

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

Мы решили перевести работу на серверную версию Jira, которой уже пользовались продуктовые команды и внутренняя техподдержка. Рассказываем, с какими проблемами столкнулись и как адаптировали новую систему для работы с огромными объёмами данных.

Проблемы

Наши сервисные департаменты обрабатывают большой поток заявок и общаются с разными вендорами. Поэтому во время переезда появилось несколько проблем.

Во-первых, инструменты Jira не закрывали все наши задачи. Например, у инженеров не было возможности быстро ориентироваться в множестве оборудования, по которому приходят заявки и разбираться в информации о нём.

Во-вторых, объём данных, с которым мы работаем, иногда оказывался для Jira слишком больши́м. Так, система рассчитана примерно на 200 соглашений SLA, а у нас их несколько тысяч.

В-третьих, нас не устраивала скорость обработки. Команде нужен был поиск по всем серверам на поддержке. А это множество данных, среди которых приходится искать нужные по вхождению подстроки в строку. Встроенными инструментами Jira такую работу тяжело оптимизировать.

Всё это пришлось решать кастомизацией.

Как мы адаптировали Jira

Чтобы подогнать систему под наши задачи, мы настроили работу со справочниками, с соглашениями SLA и печатными формам, поменяли интеграцию с внешними и внутренними сервисами.

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

На разных этапах мы показывали работу заказчикам: инженерам и их менеджерам. И смотрели, как они пользуются системой и обрабатывают заявки. Удобно ли им. Понятно ли. Нужно ли сделать что-то дополнительно.

От старта разработки до запуска прошло 8 месяцев.

Справочники: много данных и медленный поиск

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

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

Одной из идей было — сделать таблицы в базе данных и загружать всю информацию туда. Но нам нужен был быстрый поиск по строке, а Jira сильно тормозила процессы. Проблему решили в несколько этапов.

Создали проекты типа «Справочники», и начали писать задачи в них. Так каждая сущность справочника стала отдельной задачей, благодаря чему мы теперь достаём любые поля и данные и используем их, как считаем нужным.

Сделали кэш, который хранится в оперативной памяти, и ищем всё в нём. Это позволило добиться скорости поиска в 50 миллисекунд (весьма неплохой результат).

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

В ответ мы сделали так, что часто используемые задачи справочника при перезагрузке обновляются в первую очередь. Это позволяет не тормозить инженеров каждый день.

SLA: 6 тысяч уникальных соглашений против 200 в Jira

Настройка SLA-соглашений в Jira работает с помощью JQL. И система встаёт, если загрузить в неё более 200 строк.

У нас же около 6 тысяч соглашений. Каждое формируется из 4 уникальных полей (а вариантов таких полей до 20–30). Плюс у каждого свои календари, прописанные в договоре с заказчиком. Организовать всё встроенными системами Jira нереально.

Мы обсуждали разные доработки — с учётом разветвлённой системы алгоритмов и множества параметров, которые называются похожим образом. В итоге решили при каждом обновлении пересчитывать заявки SLA по заданному алгоритму — при таком варианте тысячи JQL-строк не нужны.

Разработку мы передали на подряд, сами занимались только составлением ТЗ и тестированием.

Интеграция: перейти на новую систему и сохранить связь с заказчиками

Раньше процессы внешней техподдержки — в том числе взаимодействие с заказчиками — мы вели через старый софт. Поэтому при переезде на Jira пришлось интегрироваться с клиентами заново. Разберу на примере.

У нас была интеграция с внешним заказчиком — через один сервис на обеих сторонах. Так что по внутренним протоколам системы отлично взаимодействовали друг с другом.

После переезда интеграцию пришлось переносить. Мы рассматривали два варианта: напрямую, через сервисную шину, или сделав старый софт неким посредником. В итоге использовали их смесь: данные из Jira идут в шину, затем в систему, с которой мы переехали, и после — к клиенту.

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

Печатные формы

У нас были десятки форм, которые используют инженеры для заказа запчастей, их доставки и приёмки, для планового обслуживания и так далее.

Хотелось легко менять их шаблоны — пусть даже через поддержку системы, но без изменения исходного кода. Хорошим решением оказалось написать формы в excel-файлах, которые хранятся на сервере, и дать Jira подставлять нужные значения в нужные ячейки.

Внедрение и адаптация

Внедрение было сложным — мы переходили почти три дня.

В первый день обнаружили проблемы: что-то недотестировали, что-то отвалилось, где-то не работали фрагменты интеграции и так далее. Так внедряться было нельзя. Во второй — заново тестировали систему и исправляли ошибки. И в третий уже внедрялись.

Также мы проводили обучение. Показывали, как заявки приходят на почту, как появляются в системе и как их обрабатывать, какие данные откуда подтягиваются и что будет уходить клиенту.

В это время мы тесно взаимодействовали с инженерами и с их руководителями, обсуждали проблемы и варианты решения. Благодаря чату в Telegram мелкие баги находились в течение нескольких минут — и общение было максимально продуктивным.

Нашей целью было непросто переехать из старой системы в новую. Мы критически смотрели на всю работу внешней техподдержки. Какие элементы системы нужны инженерам, а какие — нет. Насколько действующие инструменты помогают работе. Можно ли без них обойтись.

В итоге мы перестроили процессы, сделали более простую и современную систему, дописали алгоритмы, которые необходимы, чтобы работать с больши́м количеством данных.

Период стабилизации уже закончился, и можем сказать, что мы переехали успешно.