Класть ли все яйца в одну корзину?
Автор
Алексей Лукацкий
Попытка построить надежную инфраструктуру на базе более чем одного поставщика, с одной стороны, позволяет снизить одни риски, но увеличивает другие.
В заголовок статьи вынесен актуальный вопрос, который в зависимости от задачи означает от «можно ли основную и резервную сети передачи данных строить на базе решений одного вендора» до «можно ли доверить одному вендору серверы, системы хранения данных, сетевую инфраструктуру и безопасность?»
Иными словами, один из самых распространенных вопросов, который звучит из уст ИТ-директоров, что выгоднее: строить инфраструктуру на базе решений как можно меньшего числа производителей или искать лучших в своем классе и пытаться потом интегрировать их между собой в надежде на то, что лучшие дадут еще больший синергетический эффект, если заработают вместе? Вопрос непростой, и каждый вендор, наверное, даст индивидуальный ответ, в зависимости от наличия в своем портфолио продуктов различных классов. Я не буду уподобляться производителям и попробую рассмотреть данный вопрос системно, взяв за основу ключевые факторы, стоящие на повестке дня ИТ-директора.
Доступность инфраструктуры
Чего рядовые пользователи обычно ждут от ИТ? Чтобы все работало! Не больше и не меньше. И одной из метрик, иллюстрирующих это высказывание, является доступность инфраструктуры. Задержки в обслуживании или вовсе отказ от него может обернуться серьезными как финансовыми, так и репутационными потерями для компании. В России отсутствуют оценки стоимости потерь от простоя того или иного приложения или сервиса, в то время как на Западе такие оценки делаются достаточно регулярно. Одной из организаций, которая регулярно проводит такие исследования, является Contingency Planning Research (см.табл.1).
Могу предположить, что в России суммы убытков меньше, но в любом случае они будут достаточно показательными, чтобы вопрос построения надежной и отказоустойчивой инфраструктуры решался с учетом множества факторов. К ним принято относить следующие:
• Высокая доступность
• Время восстановления после отказов (MTTR)
• Поддержка непрерывности бизнеса в процессе восстановления после катастроф и сбоев
• Достижение более гибких цен в условиях конкуренции
• Риск «одного поставщика» (зависимость и т. д.)
• Риск банкротства или смены собственника производителя инфраструктурных решений.
Попытка построить надежную инфраструктуру на базе более чем одного поставщика, с одной стороны, позволяет снизить одни риски, но увеличивает другие. Например, возрастает сложность дизайна сети, появляются дополнительные слабые звенья, становится сложнее интеграция решений разных вендоров между собой, отмечается рост числа уязвимостей. На другой чаше весов — снижение цены поставки за счет сталкивания лбами двух конкурентов, отсутствие диктата своих условий монополистом и вероятность быть поглощенным каким-либо более крупным ИТ-игроком. Универсального ответа в данном уравнении быть не может, но в целом замечу, что за последнее время никаких потрясений на рынке поставщиков решений для сетевой инфраструктуры не было. Cisco стоит незыблемо как скала. Слухи о покупки Juniper компанией EMC пока не подтвердились. HP продолжает продажи своих корпоративных решений в придачу к поставкам принтеров и картриджей к ним.
Функциональность инфраструктуры
Не погружаясь в детали конкретных технологий, сложно объяснить разницу между двумя подходами в строительстве ИТ-инфраструктуры. Возьмем только один пример. Два маршрутизатора разных производителей, через которые идет трафик от системы видео-конференц-связи. Оба сетевых устройства умеют приоритизировать мультимедиа-трафик с высокими требованиями по качеству обслуживания. Но один это делает лучше другого применительно к данной системе ВКС. Потому что разработал их один производитель. И чтобы ни говорили о важности стандартизации, всегда существуют либо собственные (проприетарные) протоколы, либо изменения в стандарты, которым еще только суждено получить официальную поддержку ИТ-отрасли. А пока они остаются доработкой конкретного производителя, доступные лишь в его оборудовании и используемые лишь в его решениях. Плохо ли это? С точки зрения стандартизации — возможно. С точки зрения поддержки стоящих перед бизнесом задач и транслируемых в ИТ-требования? Скорее наоборот.
Поддержка инфраструктуры
Операционные затраты обычно одна из самых непредсказуемых статей бюджета ИТ-департамента. Разумеется, правильное финансовое планирование позволяет не выходить за установленные бюджетом пределы больше чем на 5–10%, но чем больше в нашем уравнении неизвестных (или известных), тем сложнее становится расчет и тем непредсказуемее становится результат. Обновления ПО, поступающие в разное время из разных источников. Разные процедуры установки обновлений. Разные механизмы тестирования обновлений. Разные жизненные циклы и частоты обновлений. Все это многократно усложняет процесс поддержки инфраструктуры. Особенно на местах, где квалифицированного персонала обычно не хватает и становится очень важным наличие процедур удаленного мониторинга и поддержки, которые также могут различаться от вендора к вендору. А что проще — взаимодействовать с одним или несколькими вендорами? Согласно исследованию Sage Research, время реагирования на проблему со стороны одного производителя составляет менее 4 часов в 73% случаев; при мультивендорной инфраструктуре этот показатель снижается и составляет около 55% случаев. Да и время внедрения таких инфраструктур различаются. Так, при внедрении и интеграции моновендорных решений время персонала сокращается на 20–30% по сравнению с решениями от нескольких компаний.
Персонал
ИТ-персонал в России сегодня в дефиците. Квалифицированный персонал конечно. И тут достаточно посмотреть на рынок труда, на предложения различных онлайн-сервисов по поиску работы, чтобы понять: найти хорошего сотрудника, специализирующегося на каком-либо одном производителе, проще, чем такого же специалиста, знакомого с двумя или даже большим числом продуктов от разных поставщиков. А если он и есть, то, во-первых, стоит он дороже своего «моновендорного коллеги», а, во-вторых, риски его перекупки гораздо выше (хотя надо признать, что в регионах и специалиста по одному производителю тоже могут перекупить). Если же искать моноспециалистов на каждого используемого в организации вендора, то цена такого выбора может быть непомерно высокой.
И это только вопрос приобретения специалиста. Но ему же нужно поддерживать свою квалификацию, проходить различные тренинги, посещать различные мероприятия, устраиваемые производителями. Что выгоднее — делать это для одного, или двух, или трех вендоров?
А ведь иногда стоит подумать и об отпуске. А если человек заболел или по семейным обстоятельствам не смог выйти на работу? Кому легко найти замену: специалисту с квалификацией по одному производителю или по нескольким? И вопрос болезни непраздный. Нагрузка на ИТ-специалистов растет; требования к инфраструктуре со стороны бизнеса только увеличиваются. Работа в условиях постоянного стресса приводит к сбоям… но уже не в работе оборудования, а в работе персонала. И перед нами опять стоит задача — либо временно возложить часть функций на оставшийся в строю персонал, либо оперативно искать замену. В мультивендорной среде сделать это непросто.
Безопасность
Не бывает неуязвимых продуктов, бывают продукты с плохо выстроенным процессом управления уязвимостями и патчами. Но дело не только в том, как тот или иной производитель устраняет баги в своем оборудовании. Допустим, все они это выполняют одинаково хорошо. Дело в росте числа этих уязвимостей. Если в продукте одного производителя их 10, то у двух — уже примерно 17, у трех — 23–25 и т. д. Очевидно, какие-то уязвимости будут общими для всех продуктов, построенных на базе единого стека протоколов (например, TCP/IP) или одной библиотеки. Но многие дыры привносятся уже на этапе разработки, и каждый вендор в этом процессе уникален. Рост числа уязвимостей приводит к повышению затрат на их устранение. А это опять люди, время, деньги…
Посмотрим на безопасность с другой стороны. Стоит ли применять, например, два межсетевых экрана от разных производителей для защиты одного веб-сегмента, в котором находятся все публичные ресурсы компании? Казалось бы, защита должна быть в два раза лучше — то, что пропускается одним средством защиты, блокируется вторым. В теории да. А на практике? Два разных средства защиты. Две разных политики. Два разных способа описания правил разграничения доступа. Два разных способа управления. Две разных консоли администрирования. Два разных способа и источника обновления системы защиты. Сложность всего решения, а значит, и вероятность ошибки, тоже в два раза выше. И это если не рассматривать версию, что два вендора свои продукты строят на одних принципах, и пропуск какой-либо атаки одним средством защиты не гарантирует, что второе средство эту атаку увидит и заблокирует.
Чтобы не быть голословными, возьмем всего два примера — протокол SNMP для управления сетевым оборудованием и протокол H.323 для работы IP-телефонии и видео-конференц-связи. Эти протоколы реализованы различными производителями, но в них все равно существуют уязвимости, общие для самого протокола. Например, использование заданного по умолчанию имени SNMP community «public» или отказ в обслуживании H.323-устройства путем отправки ему специально сформированных IP-пакетов на порт 1720/tcp. Данный пример, с одной стороны, объясняет, почему число уязвимостей не растет линейно с числом используемых вендоров. А во-вторых, почему применения средств защиты от разных вендоров не увеличивает защищенности от подобных атак. А если еще и сами средства защиты страдают от этих уязвимостей…
Финансы
Финансы — это не только и не столько капитальные затраты, сколько совокупная стоимость владения инфраструктурой (TCO), которая делится на три больших блока:
• Затраты на приобретение (примерно 25% от TCO)
• Затраты на операционную поддержку (около 40%)
• Затраты на ресурсы (около 35%, включают услуги связи, поддержку оборудования, электричество, услуги ЖКХ и т. д.)
Кто-то считает, что все затраты на ИТ-инфраструктуру делятся на две большие составляющие – капитальные затраты (CapEx), составляющие около 30%, и операционные (OpEx), составляющие оставшиеся 70%. Не так важно, на сколько составляющих делятся затраты на ИТ-инфраструктуру, главное, что они не ограничиваются только одним показателем — стоимостью закупки. Если ориентироваться только на этот показатель, то выбирать, по сути, будет не из чего. Качественное решение, удовлетворяющее всем нынешним и будущим потребностям бизнеса, найти окажется сложно.
Если же рассматривать совокупную стоимость владения целиком, то картина меняется, и меняется сильно. Существует немало исследований, посвященных вопросу сравнения расчета TCO для моно- и мультивендорных решений. К их числу можно отнести:
- Sage Research. 2004;
- «The Net Impact Study». Momentum Research Group. 2006;
- «Multi-Vendor Versus Lead-Partner Strategies: Telecommunications Service Provider Perspective»ю IBSG Economics and Research. June 2008;
- «Navigating Network Infrastructure Expenditures During Business Transformations». Lippis Report. 2009;
- «Total Economic Impact of Cisco’s Borderless Networks». Forrester Consulting. November 2010;
- «Debunking the Myth of the Single-Vendor Network». Gartner. November 2010;
- «Multivendor Network Architectures, TCO and Operational Risk». Deloitte Consulting. February 2012.
В зависимости от выбранной методологии они приводят разные цифры, но в целом все исследователи сходятся в одном — на текущем этапе развития ИТ-отрасли снижение TCO для мультивендорной инфраструктуры ниже, чем для моновендорной. Например, согласно отчету SAGE Research сокращение капитальных и операционных издержек в случае стандартизации инфраструктуры на базе одного производителя составляет 29% (по сравнению с инфраструктурой на базе нескольких производителей).
Существуют достаточно простые формы или уже готовые калькуляторы (в приведенных выше исследованиях, которые легко найти в Интернете), облегчающие расчет для каждой конкретной ситуации. Единственное, что следует всегда учитывать при самостоятельной калькуляции, — брать не менее чем трехлетний период расчета. В противном случае, эффект не будет показан никогда, так как в первый год все затраты исключительно капитальные.
Выводы
Универсального ответа на вопрос, заданный в заголовке статьи, к сожалению, а может, и к счастью, не существует. Все зависит от множества факторов, которые заранее учесть невозможно. Условия финансирования, взаимодействия с поставщиками, масштаб организации, стратегия управления рисками... Все это влияет на итоговое решение. Очевидно, что всегда хочется взять самые лучшие решения на рынке и объединить. Помните, как было во втором действии «Свадьбы» Гоголя?.. «Уж как трудно решиться, так просто рассказать нельзя, как трудно! Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмина, да взять сколько-нибудь развязности, какая у Балтазара Балтазарыча, да, пожалуй, прибавить к этому еще дородности Ивана Павловича — я бы тогда тотчас же решилась. А теперь поди подумай! просто голова даже стала болеть». Процесс выбора вендоров для собственной инфраструктуры схож с выбором жениха. Но даже у Гоголя не получилось решить эту задачу.
В реальной жизни, когда таких «женихов» немало, выбор становится гораздо сложнее. А все потому, что нам важно не только выбрать лучших из лучших, но и «подружить» их в нашей инфраструктуре. И вот тут кроется последняя проблема, о которой выше я не писал, — интеграция. Какой прок от лучшей системы видео-конференц-связи и лучшей системы IP-телефонии, если они не могут интегрироваться между собой? Какой прок от лучших в своем классе системы предотвращения вторжений и маршрутизатора разных вендоров, если при обнаружении атаки первая не может дать команду второму на блокирование трафика с подозрительного IP-адреса? Где синергетический эффект? Его нет. А операционные затраты по внедрению, управлению, обновлению, поддержке мультивендорных решений по-прежнему тяжким грузом лежат на плечах ИТ-департамента. Так есть ли выгода в выборе решений от разных вендоров? На сегодняшний день, при всех прочих равных условиях, ее нет. Пока уровень стандартизации взаимодействия между продуктами разных фирм будет оставаться на крайне низком уровне, никакой выгоды от приобретения лучших в своем классе продуктов не будет. Все эти выгоды будут съедаться сложностями внедрения и интеграции в уже существующую инфраструктуру. В дальнейшем, возможно, ситуация изменится, но пока говорить об этом рано.
Опубликовано 27.11.2012
