Найдите решение по признакам

Фрагментация систем — это не техническая проблема, а бизнес-риск. Невозможно управлять тем, что не видно в едином поле.

Решение

• Единая платформа с модулями: производство, склад, логистика, бухгалтерия.
• API-интеграция существующих систем без их замены.
• Единый дашборд для руководителя с данными из всех отделов.
• Автоматические уведомления при отклонениях от нормы.

Результат: все отделы работают с одними цифрами, решения принимаются быстрее.

Управление по факту — это постоянное тушение пожаров. Руководитель не может предотвратить то, о чём не знает.

Решение

• Дашборд в реальном времени с ключевыми метриками производства.
• Автоматические алерты при выходе за пороговые значения.
• Прогнозные отчёты: что произойдет через смену, если ничего не менять.
• Единый источник правды для всех уровней управления.

Результат: управление становится упреждающим, а не реактивным.

Резервное копирование — не «сделать копию», а «гарантировать восстановление». Backup, который никогда не восстанавливали — это не backup.

Компоненты стратегии

• pg_dump — логическое резервное копирование. Полный снимок схемы и данных. Запускается по расписанию (cron/systemd timer).
• WAL-архивирование — PostgreSQL пишет WAL (Write-Ahead Log). Архивирование WAL позволяет восстановить состояние БД на любую минуту (Point-in-Time Recovery).
• Хранение — backup хранится на отдельном сервере или в облачном хранилище (S3-совместимое). Не на том же сервере, что и БД.
• Тест восстановления — регулярно (раз в месяц) восстанавливаем backup на тестовом сервере и проверяем целостность.

Типичное расписание

• Полный pg_dump — ежедневно ночью.
• WAL-архивирование — непрерывно.
• Хранение — 30 дней (полные) + 7 дней (WAL).
• Тест восстановления — ежемесячно.

Это базовый уровень. Для критичных систем — репликация на горячий резерв (streaming replication).

Схема базы данных меняется по мере развития системы. Без версионирования миграций — хаос: на dev одна схема, на prod другая, откат невозможен.

Alembic — что даёт

• Версионирование — каждая миграция имеет ревизию. `alembic upgrade head` применяет все неприменённые. `alembic downgrade -1` откатывает последнюю.
• История — видно, когда и какая миграция применена. `alembic current` — текущая ревизия на prod.
• Безопасность — перед миграцией автоматически создаётся backup. Если миграция не прошла — откат.

Правила

• Миграции должны быть обратимыми — для каждой `upgrade` пишем `downgrade`.
• Не блокируем таблицы там, где можно. Добавление колонки с default — без блокировки. Пересоздание индекса — `CONCURRENTLY`.
• Не делаем миграции, которые меняют данные массово. Сначала схема, потом отдельный скрипт данных.
• Тестируем миграцию на копии prod перед применением.

Это позволяет обновлять систему без остановки работы склада или производства.

On-premise — развёртывание на сервере заказчика. Данные не покидают периметр. Нет облачных зависимостей. Полный контроль над всем стеком.

Стек развёртывания

• Docker — контейнеризация приложения. Изолированная среда, одинаковая на dev и prod.
• Docker Compose — оркестрация: приложение + PostgreSQL + Nginx. Одна команда запускает весь стек.
• Nginx — обратный прокси, TLS, статика.
• PostgreSQL — в отдельном контейнере, данные на volume.

Что получает заказчик

• docker-compose.yml — конфигурация всего стека.
• .env — переменные окружения (пароли, пути).
• Инструкцию по запуску — одну команду.
• Backup-скрипты — регламентное копирование.
• Мониторинг — health-check эндпоинты.

Почему не Kubernetes

Для MES/WMS на одном предприятии Kubernetes — избыточен. Docker Compose достаточно: один сервер, один стек, простое управление. K8s имеет смысл при масштабировании на несколько предприятий или при микросервисной архитектуре с десятками сервисов.

Ролевая модель доступа (RBAC — Role-Based Access Control) — каждый пользователь имеет роль, роль определяет доступ.

Типичные роли в MES

• Рабочий — видит свои операции, закрывает наряды. Не видит чужие операции, зарплаты, отчёты.
• Мастер — видит весь цех, назначает операции, контролирует выработку.
• ОТК — видит брак, причины, качество по операциям.
• Руководитель — видит отчёты, аналитику, KPI. Не видит детали операций (если не нужно).
• Администратор — управляет пользователями и ролями.

Типичные роли в WMS

• Кладовщик — приёмка, отгрузка, перемещения, инвентаризация.
• Комплектовщик — сборка заказов по маршруту.
• Менеджер — заказы, остатки, аналитика.
• Руководитель — KPI склада, отчёты.

Реализация

• JWT-токены с ограниченным сроком жизни.
• Проверка роли на каждом API-эндпоинте.
• LDAP/AD-интеграция — для корпоративных систем с единой учёткой.
• Аудит-лог — кто и когда обратился к данным.