Вы наверняка это видели: заходишь в проект, открываешь код — и сразу понятно, что тут поработали разные команды, каждая со своими привычками. Где-то копипастное болото, где-то хаос, документация — если повезёт, в устной форме от сеньора.
А теперь представьте другую картину: модули — по местам, код — читается, как хорошая книга, документация — в порядке, новичок — в процессе, а не в шоке. Это не фантазия, а Open vAIR.
Начинали как просто продукт, но по ходу обкатали архитектурные подходы, которые теперь используем как стандарт. И да — выложили всё в open source. Зачем? Сейчас расскажем. А заодно — что с этим делать вам.
О чём поговорим:
Почему без стандартов — всё разваливается
В IT любят кидаться словами вроде "best practices" и "clean architecture", но в реальности каждый пишет, как привык. Один проект — миллион стилей, архитектурная эклектика и логика, понятная только её автору (да и то — на свежую голову, в первый день после отпуска).
Формально есть всё: style guides, линтеры, код-ревью, CI. Но давайте честно: ими пользуются, когда удобно. В стартапах код пишется под огнём дедлайнов. В крупных компаниях — легаси превращается в священную корову: работает — не трогай. А в open-source за порядком следят, но диванные архитекторы не дремлют — за плохой код прилетает быстро и публично.
Что из этого выходит:
Разнородный код. Половина проекта — по канону, другая — как будто делалась на спор.
Онбординг на выживание. Джун смотрит в код, а код смотрит в него. И никто не улыбается.
Костыли вместо архитектуры. Хотели рост — получили «срочно прикрутить», «выпустим патч» и «чиним, не трогая».
Актуализация превращается в квест. Даже если хочется всё привести в порядок — страшно, долго и «а вдруг отвалится».
С некоторыми из этих проблем мы тоже столкнулись. К моменту, когда появилась идея Open vAIR, шишек уже было достаточно, чтобы захотелось: давайте сделаем по уму. Хотелось не просто «очередной проект», а продукт, который будет удобен в поддержке, масштабируем, прозрачен и пригоден для переиспользования. Так мы и подошли к разработке Open vAIR — как к шансу попробовать всё «как надо». И заодно — заложить фундамент того самого стандарта, которого всем не хватало.
Как появился Open vAIR
К моменту старта Open vAIR у нас в компании уже было несколько продуктов. Каждый — со своим стилем, логикой, любимыми паттернами и внутренними «традициями». Формально — всё работало. По факту — поддерживать и развивать становилось больно. Новый разработчик, вместо того чтобы вливаться в проект, разбирался, почему один кусок кода написан строго по SOLID, а другой — как получится. Где-то линтер, где-то дед-инсайд, где-то документация «в голове у Васи». Мы не сразу пришли к модульной архитектуре. Сначала просто искали: читали про DDD, пытались применить Clean Architecture, изучали best practices. Смотрели, как делают другие. Многие решения — либо громоздкие, как OpenStack (и завести их без жертв маловероятно), либо слишком заточены под узкие кейсы.
Хотелось простого: запустил, работает. Без недель конфигурации, без таинственных YAML’ов с зависимостями на пол-интернета. С этого и начался Open vAIR.
Так появился не абстрактный «универсальный стандарт», а рабочий инструмент, рождённый из боли. Мы не пытались навязать единственную истину, но выстроили принципы, которые реально помогают:
быстро понять, что происходит в коде, без расшифровки местных обычаев;
легко переключаться между проектами, не перенастраивая мозг каждый раз;
сократить ревью до сути, а не обсуждения стиля скобочек.
Мы не изобретали велосипед. Взяли известные практики — тот же DDD — и адаптировали под наши задачи. Так, шаг за шагом, выстроили модульную архитектуру, где каждый компонент изолирован, работает по контракту и не лезет в чужую логику. Добавить новый функционал — не переписывая половину системы — стало возможным. А главное, это можно повторить в других проектах.
Как мы работаем
Open vAIR не пилится на коленке по пятницам. У нас — вменяемый процесс, вполне по-людски организованный. Никаких откровений, просто здравый Agile: каждую неделю собираемся, определяем, что в приоритете, кто за что берётся — и поехали.
Как это устроено:
Планирование по понедельникам. Собрались, накидали задач, расставили приоритеты.
Issue — всё туда. Хоть баг, хоть хотелка, хоть «а давайте». Всё фиксируется.
Работа через pull request. Сделал задачу — оформил PR. Перед ревью изменения проходят ручное тестирование: проверяем, не развалилось ли ничего критичного, прогоняем основную логику. Только потом — ревью и merge.
Закрытие задач. После merge — задача автоматом закрывается, красота.
Telegram-бот. Подсказывает, кто чего заапрувил, где обсуждение, где пора ревьюить.
CI у нас минималистичный, без фанатизма. Большая часть тестов — вручную. Пока так, но работает: помогает не бояться нажимать на merge и не держать прод в заложниках. Плюс, на всякий случай, всё зеркало на GitFlick, GitVerse и GitLab — если GitHub однажды решит «а всё», мы продолжим писать, как ни в чём не бывало.
Главное — прозрачность и повторяемость. Такой подход легко адаптируется под другие команды и продукты. И главное — без боли.
Как устроен Open vAIR внутри
В основе Open vAIR — практичные, проверенные принципы. Мы перебрали кучу подходов, отсекая всё лишнее и оставляя только то, что действительно работает и упрощает жизнь разработчикам. Это не попытка вылепить «идеальный» стандарт ради галочки, а рабочий инструмент, который делает код понятным, разработку — предсказуемой, а поддержку — не адом.
Что лежит в основе:
Модульность. Каждый компонент изолирован и живёт по своим правилам. Если что-то ломается — ломается только оно. Остальное продолжает работать. (Привет, DDD!)
Прозрачные процессы. Все задачи — на канбан-доске в GitHub. Pull request — обязательный этап. Ревью — тоже.
Живое документирование. Используем Swagger и Sphinx. После установки проекта вся документация уже доступна — без дополнительных телодвижений.
Уведомления без лишнего шума. Telegram-бот в чате обсуждений следит за ишью, PR'ами и обсуждениями.
И простой стек — без магии.
С самого начала мы проектировали Open vAIR как платформу-конструктор. Можно использовать как есть. Можно — допилить под себя. Архитектура это позволяет.
Например:
Бэкап-модуль. Мы не планировали делать резервные копии — но появилось требование от product owner, и модуль с RESTIC-подкапотом встроился без боли.
Дополнительные модули. Хотите мониторинг, оркестрацию или что-то своё? Пожалуйста. Главное правило: новый функционал — это отдельный модуль. И если он упадёт, не утащит за собой остальное.
Надёжность важнее хайпа
Когда речь заходит о стандартах, закономерно звучит вопрос: «А зачем всё это?» Если подход не даёт ощутимой пользы, не упрощает поддержку и не стабилизирует систему — значит, он просто мешает. В Open vAIR мы пошли от обратного: от практических задач к конкретным решениям.
Мы сфокусировались на двух вещах: отказоустойчивость и производительность. Не ради отчётности, а чтобы система не падала, когда вокруг всё летит к чёрту, и не тормозила, когда её наконец начали использовать по назначению.
Отказоустойчивость
Open vAIR проектируется с расчётом на graceful degradation. Если один модуль вылетает — вылетает только он. Остальное продолжает жить. Например, если отвалится сервис, отвечающий за журналирование или бэкапы, виртуальные машины продолжат работать. Паники нет. Фатального краха — тоже.
Мы уже начали внедрять механизмы, которые усиливают устойчивость:
PostgreSQL с репликацией и масштабируемостью.
RabbitMQ в кластере — чтобы сообщения не шли в одно горлышко.
Corosync + Pacemaker — балансировка, резервные IP, отказоустойчивые связки.
Производительность
Ставили цель: ничего лишнего, всё быстро. Поэтому:
FastAPI + RabbitMQ — асинхронно, параллельно, без тормозов.
PostgreSQL — выжимает максимум даже без супернастроек, плюс можно легко нарастить мощности.
Вся архитектура — модульная, без лишних зависимостей. Один сервис не тянет за собой пол-системы.
Безопасность
Без лишней бравады: сейчас безопасность — это базовый уровень. Авторизация — через JWT. Код проверяется вручную. Отдельного security review пока нет, но если вы этим горите — приходите, будет чем заняться. Мы открыты к предложениям, в том числе по улучшению обработки ошибок, ограничению зон доступа, изоляции и другим темам.
Как мы используем Open vAIR — и как можете использовать его вы
Open vAIR — это не лабораторный концепт и не pet-проект с GitHub. Это полноценный продукт, ставший первым, созданным по новому стандарту. Внутри компании он лежит в основе архитектуры всех новых решений — от open-source до коммерческих. Это уже не эксперимент, а часть устойчивой практики. Переписывать старые продукты — дорого и больно. Поэтому там, где целиком перенести архитектуру нельзя, команды постепенно внедряют отдельные элементы: модульность, каноничные интерфейсы, единый подход к обработке данных. Всё это облегчает поддержку и даёт меньше поводов для фраз типа «а почему оно вообще работает?».
А теперь — про вас.
Мы открыли Open vAIR, потому что сделали действительно полезный, удобный и масштабируемый инструмент — не только для себя, но и для сообщества. Нам важно делиться тем, что работает, и развивать это вместе. Мы также стремимся углублять экспертизу в DDD-архитектуре и открыты к диалогу со сторонними специалистами, чтобы вместе исследовать её потенциал.
В открытом доступе — исходный код, документация и базовые модули виртуализации:
создание виртуальных машин;
настройка сетей и дисков;
работа с локальными хранилищами, NFS, iSCSI, Fibre Channel;
журналирование и прочее — список растёт.
Что дальше:
Прокачиваем KVM. Не размазываемся на всё подряд — делаем глубже, а не шире.
Работаем над расширением VLAN-лимитов. Уже есть идеи, как пробить стандартный потолок.
Улучшаем UI, шлифуем документацию. Не только для админов, но и для тех, кто впервые зашёл «просто попробовать».
Куда пойдёт Open vAIR дальше — зависит не только от нас. Если ты разработчик, архитектор, девопс или просто хочешь поучаствовать в чём-то полезном — заходи. В issues всегда есть задачи. В Telegram — диалоги. В проекте — место для тебя.
Присоединяйтесь к Open vAIR
Если хочется поучаствовать в чём-то полезном, живом и не унылом — добро пожаловать. Даже если вы не готовы сразу залезть в кодовую базу по уши, есть множество способов внести вклад.
Чем можно помочь:
Писать код. Новый модуль? Отлично. Если функциональность полезная — заберём в основную версию.
Тестировать. Чем больше нестандартных кейсов, тем лучше. Один из пользователей, например, пытался запустить Windows XP на виртуальной машине (да, в 2025 году) — и в итоге помог найти интересные нюансы.
Работать с документацией. Нашли опечатку? Объяснили сложное проще? Добавили пример? Спасибо, теперь и другим будет легче.
Что мы делаем сейчас:
клонирование виртуальных машин и шаблоны ВМ;
развитие кластеризации: High Availability, миграция между хостами и всё, что будет полезно;
улучшение работы с VLAN — экспериментируем с увеличением стандартных лимитов.
Интеграции с другими проектами пока обсуждаем — если появятся конкретные партнёры, расскажем отдельно. А пока — фокус на стабильности и развитии функционала.
Где нас найти:
GitHub: github.com/Aerodisk/openvair
Kanban-доска: github.com/users/Aerodisk/projects/2
Telegram-чат: t.me/Open_vAIR_AERODISK
Заключение
Open vAIR — это не набор догм, а живая платформа. Мы не исповедуем единственную истину, не выкатываем стандарты ради самих стандартов. Мы просто делаем инструмент, который помогает — и нам, и другим разработчикам.
Domain-Driven Design? Кто-то реализует его строго по книжке, кто-то адаптирует под себя. Мы — за второй подход. И если завтра кто-то предложит более удобную реализацию — рассмотрим. Потому что цель не в том, чтобы быть «правыми». Цель — чтобы работало.
Если тебе близка идея делать архитектуру не ради слайдов, а ради живого кода — заходи. В проекте хватит места и для сеньоров, и для тех, кто хочет разобраться, как устроена взрослая виртуализация. Присоединяйся — обсудим, поспорим, допишем.
