Подводные камни большого рифа: поддержка сетей в новой реальности

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

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

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

С появлением небольших компаний, обеспечивающих сервисную поддержку, ужесточилась конкуренция на рынке сервисных услуг. Чтобы получить свою рыночную долю, небольшие сервис-партнеры заключают договоры с заказчиками по сниженным тарифам. В результате многим подобным сервисным компаниям не хватает экспертизы, специалисты по сервису нарушают SLA, долго отвечают на заявки и вместо заявленного формата работы 24/7 работают в режиме 8/5. В итоге заказчики разрывают либо не продлевают контракты на сервисное обслуживание с такими партнерами и возвращаются к надежным крупным ИТ-интеграторам.

Сценарии развития сетей

Сегодня у бизнеса есть несколько вариантов развития имеющихся сетей. В целом компании разделились на два лагеря. К первому относятся «рок-н-ролльщики», которые продолжают работать на импортных решениях. Они рискуют: все еще остаются клиентами зарубежных вендоров и верят (возможно, небезосновательно) в то, что производители рано или поздно вернутся на российский рынок. В сумме они составляют примерно 30% рынка. Второй лагерь и остальные 70% — это организации с госучастием и бизнес, который стратегически смотрит в будущее. Они понимают, что рано или поздно российским компаниям придется перевести хотя бы часть инфраструктуры на отечественные продукты. В области сетевых решений вопрос стоит не так остро, как с информационной безопасностью, — аналога ФЗ-250 пока не существует. Тем не менее большинство воспринимает этот закон как указание к пересмотру ИТ-инфраструктуры в целом, а не только ИБ-составляющей.

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

Интеграция решений зарубежных вендоров с российским оборудованием может потребовать более глубокого погружения. Не все протоколы, которые были реализованы на оборудовании зарубежных вендоров, поддерживаются отечественными ИТ-продуктами. Российские производители, как правило, разрабатывают оборудование с поддержкой всех доступных открытых протоколов передачи данных. Ряд иностранных производителей в свое время внедрили большое количество собственных (проприетарных) протоколов. Поэтому миграция на отечественные решения также связана с переходом от проприетарных протоколов к общедоступным, что требует достаточной экспертизы и детального подхода. У многих крупных ИТ-интеграторов уже есть проектный опыт по миграции с проприетарных протоколов DMVPN, PVST, EIGRP на общедоступные протоколы DMVPN, MSTP и OSPF соответственно.

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

На одном из проектов наша команда столкнулась с проблемой балансировки трафика, который входил в облако с помощью механизма маршрутизации ECMP на несколько виртуальных машин с одинаковыми IP-адресами. На практике проблема приводила к тому, что трафик попадал только на некоторые из них. Кроме того, не работало горизонтальное масштабирование, предусмотренное дизайном VNF. Мы провели обширный разбор и анализ ошибок: наши специалисты выполнили тесты и создали документы, благодаря чему вендор смог оперативно вникнуть в проблему и создать быстрое решение на текущем ПО. В следующем релизе производитель включил в конфигурацию возможность настройки расчета хеша для ECMP. Это помогло решить возникшую проблему после обновления ПО фабрики.

Помимо описанного выше случая, в нашей практике уже есть и позитивные, и достаточно сложные кейсы. К первым можно отнести тестирование беспроводных точек доступа российского производителя сетевого оборудования Eltex. У производителя была подробная методика, нам оперативно предоставляли новые релизы ПО с необходимыми корректировками. Оборудование Wi-Fi 6 достойно показало себя во время испытаний. Оно подойдет компаниями, которым необходимо построить Wi-Fi с технологическим потенциалом на ближайшие несколько лет. В диапазоне 5 ГГц пропускная способность увеличилась на 27–65%, а в диапазоне 2,4 ГГц ― на 21–45%. Увеличение будет особенно заметно при использовании устройств, которые поддерживают стандарт Wi-Fi 6 (802.11ax).

Сервисное комбо

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

Это минимум, который точно необходим для поддержки ИТ-инфраструктуры компании.

При необходимости этот перечень можно расширить дополнительными услугами:

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

Такой подход позволяет специалистам ИТ-интеграторов расширять свою экспертизу.

Подменное оборудование на следующий день

Иногда компании сталкиваются с тем, что при рассмотрении их запроса сервис-партнер сообщает о том, что устройство или его комплектующие, в которых возникли неполадки, неисправны и требуют замены или ремонта. В этом случае компания может воспользоваться услугой по замене неисправных устройств (RMA). Чаще всего компании выбирают классические условия для услуги по возврату, и подрядчик по сервисной поддержке отправляет им подменное оборудование на следующий рабочий день (NBD). В случае, если у сервис-партнера нет такого устройства на складе, будет предложена замена на аналогичное или лучшее по характеристикам оборудование. У российских производителей, как и у зарубежных вендоров, программы по SLA фиксированные. ИТ-интеграторы являются более клиентоориентированными и могут максимально адаптировать SLA под запросы заказчика. Кроме того, нужно учитывать ряд важных нюансов.

Предположим, вы выбираете расширенную программу поддержки: подразумевается, что в случае выхода оборудования из строя новое железо будет отправлено на NBD. Если вы находитесь в Москве, а вендор базируется не в Центральном регионе (или наоборот), сроки вряд ли будут соблюдены. Скорее всего, вы получите подменное оборудование в течение недели. Как и в случае с зарубежными вендорами, один из самых простых способов нивелировать эти риски — воспользоваться RMA-программой ИТ-интеграторов.

Сервисные кейсы

Сервисная команда компании «Инфосистемы Джет» за последний год построила около 30 стендов для решения сервисных запросов повышенной сложности. Помимо отечественных решений, специалисты ИТ-компании продолжают поддерживать сетевые продукты зарубежных производителей: коммутаторы, ВКС, балансировщики, инфраструктурные решений и др. Почти 30% заявок, поданных в 2022 г. и первой половине 2023 г., были связаны с вопросами по неисправностям блоков питания. Это связано с тем, что при скачке напряжения в электросети блоки питания оборудования первыми принимают на себя удар и поэтому чаще выходят из строя. Проблемы с коммутаторами и линейными картами с оптическими портами составили по 18% от общего количества заявок. 12% обращений пришлось на межсетевые экраны и маршрутизаторы.

Чтобы оптимизировать стоимость сервисной поддержки в разрезе года, многие компании стараются заключать долгосрочные контракты, длительностью более 12 месяцев. У сервисной команды центра сетевых решений компании «Инфосистемы Джет» средний срок контракта составляет 32 месяца.

Как изменились инструменты поддержки

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

Каждая заявка сопровождается решением проблемы. Функционал решений российских и зарубежных производителей пока сложно сравнивать. Сети компаний становятся все более гибридными. Даже если в компании есть вендорская система мониторинга, она не сможет отслеживать работу нового российского или зарубежного оборудования других вендоров. Для решения этой проблемы компаниям стоит обратить внимание на продукты open source.

Такие решения можно максимально подстроить под задачи компании, работать с привычным интерфейсом и получать круглосуточную поддержку от производителя оборудования open source. Среди российских производителей подобный продукт есть у «Лаборатории Числитель». «Пульт» — отечественная система мониторинга ИТ-инфраструктуры с квалифицированной техподдержкой. Это решение разработано на основе открытой программной платформы Zabbix и входит в реестр российского ПО. Компании, которые уже используют решения Zabbix в своей инфраструктуре, смогут также полноценно использовать весь функционал системы «Пульт». Она включает в себя встроенную поддержку СУБД и набор шаблонов для мониторинга оборудования, систем и баз данных.

Как выбрать сервис-партнера

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

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