Как Optus улучшает качество обслуживания клиентов в сфере широкополосной связи и мобильной связи с помощью платформы анализа сетевых данных на AWS

Переиздано Платоном

Читают: 0

Это гостевая запись в блоге, написанная в соавторстве с Раджагопалом Махендраном, менеджером по развитию команды Optus IT Innovation.

Optus является частью группы The Singtel, которая работает в одном из самых быстрорастущих и динамичных регионов мира и присутствует в 21 стране. Optus предоставляет не только основные телекоммуникационные услуги, но и широкий спектр цифровых решений, включая облачные технологии, кибербезопасность и цифровую рекламу для предприятий, а также развлекательные и мобильные финансовые услуги для миллионов потребителей. Optus предоставляет услуги мобильной связи более чем 10.4 миллионам клиентов и услуги широкополосного доступа более чем 1.1 миллионам домов и предприятий. Кроме того, Optus Sport объединяет около 1 миллиона болельщиков с Премьер-лигой, международным футболом и фитнес-контентом.

В этом посте мы рассмотрим, как Optus использовал Амазонка Кинезис для приема и анализа сетевых данных в озере данных на AWS, а также для улучшения качества обслуживания клиентов и процесса планирования услуг.

Задача

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

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

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

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

Конструктивные соображения

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

У нас были следующие функциональные и нефункциональные требования:

Новая платформа должна быть способна поддерживать сбор данных с будущих типов клиентского оборудования, а также новые способы приема (новые протоколы и частота) и новые форматы данных.
Он должен поддерживать множество потребителей (API, работающий практически в реальном времени для сотрудников службы поддержки и клиентских приложений, а также операционных и бизнес-отчетов) для потребления данных и получения аналитической информации. Цель состоит в том, чтобы платформа активно выявляла проблемы и генерировала соответствующие оповещения для сотрудников службы поддержки, а также для клиентов.
После поступления данных аналитические данные из данных должны быть готовы в виде API через несколько секунд (максимум 5 секунд).
Новая платформа должна быть достаточно отказоустойчивой, чтобы продолжать обработку в случае сбоя частей инфраструктуры, таких как узлы или зоны доступности.
Он может поддерживать большее количество устройств и служб, а также более частый сбор данных с устройств.
Небольшая межфункциональная команда, специализирующаяся на бизнесе и технологиях, будет создавать и управлять этой платформой. В долгосрочной перспективе нам необходимо обеспечить минимальные инфраструктурные и эксплуатационные накладные расходы.
Конвейер должен иметь высокую доступность и позволять выполнять новые развертывания без простоев.

Обзор решения

Учитывая цель платформы и особенности проектирования, мы решили использовать сервисы более высокого порядка и бессерверные сервисы AWS, где это возможно, чтобы избежать ненужных операционных затрат для нашей команды и сосредоточиться на основных потребностях бизнеса. Сюда входит использование семейства сервисов Kinesis для приема и обработки потоков; AWS Lambda для обработки; Amazon DynamoDB, Сервис реляционной базы данных Amazon (Amazon RDS) и Простой сервис хранения Amazon (Amazon S3) для сохранения данных; и AWS Elastic Beanstalk и Шлюз API Amazon для обслуживания приложений и API. На следующей диаграмме показано общее решение.

Решение принимает файлы журналов с тысяч клиентского сетевого оборудования (домашних маршрутизаторов) в заранее определенные периоды времени. Клиентское оборудование способно отправлять только простые запросы HTTP PUT и POST для передачи файлов журналов. Чтобы получить эти файлы, мы используем приложение Java, работающее в группе Auto Scaling. Эластичное вычислительное облако Amazon (Amazon EC2). После некоторых первоначальных проверок приложение-получатель выполняет очистку и форматирование, а затем передает файлы журналов в потоковом режиме. Потоки данных Amazon Kinesis.

Мы намеренно используем специальное приложение-приемник на уровне приема, чтобы обеспечить гибкость в поддержке различных устройств и форматов файлов.

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

Индивидуальные идеи – Вопросы, на которые есть ответы в этой категории, включают:
- Сколько ошибок произошло на конкретном клиентском устройстве за последние 15 минут?
- Какая была последняя ошибка?
- Сколько устройств в настоящее время подключено у конкретного клиента дома?
- Какова скорость передачи/получения, зафиксированная конкретным клиентским устройством?
Базовая информация – Что касается группы или всей базы пользователей, вопросы этой категории включают:
- Сколько клиентских устройств сообщили о сбоях в обслуживании за последние 24 часа?
- На устройствах каких типов (моделей) возникло наибольшее количество ошибок за последние 6 месяцев?
- Сообщили ли они о каких-либо ошибках после вчерашнего обновления патча на группе устройств? Было ли техническое обслуживание успешным?

Верхняя полоса архитектуры показывает конвейер, который генерирует отдельные идеи.

Сопоставление источника событий функции Lambda настроено на использование записей из потока данных Kinesis. Эта функция считывает записи, форматирует их и подготавливает их на основе необходимой информации. Наконец, он сохраняет результаты в хранилище Amazon S3, а также обновляет таблицу DynamoDB, в которой хранится сводка и метаданные фактических данных, хранящихся в Amazon S3.

Чтобы оптимизировать производительность, мы настроили две метрики в сопоставлении источников событий Lambda:

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

Наконец, API предоставляется через API Gateway и запускается в приложении Spring Boot, размещенном на Elastic Beanstalk. В будущем нам может потребоваться сохранять состояние между вызовами API, поэтому мы используем Elastic Beanstalk вместо бессерверного приложения.

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

МЫ ИСПОЛЬЗУЕМ Аналитика данных Amazon Kinesis, выполняя вычисления с сохранением состояния для потоковых данных, чтобы суммировать определенные показатели, такие как скорость передачи или частота ошибок, в заданных временных окнах. Эти сводки затем передаются в Амазон Аврора База данных с моделью данных, подходящей для информационных панелей и отчетов.

Затем полученные данные представляются на информационных панелях с помощью веб-приложения, работающего на Elastic Beanstalk.

Уроки, извлеченные

Использование бессерверных шаблонов и сервисов более высокого порядка, в частности Lambda, Kinesis Data Streams, Kinesis Data Analytics и DynamoDB, обеспечило большую гибкость нашей архитектуры и помогло нам перейти к микросервисам, а не к большим монолитным пакетным заданиям.

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

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

В ходе разработки и производства мы также обнаружили несколько технических советов, которыми стоит поделиться:

Результаты и преимущества

Теперь у нас есть возможность отслеживать производительность наших фиксированных и мобильных сетей практически в реальном времени, как это видят наши клиенты. Раньше у нас были только данные, которые поступали в пакетном режиме с задержкой и тоже только от наших собственных сетевых датчиков и оборудования.

Благодаря просмотру сети практически в реальном времени при возникновении изменений наши оперативные группы также могут выполнять обновления и обслуживание всего парка клиентских устройств с большей уверенностью и частотой.

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

Забегая вперед

Поскольку платформа сетевой аналитики работает уже несколько месяцев и сейчас стабильна, существует потребность в более глубокой информации и новых сценариях использования. Например, мы рассматриваем вариант использования мобильных устройств, чтобы лучше управлять пропускной способностью на крупномасштабных мероприятиях (например, спортивных мероприятиях). Цель состоит в том, чтобы наши команды управлялись данными и могли реагировать практически в реальном времени на потребности в мощности в таких событиях.

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

Об авторах

Раджагопал Махендран является менеджером по развитию в команде Optus IT Innovation. Махендран имеет более чем 14-летний опыт работы в различных организациях, предоставляющих корпоративные приложения от среднего до очень крупного масштаба с использованием проверенных и передовых технологий в области больших данных, приложений потоковой передачи данных, мобильных и облачных приложений. Его страсть — воплощать в жизнь инновационные идеи с использованием технологий для улучшения жизни. В свободное время он любит гулять по лесу и плавать.

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

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