Автоматизація провайдера

Мій досвід автоматизації інтернет-провайдера…

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

Загальні дані

- мережа провайдера охоплює сотню багатоповерхівок (FTTB, оптика до будинку);
- налічує близько тисячі абонентських проводових підключень ("вита пара").
- маємо 2-3 заявки на день (підключення, перепідключення, ремонт)

Люди:
- техніки = 1,5 (другого техніка ділим з оператором кабельного телебачення). Відповідають за абонентську ділянку.
- оператор-адмін = 1. Прийом та обробка заявок. Вирішення заявок в телефонному режимі. Робота з абонентськими даними.
- керівник-адмін - я. Підбір та налаштування мережевого обладнання, серверного обладнання та програмного забезпечення. Запасний гравець на випадок відпусток, лікарняних.

На перший погляд людей маловато, яле ми встигаємо розрулювати заявки, налаштовувати абонентське обладнання та займатися сторонніми справами (допомагати абонентам в відновлення працездатності їх пристроїв (відновлення "вінди", андроїдів, видалення вірусів, ремонт "заліза"), займатися сторонніми проектами, дивитися серіали та грати в ігри).

Все це стало можливим завдяки палкому бажанню вивільнити собі час.
Вивільнив настільки, що зміг на 15 місяців відлучитись до армії ))

Юзерсторі

Інтернет-провайдер - це доволі простий бізнес. Необхідно мати:
- сервер-доступу підключений до мережі Інтернет (абоентський доступ по ip з прив'якою по mac);
- білінг- база даних, що зберігає всі абонентські дані, та дає вказівку серверу доступу кого і на якій швидкості пропускати в Інтернет;
- мережу, що об'єднує мережеве обладнання, розміщене в будинках;
- абонентські лінії, що єднають обладнання абонента до провайдерської мережі.

Абонентський доступ

Абонентський пристрій при позитивному балансі на рахунку автоматично отримує, виділену йому ip-адресу, і абонент отримує доступ до скарбів Інтернету. Якщо ж інтернету нема, він телефонує нам або чекає, коли саме все розрулиться (звичка від користування послугами наших конкурентів).

Телефонна станція

Дзвінок приймає телефонна станція з опенсорсного Астеріска (до 2011 я активно займався ip-телефонією, навіть дотепер лишаюсь в десятці лідерів asterisk-support.ru маючи кількарічну перерву). Астеріск нам потрібний для розумної маршрутизації дзвінків (вихідні - по найнижчій вартості, вхідні - в залежності від режиму роботи), їх переадресації на чергового диспетчера в неробочий час, голосового повідомлення-заглушки на випадок авралів на мережі (ми працюємо над вирішенням і повідомляти нас вже не потрубно), визначення номера з якого нам телефонують, ведення історії дзвінків та простої інтеграції з веб-системами. Як бачите, використовуємо мінімум можливостей.

Карточка абонента (примітивний CRM)

Якщо час робочий, дзвінок приходить до оператора-адміна. На самописній веб-сторінці ми бачимо телефонний номер (якщо не анонім). Далі ми можемо натиснути кнопку пошуку і система спробує віднайти карточку абонента з таким телефонним номером. При позитивному результаті пошуку ми можемо привітати абонента по імені і, навіть, локалізувати проблему, що виникла у абонента (телепати на лінії;). При відсутності номера в базі доведеться допитувати абонента про його адресу і шукать його дані вже по цьому критерію.

Веб-рішення є вимушеною надбудовою над білінгом, що дістався мені в спадщину. На відміну від білінгу, воно здатне дістати всю важливу інформацію стосовно абонента та розмістити її на одному екрані (в білінгу це окремі сторінки вагою в МБ).

Система додатково проводить автоматичний аналіз основних параметрів і за допомогою виділених підказок та підсвідки дає попередній діагноз (закінчились гроші на рахунку, давно не працював, повторне підключення чи Абонент онлайн і все має працювати.. Доморощена експертна система).

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

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

Облік заявок (Тікетинг)

Для обліку заявок мною було розроблено примітивне веб-рішення, яке дозволяє всім заносити заявки в базу даних.

Ієрархія проста: адміни та техніки. Адміни бачать всі незакриті заявки, техніки - заявки, що назначені їм та ті, що самі створили.
Ідея даного тікетингу примітивна: адмін розглядає заявку, якщо питання в його компетенції то вирішує його сам, якщо потрібне втручання техніків - перенаправляє заявку на техніків. Техніки, на основі своїх заявок, самостійно планують свою роботу (домовляються з абонентом на час та визначають об"єм робіт). Коли заявка вирішена - вона закривається з відповідними коментарями і пропадає в історії. Згадуєм про неї лише, коли працюємо з Карточкою даного абонента.

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

Моніторинг мережевого обладнання та абонентських підключень

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

Початкове рішення було просте - Nagios та старий добрий ping. Ними ми закрили питання доступності керованого мережевого обладнання (на локаціях з відносно великою кількістю абонентів). Локації з тупими свічами моніторили по онлайн абонентам З білінга (сервера доступу).

Пізніше було запущено Syslog-сервер (дає дані по петлям в мережі з керованих свічів, які вміють їх детектить) та збір mac-ів з портів свічів абонентського доступу. Останнє рішення довелось збирати власноруч з опенсорс компонентів та заносити дані в базу даних.В результаті додатково до бази маків по локації/свічу отримав інвентаризацію абонентських підключень та можливість виявляти несанкціонований доступ (підміна мас, з підміною ip допомагає боротись arpwatch на сервері доступу).

Результати

Таким нехитрим чином було автоматизовано роботу по обслуговуванню мережі та отримана статистика по роботі компанії вцілому:
- використання трафіку;
- пікові часи роботи;
- річні міграціє абонентів;
- точні дані по абонентським підключенням (всіх за весь період ведення білінгу, "живих" по білінгу, живих по даним мережі);
- інші корисні дані (взагалі дані лишніми не бувають;).

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

На жаль, особливості роботи на периферії не принесли надприбутків в результаті цих оптимізацій-автоматизацій. Вдалось лише значно скоротити видатки та спростити роботу собі та підлеглого мені колективу. Для абонентів це вилилось в стабільно якісне та швидке вирішенням проблем (на відміну від наших конкурентів;).

 

P.S. Все це було до моєї мобілізації, а про позитивний вплив армії на подальший апгрейд підшефного мені провайдера буде далі..
P.S.S. Dсе вищеописане залюбки повторю для інших ще неоптимізованих периферійних провайдерів. Даєш якісні послуги!