Уронить нельзя поддерживать сеть

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

Преамбула

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

Story

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

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

И подборка полного функционального аналога не выглядела простой задачей.

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

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

Мы хотели простую, но функциональную систему, желая сохранить текущие интеграции с другими сервисами, или даже их расширить. Готовых AIO решений под наш зоопарк серверов и сетевого оборудования не нашлось. Даже крутые вещи наподобие NOC недотягивали до наших требований: либо не хватало функционала, либо поддержки сетевых устройств. И тут пришлось бы уходить в содержание сразу нескольких решений, что, на наш взгляд, непродуктивно от слова совсем.

Мы пошли любимым нами путём.

Так зародилась идея иметь полный контроль над сетью и её мониторингом в одном месте, без компромиссов (да, было больно и тернисто, но мы справились). Проект получил кодовое название UnicNet.

Задачи:

• Инвентаризация, максимальная актуальность всего парка сетевого оборудования, сканирование сети для автонаполнения базы устройств. 
• Массовое конфигурирование сетевого оборудования: чем проще, тем лучше. Инфраструктура как код (IaC) выглядела идеальным подходом под этот концепт. 
• Контроль конфигураций с полной историей изменений; удобный компаратор конфигов; сигналинг и откат изменений руками и по триггеру при получении данных по SNMP или SYSLOG. 
• Визуализация топологии сети с динамическим обновлением ее состояния, L2+L3.
• Группировка девайсов, теги, локация, быстрая БД устройств, которая махом перелопатит и выдаст любые объёмы списком, да ещё и с фильтрами и поиском (а вот и вопросы масштабирования системы подъехали).
• CLi — чтобы не хуже, чем у Putty и CMD, но с вечной памятью команд, избранными командами, и чтобы удобный. Ну и рабочие SNMP запросы оттуда же (мы же можем себе это позволить).
• Автоматизация любых задач с расписанием и удобной выборкой устройств для реализации Zero-Touch Provisioning (ZTP), чтобы любой юзер мог настраивать целые сети в пару кликов, заливая таким образом готовые конфигурации из базы UnicNet. Туда же — автодискавер, автообновление данных в базе, и главное — нормальные скрипты, в нативном виде для устройства. Но не уходить же от готовых скриптов Ansible — надо сделать интеграцию…
• …и как-то решить задачу простоя сетевых участков или недоступности ресурсов, пока идёт решение каких-либо проблем, возникших в сети. Ключевая задача — ускорить процесс, чтобы инженеры не сидели часами в командной строке и логах Zabbix.
• Максимальный охват вендоров. Российские сферы богаты на истории с содержанием древнего, а иногда и непопулярного оборудования в своих сетях. Да и мы сами понимали, что нет смысла становиться очередной системой с узкой поддержкой, всё-таки для нас не менее важно не только решать свои задачи, но и коммерциализировать продукты. 
• Быстрый и красивый UI, и дайте тёмную тему! (мы совсем не против кучи окошек Cli, но UX наше всё)

Вывод

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

Во второй части рассказываю, что из себя по существу представляет наше решение и как его готовим мы и наши клиенты. И конечно же о наших планах на будущие итерации UnicNet:

• Развертывание в Kubernetes
• Поддержка distributed databases
• Использование ML-моделей для предсказания сбоев сети, анализ аномалий на основе статистики
• Оптимизация QoS-параметров на основе анализа трафика
• Как мы ушли в разработку модуля для создания цифрового двойника сети (Network Digital Twin) и куда пришиваем этот ваш ИИ.
• Интеграции с облачными решениями и ещё много всего…