Возможности текущего сервера относительно Atlas
Оценка того, насколько существующий server2 подходит для запуска и развития Atlas — собственной платформы компаний, экспертов и платных публикаций. Документ основан на read-only аудите сервера от 2 сентября 2026 года. Там, где приведена оценка будущей нагрузки, это инженерный прогноз, а не результат stress test.
1. Итоговая оценка
2. Что уже есть и может быть использовано
| Компонент | Фактическое состояние | Роль в Atlas | Оценка |
|---|---|---|---|
| nginx | Активный reverse proxy 1.24.0, обслуживает несколько доменов | Публичный вход в Atlas, TLS, проксирование frontend/backend | ГОТОВО |
| Docker | Docker 29.6.1, Compose v5.3.1 | Изолированный stack Atlas | ГОТОВО |
| PostgreSQL | Есть контейнер PostgreSQL 17/pgvector | Пользователи, компании, статьи, заказы, индексация, аналитика | ГОТОВО |
| pgvector | Используется образ pgvector/pgvector:pg17 | Embeddings, semantic search, entity matching | ПОДХОДИТ |
| Redis | Redis 7.4 container | Очередь jobs, кеш, rate limiting, locks | ГОТОВО |
| MinIO | Есть отдельный object storage container | Логотипы, изображения, документы, обложки, вложения | ГОТОВО |
| Authentik | Отдельный auth stack с server/worker/PostgreSQL | Потенциально SSO/admin-auth; пользовательскую auth-схему Atlas можно проектировать отдельно | МОЖНО ИСПОЛЬЗОВАТЬ, НО НЕ ОБЯЗАТЕЛЬНО |
| llama-server | Локальный AI процесс, использует RTX 4080 SUPER | AI editor, classification, entity extraction, text checks | ГОТОВО ДЛЯ MVP |
| Let's Encrypt / Certbot | Сертификаты и certbot.timer присутствуют | HTTPS для Atlas | БАЗА ЕСТЬ |
| UFW / fail2ban | Активны | Базовая защита | ЕСТЬ, НУЖНА ДОПРОВЕРКА |
3. Ресурсный запас сервера
CPU
На момент аудита нагрузка была около 0.17–0.18 при 24 логических CPU, а vmstat показывал примерно 97% idle. Для обычного B2B web-приложения это большой запас. Публичные статьи, карточки компаний, личный кабинет, API и CMS сами по себе не являются тяжёлой нагрузкой.
RAM
Из 62 GiB RAM было доступно около 57 GiB. Текущие контейнеры занимали относительно небольшой объём памяти: frontend ~178 MiB, backend ~130 MiB, PostgreSQL SMM ~56 MiB, Redis ~17 MiB, MinIO ~139 MiB. Это означает, что новый изолированный Atlas stack можно разместить без заметного давления на память на стадии MVP.
GPU
RTX 4080 SUPER имеет 16 376 MiB VRAM. На момент снимка около 8 926 MiB уже использовалось локальной AI-нагрузкой, свободно было примерно 7 GiB. Поэтому GPU является не проблемой для нескольких AI-задач, но именно здесь первым появится лимит при массовой параллельной генерации материалов.
Storage
На проектном NVMe свободно около 842 GiB. На HDD 9.1 TiB свободно около 8.6 TiB. Для текстового медиа этого чрезвычайно много: даже десятки тысяч публикаций занимают ничтожный объём по сравнению с доступным пространством. Основной рост storage создадут изображения, документы, backups, crawler-архивы и AI datasets.
4. Что Atlas может запускать на server2 прямо сейчас
| Функция Atlas | Возможность | Что требуется |
|---|---|---|
| Публичный медиа-сайт | БЕЗ ПРОБЛЕМ | Отдельный frontend container + nginx |
| Карточки компаний | БЕЗ ПРОБЛЕМ | PostgreSQL + SSR/SSG frontend |
| Карточки экспертов | БЕЗ ПРОБЛЕМ | Та же база и API |
| Статьи / кейсы / исследования | БЕЗ ПРОБЛЕМ | CMS + object storage |
| Полнотекстовый поиск | БЕЗ ПРОБЛЕМ | PostgreSQL FTS; отдельный search engine не нужен на MVP |
| Semantic search | МОЖНО | pgvector + embeddings |
| Личный кабинет | БЕЗ ПРОБЛЕМ | Frontend/backend/auth |
| Модерация | БЕЗ ПРОБЛЕМ | CMS + workflow/statuses |
| Оплаты | НУЖЕН ВНЕШНИЙ ПРОВАЙДЕР | Payment provider + webhooks + idempotency |
| НУЖЕН ВНЕШНИЙ ПРОВАЙДЕР | Transactional email service | |
| AI-редактор | МОЖНО | Очередь Redis + llama-server |
| AI fact/structure checks | МОЖНО | Workers + лимиты |
| Embeddings | МОЖНО | pgvector + локальная/внешняя модель |
| Crawler | МОЖНО, НО ЧЕРЕЗ WORKERS | Rate limits, scheduling, robots/legal policy |
| Index monitoring | МОЖНО, НО НУЖНО ПРОЕКТИРОВАТЬ | Очередь, scheduler, хранение истории |
| AI Visibility monitoring | МОЖНО НА РАННЕМ ЭТАПЕ | Очереди, quotas, API/локальные модели, отдельные budgets |
| CDN/WAF | ВЫНЕСТИ НАРУЖУ | Внешний edge-провайдер |
5. Рекомендуемый Atlas stack на этом сервере
Ключевой принцип: Atlas должен быть отдельным Docker stack со своими volumes, базой и Redis, а не расширением уже существующего SMM stack.
6. Реалистичная нагрузочная зона
| Стадия | Ожидаемый масштаб | Оценка server2 | Комментарий |
|---|---|---|---|
| MVP | 100 пользователей / ~10 concurrent | С БОЛЬШИМ ЗАПАСОМ | Аудит прямо считает этот уровень реалистичным. |
| Ранний продукт | 1 000 зарегистрированных / до ~100 concurrent | РЕАЛИСТИЧНО ПОСЛЕ ПРОФИЛИРОВАНИЯ | БД, кеш, очереди и AI/crawler задачи должны быть правильно разделены. |
| Растущий Atlas | 10 000 зарегистрированных пользователей | САМО ПО СЕБЕ НЕ ПРОБЛЕМА | Количество аккаунтов мало влияет на нагрузку; важна concurrency. |
| Высокая concurrency | 500 concurrent | НЕ СЧИТАТЬ ГАРАНТИРОВАННЫМ | Нужны load tests и, вероятно, отдельные web/API/worker узлы. |
| Массовый AI | десятки одновременных генераций | GPU СТАНЕТ УЗКИМ МЕСТОМ | Нужна очередь, лимит concurrent jobs или внешние API. |
| Массовый crawling | десятки/сотни тысяч URL по расписанию | ВЫНОСИТЬ ПО МЕРЕ РОСТА | Не должен конкурировать с web/API за CPU, RAM и network I/O. |
7. Сколько публикаций может хранить сервер
С точки зрения дискового места именно статьи почти не являются ограничением. Текстовые записи, метаданные и structured data занимают очень мало. Даже если Atlas накопит десятки или сотни тысяч публикаций, гораздо больше места будут занимать обложки, пользовательские файлы, резервные копии и crawler snapshots.
Практическое ограничение будет определяться не количеством HTML-страниц, а скоростью базы, поиском, количеством одновременно работающих пользователей и фоновыми AI/crawler задачами.
8. AI-возможности сервера для Atlas
Генерация и редактура материалов
- Генерация статьи из брифа.
- Переписывание заголовка и лидов.
- Проверка структуры.
- Классификация материала.
- Выделение сущностей.
- Создание tags/topics.
- Рекомендации по GEO-структуре.
Помощник редактора, а не полностью автономный модератор
- Флаги SEO-spam / рекламный мусор.
- Поиск очевидных проблем структуры.
- Выделение потенциально проверяемых фактов.
- Проверка наличия обязательных полей.
- Оценка читабельности.
Много параллельных длинных материалов
На текущем GPU уже занято около 8.9 GiB VRAM. Поэтому Atlas не следует строить с предположением, что 50 клиентов одновременно будут генерировать длинные статьи локально без очереди. На раннем этапе лучше использовать job queue и ограничивать количество одновременных inference-задач.
9. Что станет узким местом первым
| Компонент | Когда становится проблемой | Что делать |
|---|---|---|
| GPU | Много параллельной генерации/анализа | Очередь → quotas → второй GPU/AI server или внешние API |
| Crawler | Большое количество внешних URL и частые проверки | Отдельные workers; потом отдельный crawler node |
| PostgreSQL | Высокая concurrency, тяжёлые analytics/query patterns | Indexes → pooling → profiling → при необходимости отдельный DB node |
| Network / edge | Рост публичного трафика и боты | CDN/WAF/cache |
| Backups | Появляются платные клиенты и пользовательские данные | Offsite backup + restore drill |
| Monitoring | Как только Atlas становится коммерческим | Uptime + error tracking + metrics + alerting |
10. Что нужно исправить до production
Аудит обнаружил значительное количество non-loopback listeners. Их реальная доступность из интернета не была подтверждена. Перед запуском Atlas необходимо определить, какие из них действительно доступны снаружи, и минимизировать attack surface.
Root login отключён, SSH ограничен LAN, fail2ban активен, но password authentication всё ещё разрешена. После проверки key-based recovery логично перейти на key-only access.
Backup-каталоги и timers существуют, однако аудит не доказал полное покрытие PostgreSQL, MinIO и Docker volumes и не подтвердил успешный restore test. Для платного ресурса этого недостаточно.
Не обнаружены подтверждённые Grafana/Prometheus/Sentry/external uptime monitoring. Для production нужны хотя бы uptime checks, error tracking и оповещения о проблемах приложения, базы и дисков.
В аудите не подтверждена полноценная dev/staging/prod схема. Atlas лучше сразу разворачивать отдельными staging и production окружениями, чтобы публикационный сайт не ломался при каждом релизе.
11. Как использовать диски
| Хранилище | Что размещать |
|---|---|
| NVMe /mnt/ssd_projects | PostgreSQL, Redis persistence, MinIO hot-data, application volumes, indexes, embeddings, active logs |
| HDD /mnt/data10tb | Архивные backups, historical crawler datasets, экспортные архивы, старые assets, долгосрочное хранение |
| Offsite storage | Копии PostgreSQL/MinIO/config, которые должны пережить полную потерю server2 |
12. Предлагаемое ресурсное разделение Atlas на MVP
Точные лимиты следует поставить после первого профилирования, но исходный подход может быть таким:
| Контейнер | Начальный принцип | Причина |
|---|---|---|
| atlas_frontend | Небольшой CPU/RAM лимит | SSR/SSG web слой не должен потреблять много ресурсов |
| atlas_backend | Несколько CPU, умеренный RAM | API и бизнес-логика |
| atlas_postgres | Приоритет на RAM и быстрый NVMe | Главный persistent state |
| atlas_redis | Небольшой RAM limit + persistence policy | Queue/cache/locks |
| atlas_minio | NVMe для hot data | Assets и документы |
| atlas_worker | CPU/RAM limit | Не позволять background jobs мешать web |
| atlas_ai_worker | Concurrency=1..N по фактическому профилю | Защита GPU и latency |
| atlas_crawler | Низкий приоритет + rate limit | Фоновая сеть/CPU не должна влиять на сайт |
13. Когда потребуется отдельный сервер
Не по количеству статей. Не по количеству зарегистрированных компаний. Переезд или разделение инфраструктуры имеет смысл, когда появляется одна из следующих ситуаций:
- AI очередь становится постоянным bottleneck;
- crawler выполняет десятки или сотни тысяч внешних проверок и мешает основному приложению;
- PostgreSQL становится критичным single point of failure для существенной выручки;
- появляется высокая реальная concurrency;
- бизнесу нужен SLA, который нельзя обеспечивать одной физической машиной;
- backup/restore и disaster recovery требуют географического разделения;
- Atlas становится слишком важным, чтобы делить server2 с другими экспериментальными проектами.
14. На сколько Atlas хватает текущего server2
Практический ориентир: если Atlas доходит до первых 20–30 платных публикаций в месяц, сервер менять не нужно. При 50–100 публикациях в месяц сервер также должен оставаться достаточным при корректной архитектуре. Вопрос отдельной инфраструктуры становится актуальным не из-за количества публикаций, а при росте concurrent traffic, AI-нагрузки и фонового мониторинга.
15. Что нужно сделать перед началом разработки Atlas
| Приоритет | Действие |
|---|---|
| P0 | Создать отдельный Docker network/stack/volumes для Atlas. |
| P0 | Определить staging и production схему. |
| P0 | Проверить backup PostgreSQL/MinIO и провести тест восстановления. |
| P0 | Проверить реальную внешнюю доступность всех non-loopback ports. |
| P1 | Настроить monitoring, error tracking и external uptime checks. |
| P1 | Определить secrets management. |
| P1 | Подключить CDN/WAF. |
| P1 | Определить transactional email provider. |
| P1 | Определить payment provider. |
| P2 | Провести metadata-only audit PostgreSQL: sizes, extensions, max_connections. |
| P2 | После MVP провести load test именно Atlas. |
16. Финальный вывод
С инженерной точки зрения Atlas не требует новой серверной инвестиции на старте. Текущая инфраструктура позволяет сосредоточиться на продукте, контенте, SEO/GEO-архитектуре, модерации и продажах. Главная работа перед production — не расширение железа, а изоляция Atlas, backup/restore, security, monitoring, staging и организация background workloads.
Источник данных
Основание документа: read-only аудит server2 от 02.09.2026. В нём зафиксированы i7-13700F, 62 GiB RAM, RTX 4080 SUPER 16.4 GiB, Ubuntu 24.04.3 LTS, Docker, PostgreSQL/pgvector, Redis, MinIO, nginx, Authentik, локальный llama-server, свободный NVMe/HDD и текущая низкая нагрузка. Нагрузочные выводы Atlas являются инженерной интерпретацией этих данных и требуют подтверждения load testing после появления приложения.