Три подводных камня при создании сетевой инфраструктуры предприятия

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

Момент № 1. Нехватка компетенций: топорная реализация важных сетевых технологий (QoS), «экономия» вместо экономии

Представим ситуацию: у топ-менеджмента важный звонок по видео-конференц-связи (ВКС), а бухгалтерам нужно срочно сдавать квартальные отчеты. При этом работают они удаленно. Если компания не использует технологи QoS (Quality of Service), позволяющие обслуживать различные виды сетевого трафика в соответствии с его особенностями, в сети будут возникать сложные неуправляемые ситуации. Пользователи начнут мешать друг другу: видеосвязь будет некачественной, рабочие места бухгалтеров станут функционировать с задержками. Причина в том, что сетевое оборудование обрабатывает все приходящие пакеты по очереди, произвольно отбрасывая при перегрузках те, которые могут быть очень важны с точки зрения бизнеса (голос, звук, работа с 1С и т. д.). В результате «1С: Предприятие» зависает, отчеты перестают строиться, картинка в ВКС идет пикселями, а при звонке слышно только бульканье. Рядовые сотрудники получают штрафы, топ-менеджмент теряет лицо, компания — репутацию.

Подобные проблемы часто решаются в лоб: например, увеличением пропускной способности каналов передачи данных, сменой среды передачи данных — с меди на оптику или с 4G на Wi-Fi. Или использованием провайдерского MPLS для организации связи между филиалами. Но и эти меры не всегда дают желаемый результат. У многих заказчиков мы наблюдаем сходную ситуацию: к массовому недовольству пользователей приводит именно нежелание или неумение сетевиков осваивать и корректно задействовать полный стек технологий QoS. А их сегодня немало, в частности, для серверного сегмента сети это могут быть 802.3x, 802.1p; для WAN-каналов — LLQ (по факту CBWFQ + PQ) и policing; для клиентского доступа — 802.1p., shaping и другие.

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

·       Platinum — для голоса и служебного сетевого трафика.

·       Gold — для ВКС или потокового видео (к примеру, корпоративные стримы).

·       Silver — для интерактивных бизнес-критичных сервисов: RDP, 1С, CRM, веб-приложений.

·       Bronze — для остальных бизнес критичных сервисов: почта, файловые службы.

·       BestEffort — трафик с негарантированной доставкой, трафик для работы в Интернете, скачивания файлов и т. д.

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

Обойти подобные ловушки проще всего, если покупать готовые знания, умения, навыки и подходы зрелой сервисной компании, в штате которой есть специалисты по сетевой инфраструктуре. Умеющие работать с широким стеком технологий (от начальной маркировки и классификации пакетов на уровне доступа до распределения пакетов в соответствующие очереди на WAN-маршрутизаторах). Сегодня этот путь связан с меньшими рисками и затратами, чем пока еще более привычный вариант — развивать такие компетенции самостоятельно, несмотря на серьезные траты на ФОТ, трудности масштабирования, сложности обучения и особую дороговизну ошибок на данном этапе, а также на высокую вероятность трудно выявляемых ошибок в настройке СИ. Привлечение сервисной компании незаменимо при построении СИ с поддержкой QoS для филиальных сетей. Сильная сервисная компания может снизить стоимость владения сетью (например, за счет использования менее дорогих каналов связи), сохранив работу всех сервисов на хорошем уровне. А экономия может быть значительной.

Так, используя QoS для многих средних предприятий-клиентов, мы снижаем стоимость аренды каналов в 2–4 раза — причем для каждого регионального сегмента сети. Одновременно рекомендуем уменьшать пропускную способность каналов сети, подгоняя ее точно «по размеру» (не 50, а 10–15 Мбит/с). Нередко удается отказаться от дорогих и излишних частных выделенных каналов у провайдера. Во многих случаях реальной потребности в них у бизнеса нет, а платить ему пришлось бы на порядок больше по сравнению с публичными каналами передачи данных. В таких ситуациях заказчик получает собственную VPN-сеть на основе публичных сетей с достаточной пропускной способностью и латентностью. В сети предусмотрена самостоятельная маркировка трафика по приоритету и его самостоятельное распределение. В результате высокоприоритетный для компании трафик (ВКС, 1С, CRM, веб-сервисы) никогда не урезается, а сеть и бизнес-критичные приложения работают стабильно даже при высокой нагрузке в пиковые периоды (сезон продаж, сдача отчетности). Штатная ИТ-служба при этом ясно представляет, как используется пропускная полоса каналов передачи данных. И как при необходимости аргументированно обосновать ее увеличение.

Вообще реальные компетенции по правильной организации QoS — это отсутствие головной боли по типовым проблемам («зависает — разберитесь») и плановая, четкая работа с сетью. QoS помогает сгладить углы для конечных пользователей при работе с сервисами компании. А также точно определять реальные потребности в оборудовании и каналах передачи данных. Но, как я уже говорил, правильный выбор класса оборудования и стека технологий возможен только, если ИТ-специалист умеет говорить на языке бизнеса. В терминах возможных бизнес-рисков — «частые сбои», «простои», «финансовые убытки в сотни тысяч рублей ежемесячно только в филиалах», «тушение пожаров» и «постоянный негатив со стороны пользователей».

Момент № 2. Отсутствие привязки к одному поставщику (vendorlock-in) — головная боль по собственной инициативе

«Зоопарк» из сетевого оборудования (например, в центре коммутаторы доступа Cisco, HP, 3Com, а в филиальном сегменте дополнительно — оборудование Mikrotik и Zyxel) еще приводит к большому числу ИТ-проблем. Построение же отдельных функциональных сегментов сети (клиентский доступ, доступ распределения, серверный сегмент, DMZ-сегмент, региональные сегменты) на базе оборудования от одного вендора избавляет компанию, строящую и обслуживающую сеть самостоятельно, от хронических убытков, вызванных разными простоями. В частности, от «футбола» между производителями оборудования, которые кивают друг на друга, когда оборудование не работает, как заявлено. И в итоге оставляют заказчиков один на один с нерешенными проблемами. Если же поставщик оборудования один, «футбола», как правило, не возникает, а ИТ-инциденты решаются примерно в 10 раз быстрее, чем в мультивендорной СИ. К тому же если оборудование разное, компания просто вынуждена держать в штате специалистов по всему спектру (Cisco, Mikrotik, D-Link) или молиться на универсала.

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

Если к планированию и построению сети привлечена зрелая сервисная компания, проблем с оборудованием от разных производителей почти не возникает. Во-первых, у нее есть достаточное количество компетенций, чтобы оперативно их решить. Во-вторых, умение ее специалистов работать с открытыми стандартами снимает большую часть вопросов, связанных с интеграцией оборудования и т. д.

Момент № 3. Поверхностная проработка архитектуры сети — сложная эксплуатация и поддержка, дыры в безопасности всех ИТ-сервисов, сбои, простои, убытки

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

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

На этапе планирования cети (и позже, на этапе апгрейда, когда ставятся новые сетевые устройства, переделываются концентраторы VPN) важно фиксировать параметры каждого конкретного бизнес-сервиса и сети в целом:

·       заявленную доступность, плановую недоступность сети в случае форс-мажоров (головной офис, региональная сеть);

·       пропускную способность основных каналов передачи данных;

·       используемые технологии: STP, VLAN, QoS, NAT;

·       критичные для бизнеса сервисы (1С и популярные конфигурации на базе этого ПО, почта, ERP, CRM, CLM), транспорт, который они используют (HTTP, SIP, RDP, в случае отдельных бизнес-приложений — RPC) дополнительные требования к сети;

·     количество рабочих мест с привязкой к используемым сервисам, итоговый подсчет необходимых параметров работы сети;

·       требования со стороны информационной безопасности.

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

Еще один фактор, который нужно учесть перед началом планирования и проектирования сети, — «здоровье» ИТ-инфраструктуры компании-заказчика. Здесь я бы рекомендовал проводить высокоточный ИТ-аудит, предоставляющий полную картину состояния ИТ-инфраструктуры. Опираясь в том числе и на него, эксперты сделаю заключение, как должна быть спроектирована сеть. В идеале следует проверить состояние ИТ-инфраструктуры и позже, кода сеть заработает. Нужны проверки и при каждой модернизации сети. Их можно провести, например, с помощью нескольких аудитов в онлайн-режиме, которые эффективно реализует сервис централизованного мониторинга и контроля над состоянием ИТ-инфраструктуры (СЦМК).

Об информационной безопасности сети правильнее всего думать, опять же, на этапе ее планирования. Особенно если персональные данные (относящиеся, скажем, к медицине) перед передачей по каналам компании должны шифроваться по определенным ГОСТам. Если бизнес или ИТ упускают этот момент, позже оказывается, что оборудование не может прокачать нужный объем зашифрованных данных, а деньги на него уже потрачены. Чтобы избежать таких ситуаций, важно тесно сотрудничать с подразделением, специалистом или сторонней компанией, профессионально занимающимися ИБ.

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

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

Итого

Проблемы в работе ИТ-сервисов компании далеко не всегда решаются линейным масштабированием качественных характеристик каналов передачи данных. Намного чаще устранить подводные камни в сетевой инфраструктуре помогает внедрение продуманного QoS (Quality of Service), позволяющего оптимально использовать ресурсы компании, снижать стоимость владения сетью в 2–4 раза и более. И сохранять на хорошем уровне показатели работы критичных бизнес-сервисов (1С, почта, CRM, CLM и пр.). Второй способ избавиться от проблем в работе сети — моновендорность при построении всей сети или ее отдельных функциональных сегментов. Это предоставляет возможность значительно повысить стабильность ее функционирования и избежать растущей лавины ИТ-инцидентов и проблем, на решение которых специалистам нужно все больше времени. И наконец, при планировании архитектуры сети ИТ нужно верно доносить все риски до бизнеса (повторяющиеся сбои, простои, деградация сети — плохая работа всех служб и сервисов). Бизнесу же следует принимать их. Или увеличивать бюджеты, понимая, что сеть — основа для работы каждого ИТ-сервиса/службы. И если она не спроектирована должным образом, ни о какой непрерывности бизнеса говорить не приходится.

Чако ОМАРОВ,

ведущий специалист департамента ИТ-аутсорсинга ALP Group