Кейс: как мы доработали SLA с помощью ETL
Среди наших разработок есть 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.
Из минусов мы нашли только один, но не критичный — задачи обновляются один раз в час.
