За последние полгода я часто стал слышать на конференциях и от знакомых про различные продукты, основанные на понятии «качество восприятия» услуги (Quality of Experience, QoE). Этот термин становится все более популярным. Довольно много исследований ведется по созданию новых методов определения качества восприятия пользователей, того или иного сервиса или услуги, но сейчас не хочется углубляться в теорию, кому интересно тот сможет самостоятельно погуглить.
В рекламных посланиях говорится о том, что этот чудо-продукт умеет:
- Выявлять проблемы с качеством связи за CPE, в том числе до абонентского оборудования,
- Повышать LTV (LifeTimeValue),
- Сlickstream-аналитика, то есть, возможность отслеживать посещаемые сайты, включая сайты конкурентов,
- Узнавать сколько виртуальных IP-адресов находятся за реальным IP-адресом,
- Определять какими сервисами/оборудованием пользуются абоненты (SIP, OTT, smart house, smart tv, сетевое оборудование),
- Для каждого пользователя приоритезировать трафик и ограничивать те или иные протоколы на основе L7,
- Простая интеграция с OSS/BSS.
Поскольку моя основная задача заключается в том, чтобы находить абонентов недовольных качеством интернета и вообще всячески решать проблемы оттока абонентов (работаю в одном, не самом маленьком телеком-операторе в отделе качества услуг), то данный продукт (будем называть его для удобства «QoE»), со сладких слов продавцов и маркетологов решает эту задачу. Но это все в теории и пока сам не убедишься на практике, то и не поймешь. Именно поэтому мне захотелось поделиться с коллегами практической стороной данного решения, лишенного красивой маркетинговой упаковки.
Сразу оговорюсь, что не буду называть вендора, а то сочтут за рекламу, да и денег мне никто за это не заплатит. Скажу лишь, что это российский производитель, в линейке которого есть решения (аппаратно-программный комплекс) по фильтрации URL, DPI и продукт, основанный на принципах QoE на базе этого DPI.
Поэтому расскажу и покажу какой функционал мне удалось протестировать, какие проблемы возникли при тестировании и подведу свой субъективный итог.
Начало тестирования
Не буду особо расписывать, как я получал оборудование на тестирование, так как ничего особенного на этом этапе не происходило. Если кратко, то со мной быстро связались партнеры вендора из компании НАГ.
Запросили уточняющую информацию о задачах, которые мы хотим решить с помощью QoE, топологию сети, объем трафика и данные контактного лица со стороны нашей компании. После этого, прислали ссылку на личный кабинет, где можно было вживую ознакомиться с продуктом.
Личный кабинет
При авторизации появляется dashboard, где показаны:
- Активные абоненты,
- Абоненты с плохим RTT / ужасным RTT (Round Trip Time),
- Пакеты от абонентов/к абонентам,
- Среднее значение RTT.
Честно говоря, понятие «ужасный RTT» какое-то невнятное. Для одних ужасным считается 10 мс, для других – 100 мс. Но, обратившись в техподдержку вендора, я узнал, что показатель «ужасности» определяет сам провайдер, и прописывает его в конфигурации QoE.
Проблемы у конкретных абонентов
Я сразу нашел проблемных абонентов, у которых наблюдались серьезные задержки. Например, более 4,5 мс
Тут же можно посмотреть данные клиентского оборудования, в данном случае у него TP-LINK. Также, видна длина кабеля абонента и ошибки CRC.
Небольшая справка, на всякий случай: Циклическая проверка избыточности — Circular redundancy check (CRC) — это способ обнаружения небольших изменений в блоках данных. Этот тип обнаружения ошибок особенно полезен при отправке пакетных данных по сети, такой как SynqNet. В то время как счетчик ошибок пакетов проверяет наличие отсутствующих или недопустимых пакетов, счетчик ошибок CRC проверяет достоверность данных в пакетах.
Можно сделать вывод о том, что или кабель битый или проблемы внутри квартиры.
Можно выводить магистральные проблемы: например, сегментировать абонентов по группам районов в зависимости от времени суток и RTT, можно фильтровать и группировать по различным критериям:
- Количество CRC за неделю,
- Коммутатор доступа,
- Услуга,
- Магистральный коммутатор,
- Договор,
- Район,
- Вендор абонентского устройства,
- Длина кабеля.
Выведем список магистральных коммутаторов, отфильтровав по району. В итоге, увидим число абонентов на магистральных коммутаторах. На одном сидит 99 абонентов, на другом 64 и т.д. Также, можно увидеть среднюю задержку на магистральных коммутаторах.
Мне больше всего интересно было найти самые тормозные коммутаторы. Как видно из скриншота выше, таким коммутатором является самый первый, в списке с 99 абонентами. Мы можем зайти в его данные и посмотреть, что с ним не так.
Кликаем на коммутатор, фильтруем по критерию «Магистральный коммутатор», сгруппировав по критерию «Коммутатор доступа». Так будет понятно, какой коммутатор доступа самый «плохой» на данном магистральном коммутаторе:
В итоге, выведется самый плохой коммутатор доступа (выделил красным) — у него самый большой RTT.
Теперь заходим на этот, самый плохой коммутатор доступа и видим такую картину:
Мы видим много сессий с большими задержками. Если посмотреть абонентов на данном коммутаторе доступа, то можно увидеть тех, у кого ошибки на порту – это проблемы с кабелем. На скриншоте ниже виден абонент под номером 12, у которого 898 ошибок.
Сразу можно заметить абонентов с большим RTT, например, 10.5
Заходим к абоненту и видим такую картину:
На каждую пятиминутку ретрансмитов у абонента около 2% потерь. Скорее всего, ему надо менять Wi-Fi-роутер. Этим клиентом точно надо заняться.
Абоненты со стабильно плохим Интернетом
Это одна из основных причин, которые побудили меня попробовать QoE. Можно вывести всех абонентов со стабильно плохим RTT и с каждым поработать индивидуально. Например, откроем статистику в списке по абоненту №3.
У данного абонента нет ошибок на порту, кабель 37 метров. Скорее всего, беда кроется в квартире абонента.
Проблемные Wi-Fi-вендоры
Как я понял, работает это так: снимается информация с DHCP-сервера по MACам абонентских устройств. Таким образом, вытаскиваются все Wi-Fi-вендоры:
Самый популярный и с нормальным RTT оказался Zyxel, на нем 9307 абонентов.
Топ худших ниже, с RTT от 15.2 и ниже.
Перепродажа Интернета
Нашел еще такую функцию, которая показывает абонентов с количеством сессий.
Сразу видно абонентов с кучей сессий. Зайдем в абонента под номером 1.
В разделе «Логи Clickstream» можно увидеть сколько устройств у абонента на данный момент:
Как мы видим, у абонента 100 устройств. Такой абонент точно перепродает интернет. Что с ним делать? Например, мы таких абонентов планируем перевести на обслуживание, как юр лицо.
Clickstream-аналитика
Тут, кажется, все просто: clickstream показывает какие устройства используют абоненты, какие сайты посещают, какими браузерами пользуются. Мне данная информация не так интересна, но она оказалась нужна нашим маркетологам. Им, например, интересны следующие сценарии:
1) Продажа нашего ТВ-сервиса тем абонентам, у которых есть Smart TV. Для этого можно отфильтровать по «user-agent: SmartTV» и вывести владельцев умного ТВ. Потом дело техники: обзвон клиентов или письмо с предложением подключить тариф с ТВ.
2) Поиск потенциальных недовольных клиентов, которые интересуются сайтами конкурентов. В том же разделе «логи Clickstream» вбиваем в строку «домен» URL интересующего нас конкурента, и, в результате, получаем такой список:
Дополнительно можно вернуться в самое начало моего теста и проверить на качество RTT (может у абонента проблема с его Wi-Fi-роутером).
Дальше эту информацию можно передавать в маркетинг, колл-центр, они знают, что делать. Как минимум, пообщаются с абонентами по поводу их удовлетворенности качеством наших услуг.
Connection Log
Есть функция connection log, с помощью которой можно определить, сколько виртуальных адресов находится за одним реальным.
По сути, данный график показывает плотность работы NAT провайдера. На данном графике видно, что NAT еще можно уплотнить.
Логи DPI
Тут можно посмотреть ТОП автономок, приложений.
Можно посмотреть конкретное приложение в разрезе качества связи, и с каких автономок льется, например World of tanks:
Ничего необычного: льется с GCORE, тормозов особо нет.
Можно зайти на автономку GCORE и посмотреть, что еще с нее на нас льется:
Еще можно создать интересный фильтр. Например, показать российские AS, у которых, задержка более 16 мс.
Другими словами, можно понять где пиринг ходит через Запад
В результате получаем список AS:
Итог:
Для моих задач в целом продукт годный, так как без особого труда я смог найти всех проблемных абонентов с RTT больше 4-5 c с указанием причины (битый кабель, вирусы и тд) и указанием «проблемных» районов – с указанием улицы и IP абонентов. Также хочу отметить полезную функцию – поиск абонентов, которые уже рассматривают свой побег к конкурентам.
Чего бы мне хотелось видеть в будущих версиях продукта – это автоматизацию. То есть, вот система находит абонентов, которые начали заходить на сайты конкурентов, то мне бы было удобнее получать уведомления на почту о таких событиях.
Еще в плане автоматизации было бы удобно, если можно было бы интегрироваться с нашей VoIP, чтобы при возникновении «ужасного» RTT у абонента, наш колл-центр автоматически позванивал таких клиентов по заранее прописанному сценарию.
Но пока нам, как провайдеру, придется решать задачу оттока клиентов в комплексе совместно со службой поддержки и колл-центра в ручном или полу ручном режиме. В ближайших планах хотим перейти от тестирования к внедрению.
P.S.: Если будет интересно, то могу рассказать о том, как мы работали с абонентами, которые хотели сбежать к конкурентам. А также о том, как мы будем интегрировать данный продукт в нашу сеть.
В общем, пишите в камменты, какую из этих тем вы бы хотели видеть в качестве следующей статьи, а я отправлю в редакцию сайта материал — может они согласятся опубликовать мои творения.