Привет, Хабр! Меня зовут Сергей Стецюк, и в K2Тех я руковожу подразделением, которое обеспечивает бесперебойную работу вычислительной инфраструктуры для enterprise-бизнеса.

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

Давайте разберемся, как это произошло.

Вместо предисловия

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

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

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

Если бы мы знали, что это такое, но мы не знаем, что это такое

Исторически техническая поддержка не отличалась инновационным подходом, она всегда работала по принципу break&fix: что-то сломалось – надо чинить. С развитием рынка сервис-провайдеров и моделей оказания сервисных услуг стало ясно, что во многих кейсах одного ремонта недостаточно.  В таких случаях лучшее решение – это не только оперативное закрытие тикета, но и общение с ИТ-командой заказчика.  

Производители давали (а в некоторых случаях и до сих пор дают) отличную теоретическую базу и общие принципы работы оборудования, которые зафиксированы в документации. Однако как говорится – на базу надейся, а сам не плошай, ведь незадокументированных нюансов, на самом деле, туча. 

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

Получив первый запрос на проведение конкретного обучения для специалистов заказчика, мы задумались – как организовать его так, чтобы было полезно, что именно важно донести и в каком формате лучше всего это делать.  Честно, немного переживали, ведь инженер – это, в первую очередь, полевой боец, а не учитель, но только он знает все нужные инсайты. Спойлер: как оказалось, самое сложное – это не выступление, а именно подготовка.

Решили идти по принципу врачебной консультации – уточнить более конкретный запрос заказчика, и на основе «диагноза» уже думать над наполнением и подачей. И как настоящие лекари, изучали полную «историю болезни», а если быть конкретнее, искали пробелы у заказчика, на которые можно было бы опираться. 

И вот настал день Х. Мы подготовили материалы, презентацию, собрали ИТ-команду заказчика и провели первую «zoom-лекцию» и поняли – получилось! В результате общение стало еще проще: например, когда запрашиваешь у инженера на стороне клиента собрать конкретный лог, он точно понимает, о чём речь. К слову, при плановом service review (регулярные встречи с заказчиком по обсуждению хода проекта) коллеги отметили, что их команда стала увереннее и самостоятельнее благодаря нашей встрече. Со своей же стороны мы отметили, нас привлекают сильно реже, только на точечные, более сложные инциденты.

Одна ошибка и ты ошибся

Наша работа периодически привносит разные плот-твисты. Недавно вечером у одного из наших крупных заказчиков произошла проблема. Сервисы остановились, пользователи ничего не могли сделать — классический кошмар для любого администратора. Нашего инженера срочно подняли по тревоге, когда он ехал в метро после работы, и он тут же подключился к ситуации (не входящей в наш скоуп работ по договору). Выяснилось, что сбой произошел из-за ошибки в конфигурации резервирования: отказал один узел, а резервный не взял нагрузку на себя. Коллега за пару часов восстановил работоспособность — переподключил оборудование, исправил настройки отказоустойчивости, проверил, что данные целы. К ночи инфраструктура заказчика снова работала в штатном режиме.

На следующий день мы направили детальный отчет о причине сбоя и о том, как мы его устранили. Реакция нас удивила: мы получили просьбу провести для их ИТ-команды обучающую сессию. Клиент честно признался, что их инженеры растерялись в нештатной ситуации, не до конца понимали, как действовать, да и в целом хотели бы повысить свою квалификацию. Они спросили: можем ли мы обучить их правильно работать с этой инфраструктурой, чтобы в будущем самим справляться с подобными авариями?

Идея выглядела здраво. Мы понимали: проведя небольшой тренинг, мы поможем их специалистам лучше разбираться в своем оборудовании и предотвращать ошибки, а значит, в будущем подобных авралов станет меньше. Да и самим нам спокойнее, когда первая линия поддержки на стороне заказчика действует уверенно и лучше понимает, что происходит. Разумеется, никакой готовой «учебной программы» у нас не было — все делали с нуля, опираясь на свежий опыт аварии и наши внутренние наработки. Получился своего рода мастер-класс «как не “угробить” инфраструктуру за 5 минут (и что делать, если всё-таки “угробил”)».

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

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

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

Научи ученого: заменит ли сервис-провайдер вендорские курсы

Сразу хочется ответить на этот вопрос уверенным «нет» и поставить точку. Но не всё так просто. Я считаю, что часто не стоит смешивать сладкое с соленым, но мы знаем примеры, когда такие сочетания действительно могут успешно работать (вспомним солёную карамель:)).

Похожая трансформация происходит и в нашем подходе к работе. Сначала казалось, что обучение не наша задача, а какая-то отдельная, для других команд, или вообще выстрел в ногу. Мы же инженеры: настраиваем, сопровождаем, чиним, решаем сложные инциденты, это наш хлеб и граница нашей зоны ответственности. Но сервис-провайдер действительно уже становится бизнес-партнером для компаний, а не просто исполнителем. Такой подход уже широко распространён на Западе, где внешние команды берут на себя полное управление ИТ-инфраструктурой и помощь в развитии, освобождая CIO для стратегических задач. 

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

Со временем стало ясно: подобная передача знаний — это не побочная активность, а часть нормальной, партнерской работы с заказчиком и его инфраструктурой. Это не про перекладывание работы на клиента, а про осмысленную совместную работу, когда обе стороны понимают, что происходит, идет совместное движение и развитие.

Наиболее интересные кейсы мы дополнительно разбираем и на кросс-командных обучениях внутри: собираемся с инженерами и дискутируем и предлагаем альтернативы. Это помогает повышать насмотренность и усилять проактивность – когда команда, еще не столкнувшись с проблемой в реальности, уже знает, как ее можно будет не только устранить, но и не допустить. 

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

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

С течением времени мы определили для себя несколько инсайтов, которыми хочется поделиться с вами: 

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

• Усиление командного духа. Подобная практика является «отдушиной» для самих инженеров, позволяя им немного разгрузиться от рутины. Обучения помогают поддерживать вовлеченность специалистов и поддерживать их мотивацию.

• Как показал пример с одним из крупных ритейлеров, качественное обучение становится катализатором доверия. После цикла наших встреч клиент заказал дополнительный курс по смежной теме — уже у смежной сервисной команды. Коллеги отметили, что им понравилась методика: живые лабораторные работы, конкретные примеры и полное погружение в архитектуру. 

• Еще один кейс с крупным банком — отличный пример партнерской синергии. Мы поделились своими «тайными знаниями»: точечно настроили фичи и решили казалось бы мелкие, но критичные для клиента задачи. Со стороны заказчика — сняли их головную боль и автоматизировали рутину. С нашей — еще раз доказали экспертность. 

Не стоит бояться тратить трудозатраты на непрофильные задачи и тестировать новые процессы. Break&fix, SLA, поддержание работоспособности  — это основа основ, столпы, они никуда не денутся. Но мы для себя поняли, что по-настоящему крутой результат рождается, когда мы делимся с партнерами не только запчастями, временем экспертов при решении кейсов, отчетами, но и знаниями. 

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

А как считаете вы? Поделитесь в комментариях своими кейсами, когда вы выходили за «привычные» рамки в своей работе с клиентами? И как это помогло обеим сторонам?