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