В этой статье разберём, как устроены линии технической поддержки (Service Desk), какие бывают уровни и кто за что отвечает. А главное — покажем, как это работает в реальной практике Monoplan и какие метрики (SLA) должны быть у каждого уровня.
Зачем нужны уровни поддержки
Без разделения на уровни поддержка превращается в хаос. Один и тот же инженер отвечает на звонки, ищет баги и пишет новый код. В результате:
- Растёт время реакции (все заняты всем).
- Сложные задачи откладываются из-за постоянных отвлечений.
- Качество страдает, потому что специалист не может сфокусироваться.
- Клиент не понимает, почему его простой вопрос не решается часами.
- Сотрудники выгорают из-за многозадачности и отсутствия зон ответственности.
Традиционная модель: 3 линии поддержки
В мировой практике ITIL принята трёхуровневая модель. Она отлично подходит и для технической поддержки сайтов, особенно если речь идёт о высоконагруженных e-commerce и B2B-проектах.
1-я линия (L1) — Операторы / Help Desk
Кто: Операторы технической поддержки, менеджеры с технической базой, иногда чат-боты.
Задачи:
- Приём и регистрация заявок (телефон, чат, email, Telegram).
- Первичная классификация проблемы (что случилось, как критично).
- Решение типовых, простых проблем (например, «не могу войти в личный кабинет», «слетела вёрстка на главной»).
- Использование базы знаний (FAQ, скрипты, чек-листы).
- Если проблема не решается за отведённое время (обычно 15–30 минут) — эскалация на 2-ю линию.
Что важно: 1-я линия не лезет в код, не меняет настройки сервера. Её задача — быстрая диагностика и решение очевидных проблем, а также фильтрация заявок для инженеров.
Примеры задач L1: сброс пароля пользователя, проверка поступления заказа в CRM, обновление баннера (если есть интерфейс), объяснение клиенту как скачать электронный чек.
Метрики для L1: время первого ответа (15–30 минут), процент решённых заявок без эскалации (цель 50–70%), удовлетворённость пользователя (CSAT).
2-я линия (L2) — Инженеры поддержки / Администраторы
Кто: Опытные инженеры, знающие платформу (1С-Битрикс), серверное окружение, интеграции.
Задачи:
- Диагностика и устранение технических проблем, которые не решила L1.
- Работа с логами, базами данных, отладка кода.
- Исправление ошибок в компонентах, настройка интеграций (1С, CRM, платёжные шлюзы).
- Восстановление сайта после сбоев, откат изменений.
- Решение большинства инцидентов (80–90% после фильтрации L1).
- При необходимости — эскалация на 3-ю линию.
Что важно: L2 — это «боевая» инженерная сила. Они работают в тикет-системе, имеют доступ к серверам и коду, но не занимаются разработкой нового функционала (это зона L3 или команды развития).
Примеры задач L2: исправление ошибки 500 при оформлении заказа, восстановление обмена с 1С после сбоя API, удаление вредоносного кода после взлома, оптимизация медленного SQL-запроса в каталоге.
Метрики для L2: время реакции (1–8 часов в зависимости от приоритета), время восстановления (SLA для P1 — 4 часа, P2 — 8 часов), процент успешно решённых заявок без эскалации на L3 (цель 80–90%).
3-я линия (L3) — Разработчики / Архитекторы / Тимлиды
Кто: Senior-разработчики, технические архитекторы, тимлиды, знающие систему «изнутри».
Задачи:
- Анализ сложных, повторяющихся проблем, которые не может решить L2.
- Поиск первопричин и исправление ошибок в ядре или кастомном коде, требующих изменений архитектуры.
- Разработка долгосрочных исправлений (патчей, обновлений модулей).
- Анализ и оптимизация производительности (кэширование, запросы к БД, рефакторинг).
- Создание документации и обучение L1/L2.
- Обычно L3 работает не в режиме «горячей линии», а по задачам из бэклога, с приоритетом для критических инцидентов.
Что важно: L3 — это не поддержка в классическом смысле, а эскалационный уровень для самых сложных проблем. Именно здесь рождаются изменения в архитектуре, которые затем попадают в план развития.
Примеры задач L3: исправление ошибки в кастомном модуле оплаты 5-летней давности, рефакторинг компонента корзины, падающего при высокой нагрузке, перепроектирование схемы БД для устранения блокировок, разработка нового API для мобильного приложения.
Метрики для L3: время до начала анализа (1–2 рабочих дня для некритичных проблем), время выпуска исправления (от нескольких дней до спринта), снижение числа повторных инцидентов после изменений.
