Оборудование
NAS-серверы, коммутаторы, IPTV-приставки и настройки СОРМ — всё сетевое оборудование, которым управляет биллинг.
3. Оборудование
Раздел меню «Оборудование» объединяет всё сетевое и абонентское оборудование, через которое работает биллинг.
3.1. NAS
URL: /admin/equipment/Nas/
NAS (Network Access Server) — устройство, через которое клиент попадает в сеть: BRAS, MikroTik, коммутатор с авторизацией. Для биллинга это одновременно RADIUS-клиент (шлёт Access-Request и Accounting) и цель управляющих команд (CoA Disconnect, SSH). На проде 12 устройств.
Что такое NAS для биллинга
- NAS
- Идентификация
- IP и маска
- RADIUS secret
- Тип устройства
- Организации
- Роль RADIUS
- Access-Request
- Accounting
- Пулы адресов
- Параметры тарифа
- Управление
- CoA Disconnect
- SSH fallback
- Развёртывание конфигов
- Перезапуск FreeRADIUS
- Наблюдение
- UP DOWN
- Онлайн-сессии
- Простой за сутки
- SLA и алерты
Из этой карты следует главное: NAS — не просто запись в справочнике. Ошибка в secret рвёт авторизацию всем клиентам устройства, а неверный IP делает CoA бесполезным — команда уйдёт в никуда, и заблокированный клиент останется в сети.
Как проходит авторизация
flowchart LR
AB["Клиент
подключается"] --> NAS["NAS"]
NAS -->|"Access-Request
+ secret"| RAD["FreeRADIUS"]
RAD --> CHK{"Клиент известен?
clients.conf"}
CHK -->|"нет"| DROP["Пакет отброшен"]
CHK -->|"да"| USR{"Учётка и
тариф есть?"}
USR -->|"нет"| REJ["Access-Reject"]
USR -->|"да"| BAL{"Баланс и
блокировки"}
BAL -->|"заблокирован"| REJ
BAL -->|"ок"| ACC["Access-Accept
+ IP + шейпер"]
ACC --> SESS["Сессия в
USERS_RADIUSAUTH"]
SESS --> ONL["Колонка «Онлайн»
в списке NAS"]
clients.conf генерируется из таблицы NAS при старте контейнера FreeRADIUS. Поэтому после добавления устройства или смены secret нужен перезапуск RADIUS — иначе новый NAS для демона не существует. Список сам показывает предупреждение, когда конфигурация изменилась.
Список устройств

- KPI-чипы справа: Всего / UP / DOWN / Онлайн / CoA-готовность. Считаются по всей выборке, не по странице.
- Чипы-фильтры со счётчиками: Все · UP · DOWN · без RADIUS · без SSH · PROD · выключенные. Состояние переносится в URL, ссылку можно отправить коллеге.
- Состояние (UP/DOWN/OFF) — из
NasStatusLog, с подсказкой о длительности простоя. Строки DOWN подсвечены. - Колонка «Орг.» — организации устройства, см. Мультиорганизация.
- Онлайн — прогресс-бар «активных / максимум». Клик по числу открывает список сессий.
- Бейджи у имени: PROD (боевое), CoA (Disconnect настроен), SSH (только SSH-fallback).
Адрес установки сокращается многоточием: полный остаётся в подсказке. Так таблица помещается в экран без горизонтальной прокрутки — а она в списке оборудования особенно мешает, потому что взгляд идёт по строке до колонки «Состояние».
Мультиорганизация
Связь NAS с организацией — «многие ко многим», а не одна компания на устройство. Причина простая: один BRAS обслуживает клиентов нескольких организаций сразу, и жёсткая привязка была бы неверной.
- Колонка «Орг.» показывается только при мульти-орг и режиме «Все организации».
- Организации отмечаются чекбоксами в полосе статистики карточки — сразу видно, кого обслуживает устройство.
- Устройств без организации быть не должно: при переходе на связь всем существующим проставлена организация по умолчанию.
Список NAS намеренно не скоупится по организации. Сотрудник компании должен видеть оборудование, через которое работают его клиенты, даже если устройство принадлежит другой организации — иначе диагностика «почему у клиента нет интернета» упирается в пустой экран. Скоуп стоит там, где раскрываются данные клиентов.
Что видит сотрудник чужой организации
flowchart LR
REQ["Запрос сотрудника"] --> T{"К чему обращается"}
T -->|"список NAS"| OPEN["Виден весь
парк устройств"]
T -->|"сессии, панель клиентов"| SCOPE["Фильтр по
организации клиента"]
T -->|"отключить, IP, resync"| GUARD["Проверка клиента"]
T -->|"перезапуск RADIUS"| PERM{"Админ сети?"}
GUARD -->|"чужой"| E404["404"]
GUARD -->|"свой"| DO["Действие выполняется"]
PERM -->|"нет"| E403["403"]
PERM -->|"да"| RST["Перезапуск"]
Ответ на чужого клиента — 404: одинаковая реакция на «нет такого» и «есть, но не ваш» не даёт перебором выяснить, какие клиенты существуют. Перезапуск RADIUS отвечает 403 — здесь скрывать нечего, а причина отказа должна быть понятной.
Карточка устройства

Шесть вкладок. Сверху — полоса статистики (активных / максимум / последняя авторизация) и чекбоксы организаций.
RADIUS

RADIUS secret — общий ключ с устройством; при несовпадении демон молча отбрасывает пакеты, и клиенты просто не авторизуются. CoA пароль и порт (по умолчанию 3799) нужны для команды Disconnect. Флаг «Не использовать CoA» переводит разрыв сессий на SSH-fallback — медленнее, но работает там, где CoA не включён.
Авторизация

Правила выдачи доступа: тип авторизации, привязка к MAC и порту, поведение при переподключении. Здесь же — «Отправлять подключение если заблокирован»: для схем с walled-garden, где заблокированного клиента пускают на страницу-заглушку вместо полного отказа.
IP-пулы

Пулы динамических и белых адресов, NAT, hotspot, DNS и «следующий NAS» для цепочек. Из этих пулов выдаётся адрес при авторизации; свободный ищет ip_allocation с проверкой занятости по трём источникам сразу.
Онлайн-сессии

Открывается кликом по числу в колонке «Онлайн». Поиск по логину, ФИО, договору и IP; подгрузка по мере прокрутки. Клик по имени открывает боковую панель клиента поверх списка — оператор смотрит карточку, не теряя разобранный список сессий.

3.2. Состояние NAS
URL: /admin/equipment/nas_status/

Страница для дежурного: что сейчас лежит и насколько это больно.
- Алерт сверху — какие устройства недоступны, сколько минут и сколько клиентов затронуто. Появляется только при авариях.
- Sparkline за 24 часа — 24 столбика по часам: зелёный (работал), оранжевый (частичный простой), красный (лежал более половины часа). Видно, это разовый сбой или устройство «моргает» третьи сутки.
- Затронутые клиенты — клик по числу открывает тот же список сессий.
- SLA за 7 и 30 дней с порогами из настроек (
NAS_SLA_TARGET_PCT,NAS_SLA_WARNING_PCT). - Авто-обновление (30 с / 60 с / 5 мин) через отдельный JSON-эндпоинт: перерисовываются только строки и KPI, страница не мигает.
- История событий сгруппирована по дням, с фильтром Все / DOWN / UP и выгрузкой в CSV.
Обновление стоит дёшево: JSON отдаётся за ~24 мс при четырёх запросах к базе, поэтому режим «каждые 30 секунд» можно держать включённым весь день.
Опасные операции
Перезапуск FreeRADIUS перегенерирует clients.conf и поднимает демона заново. На эти секунды авторизация не работает на всей сети — новые подключения не проходят, действующие сессии не рвутся.
Поэтому операция спрятана в отдельное меню и доступна только администраторам сети: superuser и группам из настройки NAS_ADMIN_GROUPS (по умолчанию root,network). Остальным кнопка не показывается, а прямой запрос отвечает 403.
Признак «конфигурация изменена» появляется в списке автоматически после сохранения или удаления NAS — чтобы перезапуск не забыли.
Мобильная версия

На телефоне остаются три колонки: название, состояние и онлайн — то, ради чего в список заходят с телефона во время аварии. IP, RADIUS, SSH, адрес и время последней авторизации скрыты, горизонтальной прокрутки нет.

В списке сессий на телефоне остаются клиент и IP: номер строки и логин на 390 px только отнимают место. ФИО не переносится — иначе одна строка растягивалась на три-четыре ряда и список переставал читаться; полное имя доступно в подсказке.
Тёмная тема

Endpoints
| URL | Метод | Назначение |
|---|---|---|
/admin/equipment/Nas/ | GET | Список устройств |
/admin/equipment/nas_status/ | GET | Дашборд состояния (?json=1 — данные для авто-обновления) |
/admin/equipment/nas_status/export/ | GET | История в CSV (?period=24h|7d|30d) |
/admin/equipment/nas_modal/[<id>/] | GET / POST | Карточка: чтение, сохранение, удаление |
/admin/nas_api/<id>/online/ | GET | Онлайн-сессии устройства (скоуп по организации клиента) |
/admin/nas_api/<id>/abonents/ | GET | Панель клиентов устройства (скоуп по организации) |
/admin/nas_api/<id>/ping/ | POST | TCP-проверка доступности |
/admin/nas_api/<id>/sync/ | POST | Синхронизация сессий |
/admin/nas_api/abonent-disconnect/<id>/ | POST | Разрыв сессий клиента (проверка организации) |
/admin/nas_api/allocate-ip/<user_id>/ | POST | Выдача свободного IP (проверка организации) |
/admin/nas_api/restart-radius/ | POST | Перезапуск FreeRADIUS (только админы сети) |
Смежные разделы
- Кэш авторизаций — почему повторная авторизация проходит за миллисекунду.
- RADIUS REJECT без тарифа — частая причина «клиент не подключается».
- Карта сети — те же устройства на карте с панелью клиентов.
- Счета и Финансовые операции — блокировка по балансу, из-за которой NAS получает REJECT.
- IP-пулы — адреса, которые устройство раздаёт.
Кэш авторизаций (Redis fast-path для FreeRADIUS)
Виджет на дашборде «Состояние NAS». Решает проблему массового падения NAS: когда тысячи клиентов одновременно переавторизуются, FreeRADIUS не успевает обрабатывать пакеты из-за серии SQL-запросов на каждый Access-Request.
Без кэша один authorize() делал 5 SQL-запросов:
Users + abonent + nas + NasRadiusParams + TarifRadiusParams + VpnConst,
суммарно 5–15 ms на пакет. При 1000 пакетов/сек FreeRADIUS не успевал,
очередь max_requests=16384 заполнялась за 16 сек, NAS retry'ил пакеты,
БД захлёбывалась.
С кэшем: при штатной авторизации (не заблокирован, NAS назначен, IP в пуле) ответ строится из снапшота в Redis — 1 ms вместо 10 ms, SQL не выполняется. Эффективная capacity FreeRADIUS Python module растёт в 5–10 раз.
Архитектура
- Сервис:
billing/services/radius_user_cache.py - Ключи Redis:
radius_user:{login}— снапшот, TTL 5 минradius_user_neg:{login}— маркер «не найден», TTL 60 сек (защита от перебора)radius_cache_stats(HSET) — счётчики hits/misses/negatives/invalidations
- Содержимое снапшота:
user_id,psw,enabled,ip,nas_id,abonent_tarif_id, объединённый списокreply_attrsиз NasRadiusParams + TarifRadiusParams
Fast-path vs Slow-path
Fast-path (новый, без БД) активируется только при штатных условиях:
enabled=True, abonent_enabled=True, есть пароль и NAS,
ip в пулах NAS. Иначе срабатывает slow-path с ORM —
для блокированных клиентов (нужна логика soft-block), OPT82, auto-assign NAS/IP,
cache miss. После успешного slow-path снапшот пишется в кэш для следующих пакетов.
flowchart LR
REQ["Access-Request
от NAS"] --> CACHE{"Снапшот
в Redis?"}
CACHE -->|"hit"| CHKFAST{"Штатные
условия?"}
CACHE -->|"miss"| PWD{"Пароль
верный?"}
CHKFAST -->|"да · fast-path 1 ms"| OK["RLM_MODULE_OK
+ Framed-IP
+ Rate-Limit"]
CHKFAST -->|"нет"| PWD
PWD -->|"нет"| REJ["REJECT"]
PWD -->|"да · slow-path ~10 ms"| TARIF{"tarif_id?"}
TARIF -->|"NULL"| REJT["REJECT
no tariff"]
TARIF -->|"есть"| BLOCK{"Заблоки-
рован?"}
BLOCK -->|"да"| SOFT["soft-block
блок-пул"]
BLOCK -->|"нет"| WRITE["Снапшот → Redis
TTL 5 мин"]
WRITE --> OK
OK --> AB(("Клиент
в сети"))
style REQ fill:#1e3a5f,stroke:#5BA89D,color:#fff
style CHKFAST fill:#14532d,stroke:#16a34a,color:#fff
style OK fill:#43b77a,stroke:#2d9a5f,color:#fff
style REJ fill:#7f1d1d,stroke:#dc2626,color:#fff
style REJT fill:#7f1d1d,stroke:#dc2626,color:#fff
style SOFT fill:#78350f,stroke:#d97706,color:#fff
style AB fill:#134e4a,stroke:#43b77a,color:#fff
Инвалидация
5 Django signals (post_save) сбрасывают соответствующие ключи:
| Модель | Что сбрасывается |
|---|---|
Users | Свой ключ |
Abonents | Все ключи учёток клиента |
AbonentsBlock | Все ключи учёток клиента |
NasRadiusParams | Все ключи users этого NAS |
TarifRadiusParams | Все ключи users на этом тарифе |
Дополнительно — TTL 5 минут гарантирует протухание даже без сигналов (защита от рассинхрона при ручном UPDATE через psql).
Метрики и UI
Виджет «Кэш авторизаций» на дашборде «Состояние NAS» показывает:
- Hits — попадания в кэш (1 ms, без БД)
- Misses — промахи (10 ms через ORM)
- Hit ratio % — целевое значение > 90% (после прогрева)
- В кэше — количество ключей
radius_user:*в Redis - Инвалид — счётчик сбросов по сигналам
- Кнопка «Сбросить» (для superuser) — полный flush, например после массового импорта Users
Endpoint: GET /admin/equipment/radius_cache_stats/ возвращает JSON с метриками.
POST /admin/equipment/radius_cache_flush/ сбрасывает весь кэш (только superuser).
Реальная статистика рабочего сервера через 5 минут после деплоя при штатной нагрузке ~10–20 авторизаций/сек: hits=838, misses=92, hit ratio=90.1%.
При hit ratio 90% среднее время authorize() снизилось с 10 ms до ~2 ms,
эффективная пропускная способность выросла в ~5 раз без увеличения ресурсов.
RADIUS REJECT без тарифа
Защита от бесплатного интернета у клиентов без тарифа.
До фикса клиент с Abonents.TARIF_ID=NULL авторизовывался в RADIUS, получал IP и
нерезаную скорость канала (без Mikrotik-Rate-Limit). Параллельно
billing_worker его не списывал — у клиента без тарифа нет связанных UsersUsluga.
Симметричная дыра: интернет работал бесплатно, пока кто-то не назначит тариф вручную.
Логика после фикса (radius_python/internet.py::authorize и
_try_authorize_from_snapshot):
- После проверки пароля проверяется
user.abonent.tarif_id - Если
NULL→RLM_MODULE_REJECTс пометкойno tariff assigned - Fast-path (Redis cache) тоже валидирует
tarif_idиз snapshot — иначе fall-through на slow-path → REJECT
Quick Add (создание клиента) — валидация на billing/views/abonents.py::abonent_quick_add:
поле «Тариф» помечено required, при пустом значении возвращается HTTP 400 с сообщением
«Тариф обязателен — выберите тариф для нового клиента».
Management-команда зачистки «осиротевших»:
python manage.py disable_abonents_without_tariff --dry-run
python manage.py disable_abonents_without_tariff --apply
Команда находит активных клиентов с TARIF_ID IS NULL и блокирует их через
ab.block(comment='Автоблок: нет назначенного тарифа', flags=['b_sys']). На рабочий сервер
2026-05-13 нашла 72 таких клиента (6 с активной RADIUS-сессией, суммарно ~12 ГБ нерезаного трафика).
Telegram-алерт (опционально): Celery beat-задача раз в час шлёт уведомление,
если за последние 24 часа создан клиент с tarif_id IS NULL. Защита на случай если
основной REJECT кто-то откатит.
В разделе «Диагностика связи» (карточка клиента) добавлена красная плашка «⚠ Тариф не назначен — RADIUS должен отклонять авторизацию» — оператор видит проблему сразу при открытии карточки.
3.2А. Мониторинг оборудования
Оборудование → Мониторинг оборудования, URL /admin/equipment/monitoring/.
Опрос управляемых коммутаторов по SNMP: состояние (в сети / не отвечает),
число активных портов, история падений. Биллинг опрашивает устройства сам, раз в 5 минут,
и присылает алерт в Telegram при падении.

Как это работает
Каждое устройство опрашивается по стандартному IF-MIB (ifOperStatus,
ifSpeed, счётчики ошибок) через утилиты net-snmp. Результат — снимок состояния
и событие в истории при смене «в сети ↔ не отвечает». Опрос идёт напрямую из сети сервера,
дополнительного ПО на коммутаторах не требуется — достаточно включённого SNMP с community
на чтение.
Дашборд состояния
Над таблицей — счётчики Всего / В сети / Не отвечают / Неизвестно. В таблице по каждому устройству:
- Статус — цветная точка: зелёная «в сети», красная «не отвечает», серая «неизвестно» (ещё не опрашивалось).
- Порты — прогресс-бар и счётчик активных портов (например, 29 / 48).
- Модель — определяется автоматически из ответа устройства (
sysDescr). - Последний опрос — время последнего успешного опроса.
- Действия: опросить сейчас, снять MAC портов, пауза, удалить.
Ниже — блок «Последние события» с историей падений и восстановлений (время, устройство, событие, длительность простоя).
Добавление устройства
Кнопка «Добавить устройство» открывает окно выбора коммутатора (показываются записи с заполненным IP, ещё не под мониторингом), SNMP community и интервал опроса. После добавления устройство попадает в очередь опроса автоматически.
Отображение на карте сети
Коммутаторы под мониторингом раскрашиваются на карте сети по статусу: зелёный маркер — в сети, красный — не отвечает, серый — без мониторинга. В всплывающем окне маркера показывается статус и число активных портов.
MAC на портах (кто где подключён)
Кнопка «Снять MAC портов» читает у коммутатора таблицу MAC-адресов по портам и сопоставляет их с MAC-адресами клиентов в биллинге. Совпавшие записи показывают, на каком физическом порту (и в каком VLAN) подключён конкретный клиент. Точность зависит от того, насколько заполнены MAC-адреса в карточках клиентов.
Оптические линии (GPON) и радиосекторы
Сейчас мониторинг охватывает управляемые коммутаторы. Сбор оптического уровня сигнала с OLT (GPON-клиенты) и уровня радиосигнала с базовых станций (радиоклиенты) — следующие этапы; они требуют сетевого доступа сервера к этому оборудованию и доступа на чтение.
3.3. IPTV
Тот же список NAS, но отфильтрованный по типу оборудования IPTV-серверы: middleware и stream-серверы провайдера (TVIP Media, LFStream «Смотрёшка»).

Привязка пакетов IPTV к услугам биллинга настраивается отдельно — в разделе Настройки → IPTV-пакеты (см. 5.6).
Подробная документация — на отдельной странице
Настройка TVIP Media, LFStream и маппинга пакетов — в разделе Интеграция с оборудованием → IPTV.
3.4. Коммутаторы
Список всех коммутаторов в сети оператора. Записи используются для:
- Привязки точек подключения клиентов (порт коммутатора + VLAN).
- DHCP Option 82 — распознавание клиента по физическому подключению.
- Генерации конфигов и SORM-отчётов.

В списке доступны поиск, модальное добавление/редактирование/удаление. Колонка «Тип» показывает модель коммутатора (бренд + серия) и скрывается на мобильном.
3.5. Типы коммутаторов
Шаблоны типов коммутаторов: бренд, модель, число портов, наличие Opt82. Используется при создании коммутатора чтобы не вводить параметры вручную.

3.6. Настройки СОРМ
Список конфигураций выгрузки данных в СОРМ-3 на FTP-сервер РКН. Каждая конфигурация определяет: имя оператора СОРМ, FTP-сервер, расписание выгрузки, набор отчётов.

Подробная документация — на отдельной странице
Принцип работы СОРМ-3, список интегрированных решений, метаданные UserAttributes, pre-flight валидация и REST API готовности — в разделе Интеграция с СОРМ3.
3.7. Карта сети
Интерактивная GIS-карта сети оператора на Leaflet: узлы (PoP / боксы / муфты /
опоры / колодцы / шкафы / NAS), оптические трассы с классами
(магистраль / распределение / абонентская), зоны покрытия,
точки подключения, а также заявки Поддержки и мониторинг
состояния NAS — всё на одном слоистом полотне. URL:
/admin/equipment/netmap/. Меню: Оборудование → 🗺 Карта сети.
Восемь слоёв и что на них видно, поиск объекта и ссылка на него, карточка со статусом использования, подстанции и договорные опоры, заявки в дежурной смене, карта на телефоне и три правила работы со схемой.

Слои и тулбар
- 8 переключаемых слоёв: Узлы · Оборудование · Трассы · Зоны · ТП (подстанции электросетей) · Опоры (оплачиваемые по договору) · Точки (точки подключения, ~4.6 тыс. — грузятся при первом включении) · Заявки. Включённый слой залит своим цветом, выключенный — только контур.
- Счётчик — в самой кнопке: «Узлы 1.2к», «Трассы 874», «ТП 10». Отдельной строки статистики больше нет, она занимала целый ряд и повторяла те же кнопки. Километраж волокна — в подсказке кнопки «Трассы».
- Поиск — по названию узла и трассы, адресу дома, ФИО и номеру договора клиента (см. ниже).
- Мониторинг NAS (кнопка «Монитор») — наложение состояния UP/DOWN на маркеры NAS, авто-обновление каждые 30 с, счётчик онлайн-клиентов.

Инструменты карты — в её правом верхнем углу, отдельной панелью поверх полотна: карандаш (режим редактора — рисование и перетаскивание объектов через Geoman: маркер = узел или бокс, линия = трасса, полигон = зона), линейка (измерение расстояния по ломаной), «во весь экран» (вернуться к общему плану сети) и обновление данных без перезагрузки страницы. На телефоне те же кнопки остаются в мобильной панели.

Полосы фильтров под тулбаром
Под кнопками слоёв — две полосы, каждая появляется вместе со своим слоем и исчезает, когда слой выключен:
- Технология (со слоем «Зоны») — Оптика, Радио, Медь, Медь / оптика, Для бизнеса со счётчиком зон. Клик прячет зоны этой технологии.
- Заявки (со слоем «Заявки») — четыре среза для дежурной смены: Ожидают (открытые и ждущие ответа, включён по умолчанию), Мои (назначенные на вас), Не назначены (ничьи), Закрыты. Срезы складываются; последний включённый выключить нельзя — иначе карта опустела бы молча.
Внизу карты — линейка масштаба и переключатель подложки («Как тема» / «Светлая» / «Тёмная»), не зависящий от темы интерфейса: на тёмной подложке хуже читаются названия улиц, и это отдельный выбор. Он запоминается.
Откуда берётся каждый слой
Карта ничего не хранит у себя, кроме собственных объектов сети: остальные слои читают те же таблицы, что и разделы биллинга, поэтому расходиться им не с чем.
Google Earth"] --> NODES["Узлы и трассы
NetworkNode, CableRoute"] ROSSETI["Акты и договор
Россетей"] --> TP["ТП и опоры
узлы особых типов"] NAS["Учёт оборудования
Nas, Switch"] --> EQ["Оборудование"] CP["Точки подключения
ConnectionPoints"] --> DOTS["Точки"] SUP["Поддержка
SupportConversation"] --> TICK["Заявки"] NODES --> MAP(["Карта сети"]) TP --> MAP EQ --> MAP DOTS --> MAP TICK --> MAP MAP --> ORG{{"Скоуп
организации"}} ORG --> VIEW["То, что видит
сотрудник"]
Слой отдаётся только в рамках организаций сотрудника: узлы, трассы и зоны — по своей организации, точки подключения — по организации клиента, оборудование — по привязке NAS и коммутаторов. Объекты без организации видны всем.
Поиск, ссылки на объект и запоминание вида
Поле поиска в тулбаре ищет одновременно по узлам (название, комментарий), трассам (название, марка кабеля) и адресам клиентов — по улице, ФИО и номеру договора. Результаты сгруппированы значками, выбор центрирует карту и открывает карточку объекта; если объект лежит в выключенном слое, слой включается сам. Для адреса ставится временная метка — видно, куда именно попали. Список управляется с клавиатуры: стрелки, Enter, Escape.

Ссылка на объект. Адрес страницы меняется при выборе объекта:
?node=1222, ?route=87 или ?lat=&lon=&z=.
Такую ссылку можно скопировать из строки браузера и отправить коллеге — она
откроет карту сразу на нужном объекте с раскрытой карточкой. Если объекта нет
или он принадлежит другой организации, показывается сообщение.
Карта помнит, где вы были. Включённые слои, центр и масштаб сохраняются в браузере и восстанавливаются при следующем заходе — не нужно каждый раз включать «Опоры» и доезжать до своего участка. Кнопка «Показать всю сеть» возвращает общий план. Ссылка на объект приоритетнее запомненного вида.
Измерение расстояния
Кнопка с линейкой включает режим измерения: клики по карте строят ломаную, длина считается нарастающим итогом и показывается в метрах или километрах. Двойной клик завершает измерение, ссылка «сбросить» очищает построенное. Инструмент считает расстояние по прямой между точками — для прикидки длины кабеля с запасом на провис это и нужно.

Импорт схемы из Google Earth
Если схема сети ведётся в Google Earth, её не нужно перерисовывать: выгрузка KMZ или KML загружается командой
manage.py import_netmap_kml --file "smit34 map.kmz" --org 1 [--dry-run] [--fibers]
manage.py import_netmap_kml --purge-source kmz_smit34_map # откат импорта
Точки становятся узлами, линии — трассами. Тип объекта и ёмкость кабеля определяются по названию, как их пишет инженер: «муфта оптическая» → муфта, «ТШ Мира 8» → уличный шкаф, «ТП-417» → подстанция, «48ОВ» в названии линии → 48 волокон. Команда идемпотентна: повторный запуск обновляет ранее импортированное, а не плодит дубли, поэтому карту можно переливать после каждой правки в Google Earth.
Фильтр по региону. В выгрузках Google Earth часто лежат демонстрационные метки («Тур по достопримечательностям» — Сидней, Париж, офис Google). Импорт берёт только объекты в границах области, иначе карта растянулась бы на весь мир.
Статус использования
У каждого узла и трассы есть статус: используем, не используем или не определено. Неиспользуемые объекты на карте гаснут и получают красный крестик, неопределённые — знак вопроса. Статус переключается прямо из карточки объекта в режиме редактора.
Это основа инвентаризации подвеса: участок со статусом «не используем» либо исключается из договора с сетевой организацией, либо демонтируется — и то, и другое дешевле, чем платить за размещение.
Подстанции и договорные опоры
Два слоя описывают не нашу сеть, а чужую инфраструктуру, на которой она висит.
- ТП — трансформаторные подстанции электросетей. К карточке подстанции прикрепляется поопорная схема сетевой организации, в описании — паспорт (тип КТП, мощность, число линий, питающая ВЛ) и разбор претензий, если они были.
- Опоры — опоры, за размещение на которых оператор платит по договору. Одна точка соответствует улице: в реестре сетевой организации координат нет, только номера опор, линия ВЛ и адрес. В карточке — реквизиты договора, перечень позиций реестра с номерами опор, список подстанций и прямая оговорка, что координата ориентировочная.
Зоны покрытия и технологии
Зона покрытия — полигон с указанием технологии абонентской линии: оптика, радио, медь, медь / оптика, «для бизнеса». Технология задаётся отдельным полем, а не подписью, поэтому по ней можно фильтровать карту.
Под тулбаром выводится легенда-фильтр: чип на каждую технологию с её цветом и числом зон. Клик по чипу убирает группу с карты — удобно, чтобы посмотреть, например, только радиопокрытие. Легенда появляется вместе со слоем «Зоны» и прячется вместе с ним. При наведении на полигон всплывает подсказка «название · технология».

Перенос из Конструктора Яндекс.Карт. Если карта
покрытия велась в Конструкторе, её объекты переносятся командой
manage.py import_yandex_zones --um <ID> --org <N> --apply.
Без --apply команда только показывает, что будет создано.
Технология определяется по подписи полигона — именно по абонентской
линии: «аплинк радио, абонентская линия оптика» попадёт в «оптику», потому что
подключаемость адреса определяет последняя миля, а не аплинк. Повторный запуск
с --replace перезаливает ту же карту.
Оптические волокна и трассировка
Трасса хранит структуру кабеля по стандарту TIA-598 (модули × волокна), панель свойств показывает разварку (splice) на муфтах и узлах. Поддерживается трассировка пути волокна от точки к точке — подсветка участков на карте.


Заявки Поддержки на карте
Слой «Заявки» накладывает геопривязанные тикеты Поддержки СмИТ Биллинг. Клик по маркеру открывает панель тикета: ответ клиенту, Нейроответ (AI-черновик), внутренняя заметка, назначение ответственного, а также drawer карточки клиента.


Мониторинг NAS
Включённый «Монитор» подсвечивает аварийные NAS, в панели узла доступны действия Ping, Синхронизация, Рестарт RADIUS и список онлайн-клиентов.

Слои и источники данных
flowchart LR
KMZ["Google Earth
KMZ / KML"] -->|"import_netmap_kml"| MAP
MAP["Карта Leaflet
8 слоёв"] --> N(("Узлы /
оборуд."))
MAP --> R(("Трассы
(волокна)"))
MAP --> Z(("Зоны
покрытия"))
MAP --> TP(("ТП и опоры
электросетей"))
MAP --> CP(("Точки
подключения"))
MAP --> TK(("Заявки
Поддержки"))
MAP --> MON(("Монитор
NAS"))
N -->|"редактор"| EDIT["Geoman
CRUD + drag"]
R -->|"клик"| FIB["Панель волокон
splice · трассировка"]
TP -->|"клик"| DOC["Схема и договор
номера опор"]
TK -->|"клик"| TPANEL["Панель тикета
ответ · AI · заметка"]
MON -->|"клик NAS"| NAS["Ping · Sync ·
Restart · онлайн"]
style KMZ fill:#0f766e,stroke:#43b77a,color:#fff
style MAP fill:#134e4a,stroke:#43b77a,color:#fff
style FIB fill:#1e3a5f,stroke:#5BA89D,color:#fff
style DOC fill:#7048e8,stroke:#9775fa,color:#fff
style TPANEL fill:#78350f,stroke:#d97706,color:#fff
style NAS fill:#7f1d1d,stroke:#dc2626,color:#fff
style EDIT fill:#43b77a,stroke:#2d9a5f,color:#fff
Связи объектов карты
Узел — универсальный объект с координатами. Он может быть «геопаспортом» уже учтённого оборудования (тогда ссылается на NAS, коммутатор, точку подключения или адрес), либо самостоятельным инфраструктурным объектом (муфта, опора, колодец).
erDiagram
NETWORK_NODE ||--o{ CABLE_ROUTE : "откуда / куда"
NETWORK_NODE ||--o{ FIBER_SPLICE : "разварка в узле"
NETWORK_NODE ||--o{ COVERAGE_ZONE : "покрытие узла"
NETWORK_NODE }o--|| NAS : "геопаспорт"
NETWORK_NODE }o--|| SWITCH : "геопаспорт"
NETWORK_NODE }o--|| HOMES : "адрес"
NETWORK_NODE }o--|| CONNECTION_POINT : "точка подкл."
CABLE_ROUTE ||--o{ FIBER : "волокна кабеля"
FIBER }o--|| ABONENTS : "кому заведено"
FIBER ||--o{ FIBER_SPLICE : "сварка A/B"
COVERAGE_ZONE }o--|| NAS : "покрытие NAS"
ORGANIZATION ||--o{ NETWORK_NODE : "принадлежит"
ORGANIZATION ||--o{ CABLE_ROUTE : "принадлежит"
ORGANIZATION ||--o{ COVERAGE_ZONE : "принадлежит"
Справочники значений:
- Типы узлов: узел связи (PoP) · бокс / ШР · муфта · опора · колодец · уличный шкаф · трансформаторная подстанция · прочее.
- Статус использования (у узлов и трасс): используем · не используем · не определено.
- Типы трасс (задают цвет по умолчанию): магистраль (красная) · распределение (синяя) · абонентская (зелёная) · воздушная (жёлтая) · подземная (серая).
- Статусы волокна: свободно · занято · резерв · повреждено. Цвет самого волокна — по TIA-598, циклично по 12.
- Типы разварки: сварка · разъём · сплиттер (PON).
- Технологии зон: оптика · радио · медь · медь / оптика · для бизнеса.
Карта раздела
- Карта сети
- Слои
- Узлы
- Оборудование
- Трассы
- Зоны покрытия
- Подстанции
- Договорные опоры
- Точки подключения
- Заявки Поддержки
- Навигация
- Поиск по узлам и адресам
- Ссылка на объект
- Запоминание вида
- Измерение расстояния
- Данные
- Импорт из Google Earth
- Статус использования
- Идемпотентный перезалив
- Оптика
- Волокна TIA-598
- Разварка в узлах
- Трассировка пути
- Статусы занятости
- Зоны
- Технология линии
- Легенда-фильтр
- Импорт из Яндекс.Карт
- Эксплуатация
- Мониторинг NAS
- Ping и синхронизация
- Рестарт RADIUS
- Онлайн-клиенты
- Доступ
- Просмотр всем сотрудникам
- Правка root и network
- Изоляция по организации
Права и разграничение по организациям
Просмотр карты доступен любому сотруднику, правка
топологии — нет. Создавать, менять и удалять узлы, трассы, зоны, волокна
и разварки могут только суперпользователь и группы из настройки
NETMAP_ADMIN_GROUPS (по умолчанию root,network).
Причина ограничения практическая: удалённая трасса уносит с собой схему разварки,
восстановить её можно только силами монтажников.
Мультиорганизационность. Узлы, трассы и зоны хранят организацию, и карта показывает сотруднику только то, что входит в его разрешённые организации. Кеш слоёв разделён по этому же признаку, поэтому сотрудник одной организации не может получить закешированный ответ, собранный для другой. Ограничение действует не только на карте: списки «Узлы и боксы» и «Трассы связи», поиск, а также обращение к объекту по прямой ссылке (открытие, правка, удаление, волокна, разварка, трассировка) проверяют принадлежность — чужой объект отвечает «не найдено». Волокно наследует организацию от трассы, разварка — от узла, в котором сварена.
Если у организации своей сети на карте ещё нет, вместо пустого поля показывается подсказка с предложением загрузить схему из Google Earth или нарисовать её в режиме редактора.

Тёмная тема и адаптив
При тёмной теме интерфейса карта переключается на тёмный скин CARTO Dark Matter, zoom-контролы и легенда адаптированы. Подложку можно закрепить независимо от темы переключателем «Как тема / Светлая / Тёмная» — на тёмной подложке хуже читаются названия улиц, и при разборе адресов удобнее светлая карта в тёмном интерфейсе.
На телефоне карте отдан почти весь экран: сводка, поиск, фильтр технологий и легенда переезжают в панель «Фильтры», а в тулбаре остаются только иконки — монитор, редактор, измерение, «вся сеть», обновление. Карточка объекта раскрывается во весь экран, как остальные слайд-панели системы.


Без PostGIS — координаты и геометрия хранятся в
JSONField, расстояния считаются по формуле гаверсинуса. Раздел лицензируется
модулем netmap.