Среди наших разработок есть ETL, я, в целом, много о нем писал. Кроме своего стандартного функционала – сбора и обработки данных – мы нашли ему внутри компании нестандартное, но эффективное применение, с помощью которого сэкономили 80% времени и ресурсов на кастомизацию таск-трекера. Если у вас есть ETL – берите на вооружение.

Предыстория

Наша команда разработки внутри пользуется системой учета задач, таск-трекером,

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

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

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

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

Следующий проект планировался на год, при этом количество пользователей в системе было на порядок выше. Это, конечно, должно было привести (и привело) к пропорциональному увеличению обращений в службу поддержки.

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

Процесс работы SLA через ETL

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

У задачи в нашей системе может быть множество статусов – это помогает более точно понять текущее состояние. Но в технологическом регламенте по соглашению SLA их всего три:

  • в работе;

  • пауза;

  • выполнена.

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

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

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

Задачи ядра были следующие:

  • Определить предельное время решения в соответствии с критичностью задачи;

  • Рассчитывать затраченное время на задачу в соответствии с производственным календарем и нахождением в статусе «в работе». Например, если задача пришла после 19 часов вечера в рабочий день, то начало отсчета должно начаться в 9 утра следующего рабочего дня.

  • Рассчитать время задачи в каждом статусе.

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

Для проектов в подсистеме НСИ определили время решений каждой из заявок, а затем наложили все это на календарь. Результат отправили в виде развернутой денормализованной витрины в слой аналитических витрин, который у нас поднят на ClickHouse.

Обновление витрины настроили один раз в час.

Разработка дашборда учета задач

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

Весь процесс от идеи до публикации занял 1,5 рабочих дня.

Основные показатели вывели верх и сделали кликабельными (по клику срабатывает фильтрация дашборда):

  • задачи в работе;

  • задачи в ожидании;

  • просроченный задачи;

  • задачи без ответа пользователей.

Задачи можно искать по проектам, номерам, датам и темам (дашборд масштабировали для решения задач внутреннего сопровождения).

А для отчетности выводится отдельная таблица, которая содержит список обработанных задач для печати.

Плюсы и минусы доработки

По факту, минимальными усилиями мы сделали полноценную поддержку SLA.

Из плюсов:

  • потратили 1,5 дня вместо 1,5 недель, если бы дорабатывали нашу систему учета рабочего времени;

  • не вносили никаких изменений в саму систему, а только свели данные;

  • значительно снизился риск просрочки задач – сотрудники сразу видят, какие задачи закрыты, а у каких скоро дедлайн;

  • мы можем оперативно выбирать приоритет каждой задачи в зависимости от времени решения;

  • квартальная отчетность строится автоматически по настроенному шаблону - нужно только нажать кнопку экспорта в Excel.

Из минусов мы нашли только один, но не критичный – задачи обновляются один раз в час.