Служба технической поддержки работает по соглашению об уровне обслуживания (SLA, Service Level Agreement) между исполнителем и заказчиком, в котором заданы измеримые показатели качества [1, 2]. Для заявок обычно фиксируют время реакции и время решения, то есть интервал от обращения до полного устранения проблемы, причём целевые сроки зависят от приоритета [3]. Чтобы контролировать эти сроки, достаточно хранить в базе время создания и закрытия каждой заявки. Для небольшой команды подходит SQLite: она не требует отдельного сервера, хранит данные в одном файле и подключается из Python стандартным модулем sqlite3 [4]. Цель работы состоит в том, чтобы построить такой прототип и проверить на тестовых данных запросы, которые показывают, где нарушается SLA.
Схема данных состоит из четырёх таблиц (таблица 1). Время хранится в текстовом формате ISO 8601, а срок решения для каждого приоритета записан в таблице priority. Для связей использованы внешние ключи (PRAGMA foreign_keys = ON), на заявку наложено ограничение resolved_at > created_at, на поля priority_id и agent_id созданы индексы.
Таблица 1
Схема базы данных
|
Таблица |
Поля |
Назначение |
|
priority |
id, name, sla_hours |
приоритеты и срок решения по SLA |
|
agent |
id, name |
операторы поддержки |
|
category |
id, name |
категории обращений |
|
ticket |
id, created_at, resolved_at, priority_id, agent_id, category_id |
заявки со временем создания и закрытия |
Реальных данных поддержки в открытом доступе для работы не использовалось, поэтому набор заявок сгенерирован. Это основное ограничение работы: закономерности ниже заложены в генератор, и запросы лишь проверяются на том, что они их находят. Создано 6000 заявок за период с 1 апреля по 29 июня 2026 года, 10 операторов, 5 категорий и 4 приоритета со сроками решения 4, 8, 24 и 72 часа. Время решения моделировалось логнормальным распределением с медианами 2,5, 5, 14 и 40 часов по приоритетам. Медиана умножалась на коэффициент категории, коэффициент оператора (от 0,8 до 1,3) и на 1,35 для заявок, созданных в рабочие дни с 9 до 12 часов. Выходные заявки в генераторе встречаются реже, ночью их мало. Начальное значение генератора случайных чисел фиксировано (2026), поэтому набор воспроизводится.
Запросы выполняются из Python модулем sqlite3: после соединения с файлом базы создаётся курсор, данные загружаются методом executemany, результаты читаются методом fetchall. Значения передаются в запрос параметрами (знаки вопроса), а не подстановкой строк, это исключает ошибки экранирования и защищает от SQL-инъекций. Файл базы с 6000 заявок занимает несколько сотен килобайт, а каждый из приведённых запросов выполняется практически мгновенно, поэтому отдельный сервер и дополнительные индексы по времени для такого объёма не нужны.
Основной запрос считает число заявок, среднее время решения и долю нарушений по каждому приоритету. Время в часах получается из разности julianday, нарушением считается превышение sla_hours:
Результат приведён в таблице 2. Общая доля нарушений равна 28,4 % при 6000 заявках. Среднее время решения растёт с понижением приоритета, но доля нарушений по приоритетам различается слабо (от 26,4 до 35,5 %), так как сроки SLA и время решения в генераторе масштабируются вместе. Наибольшая доля нарушений у приоритета «Высокий» (35,5 %). Число критических заявок мало (296), поэтому их оценка менее устойчива.
Таблица 2
Время решения и нарушения SLA по приоритетам
|
Приоритет |
SLA, ч |
Заявок |
Среднее время решения, ч |
Нарушений SLA, % |
|
Критический |
4 |
296 |
3,5 |
28,7 |
|
Высокий |
8 |
874 |
7,6 |
35,5 |
|
Средний |
24 |
2997 |
20,6 |
27,5 |
|
Низкий |
72 |
1833 |
60,5 |
26,4 |
Аналогичные запросы с группировкой по оператору, категории и часу создания выявляют остальные закономерности (рисунок 1). Доля нарушений по операторам колеблется от 16,8 % (Оператор 3) до 39,6 % (Оператор 2). Среди категорий больше всего нарушений в категориях «Оборудование» (40,4 %) и «Сеть» (36,5 %), меньше всего в категории «Учётная запись» (16,1 %). Для рабочих дней с 9 до 12 часов, когда создаётся 38 % заявок, доля нарушений составила 39,4 % против 21,8 % в остальное время.
Нагрузка по операторам распределена почти поровну (от 576 до 639 заявок), а доля нарушений различается более чем вдвое. У операторов с наибольшей долей нарушений среднее время решения достигает срока SLA, у операторов с наименьшей долей составляет около 70 % срока. Такой запрос позволяет найти операторов, которым нужна помощь, но выводы по людям следует делать осторожно: в данных нет сложности отдельных заявок.
Рис. 1. Нарушения SLA по приоритетам (а) и распределение заявок и нарушений по часам создания (б)
Прототип показывает, что для первичного контроля SLA хватает одного файла базы и нескольких запросов. Результаты анализа можно использовать для планирования смен: пиковая загрузка с 9 до 12 часов совпадает с ростом нарушений. Ограничения прототипа: срок решения считается по календарному, а не по рабочему времени, нет учёта пауз при ожидании ответа заказчика, а закономерности получены на искусственных данных. Для применения в реальной службе нужны выгрузка из рабочей системы и проверка расчётов на фактических заявках.
Литература:
- Соглашение об уровне обслуживания (SLA) // Yandex Cloud. Документация. URL: https://yandex.cloud/ru/docs/glossary/sla (дата обращения: 14.10.2026).
- Брагин Д. SLA соглашение об уровне обслуживания как инструмент управления ожиданиями // Cleverence. 2026. 20 марта. URL: https://www.cleverence.ru/articles/it-i-razrabotka/-sla-soglashenie-ob-urovne-obsluzhivaniya-kak-instrument-upravleniya-ozhidaniyami/ (дата обращения: 14.10.2026).
- Что такое SLA? Разбираемся с соглашением об уровне обслуживания // Atlassian. URL: https://www.atlassian.com/ru/itsm/service-request-management/slas (дата обращения: 14.10.2026).
- AndreiMalevanyi. Работа с SQLite в Python (для чайников) // Хабр. 2023. 14 авг. URL: https://habr.com/ru/articles/754400/ (дата обращения: 14.10.2026).
