Разработка AI-системы предиктивного обслуживания телеком-сети

Предиктивное обслуживание сети: почему прогноз приходит после аварии

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

Причина не в отсутствии данных. Телеметрия с оборудования копится, вот только лежит в разных хранилищах: опрос узлов — в одном, журналы отказов — во втором, заявки эксплуатации — в третьем. Рост температуры на конкретном узле ни разу не сопоставляется с историей его прошлых деградаций, поэтому сигнал остаётся незамеченным. По оценкам Uptime Institute, заметная доля серьёзных сбоев у операторов приходится на отказы, которые развивались постепенно и были различимы в данных заранее.

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

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

Что меняется на практике: эффект прогнозной аналитики

Эффект прогнозной аналитики измеряется не числом обученных моделей, а сменой режима работы сети. Когда телеметрия с узлов и элементов стекается в единую картину, деградацию видно за часы до отказа: время реакции на инцидент сокращается с часов до десятков минут, и решение принимает дежурная смена, не дожидаясь падения трафика.

Время реакции и окно на подготовку

Прогноз даёт не сигнал «уже упало», а окно на подготовку: видно, как растёт отклонение контролируемого параметра, и есть ориентир по времени. Бригада успевает согласовать работы, подготовить комплект и подменить узел в плановое окно, а не ночью по факту аварии. Снижение времени простоя идёт не за счёт скорости выезда, а за счёт того, что выезд перестаёт быть аварийным: доля плановых работ растёт, аварийных — падает.

Какой класс отказов уходит совсем

Часть отказов развивается медленно: растут ошибки на порту, деградирует питание, шумит линия. Такой отказ ловится задолго до порога, при котором он валит сегмент, и попадает в план замены. Предотвращённые аварии — прежде всего этот класс: он перестаёт быть внезапным и переходит в разряд плановой замены оборудования.

Отдельная метрика — точность прогноза отказов. Ложные срабатывания нагружают дежурную смену сильнее, чем редкие пропуски, поэтому пороги настраиваются под конкретный участок, а поток предупреждений сводится в единую панель мониторинга Grafana. Итог — меньше ночных эскалаций и предсказуемая загрузка инженеров.

Режимы обслуживания: от аварийной реакции к профилактике

Три режима — это не «устаревший и современный», а разные уровни того, что сеть умеет видеть до отказа. Реактивное обслуживание запускается по факту аварии, планово-предупредительное — по календарю или наработке, прогнозное (предиктивное) — по состоянию узла. Переход между ними определяется не желанием, а плотностью телеметрии и накопленной историей отказов.

Когда прогноз не нужен и хватит регламента

Если деградация узла занимает часы и пороговое правило успевает поднять сигнал с запасом на выезд, прогноз ничего не добавляет — он лишь усложняет контур. Прогноз бессмысленен и без непрерывной телеметрии с разметкой отказов: без них модель учится на шуме и выдаёт ложные тревоги. И наконец, если по прогнозу нечего делать — нет резерва, нет окна на замену, нет узла на подмену, — раннее предупреждение просто фиксирует проблему раньше, не меняя исход.

Как мы внедряем систему: этапы инженерной работы

Работы идут от источников данных к работающей системе, а не от выбора алгоритма: сначала фиксируем, что вообще можно измерять на оборудовании, затем строим прогноз и передаём его эксплуатирующей команде вместе с регламентами. Каждый этап заканчивается проверяемым артефактом — схемой потоков, размеченной историей отказов, отчётом о качестве прогноза, — поэтому результат не зависит от того, кто именно ведёт проект.

1. Аудит телеметрии. Инвентаризируем источники: какие счётчики и журналы событий доступны, с какой частотой снимаются, на каких участках данные теряются. На выходе — карта покрытия и перечень пробелов, которые нужно закрыть до обучения.
2. Сбор данных с оборудования. Настраиваем выгрузку в хранилище, приводим метки времени и идентификаторы узлов к единому виду, убираем дубли и провалы в рядах. Без этого модель учится на шуме канала связи, а не на состоянии сети.
3. Разметка истории аварий. Сопоставляем записи об инцидентах и ремонтах с показаниями по времени, отделяем плановые работы от внезапных отказов. Получаем эталон, по которому потом считается качество прогноза.
4. Обучение модели. Учитываем режимы нагрузки, сезонность и вмешательства бригад, проверяем, что каждый признак доступен в момент предсказания, а не после события. Иначе на проверке модель показывает красивый результат на данных, которых в реальности ещё нет.
5. Проверка прогноза. Прогоняем модель по прошлым авариям и смотрим, за какое время до отказа она поднимала тревогу и сколько ложных срабатываний давала на спокойных участках.
6. Передача системы в эксплуатацию. Оформляем регламент реакции на тревогу, передаём обучение и дообучение эксплуатирующей команде, договариваемся о периодичности перепроверок.

Проверка на прошлых авариях, а не на красивых графиках

Критерий приёмки — доля инцидентов, которые система предсказала заранее, и число ложных тревог на единицу оборудования. Если прогноз срабатывает слишком поздно, его невозможно использовать для выезда бригады, поэтому окно упреждения и точность согласуем до запуска.

Что заказчик получает на руки: конфигурации и регламенты

Предиктивная система отличается от аналитической витрины: её результат должна воспроизводить дежурная смена, а не автор модели. Поэтому отдаём не только модель, но и полный комплект артефактов эксплуатации.

• Конфигурация сборщика данных: состав метрик, частота опроса, окна агрегации, поведение при потере узла.
• Схема потоков от оборудования до хранилища признаков — с точками отказа и резервными маршрутами.
• Описания признаков деградации: пороги, окна и допустимая доля ложных срабатываний.
• Дашборды мониторинга: состояние модели, доля аномалий, задержка телеметрии, узлы в зоне риска.
• Регламент реагирования с эскалацией по линиям и нормативным временем реакции.
• Матрица ответственности: кто подтверждает сигнал, кто выводит узел в ремонт, кто закрывает инцидент.
• Инструкции для дежурной смены: типовые сигналы, ложные срабатывания, порядок отката модели.

Регламент реагирования: кто и что делает по сигналу

Первая линия проверяет сигнал по чек-листу и отсекает заведомо ложные, вторая — сопоставляет его с журналами оборудования и запускает диагностику. Если деградация подтверждена, заявка уходит в ремонт с указанием узла и ожидаемого окна отказа, а закрытие фиксируется в системе: модель получает обратную связь и пороги уточняются.

Документация для команды эксплуатации

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

Кейс: сократили внеплановые простои в телеком-сети

Участок взяли один: полторы сотни базовых станций и транспортное кольцо между ними. Деградация оптики и перегрев радиооборудования проявлялись за часы до отказа, но в мониторинге это выглядело как россыпь разрозненных пороговых срабатываний — дежурный видел аварию, когда канал уже падал, а выезд бригады планировался по факту. Мы подняли историю инцидентов за несколько месяцев и нашли повторяющиеся последовательности в телеметрии: рост ошибок на порту, просадка уровня приёма, всплески повторных передач перед обрывом.

Что показал пилот на одном участке

Пилот шёл на выделенном фрагменте, остальную сеть не трогали. Модель строила прогноз по потоку измерений, пороги срабатывания калибровали вместе с дежурной сменой — иначе предупреждения тонут в шуме и их перестают читать. Телеметрию и разметку инцидентов сводили в Grafana, чтобы прогноз стоял рядом с привычными графиками, а не в отдельном окне.

Ключевое — не точность сама по себе, а устранённый класс отказов: деградация оптического тракта перестала доходить до аварии, её закрывают плановой работой в удобное окно. Ложные срабатывания на пилоте держались в пределах, которые смена согласилась терпеть, иначе дежурные начали бы игнорировать сигнал. После сведения метрик к стабильному профилю схему переносили на соседние участки — сначала на те, где набор оборудования совпадает. Опишите свой участок сети — вернёмся с оценкой объёма пилота и планом разметки.

Чем прогнозная модель отличается от пороговых правил

Порог отвечает на вопрос «метрика уже вышла за границу?», а не «сколько осталось до отказа». К моменту срабатывания деградация идёт часами, и на реакцию остаётся узкое окно. Прогнозная модель оценивает вероятность отказа на горизонте — этого хватает, чтобы перевести трафик или выехать на узел заранее.

Правило на скользящем окне частично снимает проблему: сравнение с собственной историей узла убирает суточный профиль и сезонность. Но условия всё равно пишет инженер, и каждое новое сочетание метрик — это правка набора правил. Модель на истории отказов восстанавливает предотказные состояния по телеметрии и не требует описывать каждую связку вручную.

Аномалии в метриках редко идут одним скачком. Обычно сначала растёт разброс по узлу, затем меняется соотношение между нагрузкой и качеством обслуживания — и только потом метрика пересекает порог. Пороговое правило видит последний шаг этой цепочки, поэтому срабатывает поздно: запас времени тратится на подтверждение.

Выбор метода обнаружения — не «или-или». Модель даёт раннее предупреждение с оценкой срока, пороги остаются страховкой на случай, если данные по узлу пропали или поведение вышло за пределы обучающей выборки.

Вопросы по данным, интеграциям и точности прогноза

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

Как решение встроится в работающий мониторинг?

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

Аварии редкие — на чём учить модель?

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

Сезонные пики нагрузки не сломают прогноз?

Календарь, погодные ряды, суточные и недельные циклы входят в признаки явно. Проверяем на контрольных периодах разных сезонов, а не на одном среднем отрезке; при устойчивом сдвиге профиля запускаем переобучение.

Кто сопровождает модель после запуска?

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

Обсудим вашу задачу: с чего начнём

Чтобы разговор был предметным, а не обзорным, начинаем с обсуждения задачи: какой класс отказов беспокоит больше всего, на каких участках сети он проявляется чаще и как сейчас устроено реагирование. От ответов зависит и модель, и то, какие данные вообще понадобятся. Ниже — минимальный набор, который нужен, чтобы перейти от разговора к оценке проекта.

• Историю отказов и инцидентов за несколько сезонов: что ломалось, когда, с какой длительностью простоя и что делали для восстановления.
• Телеметрию с оборудования: температуру, питание, уровни сигнала, счётчики ошибок — с той периодичностью, с какой её уже собирает мониторинг.
• Топологию сети и перечень критичных узлов: где резервирование есть, где его нет и какой участок болит чаще остальных.
• Журналы работ и замен: когда меняли блоки питания, модули, патч-панели — без этого модель видит отказ, но не видит вмешательство.
• Доступ к системам мониторинга и учёта на чтение, к тестовому контуру — на запись, чтобы проверять гипотезы, не задевая рабочую сеть.
• Регламенты реагирования и контакт инженера-эксплуатанта: он знает, какие срабатывания ложные, а какие действительно предвещают аварию.

Дальше порядок такой: разбираем инфраструктуру и качество данных, возвращаемся с оценкой проекта и границами применимости модели, затем запускаем пилот на одном участке — там видно, ловит ли система предотказные состояния раньше диспетчера. Если результат подтверждается, готовим план внедрения на остальную сеть с этапами, ролями и точками контроля.

Опишите задачу и то, какие данные уже есть, — вернёмся с оценкой и планом.