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

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

Вузол не виходить з ладу миттєво. За тижні до аварії на ньому зростає температура, просідає запас живлення, збільшується частка повторних передач — це ранні ознаки деградації, які видно в моніторингу телеком-мережі.

Але заміну планують лише після того, як вузол перестав тримати навантаження, — і позапланові простої вже сталися.

Причина не у відсутності даних. Телеметрія з обладнання накопичується, але лежить у різних сховищах: опитування вузлів — в одному, журнали відмов — у другому, заявки експлуатації — у третьому.

Зростання температури на конкретному вузлі жодного разу не зіставляється з історією його минулих деградацій, тому сигнал залишається непоміченим.

За оцінками Uptime Institute, помітна частка серйозних збоїв в операторів припадає на відмови, які розвивалися поступово й були розрізненні в даних заздалегідь.

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

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

Що змінюється на практиці: ефект прогнозної аналітики

Ефект прогнозної аналітики вимірюється не кількістю навчених моделей, а зміною режиму роботи мережі.

Коли телеметрія з вузлів і елементів стікається в єдину картину, деградацію видно за години до відмови: час реакції на інцидент скорочується з годин до десятків хвилин, і рішення ухвалює чергова зміна, не чекаючи падіння трафіку.

Час реакції та вікно на підготовку

Прогноз дає не сигнал «уже впало», а вікно на підготовку: видно, як зростає відхилення контрольованого параметра, і є орієнтир за часом. Бригада встигає узгодити роботи, підготувати комплект і підмінити вузол у планове вікно, а не вночі за фактом аварії.

Зниження часу простою відбувається не за рахунок швидкості виїзду, а за рахунок того, що виїзд перестає бути аварійним: частка планових робіт зростає, аварійних — падає.

Який клас відмов зникає зовсім

Частина відмов розвивається повільно: зростають помилки на порту, деградує живлення, шумить лінія. Таку відмову ловлять задовго до порогу, за якого вона валить сегмент, і вона потрапляє до плану заміни.

Запобігнені аварії — передусім цей клас: він перестає бути раптовим і переходить до розряду планової заміни обладнання.

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

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

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

Коли прогноз не потрібен і достатньо регламенту

Якщо деградація вузла займає години й порогове правило встигає підняти сигнал із запасом на виїзд, прогноз нічого не додає — він лише ускладнює контур. Прогноз безглуздий і без безперервної телеметрії з розміткою відмов: без них модель навчається на шумі й видає хибні тривоги.

І нарешті, якщо за прогнозом нічого робити — немає резерву, немає вікна на заміну, немає вузла на підміну, — раннє попередження просто фіксує проблему раніше, не змінюючи результат.

Як ми впроваджуємо систему: етапи інженерної роботи

Роботи йдуть від джерел даних до працюючої системи, а не від вибору алгоритму: спочатку фіксуємо, що взагалі можна вимірювати на обладнанні, потім будуємо прогноз і передаємо його експлуатаційній команді разом із регламентами.

Кожен етап закінчується перевірюваним артефактом — схемою потоків, розміченою історією відмов, звітом про якість прогнозу, — тому результат не залежить від того, хто саме веде проєкт.

1. Аудит телеметрії. Інвентаризуємо джерела: які лічильники та журнали подій доступні, з якою частотою знімаються, на яких ділянках дані губляться. На виході — карта покриття та перелік прогалин, які потрібно закрити до навчання.
2. Збір даних з обладнання. Налаштовуємо вивантаження до сховища, приводимо мітки часу та ідентифікатори вузлів до єдиного вигляду, прибираємо дублі та провали в рядах. Без цього модель навчається на шумі каналу зв’язку, а не на стані мережі.
3. Розмітка історії аварій. Зіставляємо записи про інциденти та ремонти з показаннями за часом, відділяємо планові роботи від раптових відмов. Отримуємо еталон, за яким потім рахується якість прогнозу.
4. Навчання моделі. Враховуємо режими навантаження, сезонність і втручання бригад, перевіряємо, що кожна ознака доступна в момент передбачення, а не після події. Інакше на перевірці модель показує гарний результат на даних, яких у реальності ще немає.
5. Перевірка прогнозу. Проганяємо модель по минулих аваріях і дивимося, за який час до відмови вона піднімала тривогу та скільки хибних спрацювань давала на спокійних ділянках.
6. Передача системи в експлуатацію. Оформлюємо регламент реакції на тривогу, передаємо навчання та донавчання експлуатаційній команді, домовляємося про періодичність повторних перевірок.

Перевірка на минулих аваріях, а не на гарних графіках

Критерій приймання — частка інцидентів, які система передбачила заздалегідь, і кількість хибних тривог на одиницю обладнання. Якщо прогноз спрацьовує надто пізно, його неможливо використати для виїзду бригади, тому вікно попередження й точність узгоджуємо до запуску.

Що замовник отримує на руки: конфігурації та регламенти

Предиктивна система відрізняється від аналітичної вітрини: її результат має відтворювати чергова зміна, а не автор моделі. Тому віддаємо не лише модель, а й повний комплект артефактів експлуатації.

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

Регламент реагування: хто і що робить за сигналом

Перша лінія перевіряє сигнал за чек-лістом і відсікає завідомо хибні, друга — зіставляє його з журналами обладнання й запускає діагностику.

Якщо деградацію підтверджено, заявка йде в ремонт із зазначенням вузла та очікуваного вікна відмови, а закриття фіксується в системі: модель отримує зворотний зв’язок і пороги уточнюються.

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

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

Кейс: скоротили позапланові простої в телеком-мережі

Ділянку взяли одну: півтори сотні базових станцій і транспортне кільце між ними.

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

Ми підняли історію інцидентів за кілька місяців і знайшли повторювані послідовності в телеметрії: зростання помилок на порту, просідання рівня приймання, сплески повторних передач перед обривом.

Що показав пілот на одній ділянці

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

Телеметрію та розмітку інцидентів зводили в Grafana, щоб прогноз стояв поруч зі звичними графіками, а не в окремому вікні.

Ключове — не точність сама по собі, а усунений клас відмов: деградація оптичного тракту перестала доходити до аварії, її закривають плановою роботою в зручне вікно.

Хибні спрацювання на пілоті трималися в межах, які зміна погодилася терпіти, інакше чергові почали б ігнорувати сигнал. Після зведення метрик до стабільного профілю схему переносили на сусідні ділянки — спочатку на ті, де набір обладнання збігається. Опишіть свою ділянку мережі — повернемося з оцінкою обсягу пілота та планом розмітки.

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

Поріг відповідає на питання «метрика вже вийшла за межу?», а не «скільки залишилося до відмови». На момент спрацювання деградація триває годинами, і на реакцію залишається вузьке вікно.

Прогнозна модель оцінює ймовірність відмови на горизонті — цього достатньо, щоб перевести трафік або виїхати на вузол заздалегідь.

Правило на ковзному вікні частково знімає проблему: порівняння з власною історією вузла прибирає добовий профіль і сезонність. Але умови все одно пише інженер, і кожне нове поєднання метрик — це правка набору правил.

Модель на історії відмов відновлює передвідмовні стани за телеметрією й не вимагає описувати кожну зв’язку вручну.

Аномалії в метриках рідко йдуть одним стрибком. Зазвичай спочатку зростає розкид за вузлом, потім змінюється співвідношення між навантаженням і якістю обслуговування — і лише потім метрика перетинає поріг.

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

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

Питання щодо даних, інтеграцій і точності прогнозу

Скепсис на етапі оцінювання зазвичай стосується не самої моделі, а даних і стикування з тим, що вже працює в мережі. Нижче — п’ять питань, які задають найчастіше.

Як рішення вбудується в працюючий моніторинг?

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

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

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

Сезонні піки навантаження не зламають прогноз?

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

Хто супроводжує модель після запуску?

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

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

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

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

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

Якщо результат підтверджується, готуємо план впровадження на решту мережі з етапами, ролями та точками контролю.

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