С нуля без шаблонов: как мы построили техподдержку "против правил"
Мы сознательно не разделили инженеров на привычные уровни L1, L2 и L3. Не стали жестко привязывать людей к грейдам и не ввели правило "простые тикеты - младшим, сложные - только старшим". Любой инженер может взять любую задачу, если чувствует в себе силы. Мы не устраиваем истерику, когда SLA загорается красным, и не превращаем дашборды в инструмент давления. При этом техподдержка работает, растет и закрывает инциденты, которые до этого тянулись у клиентов месяцами.
У нас в К2Тех сформирован собственный Центр экспертизы по комплексному сервису. Он объединяет все направления технической поддержки: инженерные системы, ИТ‑инфраструктуру, программное обеспечение и, конечно, информационную безопасность.
Я - Олег Лунгу, руковожу группой инженерной поддержки в направлении кибербезопасности. За несколько лет мы прошли путь от хаотичного реагирования "по звонку знакомому инженеру" до стройной команды из более чем тридцати специалистов, которая берет на себя весь контур сервисных задач по ИБ‑решениям. Ниже - как это получилось, что пришлось сломать и почему мы пошли против канонов классического ITIL‑подхода.
От проектного хаоса к отдельному сервисному контуру
Долгое время наше подразделение по информационной безопасности жило по типичному для интегратора сценарию: внедрили продукт, подписали акты, передали документацию - и переключились на следующий проект. Постгарантийное обслуживание и консультации появлялись эпизодически: иногда клиент звонил "своему" инженеру, иногда менеджеру.
Пока таких обращений было немного, вопросы разбирал тот, кто когда‑то вел проект. Вроде бы логично: кто настраивал систему, тот и помнит, как она устроена. Но с ростом бизнеса, появлением регулярных договоров сопровождения и SLA это начало стремительно разваливаться.
Типичная картина. Есть специалист Вова. Он только что закрыл большой проект по построению многоуровневой системы защиты периметра для крупного заказчика. В голове у него - сложная архитектура, планы развития, список рисков, дорожная карта оптимизаций. И вот ему звонит другой клиент, для которого полгода назад он настраивал VPN‑шлюз. Там все встало колом, бизнес простаивает, нужно срочно разбираться.
Вова выдергивается из текущего проекта, пытается вспомнить контур старой инфраструктуры, поднимает переписку, лезет в архивные схемы. Пока он разбирается с VPN, прилетает еще один запрос - уже по сертификатам на веб‑сервере у третьего клиента. В итоге он одновременно жонглирует тремя задачами, постоянно рвет фокус и вынужден снова и снова "перезагружать" контекст.
В чем конфликт ролей
Проектный инженер - это марафонец. Он идет длинной дистанцией: неделями и месяцами живет внутри одной системы, продумывает архитектуру, выстраивает последовательность работ, планирует изменения так, чтобы они не убивали бизнес. Ему важна глубина, предсказуемость и устойчивое внимание.
Сервисный инженер - спринтер. Его мир - это череда коротких, но интенсивных забегов. Быстрое погружение в чужую инфраструктуру, диагностика, локализация причины, конкретное решение и переход к следующему инциденту. Здесь критичны широта кругозора, скорость реакции, способность держать в голове десятки разных технологий и сценариев.
Попытка совместить в одном человеке и марафонца, и спринтера приводит к выгоранию и посредственному результату на обоих направлениях. Специалист не успевает глубоко погружаться в проекты и одновременно не выстраивает устойчивую насмотренность в типовых инцидентах.
Мы не хотели сжигать людей. Стало понятно, что нужен отдельный сервисный контур, а не "вечная подработка" проектной команды. На момент, когда я пришел в направление, запроса "сделайте полноценную техподдержку" как формализованного проекта не существовало. Была растущая боль, пачка неструктурированных обращений и общее понимание: если ничего не менять, мы захлебнемся.
Как появился первый "скелет" сервиса
Руководство обозначило задачу предельно просто: навести порядок с сервисными запросами, которые без разбора падали на команду внедрения. Первые недели все новые обращения замыкались на мне.
Раньше запросы хаотично бросали между инженерами: "кто свободен - посмотрите". Теперь появился хотя бы один центр, где все консолидировалось. По сути, это была роль диспетчера: если я хорошо знаю конкретный продукт, беру задачу в работу сам; если нет - адресно передаю специалисту внедрения, который ближе всех к теме.
Такой ручной режим продержался недолго. Поток заявок рос быстрее, чем я мог их разгрести. В какой‑то момент стало очевидно: без формализации процессов, инструментов и хотя бы минимальных правил мы просто рухнем под объемом.
Через три месяца мы вывели сервис на первый осмысленный уровень. Формально это выглядело скромно, но по сути стало переломным моментом.
Три базовых шага запуска
1. Service Desk на базе Jira
Мы создали отдельный проект в Jira и превратили его в точку входа для всех инцидентов. Каждое обращение получало уникальный номер, приоритет, статус и ответственного.
Это сразу дало несколько эффектов:
- стало видно, сколько задач реально обрабатывает команда,
- можно было посчитать нагрузку и распределить ее,
- пропала анонимность: у каждой заявки появился "хозяин", которого нельзя просто "потерять в переписке".
2. Минимальный регламент вместо толстого "тома процессов"
Мы не писали монструозный регламент на десятки страниц. На старте хватило краткого документа, где были зафиксированы:
- базовые приоритеты инцидентов;
- целевое время реакции для каждого приоритета;
- каналы, через которые клиент может обратиться;
- жизненный цикл тикета: от регистрации до закрытия.
Пара страниц текста сняла тонну вопросов: клиенту стало ясно, чего он может ожидать, а инженерам - как действовать в нестандартной ситуации.
3. Официальные каналы коммуникаций
Мы завели отдельный почтовый ящик, связанный с Jira. Письмо клиентом - сразу заявка в системе. Никаких обращений в личные мессенджеры, звонков "в обход", сообщений в неформальных чатах в 11 вечера "ты же делал нам когда‑то firewall, посмотри срочно".
Есть единый канал - есть гарантированная реакция и прозрачная история. Нет канала - нет и обязательств. Это дисциплинирует обе стороны.
В итоге наш "первый сервис" выглядел максимально просто: Jira, почтовый ящик и два листа регламента. На тот момент в команде были я и двое только что нанятых младших инженеров, которых еще предстояло научить практически всему.
Фактически мы построили крошечную пожарную часть: минимум ресурсов, но понятный адрес, на который можно звонить, и четкое понимание, кто бежит на вызов. Это позволило на время стабилизировать обстановку и перестать жить в режиме бесконечного пожара.
Кадровый вопрос: кого брать в такую техподдержку
Когда у тебя всего три человека, главный риск - вырасти не вширь, а в хаос. Первые наймы определяют культуру надолго. Мы почти сразу поняли, что просто "добирать готовых звезд с рынка" вряд ли получится:
- опытные инженеры по ИБ и сложной инфраструктуре стоят дорого;
- у многих очень сильна привычка работать по классической модели с разделением уровней поддержки;
- мы хотели вырастить людей под нашу философию, а не постоянно ломать старые паттерны.
Так сформировалась альтернативная кадровая стратегия: не пытаться купить идеальную команду "под ключ", а создать нечто вроде инженерного инкубатора.
Инженерный инкубатор: как мы выращиваем специалистов
Вместо того чтобы искать только готовых сеньоров, мы сделали ставку на умных, мотивированных новичков с базовой технической подготовкой, которые готовы быстро учиться и не боятся разнообразия задач.
Система их роста строится вокруг нескольких элементов.
Диагностика на входе
Мы смотрим не только на формальные знания, но и на то, как человек мыслит:
- умеет ли раскладывать проблему на части;
- задает ли уточняющие вопросы;
- способен ли честно признать, что чего‑то не знает, и предложить, как будет искать ответ.
Онбординг по живым кейсам
Мы не заваливаем новичка теорией. Вместо этого даем простые реальные тикеты под присмотром наставника. Человек сразу видит живую боль клиентов, учится задавать правильные вопросы и фиксировать решения так, чтобы ими могли пользоваться другие.
Наставник как "боевой напарник"
Каждому новичку назначается наставник из числа опытных инженеров. Его задача - не просто раздать задачи, а объяснить логику: почему мы делаем именно так, чем одно решение лучше другого, как не сломать клиенту бизнес, решая локальную проблему.
Регулярный ассесмент
Мы периодически оцениваем не только технический прогресс, но и развитие "софт"‑компетенций:
- коммуникация с клиентом;
- умение держать удар, когда все горит;
- способность признавать ошибки и извлекать из них пользу.
Работа с реальными, а не "учебными" задачами
Мы очень быстро даем новичкам шанс потрогать сложные кейсы - сначала в паре со старшим, потом самостоятельно с контролем. Это не всегда комфортно, но зато прогресс ускоряется в разы.
Карта роста и мониторинг: как не потерять людей по дороге
Чтобы развитие не превращалось в хаотичный набор "случайных задач", мы ввели карту роста. Это понятный маршрут, по которому движется инженер: от самых базовых навыков до экспертного уровня в конкретных продуктах и технологиях.
Карта роста фиксирует:
- какие технологии и продукты должен знать инженер на каждом этапе;
- какие типы инцидентов он может обрабатывать самостоятельно;
- какие зоны ответственности может на себя брать;
- какие шаги нужно сделать, чтобы перейти на следующий уровень.
Мониторинг - это не про контроль ради контроля. Мы смотрим:
- сколько и каких тикетов закрывает инженер;
- как меняется качество решений (по фидбеку и повторным обращениям);
- как он справляется со стрессом и загрузкой.
На основе этого можно вовремя подхватить человека, который начинает выгорать, перераспределить задачи или, наоборот, дать больше сложных кейсов тому, кто "созрел".
Почему мы отказались от деления на L1 / L2 / L3
Классическая модель техподдержки предполагает жесткое деление на линии:
- L1 - фильтрует обращения, снимает самые простые вопросы;
- L2 - решает более сложные проблемы;
- L3 - эксперты, к которым попадают единичные, особенно хитрые кейсы.
В теории это удобно. На практике, особенно в области ИБ и сложной инфраструктуры, это часто ведет к нескольким проблемам:
- пользователи часами "гуляют" по линиям, пересказывая один и тот же симптом;
- знания о продукте фрагментируются: первый уровень видит одно и то же, но поверхностно, третий - глубоко, но редко;
- мотивация людей на L1 падает: они годами варятся в рутине, не видят роста и уходят.
Мы решили не делить команду на "касты". В нашей модели:
- любой инженер имеет право взять сложный тикет, если чувствует, что потянет;
- право тянуть задачу вверх по уровню - не привилегия, а обязанность: если не уверен - эскалируй, но оставайся в контуре;
- нет "вечных новичков", которые годами сортируют только простые обращения.
Да, это рискованнее и требует более продуманной системы обучения и наставничества. Зато команда быстрее набирает экспертизу, люди видят, что могут расти не только по должности, но и по уровню задач, а клиенту не нужно пять раз рассказывать одну и ту же историю.
"Красный" дашборд и спокойная голова
Еще одна наша сознательная нелюбимая практика - культ зеленых дашбордов. Когда SLA загорается красным, в некоторых компаниях начинается паника: отчеты, разборы полетов, поиск виноватых.
Мы смотрим на это иначе:
- красный индикатор - это сигнал к разбору причин, а не повод для казни;
- иногда осознанное нарушение SLA - разумный выбор, если альтернативой будет поверхностное, но "быстрое" решение, которое взорвется через неделю;
- в сложных ИБ‑сценариях важнее не "реакция за 15 минут", а корректная диагностика, аккуратная работа в боевой инфраструктуре и устойчивый результат.
Это не значит, что мы игнорируем SLA. Мы их соблюдаем, но не превращаем время реакции в самоцель. Главное - реальная ценность для клиента, а не идеальный отчет.
Что дают такие принципы клиентам и бизнесу
Отказ от жесткого деления на линии, упор на рост инженеров и здоровое отношение к метрикам привели к нескольким практическим эффектам:
- сложные, застрявшие у клиентов проблемы наконец‑то начали решаться: не за счет "магии", а за счет того, что задачи сразу попадают к людям, готовым в них погружаться;
- команда стала более устойчива к нагрузке: каждый понимает, что может расти и брать новые вызовы, а не застревать в рутине;
- бизнес получил прозрачную, управляемую техподдержку, где можно посчитать нагрузку, предсказать потребность в ресурсах и честно разговаривать о приоритетах.
Да, такой подход не укладывается в классические схемы и не всегда удобен тем, кто привык работать строго по канонам ITIL. Но для нас он оказался рабочим: мы смогли вырастить с нуля живую, развивающуюся команду, которая одинаково уверенно справляется и с типовыми инцидентами, и с нетривиальными кейсами в области информационной безопасности.
И самое важное - мы построили техподдержку, которая не выгорает, не задыхается под весом формальных процессов и при этом реально помогает клиентам, а не просто "отрабатывает тикеты".
