Для начала давайте представимся. Miraworks - компания из тех, кто занимался подбором и продажей железа много лет в самых разных интеграторах и вендорах. Нам знакомы все проблемы и боль «а посчитайте еще на вендоре B», и мы предлагаем свое решение для упрощения жизни как заказчиков, так и интеграторов. Это кратко.
А теперь длинно.
Тема «цифровой трансформации» главный хайп корпоративных IT последних лет. Автоматизация и новые подходы к анализу данных, внедрение новых IT-систем определяет новых лидеров в различных секторах бизнеса. Важность развития IT-процессов для любой компании сегодня сложно переоценить.
«Где логика, где разум?» - вопрошал Вовочка из анекдота. Вот и мы удивляемся тому, что в 2021 IT-ландшафт нового поколения рассчитывается все так же вручную, как и 15, 20 и 30 лет назад.
Microsoft Excel – безусловный мировой лидер в области управления IP сетями, это известный каждому айтишнику факт. А как вы думаете, основной рабочий инструмент архитектора-проектировщика по IT инфраструктуре какой?
Вы, возможно, не поверите, особенно если сами никогда не работали проектировщиком, но Excel / Word / Visio. Да, у каждого вендора есть свой конфигуратор, но в конечном итоге из него идет экспорт в Excel, и дальше готовится КП (коммерческое предложение) в Word, готовится техпроект в Word, и может быть рисуются схемы в Visio. Если вендор не один на всю инфраструктуру, то приходится из пачки выгрузок в разных форматах собирать свою спецификацию вручную.
«А можно вот то же самое, но только на вендоре B» - вы никогда не слышали такого вопроса в последний момент, когда уже все посчитано и сведено?
Не знаю как вы, но члены нашей команды за более чем 10-летний опыт работы в крупнейших российских системных интеграторах и производителях оборудования прочувствовали это на собственной шкуре.
Увязнув в бесконечном процессе проработки IT-проектов и подготовки спецификаций, мысленно отмотав «счетчик человеко-дней» (читай «денег» наших работодателей), которые можно было сэкономить и направить в более продуктивное русло, мы решили создать инструмент, который облегчил бы жизнь множеству IT-профессионалов, задействованных в пресейле и проектировании IT-инфраструктуры.
И мы наконец-то можем представить первые результаты нашего труда общественности.
Наше решение – это SaaS платформа, которая позволяет облегчить проектирование ИТ-инфраструктуры с расчетом конфигураций оборудования различных производителях, автоматизировать подбор оборудования и создание спецификаций, а также быстро сравнивать и конвертировать решения между вендорами.
Начало
В основе платформы Miraworks лежат несколько идей:
Из одного интерфейса – с любым вендором. Мы хотим иметь «под рукой» информацию о решениях основных игроков рынка и работать с ней удобно и единообразно.
Все вспомогательное посчитайте сами. Ключевое – это функциональные требования, а не точное знание партномеров вентиляторов. Мы стремимся упростить процесс создания спецификаций насколько это возможно. Задавая обезличенные технические требования к решению, мы хотим получать полноценные спецификации на различных вендорах, а затем сравнивать их между собой.
Легкий импорт внешних спецификаций. А что если проект создается не с нуля? Предположим, вам прислали спецификацию и нужно её доработать или пересчитать скидку. Сейчас инженер вынужден делать множество манипуляций вручную, но мы считаем, что должна быть простая и понятная возможность импорта готовых спецификаций в систему. Все, что может быть автоматизировано, должно быть автоматизировано!
Графическое представление – это ключ к пониманию. Иногда инженер и вовсе начинает проработку с отрисовки схемы, а уже потом создает спецификацию. Но у нас никогда не было инструментов их синхронизации. Отсюда регулярные проблемы с тем, что схему перерисовали, а спецификацию не обновили, или просто забыли пару коммутаторов или трансиверов. У кого не бывало? Так появилась идея топологического конструктора с автоматическим подбором трансиверов, с проверкой совместимости между разными производителями.
"Вишенкой на торте” стал функционал конвертации спецификаций оборудования различных производителями в аналоги. Наверняка вам знакома задача «вот тебе спека на вендоре A, пересчитай на вендора Б». И хотя с инженерной точки зрения такая задача не всегда может быть корректна без учета требований к системе и её архитектуры, большинство инженеров будет сталкиваться с ней вновь и вновь. Путем декомпозиции свойств оборудования и его частей, оценки важности и приоритезации тех или иных параметров мы предложили своё решение для этой задачи.
На этом начался процесс разработки длительностью в 1,5 года.
Какие проблемы мы встретили и как искали решения мы и расскажем в этой статье.
* Дальнейшее описание будет оперировать в основном сетевым оборудованием, но все впереди. Скоро у нас появятся и серверные фермы, и виртуализация, и СХД
Итого
Написано строк кода – 200 000 строк
Добавлено оборудование вендоров – Huawei, Cisco, Juniper, Eltex
Внесено наименований оборудования и ПО – 12 838 позиций
Потрачено времени на разработку платформы – 18 месяцев
Подбор оборудования под ТЗ
В большинстве случаев инженер хорошо ориентируется в линейке оборудования одного вендора, возможно в двух, и намного реже встречаются специалисты, которые хорошо знакомы с тремя и более производителями. Хотя в основе решений разных вендоров лежат во многом одинаковые технологии и принципы построения комплексных систем, вряд ли хорошему архитектору стоит держать в голове номенклатуру оборудования и помнить принципы лицензирования функционала решений всех игроков рынка. Мы считаем, что инженер должен определять основные требования к системе, её архитектуру и состав компонентов, а наша платформа поможет легко и просто подготовить варианты реализации на различных производителях.
Изначально реализация подбора через опросный лист показалась нам относительно простой задачей, однако больше всего мы ломали голову именно над ней, и, надо признать, все еще совершенствуем алгоритмы.
За основу объекта спецификации берется самый крупный узел устройства - шасси со своим набором основных характеристик (портами и функциями). Далее к нему добавляются дочерние устройства и лицензии, также имеющие свои характеристики. В совокупности они образовывают комплект свойств, описывающих целевую спецификацию.
Поведение большинства позиций в спецификациях любого оборудования довольно прямолинейно — это либо некоторая аппаратная опция, подключаемая к шасси и имеющая конечное число копий, либо это лицензия, которая может быть применена один раз или многократно с наращиванием значения какой-то характеристики.
Но на практике встречаются случаи, которые эта модель не покрывает, да и вариативность комбинаций оказывается достаточно высока. Также существует масса вариантов, когда характеристики, которые дочерние компоненты добавляют к основному устройству, зависят не только от них самих, но и варьируются для разных сочетаний (например, один и тот же блок питания в коммутаторе А и в коммутаторе Б может давать разную мощность для суммарного POE-бюджета). А также этот блок питания, установленный как основной, дает мощность меньшую, чем если он установлен в качестве резервного, так как в первом случае часть мощности уходит под питание коммутатора, а во втором питание может полностью идти на конечные устройства. Такие ситуации требовали намного более сложных и разветвленных алгоритмов подбора, чем мы предполагали в начале, и нам приходилось совершенствовать их, стараясь при этом сохранить универсальность и модульность структуры алгоритмов. Все эти зависимости мы тщательно описали, и теперь они учитываются платформой.
Еще одна интересная особенность устройств заключается в вариативности характеристик. Например, у коммутаторов Cisco существует понятие SDM-темплейтов (аналогичные особенности есть и у других производителей, только называются они по-другому). Суть SDM-темплейтов в том, что ресурс устройства может быть перераспределен в зависимости от выбранного режима использования. Например, коммутатор может иметь 3 тыс. записей в MAC-таблице и 11 тыс. записей в таблице маршрутизации, либо 8 тыс. MAC-адресов и всего 2 тыс. IP маршрутов. Далеко не все инженеры знают об этих особенностях, и типичной ошибкой при подборе оборудования является ситуация, когда, глядя на даташит, где указаны поддержка «до 8 тыс. MAC» и «до 11 тыс. IP маршрутов», инженеры не учитывают, что эти параметры не выполняются одновременно.
В каталоге Miraworks модели коммутаторов, имеющие такие особенности, подбираются именно с учетом шаблонов ресурсов, которые подходят под конкретный запрос проектировщика. Ведь при проектировании инфраструктуры нам не так важны максимальные значения, сколько удовлетворение потребности заказчика в конкретном сценарии.
Другой, более существенный, пример – режимы портов коммутаторов, которые встречаются и у Cisco, и у Juniper, где базовое число портов 40G может быть уменьшено в пользу активации портов 100G, и один и тот же коммутатор может работать в режиме 32x40G или 16x100G, либо промежуточные комбинации, например 28x40G + 2x100G. По аналогии с ресурсными шаблонами система при поиске модели анализирует эту вариативность, что позволяет максимально точно подбирать модель под конкретные проектные требования. А еще бывают ситуации, когда добавление какого-то модуля требует установки определенных компонентов вместе с ним, например, высокопроизводительные фабрики коммутации у модульных свитчей для топовых плат. Так, для коммутатора Huawei S12700E при использовании низкопроизводительных плат будут добавлены базовые фабрики коммутации, но если вы добавите высокоскоростные платы 24x100G, система автоматически включит в конфигурацию полный комплект флагманских SFU.
А еще может оказаться, что под запрошенные характеристики лучше всего подходит готовый бандл. Тогда система просто предложит вам его на первых позициях выдачи, если он окажется дешевле аналогов в “поштучной” набивке. Свои особенности есть и у лицензий, которые зачастую бывают взаимоисключающими, а некоторые из них еще и обязаны присутствовать в любой конфигурации (в том числе, в режиме “одна из”), и под этот сценарий был адаптирован алгоритм подбора и разметки связности комплектующих. Например, новые серии коммутаторов Cisco Catalyst обязательно требуют включение в состав лицензий DNA.
Другой интересный момент - подбор комплектующих, которые все вместе должны удовлетворять требованиям заданной характеристики. Например, у некоторых модульных коммутаторов размер МАС-таблицы зависит от выбранных управляющих модулей, а у некоторых - от интерфейсных плат, которые бывают с разными аппаратными ресурсами: например, на 32 тыс. адресов или на 128 тыс. (а еще и с шаблонами распределения этих ресурсов, лицензиями, которые размер этих ресурсов увеличивают, и другие увлекательные ситуации).
Для корректной обработки таких запросов для каждого дочернего устройства устанавливаются специальные флаги, которые влияют на алгоритм сравнения итоговых параметров устройства, в некоторых случаях их суммируя, а в некоторых – выбирая наименьшее. На практике, по нашему опыту, эти особенности учитываются инженерами далеко не всегда, в документацию «кладутся» цифры из datasheet’ов, что может выливаться в большую головную боль всей проектной команды на этапе внедрения проекта.
Как видите, задача подбора по ТТХ довольно нетривиальная, возможно поэтому большинство инструментов, которые мы встречали, работают по принципу простейших фильтров. Мы же разработали алгоритм, который учитывает все вариации аппаратных компонентов и лицензий, ресурсных шаблонов и их сочетаний. То, что сейчас требует глубокого и длительного погружения инженера в документацию, мы постарались вывести в своего рода «магическую кнопку».
Подобрали спецификацию? А теперь пересчитайте ее на другом вендоре
Задача конвертации спецификаций – наиболее неоднозначная, но при этом и интересная и востребованная рынком. Её реализация, по сути, представляет собой процесс, обратный подбору по ОЛ – выделение обезличенных технических характеристик оборудования из спецификации, а затем новый подбор на их основе. Но на деле такой алгоритм часто дает абсолютно бредовые результаты и требует значительной оптимизации. В чем загвоздка описанного подхода?
Представим себе абстрактный коммутатор начального уровня с парой сотен характеристик. Если мы попытаемся подобрать устройство которое их удовлетворяет, либо мы получим 100% аналог сразу (если у него есть ОЕМ-версия от другого производителя) либо какой-то коммутатор сильно старшей линейки другого производителя. Абсолютно идентичного оборудования разных производителей не бывает. И тут наша гордость - наши обширные базы параметров - для каждого устройства играли против нас, так как сравнивать оборудование по ним дело неблагодарное.
В действительности многие из этой сотни параметров зачастую не критичны для реализации проекта. Объем памяти или емкость коммутации чипсета, которые зачастую прописываются в ТЗ, но слабо влияют на выбор моделей при проектировании – при незначительном несоответствии аналог может быть вполне оправдан.
А вот с портами получилась более интересная история. Например, можно ли заменить порт 10/100/1000 Мбит/с на порт 100/1000 Мбит/с? Или для порта мультирейт 1/2,5/5/10G является ли порт 1/10G его аналогом и в какой степени? А порт 1/2,5/5G? Это не совпадение, полное совпадение или частичное (какая-то доля совпадения)? И если доля, то какая?
Методом проб и ошибок, был создан “взвешенный” режим расчета релевантности, который включает в себя веса для каждого параметра, определяя его ценность в расчете суммарной релевантности подбора, ведь наш алгоритм уже рассчитан на то чтобы найти максимальную релевантность с минимальной ценой, нужно его лишь немного направить. К слову в системе сейчас доступен и “абсолютный” метод расчета, который эти веса игнорирует (ну вдруг кому-то понадобится).
Что касается портов, то каждый тип интерфейса раскладывается на составляющие, при этом учитывается “важность” этих составляющих (в нашем случае - это скорость, и чем она выше, тем больше её вес). В нашем примере для порта 1/2,5/5/10G, максимальной является скорость работы 10Гбит/c, совпадение с ней дает львиную долю релевантности по этому набору, вхождение в более низкие скоростные группы добивает возможную релевантность до 100%. Таким образом мы можем дифференцировать качество совпадения по портам при конвертации, давая максимальный приоритет наиболее важным совпадениям (а как правило порты выбираются для работы на максимальной скорости, а не минимальной), давая плавное разграничение по уровню коммутаторов и в итоговой выборке.
Перед нами все еще стоит сложная задача принятия решения об игнорировании некоторых параметров, т.к. текущий алгоритм может ранжировать коммутаторы максимально близко, и иногда результат может быть не оптимален: например, за счет параметров первыми в выборке могут предлагаться коммутаторы более высокого класса, чем оригинал.
Кроме того, не для всех случаев важность того или иного параметра очевидна и тогда «общие лекала» могут не подойти. Поэтому в результатах выборки мы выводим результаты, не только удовлетворяющие параметрам поиска на 100%, а предоставляем возможность сравнения с менее релевантными комплектами, с попозиционным сопоставлением всех значений в виде таблицы. Здесь инженер может сам оценить наиболее подходящее для замены оборудование.
При этом мы продолжаем адаптировать и совершенствовать алгоритм конвертации и в ближайшее время он станет еще более точным и удобным.
А ещё нарисуйте топологию
При разработке концепции Miraworks мы обратили внимание на подход BIM-проектирования (англ. Building Information Model или Modeling) в строительстве. Ведь специфика задач там очень похожа, ведомость изделий и материалов проекта здания и спецификация ИТ-проекта складываются в комплексную систему, в ходе разработки которой каждый компонент имеет множество свойств и взаимосвязей, а потеря информации об одном объекте чревата неработоспособностью системы в целом. Именно развивая идею объектного подхода, который объединяет характеристики объекта и выбранные для его создания «кирпичики», мы и поняли, как реализовать графическое представление.
Мы не нашли похожие проекты, которые бы уже реализовывали объектно-ориентированную модель в проектировании IT-инфраструктуры, от чего на старте проекта, с одной стороны, было немного страшно, а с другой - очень интересно.
Оценка возможности интеграции с привычным Visio выглядела удручающе: наши требования такое решение совсем не закрывало, ведь нам нужно не просто рисовать стенсилы и линии между ними, а заложить в них логику, синхронизировать их с объектами (оборудованием и ПО), а также иметь возможность редактировать информационную модель стенсила не уходя со схемы. В нашей модели соединительные линии – это вполне конкретные кабели, которые могут требовать наличие тех или иных трансиверов в зависимости от типа и длины кабеля. Все эти параметры влияют на выбор трансиверов, а, значит, эта задача также может быть автоматизирована.
К сожалению, оказалось, что готовых графических библиотек с поддержкой или с более-менее внятной документацией не так уж много, но так как разработка графического движка с нуля в наши планы не входила, выбор пал на библиотеку GoJS. Пока мы используем её в тестовом режиме, но, скорее всего, на ней и остановимся. К слову, она тоже имеет свои особенности и ограничения, но это уже совсем другая история.
В Miraworks топологический конструктор всегда синхронизируется со спецификацией, ведь процесс создания сетевой топологии и проработка спецификации (а именно с сетевой части было решено начать разработку платформы) всегда идут параллельно. Из спецификации можно перейти в схему, добавить на ней необходимые компоненты, а затем вернуться в конфигуратор и продолжить работать с ними уже оттуда.
И подготовьте ТКП на бланке
Мы знаем, что часто в работу инженеру в качестве исходных данных поступает уже подготовленная кем-то спецификация. Задача инженера - оценить ее или продолжить работу над ней, параллельно внося различные изменения. В Miraworks предусмотрена возможность быстрого импорта готовой спецификации, при этом не нужно подгонять исходный файл под специальный формат. Мы постарались сделать так, чтобы импорт работал «из коробки». Требуется просто загрузить таблицу в систему, выбрать нужную вкладку и указать столбцы с партномерами и их количеством. После импорта вы можете продолжить работать со спецификацией как будто вы создали ее в системе – редактировать, управлять топологией, конвертировать на других производителей и сравнивать с другими комплектами оборудования.
В части экспорта спецификаций доступна стандартная выгрузка в xls или pdf с различными настройками отображения, но куда более интересная опция - выгрузка сразу на бланке Вашей организации с факсимиле и подписью. Все, что от вас требуется - создать профиль организации и добавить в него данные, которые вы хотите видеть на бланке КП - реквизиты, логотип, печать и факсимиле, описание условий КП (блок текста перед и после спецификации). После чего в два клика вы сможете выгружать готовые КП в формате pdf. Хотите делегировать это право коллегам? Это тоже возможно, привяжите организацию к проекту и все, кто имеет права выгрузки КП в команде этого проекта, могут использовать эту возможность. Просто импортируйте спецификации, примените ваш шаблон скидок и выгрузите спецификацию в формате КП на бланке организации за считанные минуты!
Наш путь к оптимизации пресейла ИТ-проектов только начался, и мы будем рады периодически рассказывать о наших приключениях.
Спасибо за ваш интерес к статье, приглашаем посмотреть на нашу платформу «вживую».
Будет ли платформа полезна в работе вам лично? Какие функции, на ваш взгляд, были бы особенно полезны? Какие линейки оборудования вы бы хотели видеть?
Оставляйте ваши мнения и вопросы в комментариях.
