Линии поддержки: L1, L2, L3 и при чём тут DevOps

В вакансиях пишут «инженер поддержки L2», но что именно стоит за этой цифрой, обычно не объясняют. Разберём, чем линии отличаются по задачам, инструментам и зоне ответственности — и почему граница между ними подвижна.

Откуда взялись линии

Деление на линии появилось из простой экономики. Большая часть обращений типовая: забыл пароль, не пришло письмо, не открывается страница. Если сажать на такие вопросы дорогого инженера, деньги улетят впустую, а сложные задачи будут ждать в очереди.

Поэтому обращения фильтруют. Первая линия берёт массовый поток и закрывает всё, что закрывается по инструкции. Дальше уходит только то, что инструкцией не покрывается.

Из этого следует важное: номер линии описывает не квалификацию человека, а тип задач, которые до него доходят. В маленькой компании один человек может закрывать все линии сразу, а в крупной между L2 и L3 будет ещё и внутреннее деление по продуктам.

L1: принять и разобраться по инструкции

Первая линия — это точка входа. Сюда приходят звонки, письма, чаты, тикеты.

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

Ключевой навык на этом уровне вовсе не технический. Это умение вытащить из человека, который расстроен и торопится, конкретику: что именно он делал, когда, что увидел на экране. От качества этой работы зависит всё, что будет происходить дальше по цепочке.

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

Инструменты: система тикетов, база знаний, админка продукта, иногда простые запросы в интерфейсе отчётов.

L2: понять, почему сломалось

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

Типичный день выглядит примерно так. Утро начинается с проверки дашбордов и разбора алертов, которые сработали ночью. Дальше — задачи, пришедшие с первой линии. В середине дня прилетает алерт: сервис начал отдавать 500. Ресурсы в норме, но по времени видно, что незадолго до этого был релиз — связь очевидна, разработчик откатывает версию, сервис стабилизируется. После этого нужно заполнить постмортем и поставить задачу на исправление. Ближе к вечеру — настройка мониторинга новых продуктовых метрик и нетиповая выгрузка из базы по запросу бизнеса.

Обратите внимание, чего в этом дне нет: общения с конечными пользователями. Собеседник инженера L2 — это первая линия, разработчики, DevOps и бизнес.

Что должно быть в инструментарии:

• Логи. Найти нужный сервис, отфильтровать ошибки, прочитать последовательность вызовов, сопоставить события по времени. Чаще всего это ELK, OpenSearch или текстовые файлы на сервере.
• Метрики и мониторинг. Логи говорят, что случилось; метрики показывают, как система чувствует себя в целом. Базовый набор: трафик, ошибки, задержки, ресурсы, состояние базы. Инструменты — Prometheus с Grafana, Zabbix.
• API и HTTP. Большая часть инцидентов связана с взаимодействием сервисов между собой. Нужно понимать коды ответов, структуру JSON, уметь повторить запрос через Postman или curl, читать описание в Swagger.
• SQL. Администрировать базу не требуется, но делать выборки, собирать выгрузки и проверять данные приходится постоянно.

И отдельно — процессы: участие в разборе инцидентов, ведение постмортемов, работа с проблемами как с отдельной сущностью, а не просто с потоком заявок.

Есть ещё один навык, который не выглядит как навык, пока не столкнёшься с его отсутствием: умение строить и проверять гипотезы. Видеть не отдельную ошибку, а систему; задавать вопрос «что изменилось?» раньше вопроса «кто виноват?»; докапываться до первопричины вместо того, чтобы перезапустить сервис и закрыть тикет.

L3 и DevOps: сделать так, чтобы ломалось реже

Третью линию в разных компаниях понимают по-разному. Где-то это команда разработки продукта, куда уходят подтверждённые баги. Где-то — выделенная группа экспертов по конкретной системе. Общее одно: сюда попадает то, что требует изменения кода или архитектуры.

DevOps и SRE стоят немного в стороне от этой вертикали. Они отвечают не за разбор обращений, а за инфраструктуру и надёжность: автоматизация, масштабирование, отказоустойчивость, CI/CD, системные проблемы, которые проявляются как череда разрозненных инцидентов.

Если совсем коротко, разница по линиям такая: L1 принял и передал, L2 разобрался почему, L3 исправил в коде, DevOps сделал так, чтобы это не повторялось.

Как выглядит переход с L1 на L2

Формально его оформляют повышением, фактически он происходит раньше — и не в один день.

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

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

Практический вывод для тех, кто сидит на L1 и хочет дальше: просить доступ к логам и мониторингу до того, как это понадобится по должности. Разбирать закрытые чужие инциденты. Задавать разработчикам вопрос «а почему так получилось» после того, как баг исправлен. Это и есть то, что отличает кандидата на L2 от человека, который просто три года принимал обращения.

Куда дальше

Вторая линия — неплохая развилка, потому что из неё есть несколько дорог.

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

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