Почему вендорской поддержке недостаточно классической "трёхлинейки" и зачем нужна мультивендорная экспертиза
Меня зовут Артём Смирнов, я руковожу департаментом мультивендорных решений и экспертизы в YADRO. Несколько лет назад мы увидели, что клиентам всё чаще нужна не просто поддержка "железа", а помощь в понимании и развитии всей их сложной инфраструктуры, где оборудование и ПО десятков производителей переплетены в один большой живой организм. Так появилась отдельная команда третьей линии, которая занимается не только инцидентами, но и архитектурой, миграциями и взаимодействием с другими вендорами.
Зачем вообще отдельный департамент
Дивизион сервиса YADRO сопровождает свыше ста тысяч единиц ИТ-оборудования - от систем хранения и серверов до базовых станций, а также более 150 тысяч пользовательских устройств. Наши инженеры работают в разных регионах и климатических условиях, с десятками вариантов SLA и требований по доступности. Оборудование YADRO стоит в дата-центрах банков, в инфраструктуре крупных городов, промышленных предприятий и госсектора.
Классическая модель поддержки у нас, как и у многих, выглядит так:
- L0 - диспетчеры и координаторы. Они регистрируют и маршрутизируют заявки.
- L1 - квалификаторы и выездные инженеры. Их зона ответственности - базовые неполадки и типовые инциденты, решения по которым уже описаны в базе знаний.
- L2 - более глубокая техническая экспертиза. Эти инженеры разбирают нетривиальные случаи, подсказывают первой линии и принимают решение, когда инцидент надо эскалировать дальше.
- L3 - у нас разделена на два крупных блока. Одна часть команды фокусируется на самых сложных проблемах с продуктами YADRO. Вторая - на задачах, которые вылезают из-за окружения, интеграций, настроек и поведения чужого оборудования. Это и есть наш департамент мультивендорной экспертизы.
Все линии поддержки решают задачи, связанные с корректной эксплуатацией и обслуживанием продуктов YADRO. Но живая инфраструктура клиента выглядит иначе: в ней одновременно работают решения разных вендоров, интеграционные шины, специфическое ПО заказчика, старые и новые платформы. Каждый стык между этими системами - потенциальное "узкое горлышко" и источник рисков.
Именно поэтому мы решили не ограничиваться рамками собственных продуктов и создали подразделение, которое помогает компаниям разруливать ситуации в мультивендорной среде, а не только "чинить железо".
Почему мультивендорный подход критичен
В крупных организациях сегодня трудно встретить "чистый" стек одного производителя. В одной цепочке обработки запроса клиента банка или пользователя сервиса может участвовать:
- несколько типов систем хранения;
- серверные платформы от разных производителей;
- виртуализация от одного вендора и СУБД от другого;
- собственное ПО заказчика;
- решения по резервному копированию и мониторингу ещё от пары вендоров.
При этом каждая сторона зачастую смотрит только на свой участок и отвечает лишь за него. В результате при инциденте начинается классическая история: одни считают, что проблема в СХД, другие винят сеть, третьи - БД, а четвертые - "кривое приложение". Времени на поиск корня проблемы уходит много, а бизнес в этот момент терпит убытки.
Наша задача - видеть систему целиком. Мы не делим мир на "наше" и "чужое", а анализируем путь данных от начала до конца, архитектуру сервисов, режимы отказоустойчивости, процессы сопровождения и изменения. Отсюда вытекают ключевые направления работы департамента.
Проектирование комплексных архитектур
Одно из наших основных направлений - проектирование архитектур высоконагруженных и критически важных сервисов по запросу клиентов. При этом совершенно не обязательно, чтобы заказчик уже пользовался оборудованием YADRO. Мы работаем и с инфраструктурами, где наши решения занимают лишь небольшую часть, и с теми, где оборудования YADRO пока нет вовсе.
Приведу несколько типичных сценариев задач, с которыми приходят заказчики.
1. "Наследство" для новой команды эксплуатации
У компании появляется новая команда, отвечающая за поддержку информационных систем. Она получает "во владение" сложный зоопарк из серверов, СХД, виртуализации, сетей, баз данных и приложений - и не до конца понимает, как всё это связано и от чего зависят критичные сервисы.
В такой ситуации мы:
- проводим инвентаризацию ключевых компонент инфраструктуры;
- описываем взаимосвязи систем и цепочки бизнес-процессов;
- оцениваем потребление ресурсов и выявляем неэффективные участки;
- анализируем поведение систем в пиках и при авариях;
- составляем дорожную карту развития: от небольших оперативных улучшений до крупных проектов по оптимизации и масштабированию.
По сути, мы помогаем CIO и его команде "увидеть" свою архитектуру, понять её слабые места и получить план, как эволюционировать без лишних рисков.
2. Оптимизация ресурсов и "расчистка зоопарка"
Другой часто встречающийся запрос: нужно уменьшить расход вычислительных и дисковых ресурсов или подготовить инфраструктуру к новому витку роста без лавинообразного удорожания. В распоряжении заказчика - существующий пул оборудования: часть уже морально устарела, часть - от вендоров, ушедших с рынка, а что-то просто используется не по назначению.
Здесь наша работа включает:
- анализ текущей загрузки и профиля использования ресурсов;
- выявление неэффективных или опасных с точки зрения рисков элементов (например, EoL-оборудование);
- разработку вариантов модернизации: что можно перевести на другую платформу, что заменить, что вывести из эксплуатации;
- оценку экономического эффекта разных сценариев и рисков при каждом из них.
В результате заказчик получает чёткое понимание, как сократить издержки и снизить риски, не разваливая при этом существующие сервисы.
3. Повышение отказоустойчивости и готовность к сбоям
Многим компаниям важно не только удерживать текущий уровень стабильности, но и быть готовыми к крупным инцидентам: аварии в ЦОД, выходу из строя критичных узлов, ошибкам человеческого фактора.
В таких проектах мы:
- изучаем существующие регламенты переключения на резерв;
- проводим интервью с ответственными сотрудниками и техническими командами;
- строим матрицу рисков с оценкой вероятности и влияния на бизнес;
- моделируем возможные сценарии отказов и проверяем, как инфраструктура поведёт себя в каждом из них;
- формируем перечень как технических, так и процессных изменений: от донастройки кластеров и резервирования до изменений в процедуре дежурств и реакции на инцидент.
Важно, что мы рассматриваем устойчивость не только как "есть ли резервный сервер", а как способность всей связки систем пережить нештатную ситуацию и восстановиться в допустимое для бизнеса время.
Масштабирование архитектур без "ломки" бизнеса
Когда сервис растёт, компания часто сталкивается с тем, что архитектура, работавшая на десятках тысяч пользователей, начинает "скрипеть" при сотнях тысяч или миллионах. Добавление ресурсов по месту уже не помогает, требуется переосмысление ключевых компонент.
Задача департамента в таком случае - спроектировать путь масштабирования с минимальными рисками и понятными шагами:
- определить архитектурные границы текущего решения - до каких пор его можно масштабировать "в лоб";
- предложить рефакторинг архитектуры: где лучше перейти от вертикального масштабирования к горизонтальному, как разделить нагрузку, где ввести кэширование или очереди;
- подобрать оптимальные технологии и оборудование, учитывая уже существующий стек;
- выстроить поэтапный план внедрения, чтобы бизнес получал новые мощности без больших простоев.
Мы всегда стараемся сочетать эволюционный подход (поэтапные изменения) с прагматикой: иногда проще один раз аккуратно "перерезать" кусок архитектуры, чем годами латать её патчами.
Планирование и сопровождение миграций
Отдельный крупный пласт нашей работы - это миграции. Причём речь не только о переносе данных с одной СХД на другую. Это и переезд целых ЦОД, и переход между платформами виртуализации, и смена СУБД, и консолидация нескольких распределённых решений в единый комплекс.
Наш департамент:
- оценивает исходную и целевую архитектуры;
- формирует стратегию миграции с учётом ограничений по простоям;
- предлагает варианты поэтапного перехода и тестирования;
- закладывает механизмы отката на каждом критичном шаге;
- участвует в пилотных и боевых миграциях в роли технического координатора.
Мультивендорная экспертиза здесь особенно важна: нужно понимать, как себя поведут разные платформы, какие есть особенности у конкретных версий ПО и железа, какие подводные камни возникают при взаимодействии.
Эскалация проблем, связанных с чужим оборудованием
Не все инциденты, приходящие к нам как к вендору, однозначно связаны с продуктами YADRO. Часто оказывается, что корень проблемы лежит, к примеру, в:
- некорректной прошивке сетевых устройств другого производителя;
- бага в виртуализационной платформе;
- ошибочной конфигурации балансировщика нагрузки;
- несовместимости версий драйверов и микрокода.
В таких случаях департамент мультивендорной экспертизы:
- воспроизводит проблему в лаборатории, используя максимально близкую к клиентской конфигурацию;
- собирает детальные трассировки, дампы, логи с разных уровней;
- формирует структурированное описание инцидента для другого вендора на его техническом языке;
- сопровождает эскалацию до момента получения решения, участвует в валидации фиксов и рекомендаций.
Таким образом, клиенту не нужно самостоятельно "бодаться" с несколькими производителями, доказывая, что проблема не в нём. Мы берём на себя роль технического переводчика и медиатора между разными вендорами.
Лаборатории, где можно "пощупать" чужие инсталляции
Чтобы эффективно разбирать сложные кейсы, мы поддерживаем несколько лабораторных стендов, где воспроизводим клиентские конфигурации. Это не только оборудование YADRO, но и:
- разные платформы виртуализации;
- системы хранения и серверы других производителей;
- сетевую инфраструктуру с близкими настройками;
- программные стеки, используемые заказчиками.
Такие лаборатории позволяют:
- безопасно моделировать инциденты и проверять гипотезы;
- тестировать сценарии миграции до их запуска в продакшене;
- проверять, как будут вести себя обновления, патчи и новые настройки;
- обучать инженеров на реальных, а не учебных сценариях.
В ряде случаев мы собираем "под клиента" временный стенд для отработки уникальных задач - например, при крупной миграции или реорганизации архитектуры.
С кем и как мы взаимодействуем
Мультивендорный департамент по определению не может работать в изоляции. Мы постоянно взаимодействуем:
- с внутренними командами разработки и поддержки продуктов YADRO;
- с техническими специалистами других вендоров - от инженеров поддержки до архитекторов решений;
- с ИТ-службами заказчиков, включая эксплуатацию, архитектуру, безопасность и разработку.
Часто проекты становятся совместными: мы объединяем усилия с другими производителями ПО и железа, чтобы вместе выработать работающее для клиента решение. Важный принцип - фокус на результате для бизнеса, а не на том, кто "прав" в техническом споре.
Кто становится инженером такого департамента
Работа в мультивендорной третьей линии - это постоянное исследование. Типичного "портрета" инженера здесь нет, но есть несколько общих черт:
- широкий технический кругозор и опыт работы сразу с несколькими стеками технологий;
- умение смотреть на систему целиком, а не только на свой любимый продукт или технологию;
- готовность разбираться в чужих решениях, документации и логике;
- навык общаться и с разработчиками, и с эксплуатацией, и с менеджерами, переводя сложные вещи на понятный язык;
- высокая самоорганизация и готовность брать ответственность за результат в сложных проектах.
Часто в департамент приходят специалисты, которые уже прошли путь от первой и второй линии до архитекторов, и теперь хотят заниматься более комплексными задачами, где нужно комбинировать знания и опыт из разных областей.
Зачем всё это клиенту
Если попытаться сформулировать смысл существования департамента в одной фразе, то это "сделать так, чтобы ИТ-инфраструктура работала устойчиво и предсказуемо в реальном, мультивендорном мире".
С точки зрения бизнеса это выражается в:
- снижении времени простоя при инцидентах;
- более понятном и контролируемом развитии архитектуры;
- уменьшении рисков, связанных с устаревшим оборудованием или уходом вендоров с рынка;
- более эффективном использовании ресурсов;
- возможности опираться на внешнюю экспертизу при сложных решениях.
Мы не ограничиваемся рамками "наших" продуктов, потому что инфраструктура заказчика - это единая система. Для неё нет значения, чей логотип стоит на корпусе сервера или СХД. И задача современной третьей линии поддержки - понимать и уметь работать с этой реальностью.
