Уход западных вендоров СХД за последние несколько лет изменил ожидания заказчиков от работы вендоров. Когда инфраструктурная совместимость компонентов ИТ-ландшафта не гарантируется «по умолчанию», качество сервисного сопровождения становится ключевым фактором выбора решений. Куда движется направление отрасли сегодня, с какой динамикой и по каким трендам происходит его развитие — рассказывает директор по сервису компании «Аэродиск» Сергей Курилкин.
Гибкость и скорость вместо формальных SLA
На «бумаге» техподдержка ИТ-оборудования выглядит просто и понятно: есть несколько уровней сервиса, регламентированные сроки реакции на обращения, набор стандартных каналов связи. Но реальность работы с заказчиком сегодня редко укладывается в рамки формальных SLA. Они нужны в основном для тендеров и официальных документов, а в живой работе хорошая техподдержка старается действовать по принципу «все клиенты — премиум».
Даже при базовом пакете обслуживания инженеры реагируют за считанные минуты. При этом внутри команды действуют еще более жесткие внутренние метрики: если внешний SLA для клиента «Премиум» подразумевает ответ в течение часа, то для инженеров этот срок сокращен до 15 минут. Не уложились — разбираем причину и улучшаем процесс.
Гибкость проявляется и в том, как выстраивается коммуникация. Формально все взаимодействие должно идти через тикет-систему или корпоративный мессенджер заказчика, но если администратору удобнее написать напрямую в Telegram — инженеры пойдут навстречу, даже понимая, что статистику в результате придется заводить вручную.
Есть и другой уровень гибкости — готовность выходить за пределы прямых обязанностей. Если у заказчика нет своей сетевой службы, инженеры СХД не остановятся на формулировке «у нас всё зеленое» в мониторинге. Они постараются найти и устранить сетевую проблему, даже если это не их зона ответственности. Если сбой вызван несовместимостью с виртуализацией или внешней системой мониторинга, техподдержка возьмет на себя и эту часть работы.
То есть задача техподдержки сегодня не в том, чтобы формально закрыть тикет в срок, а в том, чтобы снять реальную «боль» клиента. Инженеры понимают, что за их системами стоят критически важные сервисы — госорганы, больницы, ЦОДы, — и от скорости их работы зависит, получат ли люди нужные данные вовремя. В результате реальная планка участия в решении проблем всегда выше любых формальных рамок.
От гибкости до «пожарных бригад»
В российской ИТ-практике критический сбой в СХД почти никогда не бывает изолированным. Заказчик видит, что «что-то не работает», но далеко не всегда понимает, в чем причина: проблема может быть в сети, в виртуализации, в совместимости ПО или в интеграции с другими системами. Они отправляют запросы всем вендорам, имеющим отношение к их ландшафту, но многие западные поставщики уже давно на такие запросы не отвечают, поэтому даже в случае проблем с сетью или на уровне виртуализации первой отвечает техподдержка СХД — даже если она не обязана отвечать за эти зоны.
Если диагностика показывает, что причина не в хранилище, инженеры не ограничиваются формальной отпиской. Они подсказывают, где искать сбой, помогают сформулировать запрос к нужным специалистам и, при необходимости, подключаются к решению смежной задачи. Иногда это требует умения разбираться в конфигурации сетевого оборудования, иногда — в тонкостях настройки гипервизора.
Когда речь идет о действительно серьезных инцидентах, включается система эскалаций. Это не просто передача проблемы на «следующую линию». Инженеры, руководители групп и R&D подключаются параллельно, чтобы как можно быстрее локализовать и устранить проблему.
Внутри команды действует четкое правило: заказчик должен видеть, что ситуация находится под контролем, а его администраторы должны быть максимально защищены от внешнего давления. В момент кризиса техподдержка берет на себя всю коммуникацию с руководством клиента, чтобы инженер на стороне заказчика мог сосредоточиться на технических действиях, а не на объяснениях.
Иногда инцидент в глазах клиента выглядит как катастрофа, а для техподдержки — это «обычный вторник». Этот опыт дает возможность сохранять «холодную голову», поэтому первые пять минут всегда кажутся самым страшным моментом, но через час ситуация обычно уже структурирована, а через три — решается или уходит в плановые работы. При этом темп реакции не падает — чем быстрее начнется работа, тем меньше риск масштабных последствий.
Например, если отключилось электричество, а после включения часть ИТ-ресурсов компании временно недоступна, это почти всегда вводит заказчика в стресс. Он попросту не помнит, что и в какой последовательности нужно включать и запускать, чтобы все вернулось в штатный рабочий режим. В таких случаях техподдержка на связь и подробно рассказываем нужную последовательность действий.
Важна и постоянная готовность выходить за рамки привычных сценариев. Если у клиента закрытый контур и невозможно подключиться удаленно, инженеры воссоздают его конфигурацию на своих тестовых стендах, чтобы воспроизвести и отловить проблему.
Если сбой вызван вопросами совместимости редкой комбинации ПО и оборудования, техподдержка взаимодействует напрямую с разработкой, чтобы подготовить патч или доработку.
Из техподдержки — в Roadmap
В большинстве компаний продуктовый Roadmap формируется руководителями направлений и разработчиками, опираясь на стратегические планы и видение рынка. В СХД сегодня один из основных источников идей и доработок — техподдержка. Именно здесь инженеры каждый день сталкиваются с реальными сценариями использования, ограничениями интеграций и уникальными запросами, которые никогда не появятся в лабораторных условиях.
Каждый инженер ведет кейс от начала до конца, не передавая его из рук в руки. Если в процессе выясняется, что для удовлетворения дополнительных пожеланий заказчика нужна новая функция, доработка интерфейса или изменение логики работы системы, эта информация фиксируется. И не откладывается «в долгий ящик» — запросы агрегируются, структурируются и передаются в продуктовые команды.
Важный момент — приоритизация. Поток пожеланий и замечаний от клиентов велик, если передавать их в разработку в сыром виде, они просто утонут в очереди. Поэтому техподдержка выполняет роль фильтра: каждая инициатива оценивается по частоте встречаемости, влиянию на работу и затратам на реализацию. На выходе разработчики получают не просто список пожеланий, а ранжированный пакет задач, готовых к включению в план.
Принцип «слышать и делать» здесь работает буквально. Если администратор говорит: «Было бы удобно, если бы эта функция была доступна одной кнопкой», высока вероятность, что через пару релизов она действительно появится. Более того, сами инженеры поощряют заказчиков делиться идеями, объясняя, что обратная связь реально меняет продукт. Это создает у клиента ощущение участия в развитии платформы, а у вендора — конкурентное преимущество в виде решения, адаптированного под живые сценарии.
Статистика как инструмент качества
Данные для эффективной техподдержки СХД сегодня важны как полноценный инструмент управления качеством, позволяющий не только реагировать на проблемы, но и предсказывать их.
Внутри департамента поддержки у вендоров существует целая экосистема метрик. Помимо показателей SLA, это и более глубокие метрики, которые редко встретишь в открытых отчетах. Например, связанные с работой оборудования: отслеживается, какие модели дисков или контроллеров выходят из строя чаще других, на какой срок компоненты рассчитаны в реальной эксплуатации, как влияет режим работы на их ресурс.
Это позволяет прогнозировать отказы и предупреждать их заменой до сбоя. Интересно, что по накопленным данным инженеры могут сказать, какая конкретная линейка дисков от разных вендоров живет дольше, хотя на бумаге их характеристики совершенно одинаковы.
В статистику включается и логистика: время от момента запроса до установки запасной части, скорость работы партнерских служб доставки, процент «невалидного» оборудования, пришедшего на склад. Эти данные напрямую влияют на стратегию — если доставка через одного партнера идет быстрее, пусть и дороже, при критическом инциденте выбирается именно этот вариант.
Отдельный пласт метрик связан с типами заявок. Анализируется, сколько времени тратится на решения по разным направлениям — «Стандарт», «Бизнес», «Премиум», — какие задачи выполняют базовые инженеры, а какие требуют привлечения R&D. Иногда именно статистика выявляет «невидимые» проблемы. Так, заметив аномально высокое количество замен системных дисков, команда проводит расследование, находит причину в коде и меняет его, сокращая число обращений в четыре раза.
Люди и компетенции
В сфере разработки и производства СХД нет конвейера готовых специалистов. Также обстоят дела и в поддержке. Данный сегмент ИТ требует не только глубоких технических знаний, но и развитых soft skills, умения работать с клиентом под давлением и без потери качества. Добавим сюда необходимость разбираться в смежных областях — от сетевого оборудования до виртуализации, — и становится ясно, почему нанять «готового бойца» почти невозможно.
Поэтому ставка делается на выращивание инженеров внутри компании. Новички начинают с тестовых стендов, где учатся собирать и настраивать системы, отрабатывать гарантийные операции, выполнять базовую диагностику. Этот этап не только дает технический фундамент, но и погружает в продуктовую логику. Уже на старте инженеры видят, что их работа — не механическая замена компонентов, а часть большой системы, где важна каждая деталь. Дальше происходит постепенное усложнение задач:
- подключение к пусконаладочным работам;
- участие в решении реальных инцидентов под контролем опытных наставников;
- параллельное обучение новым платформам.
Внутри департамента действует принцип «никогда не отказываться от нового опыта» — инженеры берут задачи, с которыми никогда не сталкивались, и именно это развивает их быстрее всего.
В последние годы наша компания начала работать с вузами, приглашая студентов на практику. Практикантов с первой недели подключают к полезным операциям, пусть и простым, но напрямую связанным с СХД. Из них формируется кадровый резерв, который проходит путь от младшего инженера до старшего и далее — в эксперты, руководители групп, R&D или даже пресейл. Такой карьерный лифт дает людям перспективу, а компании — специалистов, которые знают продукт изнутри.
Расширение функций и зон ответственности
Техподдержка СХД давно вышла за рамки «ремонтной бригады». Сейчас это скорее центр компетенций, где сходится всё: знание продукта, понимание инфраструктуры заказчиков и накопленный опыт эксплуатации. И движение у этой функции одно — к ещё большему расширению роли и влияния на весь жизненный цикл решений:
- Первое направление — интеграция с контролем качества. Инженеры поддержки первыми узнают о проблемах с продуктом, видят их проявления в реальных сценариях и могут моментально передать информацию в отдел тестирования или R&D. Это позволяет не ждать следующего цикла релиза, а вносить исправления по горячим следам.
- Второе — развитие опций сервиса. Уже сейчас доступны нестандартные форматы поддержки: аренда оборудования для временной миграции данных, удаленная помощь при внедрении сторонних систем, индивидуальные каналы связи с персональными менеджерами, удаленный мониторинг и автоматическая поддержка, а также трейд-ин.
- Третье — работа с продуктовой частью. Техподдержка участвует в разработке новых решений, тестирует функционал до релиза, проверяет документацию на удобство восприятия. По сути, она становится «финальным фильтром» перед тем, как продукт попадет к клиенту.
- Четвертое — аналитика отказов и прогнозирование. Чем больше данных собирает техподдержка, тем точнее можно предсказать, когда и в каком узле системы возникнет риск сбоя. Это открывает путь к проактивному обслуживанию, когда проблему устраняют до того, как клиент ее заметит.
В перспективе департамент техподдержки будет напоминать гибрид лаборатории, аналитического центра и клиентского сервиса. Это та точка в компании, где сходятся техническая экспертиза, опыт взаимодействия с заказчиком и умение быстро внедрять изменения.