Год назад я обрабатывал тикеты по инструкциям. Сейчас анализирую логи, пишу SQL-запросы и разбираю баги с разработчиками. Как же я дошёл до жизни такой?..
Привет, Хабр. Меня зовут Азиз (по паспорту Жавлонбек, но так вышло, что Азиз прижился ещё с детства, скажу спасибо старшему брату). Я младший специалист поддержки внутренних сервисов в Ozon. Начинал на первой линии L1, через год перешёл на вторую L2.
Это история о том, как реально меняется работа при переходе с первой линии на вторую. Честный разбор, что изменилось, какие навыки понадобились и почему поддержка стала для меня фундаментом для роста в IT.
Эпизод первый. Первая линия L1 как точка входа с чёткими границами
L1 — это место, где впервые погружаешься в работу IT-компании изнутри. Ты учишься работать с реальными системами, понимаешь процессы и общаешься с пользователями, у которых что-то сломалось.
Если описать L1 одной фразой, то это «много всего, но поверхностно». Работаешь с десятками сервисов, но только с простыми задачами и типовыми кейсами. Всё сложное эскалируется на L2. По сути, ты универсальный солдат первой линии, знаешь понемногу обо всём, но не глубоко.
В моём случае мы поддерживали покупателей и продавцов, принимая заявки от контактного центра. Типовые проблемы, которые встречались:
у покупателей — ошибки на сайте и в приложении, сбои авторизации, проблемы с оформлением и оплатой;
у продавцов — ошибки загрузки товаров, проблемы с УПД, некорректные статусы возвратов в личном кабинете.
Первое, что меня поразило, это количество задач. Тикеты идут потоком, и большую часть мы старались обрабатывать самостоятельно. Когда встречались незнакомые кейсы, эскалировали на L2. Но даже здесь нельзя было действовать наугад, нужно было вникнуть в проблему, точно определить команду и собрать информацию.
Работа не сводилась к слепому следованию инструкциям. Пытались разобраться сами, консультировались с L2, искали причины. Но была принципиальная граница, мы могли только направлять нестандартные случаи дальше, но не решать их.
Как проблема доходит до L1
Прежде чем погрузиться дальше, важно понять, как проблема вообще добирается до нас. Это результат фильтрации, через которую проходит каждое обращение.
Типичный сценарий выглядит таким образом. Пользователь сталкивается с проблемой, например, не может оформить возврат, не видит кнопку оплаты или получает ошибку при входе.
Уровень 1: чат-бот — автоматически решает стандартные запросы: «Где мой заказ?», «Как вернуть товар?». Многое закрывается здесь.
Уровень 2: оператор клиентской поддержки — если бот не помог, включается оператор. Он работает по скриптам и базе знаний.
Уровень 3: мы — только когда проблема требует доступа к внутренним системам, анализа данных или технического расследования, специалист создаёт тикет и передаёт его на L1.
Мы анализируем проблему, определяем затронутый сервис и проверяем, можно ли решить вопрос на нашем уровне. Если нет, то перенаправляем в соответствующую команду L2.
Ключевое отличие от клиентской поддержки заключается в том, что они работают по скриптам с пользователями, а мы с внутренними системами. У нас есть доступ к админкам, API и логам. Мы можем проверить данные, воспроизвести проблему, иногда исправить её самостоятельно.
Что мы делали на практике:
проводили базовые проверки: права, роли, доступы, настройки в админке, корректность данных;
воспроизводили инциденты по инструкциям;
применяли типовые решения;
эскалировали, если кейс не закрывался по шаблону.
Инструменты, которыми пользовались:
админки сервисов;
база знаний с инструкциями;
ServiceDesk;
сервис для просмотра логов;
чек-листы и регламенты.
Как это выглядит в реальности
Кейс 1: «Ошибка при авторизации: ошибка сервиса, попробуйте позже»
Звучит страшно? На деле алгоритм чёткий:
Открываешь кейс в базе знаний;
Проверяешь наличие привязанного номера через админку;
Если есть дубли, то отвязываешь их;
Проверяешь, не в стоп-листе ли номер;
Удаляешь из стоп-листа, если нужно;
Если проблема остаётся, смотришь логи, фиксируешь ошибку и эскалируешь на L2 с полным отчётом что проверено, включая скриншоты, логи и какие гипотезы отработаны.
Кейс №2: «Не могу открыть спор в заказе, нет кнопки»
Тво�� действия:
Проверяешь условия отображения кнопки, такие как статус заказа, схема доставки;
Запрашиваешь скриншоты у пользователя;
Советуешь почистить кэш (классика жанра!);
Проверяешь логи на наличие ошибок при загрузке элементов интерфейса.;
Не помогло? Передаёшь на L2, но уже не с просто «не работает», а со структурированной диагностикой.
Простые действия по отдельности, но в комплексе уже диагностика проблемы на техническом уровне. Именно здесь закладывается умение видеть систему за симптомами.
База знаний как главный союзник на L1
Ты живёшь по ней. Каждый новый баг, каждое нестандартное решение документируется и складывается в структурированные статьи. Когда приходит похожая проблема, не изобретаешь велосипед заново, просто открываешь базу, находишь инструкцию и применяешь её. На этом фундаменте держится вся первая линия, без неё ты бы каждый раз начинал с нуля. Как говорится, кто владеет информацией, тот владеет миром. Или хотя бы тикетами.
Но инструкции не всегда успевают за реальностью, как раз на L2 ты сталкиваешься с этим лицом к лицу.
Эпизод второй. Путь выше или как происходит переход с L1 на L2
После нескольких месяцев на первой линии я начал замечать определённый паттерн. Одни и те же проблемы повторяются, эскалации становятся предсказуемыми, а работа превращается в рутину. Тогда я задумался о следующем шаге. У нас есть специальный внутренний сервис ротации, где публикуются открытые вакансии. Это не секретный список для избранных, а доступный всем сотрудник��м инструмент. Если увидел интересную позицию, можно подать заявку. Когда на L2 по поддержке внутренних сервисов открылась вакансия, я заполнил заявку и прошёл сначала с HR собеседование, а затем техническое интервью.
Что помогло мне перейти на L2
Вовлечённость в сложные кейсы на L1.
Я не просто закрывал тикеты по инструкциям. Когда встречался нестандартный кейс, пытался каждый раз разобраться глубже. Читал логи, искал связанные проблемы, проверял гипотезы, даже если эскалировал задачу, приходил всегда с готовой аналитикой.
Самообучение на реальных задачах.
Параллельно с основной работой начал осваивать SQL. Сначала базовые SELECT-запросы, потом JOIN'ы и фильтрацию через WHERE. Когда руководитель просил помочь с простыми отчётами, я сразу брался. Также разбирался с API через Postman, читал документацию к сервисам. Хотелось понимать, как всё устроено под капотом.
Обратная связь как инструмент роста.
Пару раз в месяц проводились 1-1 встречи с тимлидом. Я открыто говорил, что хочу на L2, и мы вместе составили дорожную карту перехода, какие навыки подтянуть и какие проекты взять.
Культура роста в компании.
В Ozon переход с L1 на L2 нормальная практика. Формула здесь простая, показываешь результат, берёшь на себя ответственность, развиваешься и получаешь возможности роста.
Эпизод третий. Вторая линия про анализ, системность и многозадачность
Переход на L2 кардинально изменил характер работы. Если на первой линии я имел дело с потоком однотипных тикетов, то здесь объём рутинных обращений сократился, но взамен появилось множество внутренних чатов с командами разработчиков и коллегами-специалистами L2.
В начале было непросто переключаться между тредами. Получается, один чат — про баг в сервисе оформления, второй — про проблему интеграции, третий — про датафикс. Большую поддержку оказал бадди, да и вся команда помогала разобраться в нюансах.
Именно тогда я осознал ключевое отличие L2 от L1, здесь воронка поступления заявок становится многомерной. Если на первой линии путь был линейным, то здесь ты управляешь уже тремя параллельными потоками.
Поток 1: эскалация с L1.Получаешь заявку с первичной диагностикой и логами. Копаешь глубже, проверяешь интеграции, очереди обработки и ищешь ошибки на уровне бэкенда.
Поток 2: критичные проблемы напрямую с L1.Случаи, где первая линия сразу понимает свои ограничения. Например, массовая проблема с доступом к порталу. L1 фиксирует паттерн и сразу передаёт тебе.
Поток 3: внутренние пользователи.Обращение приходит через внутренний мессенджер напрямую, например: «Не могу зайти в портал», «Не вижу кандидатов в системе подбора». Начинаешь с нуля, но можешь сразу связаться с человеком и выяснить детали.
Многопоточность требует многозадачности. Бывает, что пока анализируешь логи по внешнему тикету, пишет коллега из бухгалтерии, а через пять минут L1 эскалирует массовую проблему или же приходит запрос от разработки на корректировку данных. Приоритизация и переключение между разными контекстами, суть будней L2.
Что мы поддерживаем и чем занимаемся на L2
На L2 мы поддерживаем внутренние сервисы по ключевым направлениям: управление персоналом, подбор персонала, корпоративный портал, T&D (обучение и развитие).
Обязанности стали серьёзнее:
анализ системных логов для выявления аномалий;
проверка и обработка данных с помощью SQL‑запросов;
поиск первопричины сбоев (root cause analysis);
подготовка технических заданий и баг‑репортов для разработчиков;
ручная корректировка данных (datafix);
координация с командами разработки и продуктами.
Инструменты:
API-тестеры (Postman, Insomnia);
системы логирования (Trace, Logging);
Python для автоматизации;
Grafana для мониторинга;
ServiceDesk;
база знаний.
Реальный кейс на L2, когда нет инструкции
Никакой инструкции, нет готового решения. После массовой загрузки кандидатов через Excel-шаблон выяснилось, что у всех некорректно подтянулся объект найма и вместо разных объектов все привязаны к одному. От правильного объекта зависит маршрутизация звонков, распределение нагрузки между рекрутерами и корректность отчётности.
Мои действия:
Проанализировал логи и сделал выборку из базы данных за день загрузки;
Сопоставил данные из CRM с исходным файлом;
Написал Python-скрипт, генерирующий SQL-запросы для массового обновления;
Сделал бэкап затронутых записей (на всякий случай, знаете ли);
Согласовал скрипт с разработкой;
Выполнил датафикс.
Результат: все кандидаты восстановлены с корректными объектами. Рекрутмент продолжил работу без потерь.
Этот пример демонстрирует ключевой принцип на L2, когда переходишь от исполнения инструкций к анализу данных и разработке решений.
Эпизод четвёртый. Как мы держим процессы «в тонусе»
На второй линии работа строится не только вокруг решения конкретных проблем. Здесь важно видеть систему целиком, знать, какие процессы работают хорошо, какие буксуют и что нужно исправить до масштабного инцидента.
Проблем-менеджмент или приоритизация задач
Работа на L2 учит расставлять приоритеты, ведь не все проблемы требуют одинакового внимания. Здесь в игру вступает проблем-менеджмент (problem management) — это построение процесса с целью минимизации типовых повторяющихся проблем. Суть показать разработке, какие задачи критичны через конкретные цифры. Когда одна и та же проблема генерирует десятки обращений, ты не можешь просто закрыть их, нужно создать задачу для разработки и линкуешь к ней все связанные обращения. Например, если задача собирает 10, 20, 30 линков она вырывается в топ на дашборде, то становится заметной и попадает под обсуждение на регулярных синках с разработкой.
Один из ключевых моментов нужно постоянно следить, чтобы задача не закрывалась до полного решения. После закрытия задачи бот отправляет уведомления, чтобы мы проверили, действительно ли проблема решена.
Мы сами анализируем процессы и предлагаем доработки. Видишь, что поддержке приходится регулярно делать датафиксы вручную? Можно автоматизировать. Замечаешь, что кейс не покрыт бизнес-логикой? Можно предложить системное решение.
Автоматизация рутины
Мы внедрили несколько ботов, которые существенно упростили работу.
Бот актуальности базы знаний — раз в неделю присылает статьи, где не вносились изменения более трёх месяцев и тегает редактора. Проверяешь актуальность, обновляешь или архивируешь. База знаний снова стала живой, а не кладбищем устаревших инструкций.
Бот для создания задач — создаёт задачи прямо из мессенджера. Отправляешь команду, описываешь проблему, и задача создаётся автоматически со ссылкой на обсуждение. Не нужно прыгать между системами.
Бот упоминаний — отслеживает, где обсуждают твои задачи и фиксирует это в комментариях. Можно увидеть полную картину, где была переписка, кто давал обратную связь.
Метрики оценки: как измерить работу там, где нет стандарта
На L1 оценка прямолинейна, это время реакции, время решения, количество решённых заявок. На L2 сложнее, потому что заявки разного характера и уровня сложности. Одна решается за полчаса, другая требует нескольких дней координации.
Мы внедрили систему меток сложности при закрытии: standard, medium, hard. Это помогает видеть не только количество решённых задач, но и их вес. Ещё одна уникальная метрика — сервис благодарностей. Когда помогаешь коллеге в чате, он может поставить специальную реакцию под сообщением.
На L2 важны не скоростные показатели, а реальная эффективность работы, которая выражается в сокращении простоев, оперативных временных решениях и постоянной коммуникации.
Эпизод пятый. Адаптация или как не утонуть в новой роли
Первый месяц на L2 был для меня испытанием. Сервисов много, кейсы сложные, темп не снижается. Стресс, путался в командах, боялся допустить ошибку. Думал: «Может, я переоценил свои силы?»
Со временем всё встало на свои места. Вот что реально помогло.
1. Практика как путь к пониманию
Сервисов действительно много, у каждого своя логика. Быстро освоить всё не получится. Но каждый новый кейс даёт опыт в копилку. Постепенно начинаешь видеть паттерны. Как пример, понимаешь, что проблема с авторизацией чаще всего в кэше или некорректных данных. Что ошибки при загрузке связаны с форматом файла или дублями в БД. Эти знания приходят только с практикой.
Как говорится, теория без практики мертва, практика без теории слепа. Держим баланс!
2. Навык искать и правильно спрашивать
Прежде чем звать старших коллег, собери данные, опиши гипотезу. Покажи, что уже проверил.
Если эскалируешь проблему выше, пусть это будет не «я не знаю, что делать», а «я проверил А, Б и В, вот логи, вот ошибка, предполагаю, что дело в Х — подскажите, как копать дальше?»
Разница огромная. В первом случае перекладываешь работу. Во втором уже сделал половину пути, и коллега просто направляет.
3. Базовые, но критичные инструменты
SQL (SELECT, JOIN, WHERE) — чтобы осознанно искать данные, а не тыкать наугад.
API и Postman — чтобы понимать, какие запросы уходят и что возвращается.
Python — для автоматизации рутины.
Основы архитектуры — общее понимание микросервисов, очередей, интеграций (не на уровне разработчика, но чтобы видеть связи)
4. Коммуникация
Научись различать, кому и зачем пишешь. Продуктам важно знать, как ошибка влияет на пользователей, а разработчикам какие логи и API падают. Лишние теги, лишние люди в обсуждениях могут вызвать информационный шум.
Когда пишешь в чат разработки, будь конкретен. Не «что-то не работает», а «при вызове API создания пользователя возвращается ошибка 500, в логах вижу NullPointerException, воспроизводится стабильно на тестовом окружении, вот трейс». Такое сообщение экономит время всем.
Эпилог. Что поменялось во мне за год
Я перестал бояться сложных задач, начал думать гипотезами, а не инструкциями. Научился видеть взаимосвязи сервисов и понимать, как данные движутся по системе и получил реальную экспертизу по нескольким внутренним сервисам.
Вместо вывода
Если работаешь на L1, значит, ты уже внутри IT, и это возможность погрузиться глубже в архитектуру и разработку. L2 это переход от поверхностного понимания к системному. Да, сложнее. Да, больше ответственности. Но именно здесь начинается реальное понимание продукта.
Дальше выбор за тобой: разработка, аналитика, продукт, процессы. Путь не быстрый и не идеальный, но абсолютно реальный.
И да, пусть логи всегда будут говорящими, а ошибки легко воспроизводимыми 🙂
