GetOLT: как из telnet-скриптов вырос сервис мониторинга PON-сети

В телеком-компании, где я работал, жило около десятка разрозненных систем — ERP, пять биллингов, BI с отчётами, ticket-tracker, ещё пара — и ни одна из них не отвечала на простой вопрос: «на каком OLT, каком PON-порту и через какой ONU подключён абонент Петров?».

Звучит как мелочь. Но именно эта мелочь стоила компании сотни часов техподдержки в месяц.

Сейчас это живой продукт — getolt.online.

Слепое пятно между ERP и оборудованием

Когда абонент звонит в саппорт с «не работает интернет», оператор первой линии должен за минуту понять: это персональная проблема (плохой сигнал, кабель, оплата) или общесетевая авария, потянувшая за собой подъезд?

В нашей инфраструктуре каждая система знала свой кусок:

• ERP — договор, ФИО, тариф, адрес
• Пять биллингов (исторически разные регионы, разные подрядчики, миграции «на потом») — балансы, начисления, история платежей
• BI — управленческая выручка и отток
• Оборудование (OLT) — telnet/SSH, vendor-specific CLI, никакой интеграции наружу

Связь «договор № → OLT, PON-порт, ONU абонента» нигде не хранилась. Оператор открывал ERP, искал по ФИО, смотрел адрес, звонил в полевую бригаду «съездите посмотрите». Каждый второй такой выезд оказывался пустым — проблема была не у абонента.

Первая попытка: скрипты по telnet

Логично было начать со скриптов. Telnet-сессия на OLT, парсинг вывода show onu, мэппинг ONU serial → login → договор. Сначала bash, потом Python, по cron'у. Результат складывали сначала в текстовый файл, потом в shared-таблицу.

Это работало. Несколько недель.

Через месяц добавили чтение уровней сигналов Rx/Tx по каждому ONU — оказалось критично для троублшутинга. Потом — заполнение PON-портов для capacity planning. Потом — версии прошивок для security-аудита. Потом — лог самих telnet-сессий, чтобы отлаживать скрипты, которые ломались каждый раз, когда вендор обновлял прошивку и менял формат вывода.

К концу третьего месяца:

• Скриптов стало шесть
• Каждое новое поле требовало правки во всех шести
• Cron-расписание начало конфликтовать само с собой
• Текстовая «схема» не масштабировалась — некоторые поля стали nullable, кто-то добавлял лишний разделитель
• Логи писались в /tmp/, ротация не предусмотрена, диск иногда заканчивался

В какой-то момент стало очевидно: это не удобный скрипт. Это полусломанный сервис без UI, без ретраев, без мониторинга самого себя.

Шаг два: вынести в сервис

Решение было прямолинейным — выделить в отдельный продукт:

• БД (MySQL) с чёткой схемой: olt, pon_port, onu, signal_log, telnet_log, subscriber_link
• Шедулер — каждые 30 минут опрашивает все OLT, лимит 100 параллельных сессий, тайм-аут 60 секунд на сессию
• Web UI — поиск по договору / абоненту / serial ONU / порту, агрегаты по сигналам
• API — чтобы диспетчерский софт и BI ходили в один источник, а не в шесть разных скриптов

Telnet-логика осталась той же — те же команды, те же парсеры. Просто переехала из bash-скриптов в Spring Boot-сервис с нормальным жизненным циклом.

Что получилось через год+ в проде

Сервис давно перешёл из «удобного инструмента отдела» в инфраструктурный компонент. Сегодня он:

• Опрашивает 350+ OLT разных вендоров (CDATA, BDCOM, GateRay), 24/7, по расписанию
• Хранит исторические уровни сигналов — деградация ONU с -22 до -28 dBm за две недели видна сразу, до того как абонент звонит в саппорт
• Закрывает связь «абонент → OLT/порт/ONU» — первой линии техподдержки за 2 секунды показывают, на каком OLT и каком PON-порту установлен ONU звонящего и какой у него актуальный сигнал
• Считает заполнение портов — сетевой отдел видит, где capacity подходит к 80% и пора заказывать сплиттеры
• Версии прошивок — security-команда видит, какие OLT в зоне CVE и нуждаются в апгрейде

Эффект, который меряется проще всего: доля «пустых» выездов полевой бригады (приехали, у абонента всё работает) — упала примерно в три раза. Звучит скромно, но за год это сотни часов работы инженеров и десятки тысяч в фонд оплаты труда.

Что дальше

Сервис из инструмента «для себя» постепенно превращается в коммерческий MVP — операторы СНГ ходят с теми же болями и интересуются. Параллельно ему добавляется ещё один слой: AI-ассистент. Бот ходит в эту же базу через MCP-tools и отвечает на естественном языке — оператору саппорта не нужно знать SQL и схему таблиц, чтобы понять «у абонента деградирует сигнал последние две недели».

Об ассистенте — в следующих постах серии:

1. Архитектура: Ollama + MCP + Spring Boot — как это устроено end-to-end
2. SSE + Spring Security — три ловушки async-обработки, которые ломают streaming
3. Prompt — это код — как лечить галлюцинации фильтров через дизайн tools

Что я понял за этот путь

1. Скрипт — это ранний прототип сервиса. Если он растёт и его сложно поддерживать, это не «надо рефакторнуть скрипт». Это «пора выносить».
2. Связи между системами ценнее самих систем. ERP, пять биллингов и оборудование по отдельности — индустриальный стандарт. Один JOIN между ними — конкурентное преимущество, которое экономит компании больше, чем стоит сам JOIN.
3. Прод-данные дают фокус. Год работы в реальной сети показал, что ценно (сигналы, capacity, links на абонентов), а что декоративно (детальные telnet-логи, которые никто не читает).
4. Превентивная аналитика > реактивная. Поймать деградирующий сигнал за два дня до звонка абонента стоит больше, чем починить аварию за десять минут после.

---

Хорошие сервисы редко рождаются на пустом месте. Чаще они вырастают из ворох скриптов, в которых стало неудобно жить.