Тема

Страница фиксирует минимальный эксплуатационный контур зрелого CMMS-модуля в Narmak: какие зависимости должны быть подняты, какие API и фоновые процессы считаются обязательными, и какой smoke-check нужно пройти после выкатки.

Что входит в release-ready контур ​

  • Управление оборудованием, категориями, деревом активов и счётчиками.
  • Полный lifecycle ремонта: RepairRequest → WorkOrder → CompletedAct.
  • Контур осмотров и дефектов: InspectionPlan, InspectionRecord, DefectJournal.
  • Контур ППР: графики, строки ППР, автосоздание заявок по просроченным строкам.
  • Reliability/analytics: простои, причины отказов, dashboard агрегатов.
  • Role-aware workflow: approvals, ограничения переходов, audit history.
  • Внешний requester-поток через c-api/v1/repair-requests/.
  • Technician-friendly очередь через GET /api/v2/plant-maintenance/workorders/my-queue/.

Обязательные зависимости ​

  • PostgreSQL с применёнными миграциями plantmaintenance.
  • Redis для уведомлений, Celery и отложенных автоматизаций.
  • celery worker для execution задач и сигналов.
  • celery beat для reminders, overdue-обновлений и ППР-автоматизаций.
  • Swagger/Redoc или сгенерированный frontend SDK после обновления API-контракта.

Миграции и backend rollout ​

bash
cd backend/narmak_v2

poetry install
poetry run python manage.py showmigrations plantmaintenance
poetry run python manage.py migrate plantmaintenance
poetry run python manage.py migrate
poetry run python manage.py check_plantmaintenance_readiness

Критично проверить, что миграции с изменением enum/choices для RepairRequest.Source и новыми полями аудита применены без ручных правок в базе.

Обязательные Celery-задачи для CMMS ​

  • plantmaintenance.generate_active_ppr_items: генерация элементов ППР по активным графикам. Без этого preventive engine не пополняет очередь работ.
  • plantmaintenance.check_overdue_inspections: перевод просроченных осмотров в OVERDUE. Влияет на dashboard и уведомления.
  • plantmaintenance.check_meter_thresholds: контроль порогов счётчиков. Нужен для meter-driven maintenance.
  • plantmaintenance.auto_create_repair_requests: автосоздание заявок по просроченным ППР. Связывает ППР с repair lifecycle.
  • plantmaintenance.send_reminders: reminders по осмотрам, зависшим нарядам и активным простоям. Замыкает automation и notification loop.

Smoke test после релиза ​

Backend ​

  1. Открыть /swagger/ и убедиться, что доступны: repairrequests, workorders, completedacts, inspectionplans, defectjournals, analytics/dashboard.
  2. Проверить c-api/v1/repair-requests/ под пользователем контрагента.
  3. Проверить GET /api/v2/plant-maintenance/workorders/my-queue/ под исполнителем.
  4. Проверить, что transition для RepairRequest и WorkOrder возвращает server-driven available_transitions.

Frontend ​

  1. main-office: открыть dashboard ТОиР, карточку заявки, карточку наряда и экран Мои наряды.
  2. counterparty-office: создать внешнюю сервисную заявку и открыть её карточку.
  3. Проверить, что build проходит после обновления API-клиента.

Бизнес-процесс ​

  1. Создать внешний RepairRequest через requester-поток.
  2. Утвердить заявку менеджером ТОиР.
  3. Создать WorkOrder, назначить исполнителя.
  4. Перевести наряд из technician-очереди в in_progress, затем в completed.
  5. Оформить CompletedAct.
  6. Проверить историю изменений и уведомления.

Минимальный тестовый пакет перед production ​

bash
cd backend/narmak_v2
poetry run pytest app/plantmaintenance/tests/ -q

cd ../../frontend/narmak-nx-angular-main
yarn nx run main-office:build:development
yarn nx run counterparty-office:build:development

Особое внимание:

  • API-тесты на permissions и workflow.
  • Контрактные тесты на requester API и technician queue.
  • Smoke-build main-office и counterparty-office после изменений DTO/SDK.

Операционный мониторинг ​

  • Dashboard ТОиР должен отображать актуальные KPI и активные уведомления.
  • Flower должен показывать успешное выполнение plantmaintenance.send_reminders.
  • Логи backend не должны содержать повторяющихся ошибок PermissionError, ValidationError и проблем с audit/history endpoints.
  • При росте числа простоев контролируйте метрики availability_percent, mtbf_hours, mttr_hours.

Риски rollout ​

  • celery beat выключен: reminders и overdue-автоматизации перестают работать silently.
  • SDK не пересобран: frontend может использовать устаревший контракт.
  • Пользователь не включён в нужную группу/не назначен исполнителем: server-driven transitions будут урезаны.
  • Контрагент не привязан к counter_party: requester portal не сможет подавать заявки.

См. также ​

Copyright © 2025 Positive Brands / Narmak