Задача
Перенос сервиса на другой узел, покупку более мощного сервера или изменение топологии обычно проверяют уже после внедрения, когда ошибка стоит денег и простоя. Разговор о модернизации опирается на ощущения администраторов: неясно, какие ресурсы востребованы, какой узел упрётся первым и даст ли закупка измеримый эффект.
Сложность в том, что нагрузку нельзя описать одним числом. Она рождается из поведения людей: бухгалтерия открывает ERP по утрам, отдел продаж весь день сидит в CRM, склад печатает документы, почта работает фоном у всех. Чтобы прогноз имел смысл, модель должна связывать действия сотрудников, зависимости сервисов и физическую топологию сети в одном времени и давать результат, который можно сравнить с другим вариантом конфигурации.
Решение
Платформа собрана из четырёх связанных уровней, и каждый следующий опирается на предыдущий.
Модель инфраструктуры. В визуальном редакторе создавались площадки, помещения, серверы, диски, сетевые устройства, каналы связи и топология сети. Для каждого узла задавались вычислительные ресурсы, тип хранения, пропускная способность, задержки и стоимость эксплуатации. Без цены оборудования оптимизация всегда приводит к совету «купите самое быстрое».
Модель сервисов. На физических узлах размещались почта, веб-приложения, CRM, ERP, файловые хранилища, принтеры и прочие корпоративные сервисы. Описывались их зависимости друг от друга, характер запросов и требования к процессору, памяти, диску и сети.
Модель пользователей. Через конструктор или формулы описывались типы поведения: какие действия выполняет сотрудник, к каким сервисам обращается, с какой частотой и в какое время. Типы объединялись в группы, численность группы менялась под конкретный эксперимент, и «рост штата на треть» можно было проверить на модели.
Экспериментальный движок. Симуляция воспроизводила действия пользователей как поток событий, маршрутизировала запросы по заданной сети и считала очереди, задержки, пропускную способность и загрузку каждого узла. Во время прогона интерфейс показывал движение запросов и изменение нагрузки, после — отчёт по сервисам, оборудованию и сетевым сегментам: загрузка, время ответа, очереди, отказы и точки, где инфраструктура переставала справляться.
Сценарии. На этой основе строились сравнения, которых обычно не бывает в реальной сети:
- одна и та же группа пользователей на нескольких версиях топологии — A/B-тест инфраструктуры;
- разные группы и профили поведения на одной конфигурации сети;
- рост численности сотрудников или интенсивности запросов без изменения оборудования;
- переносы сервисов, изменение маршрутов, добавление кэша, замена дисков и сетевых устройств.
Сценарии и версии модели сохранялись, поэтому эксперимент можно было воспроизвести и сопоставить результаты между собой.
Оптимизация топологии. Отдельный модуль анализировал результаты симуляций и предлагал более рациональное размещение сервисов. Для каждого ресурса учитывались частота обращений, требования к диску и сети, критичность задержки, объём данных и стоимость оборудования: горячий CRM-сервис логично держать на узле с NVMe и быстрым сетевым доступом, а редко используемую корпоративную wiki — на дешёвом сервере с HDD в менее приоритетном сегменте. Алгоритм перебирал допустимые перемещения, отбрасывал варианты с нехваткой ресурсов и оценивал остальные по взвешенной функции: время ответа, перегрузка узлов, сетевой трафик, стоимость и запас производительности. Лучшие конфигурации повторно прогонялись через ту же модель пользователей, и рекомендация возвращалась к архитектору уже проверенной.
Десктопное приложение построено на Qt и C#.
Результат
Ещё до закупки оборудования и переноса сервисов архитектор мог собрать модель существующей инфраструктуры, воспроизвести нагрузку разных подразделений и увидеть, где возникают задержки и перегрузки. Варианты сравнивались в одинаковых условиях, а не по памяти о прошлом инциденте.
Платформа связала в один цикл то, что обычно живёт в разных инструментах и разных отделах: инвентаризацию оборудования, нагрузочное тестирование, анализ узких мест и оптимизацию размещения ресурсов. Система показывала проблемное место, предлагала новую конфигурацию и тут же проверяла её на цифровом двойнике.
