RiX-core.uz
Главная / Проекты / ATM Monitoring (RiX Core ATM)

ATM Monitoring (RiX Core ATM)

Система мониторинга банкоматов в LAN/offline-среде с ручным вводом статусов, инцидент-менеджментом по этапам и аналитическими отчётами (KPI/экспорт).

Python Django SQLite (LAN; опционально PostgreSQL) RBAC (Admin/Tech/Viewer) Шаблоны + локальная статика (offline)
Контекст эксплуатации
  • Среда эксплуатации: локальная сеть (LAN), без доступа в Интернет (offline).
  • Статусы вводятся вручную операторами/техниками.
  • Ключевые сущности: ATM, статус ATM, инцидент, этапы (Обнаружено → Диагностика → Восстановлено), SLA, downtime, цвет инцидента.
Проблема
  • LAN/offline muhitida bankomatlar bo‘yicha umumiy holatni tez ko‘rish qiyin.
  • Incidentlarni bosqichma-bosqich yuritish va izchillikni saqlash kerak (SLA/downtime).
  • Rahbariyat/analitika uchun qisqa hisobot va eksport talab qilinadi.
Решение
  • ATM reestri + statuslarni qo‘lda yangilash (operator/texniklar uchun).
  • 3 bosqichli incident management: Aniqlash → Diagnostika → Tiklash.
  • KPI bloklari, filtrlar, grafiklar va CSV/XLSX eksport (ranglar bilan).
Результат
  • Park holatini tez ko‘rish va muammoli ATMlarni ajratish.
  • Downtime/SLA nazorati va incident sabablarini jamlash.
  • Analitika uchun tayyor hisobot va eksport: “tez tushunarli demo”.

Глубокий разбор

Сжато и по делу: что делает система и почему это важно.

Назначение и цели

Система ведёт реестр банкоматов, позволяет вручную обновлять статусы, фиксировать неисправности как инциденты и управлять их обработкой по этапам.

Цели: быстро видеть картину по ATM, контролировать простой и SLA, накапливать причины инцидентов для улучшений и формировать отчёты/экспорт для аналитики.

Функциональные возможности (по модулям)

**Аутентификация и безопасность**
- Вход по логину/паролю, выход, запрет доступа неавторизованным
- Контроль ролей (RBAC) на уровне серверных обработчиков

**Банкоматы**
- Список + фильтры (ATM ID, MFO, статус, модель)
- Карточка банкомата
- Создание/редактирование (минимум Admin; расширяемо)
- Ручная смена статуса

**Инциденты (3 этапа)**
- Этап 1: обнаружение/создание
- Этап 2: диагностика (причина + комментарий)
- Этап 3: восстановление (время, комментарий, закрытие)
- Возможность указать фактическое начало простоя отдельно от времени обнаружения
- Хронология заметок + отображение последнего комментария
- Цветовая маркировка инцидента (4 цвета + сброс) с окраской строки и сохранением в БД

**Отчёты и аналитика**
- Фильтрация по периоду и атрибутам
- KPI-блоки (инциденты, downtime, MTTR, SLA и т.п.)
- Графики: топ простоев, причины (bar/pie), расширенная аналитика (accordion + якоря)

**Cash analysis ("Нет наличных")**
- Рейтинги MFO/ATM, тепловая карта по дням/часам
- Детализация событий с сохранением пользователя в нужной секции после фильтрации

**Детализация инцидентов**
- Расширенные фильтры (включая "без цвета"), сортировка по простою
- Управление цветом прямо из таблицы (dropdown)

Технический разбор: модель данных и расчёты

**Сущности** (минимальный набор): ATM, Incident, IncidentNote (комментарии), справочники причин/моделей/статусов.
**Расчёты**: downtime вычисляется как пересечение интервала простоя с периодом отчёта; MTTR агрегируется по закрытым инцидентам; SLA — по правилам реакции/устранения (настраиваемо).

Критичные моменты реализации:
- Раздельные поля: `detected_at` vs `downtime_started_at` (если известно)
- `restored_at` и признак закрытия
- Поле цвета (enum/строка) + обязательная консистентность в экспорте
- Хранение последнего комментария (или быстрый запрос последней заметки) для списков/отчётов

Надёжность, offline и безопасность

Проект рассчитан на работу в LAN/offline. Это влияет на архитектуру UI/статики и на эксплуатацию:

- Все фронтенд-зависимости должны быть доступны локально (без привязки к CDN)
- Данные (статусы/инциденты/цвет/комментарии) сохраняются в БД и доступны после перезапуска
- CSRF защита для POST, проверка ролей на сервере
- Бэкап: копирование файла БД + медиа/статик по регламенту

Переход с SQLite на PostgreSQL возможен без изменения бизнес-логики (при росте нагрузки).

Экспорт CSV/XLSX (принципы)

Экспорт должен учитывать активные фильтры/сортировки. В данные добавляется колонка **Цвет**.

Для XLSX важно визуальное сохранение маркировки: если у инцидента задан цвет, строка в XLSX заливается соответствующим цветом.

Нефункциональные ограничения: отчёты на странице могут показывать первые N записей (найдено/показано), экспорт может иметь больший лимит, но должен быть безопасен по времени выполнения.