Мы отказались от формального деления команды на L1, L2 и L3. Разрешили инженерам брать задачи независимо от грейда. Не паникуем, если SLA горит красным. И знаете что? Это работает.
У нас в К2Тех есть собственный Центр экспертизы по комплексному сервису, который объединяет все направления техподдержки. От инженерных систем до инфраструктуры и ПО. Ну и конечно же, поддержку ИБ. Меня зовут Олег Лунгу, я руководитель группы инженеров технической поддержки К2 Кибербезопасность (входит в К2Тех). Сегодня расскажу, как вырастил команду с нуля до 30+ спецов, эффективно решающих задачи, которые мучают клиентов месяцами.
От хаоса к системе
Довольно долго наше ИБ-подразделение работало по схеме: внедрили, подписали акты, забыли. Но бизнес рос, и все чаще стали появляться договоры на сопровождение, постгарантийное обслуживание, консультации. Пока их было немного, запрос клиента подхватывал инженер, который когда-то вел проект. Но все понимали, что такая конфигурация неэффективна.
Судите сами: вот условный Вова закрыл многомесячный проект. Он внедрил многоуровневую защиту периметра для крупного клиента, а сегодня звонит клиент из «Рога и копыта», где полгода назад Вова настраивал VPN-шлюз. Там что-то случилось, и все упало. Вова мысленно уже чертил схемы для нового проекта, а теперь погружается в другую проблему, пытается вспомнить нюансы инфраструктуры. А пока он разбирается с VPN, вдобавок прилетает тикет от третьего клиента: вопрос по сертификатам на веб-сервере.
На этом примере хорошо видно одно противоречие. Проектный инженер — марафонец. Он погружается в задачу на недели и месяцы, держит в голове всю архитектуру, планирует наперед. Выдернуть его на срочный тикет как заставить архитектора бежать чинить трубу в хрущевке. Он все починит, но потом потратит часы, чтобы заново погрузиться в контекст и вернуться к проекту. А в конфиге, например, появится неоптимальный маршрут, который вылезет через год, когда система будет под нагрузкой.
Сервисный инженер — спринтер. Его работа похожа на серию коротких интенсивных забегов. Он быстро погружается в проблему, локализует неисправность и выдает решение. Для него важны широта кругозора и насмотренность. Когда человек пытается быть и марафонцем, и спринтером, он не может стать олимпийцем.
Мы не хотели сжигать наших специалистов, так что нужно было срочно что-то менять. Плана у нас не было. Была растущая боль и понимание, что нужен отдельный контур для сервисных задач. Его построение и стало моей главной целью, когда я пришел в направление.
От идеи к первому тикету
Руководство поставило задачу разобраться с сервисными запросами, которые падали на команду внедрения без разбора. Первые недели все новые заявки стекались ко мне. Раньше их хаотично перебрасывали между инженерами, теперь появилась роль диспетчера. Если я понимал в продукте, то решал проблему сам, если нет — передавал задачу внедренцам.
Это работало, пока количество запросов не превысило пропускную способность одного человека. А это случилось быстро. Стало очевидно: без систематизации мы утонем.
Полноценный запуск техподдержки
Через три месяца мы запустили полноценный сервис. На деле это означало три простые базовые вещи.
Развернули Service Desk.
Сделали обычный проект в Jira, но это была основа для новых процессов. Каждая проблема получала номер, статус, ответственного. Мы впервые увидели весь объем задач и смогли честно ответить: сколько у нас вообще работы?
Написали минимальный регламент.
Мы прописали базовые правила: время реакции на заявку в зависимости от приоритета, каналы коммуникации с клиентом, жизненный цикл тикета. Пара страниц текста дала клиентам понимание, чего ждать.
Выделили каналы коммуникации.
Завели специальный почтовый ящик с интеграцией в Jira. Никаких писем на личную почту инженерам, никаких вопросов в телеграмв 11 вечера. Есть официальный канал — есть реакция.
Вот и весь запуск: Jira, почтовый ящик и два листа правил. На тот момент команда состояла из меня и двух только что нанятых младших инженеров, которых еще нужно было всему научить. Получилась крошечная пожарная станция из подручных материалов, но с адресом и четким пониманием, что делать по звонку. На время это стабилизировало ситуацию.
Кадровый вопрос
Когда у тебя команда из трех человек, а задач становится все больше, очень хочется нанять готовых сеньоров. Открыть вакансию, предложить хорошие деньги и переманить опытного специалиста, которого можно сразу пустить в работу. Это кажется быстрым решением, но только на первый взгляд.
Во-первых, рынок. Спрос на ИБ-специалистов превышает предложение. Поиск займет месяцы, придется торговаться за каждого кандидата. И даже если переманите специалиста деньгами, он так же легко уйдет к тому, кто предложит больше.
Во-вторых, иллюзия готовности. Наш портфель — десятки продуктов от разных производителей. Найти эксперта во всем этом стеке невозможно. Гений по Cisco окажется новичком в UserGate, мастер Check Point не трогал решения от Positive Technologies. Любому придется учиться, время на адаптацию все равно потребуется.
В-третьих, культурная совместимость. Опытный специалист приходит со своими привычками и убеждениями. Он может быть блестящим технарем, но токсичным индивидуалистом. Может считать рутинные задачи недостойными своего внимания или не быть готовым к партнерскому общению с клиентом. Переучивать такого человека даже сложнее, чем учить с нуля, поэтому мы очень тщательно подбираем будущих коллег.
Альтернативная стратегия
Мы решили не покупать готовую экспертизу, а сконструировать среду для ее развития. Сделали ставку на студентов старших курсов и недавних выпускников и вместо опыта работы стали искать потенциал. Искали тех, кто дома разворачивал виртуальные стенды, кто ковырял Kali Linux из интереса, а не по заданию. Тех, кто мог объяснить, как работает тройное рукопожатие TCP, и не боялся задавать вопросы.
Чтобы набрать в отдел недостающих сотрудников, мы запустили стажерскую программу. В ней студенты работали в группах по три человека, а мы наблюдали, как они ведут себя в команде. Технические знания мы можем дать, а вот софт-скилы развивать гораздо сложнее.
Инженерный инкубатор
Конечно, получилось не сразу, но со временем мы выстроили стройную систему, которая превращ��ет студента в инженера.
Диагностика
Новый сотрудник проходит глубокое анкетирование по четырем доменам: Windows, Linux, сетевые службы и технологии. Получается подробная карта его текущих компетенций, благодаря которой мы видим, где прочные знания, а где пробелы, и можем точечно их восполнить.
Онбординг
Классический онбординг в техподдержке — это многостраничные регламенты. Мы решили эту проблему иначе: превратили 70 страниц правил в 40-минутную игру в стиле комикса. Новичок выбирает персонажа, общается с виртуальным тимлидом, ищет «золотые правила» техподдержки в интерьере офиса, а в финале проходит боевое крещение — ведет диалог с «заказчиком», который оценивает тон, грамотность и умение решать проблемы. Про разработку этого квеста мы недавно написали отдельную статью.
Наставник
К реальным задачам стажер подключается уже через месяц, правда под присмотром наставника из числа опытных инженеров. Старший специалист нужен, чтобы подстраховать от ошибок, служить живой базой знаний и на примере показывать «как у нас принято» работать. Это ускоряет адаптацию и снижает стресс у новых сотрудников, ведь они понимают, что не останутся один на один с непонятной проблемой.
Ассесмент
Ассесмент — не отдельный этап, а скорее органичная часть адаптации: диагностируем пробелы в знаниях, закрываем их вместе с наставником, проверяем фундамент. На все это уходит месяц-полтора.
Когда стажер изучил тему, он подтверждает знания. Экзамен принимает команда техлидов, а не наставник, чтобы избежать субъективности. По форме это просто беседа, в которой эксперты проверяют глубину понимания стажера. Пройдя ассесмент, стажер получает уверенность в своих силах.
Настоящие задачи
Стажер продолжает обучение и через месяц-другой набивает руку, привыкает к интерфейсам, учится общаться с клиентами. Наставник никуда не исчезает: он остается на всю стажировку, просто постепенно доверяет больше ответственности и ослабляет контроль.
Сложность задач постепенно растет, и уже через несколько месяцев человек работает самостоятельно. А за год-полтора вырастает до крепкого мидла: сам разбирается в нестандартных ситуациях, предлагает решения и помогает новичкам.
Оно того стоит
Этот путь требует времени и сил от старших инженеров, но инвестиции окупаются. На выходе получается специалист, который вырос в нашей культуре, понимает ценности и говорит с нами на одном языке.
Такая система циклична: старшие инженеры, обучая младших, сами систематизируют знания и растут как наставники. Вчерашние стажеры в свою очередь становятся наставниками для нового поколения.
Эта схема набора новых сотрудников стала нашим самым ценным активом, который невозможно купить ни за какие деньги. Она помогла в моменте развернуть новое направление работы и оперативно нарастить команду.
Карта роста и мониторинг
Итак, вчерашний стажер превратился в уверенного инженера. Он закрывает тикеты, клиенты им довольны, он приносит пользу. Что дальше?
Можно раз в год проводить аттестацию и формальный пересмотр зарплаты, но это не дает ясных профессиональных перспектив. В результате инженер, в обучение которого вложили массу сил, со временем может начать искать новое место.
Мы понимали, что наш «инкубатор» не заработает без осмысленного продолжения. Поэтому создали систему, которая отвечает на вопрос: «Что нужно сделать, чтобы стать круче и ценнее?» Она состоит из двух элементов: карты роста и мониторинга.
Карта роста
Это документ, доступный каждому сотруднику. Он отвечает на вопрос: «Что значит быть инженером нашего направления?» В карте описана идеология каждого грейда: младший инженер — надежный исполнитель, старший — наставник и эксперт, способный решать нетривиальные задачи, ведущий — лидер, который может взять на себя техническое руководство целым проектом. Там же пул технических компетенций и продуктов, софт-скилы.
Мы специально встроили софт-скилы в требования для роста. Нельзя стать старшим инженером без умения проводить обучение или публичных выступлений. Невозможно стать ведущим без навыка декомпозиции задач и лидерства в проектах. Мы прямо говорим: твой рост — это не только знания, но и взаимодействие с командой.
Инженеры получили ориентир. Любой может открыть карту, понять, где он сейчас и куда двигаться дальше. Это устраняет главный демотивирующий фактор — неизвестность. Можно посмотреть, какие навыки нужны для перехода в другой отдел или смежное направление. Например, хочешь из поддержки в интеграцию — открываешь карту и видишь, чему учиться.
Мониторинг
Карта статична, но путь у каждого свой. Дважды в год мы проводим мониторинг — глубокую беседу инженера с руководителем. У нее есть одно ключевое правило: цель ставит сотрудник, а не руководитель.
Я не могу прийти к инженеру и сказать: «Твоя цель на этот год — стать старшим», это так не работает. Я могу поставить задачу, но цель он должен выбрать сам. Задача — это что нужно сделать. Цель — то, чего хочет достичь сам сотрудник.
Диалог выглядит так. Инженер: «Хочу через год стать старшим». Мы открываем карту роста, смотрим на его позицию и требования для старшего, прокладываем маршрут. Видим: по техническим знаниям почти все есть, но нет опыта выступлений и наставничества. Его трек на полгода: взять стажера в подопечные и через три месяца провести внутренний вебинар по технологии, в которой он силен.
Мы ставим конкретные измеримые задачи. Не «стать лучше в коммуникациях», а «провести два технических демо». Не «повысить экспертизу», а «самостоятельно закрыть проект к декабрю».
Этот подход строго индивидуальный. Если инженер не хочет быть руководителем, а хочет стать экспертом по продукту — его трек будет другим. Мы отправим его на продвинутые курсы, дадим сложные кейсы, поощрим написанием статей в базу знаний.
В общем, мы не пытаемся управлять карьерой сотрудников, а помогаем построить маршрут к тем целям, которые они намечают сами.
Наши принципы
Когда строите что-то с нуля, у вас есть уникальная возможность не тащить за собой груз чужих правил. Любое изменение процессов в устоявшихся направлениях упирается в стену — привычки и согласования тормозят нововведения.
У нас была чистая доска, так что мы посмотрели, как работают другие направления, взяли, что полезно, отбросили, что не подходит. Мы могли открыть учебник по ITIL и построить многоуровневую поддержку с L1, L2, L3, но вместо этого сформулировали несколько принципов, исходя из особенностей своей работы.
Отказались от деления на касты
В классической модели L1 работают по скриптам, L2 разбирают основной поток, L3 подключаются к самым сложным случаям. Звучит логично, но на практике система часто работает неоптимально.
L1-инженерам быстро становится скучно: работа монотонная, развития нет, и главной мотивацией становится побыстрее перекинуть тикет на следующую линию.
L2 тем временем тонут во всем, что не решилось по скрипту, и времени на развитие компетенций просто не остается. В итоге тикеты летают между уровнями, теряя время и контекст. Это не уникальная боль — с ней сталкивается большинство сервисных команд на рынке.
К счастью, в Центре экспертизы по комплексному сервису К2Тех мы изначально строили сервис иначе и дали командам достаточную свободу, чтобы решить эти проблемы. Здесь есть «нулевая линия» — диспетчеры, которые проводят первичную маршрутизацию обращений, отсекают спам и передают задачи профильным командам, включая ИБ. Это дало инженерам достаточно свободы, чтобы решить типичные проблемы линейной модели.
Мы заменили пирамиду на плоскую структуру — компетенционный пул.
«Нулевая линия» работает централизованно: диспетчеры определяют, к какому направлению относится обращение (вендор, продукт, область экспертизы), и передают его целевой команде. Это может быть ИБ, инфраструктура, сопровождение и так далее.
Когда задача попадает в Jira, ее видят все. Вместо жесткого деления на линии у нас единая команда инженеров с разными грейдами. Простую задачу возьмет младший специалист — это его зона роста. Сложная достанется старшему. Но младший может подключиться к сложной задаче, помочь и поучиться. При этом старший спокойно возьмет рутинную задачу, если у младших завал. Никакого «это не моя работа». Есть общая цель: решить проблему клиента.
Эта система мотивирует расти, учиться и тянуться за сложными задачами.
Красный дашборд
Третий и, возможно, главный наш принцип касается отношения к метрикам, в первую очередь к SLA (Service Level Agreement).
SLA нужно соблюдать, клиенты прежде всего. Но важно, чтобы команда не впадала в панику при виде просроченных метрик. В панелях мониторинга они подсвечиваются красным, и страх перед такими «красными дашбордами» подталкивает сотрудников к попыткам перехитрить систему: закрывать тикеты, не решив проблему до конца, выбирать не лучшее решение, а самое быстрое, скрывать сложности от руководства. Так метрика из инструмента превращается в самоцель.
Для нас просроченный SLA и проблема, и интересная головоломка, и точка роста — ведь, по сути, он значит, что процесс где-то сломался.
Регулярно разбираем каждый случай нарушения SLA с точки зрения того, почему система дала сбой. Может, задача неверно оценена? Инженеру не хватило компетенций? Столкнулись с новым багом? Инженер перегружен? По итогу меняем систему: дорабатываем инструкции, проводим обучение, меняем процесс оценки, перераспределяем нагрузку.
Такой подход создает атмосферу психологической безопасности. Люди не боятся допустить ошибку и признаться, что чего-то не знают. Ведь рассказав о проблеме, они получат не наказание, а помощь в ее решении.
Кстати, именно об этом — как построить системную работу с инцидентами в масштабах всего комплексного сервиса — мы будем подробно говорить на Демодне «Сервис-партнер: дирижер стабильной инфраструктуры» 2 апреля. Заодно покажем наш склад ЗИП на 62+ тыс. деталей и инженерные лаборатории.
Но настоящая проверка принципов и сработанности команды происходит, когда простого ответа на задачу нет. Тогда культура определяет поведение команды: вместо того чтобы списать проблему на вендора и закрыть тикет, инженеры копают до конца. И вот вам пример.
История одного упрямого Check Point
Крупная компания со сложной инфраструктурой, кластер мощных шлюзов и сертифицированная ФСТЭК версия Check Point R77.30. Сертификация прибивает к конкретной устаревшей версии — обновиться нельзя.
Загадочные лаги
Большую часть времени все работало, но периодически без видимой причины кластер начинал сбоить, и бизнес-процессы вставали на 10–20 минут. Это выглядело как нехватка производительности, но железо было самым мощным в линейке.
Первичный анализ ничего не дал. Проверили конфигурацию, правила, сетевые настройки — все в порядке. Включили мониторинг. При следующем приступе увидели, как периодически при незначительном превышении объема трафика процессор упирается в 100%.
Вендор рекомендует
Мы эскалировали проблему вендору и отправили тонны логов и дампов. Инженеры Check Point посмотрели на R77.30 и сказали: «В этой версии известны проблемы с производительностью. Рекомендуем обновиться», но у нас-то сертификация ФСТЭК. Так что пришлось лезть под капот.
Погружение в ядро
В Check Point есть механизм распределения нагрузки — SecureXL. Он направляет сетевые пакеты по разным ядрам процессора. Мы предположили, что он отправляет весь трафик в одно ядро. Сперва прошлись по рекомендациям вендора — увеличили количество firewall-инстансов, настроили multi-queue, поменяли количество очередей на интерфейсах, привязали SND к конкретным процессорным ядрам.
Тут же наткнулись на первые грабли. В вендорской документации упоминается до 16 очередей на каждом ixgbe-интерфейсе (количество зависит от числа интерфейсов), но на практике получилось увеличить только до 14. При 15 и выше кластер отказывался собираться. Наш шлюз был 48-ядерным, но в сертифицированной версии действовало ограничение на 32 firewall-воркера максимум. Оставшись без выбора, остальные ядра мы распределяли на обработку трафика с интерфейсов и внутренних процессов.
Результат был, но проблема до конца не решилась — инфраструктура все равно иногда падала. Мы были на верном пути, но упускали что-то важное.
В конце концов включили дебаг ядра, чтобы напрямую в реальном времени наблюдать, как распределяется нагрузка.
Призрак в машине
Сразу после применения наших настроек мы видели корректное распределение firewall-инстансов по ядрам. Однако картина менялась после их распределения по ядрам процессора. Часть инстансов получали по одному ядру, а другие делили одно ядро на двоих.
Выглядело это примерно так: cpu0 — fw_worker0, cpu1 — fw_worker1, а вот на cpu2 теснятся fw_worker2 и fw_worker3, на cpu3 — fw_worker4 и fw_worker5. И так далее. Были ядра, на которые не удавалось сделать четкий affinity. 1 ядро — 1 процесс fw worker. Они просто занимались всеми процессами.
Из-за этого дисбаланса часть ядер оставалась без выделенных задач, а другие, напротив, были перегружены. Пришлось копать дальше.
Сразу после применения наших настроек мы видели корректное распределение fw-worker по ядрам. Однако при проверке этого распределения через пару десятков секунд после применения скрипта мы видели уже другую картину. Часть инстансов получали по одному процессорному ядру, а другие делили одно ядро на двоих. Это заметно снижало производительность, в то время как мы старались выжать из шлюза максимум производительности.
В итоге выяснилось, что в коде системного скрипта были строчки, которые применялись уже после обращения к нашему файлу конфигурации:
Откуда взялась такая закладка — неизвестно, но именно это жесткая привязка мешала корректному распределению fw_workers по ядрам.
Решение
Эти поиски растянулись на несколько месяцев. Работать можно было только ночами и в выходные, причем удаленно через ВКС (видеоконференцсвязь). А любой дебаг и отладка сами по себе очень сильно нагружали Check Point, так что система регулярно падала прямо в процессе. Мы аккуратно отредактировали скрипт, сохранили, перезагрузили, и все заработало. Проблема, которая мучила клиента месяцами, решилась правкой нескольких строчек в системном скрипте.
Заключение
Сегодня в портфеле нашей команды из 30+ специалистов, 34 класса СЗИ, более 100 продуктов и более 100 заказчиков.
Чтобы вырастить эту команду, мы нарушили каноны ITIL, отказались от многоуровневой структуры и жесткой иерархии. Вместо готовых сеньоров взяли студентов. Построили систему, где младший инженер может взять сложную задачу, а старший — рутинную. Но это наш опыт, а что из него можно применить у себя?
На самом деле не обязательно копировать нашу модель целиком. Возьмите то, что резонирует с вашими задачами:
Если у вас проектные инженеры тонут в сервисных запросах, создайте отдельный контур, чтобы разделить марафонцев и спринтеров.
Если не можете найти готовых специалистов — попробуйте вырастить своих. Стажерская программа требует ресурсов, но дает лояльную команду с нужной культурой.
Если линейная модель L1 — L2 — L3 не работает, то попробуйте заменить ее компетенционным пулом. Дайте людям брать задачи по силам, а не по формальному грейду.
Если команда боится ошибок, стоит пересмотреть отношение к метрикам. SLA важен, но страх перед ним убивает инициативу.
Главное, помните, что процессы — это инструмент, а не догма. Когда строите что-то с нуля, у вас есть редкая возможность сделать не «как принято», а «как правильно для нас». Изучайте фреймворки и лучшие практики, берите то, что работает, и безжалостно отбрасывайте то, что мешает.
