Cómo Optus mejora la experiencia del cliente móvil y de banda ancha utilizando la plataforma Network Data Analytics en AWS

Esta es una publicación de blog invitada coescrita por Rajagopal Mahendran, Gerente de Desarrollo del Equipo de Innovación de TI de Optus.

---

Optus es parte del grupo The Singtel, que opera en una de las regiones más dinámicas y de más rápido crecimiento del mundo, con presencia en 21 países. Optus ofrece no solo servicios básicos de telecomunicaciones, sino también una amplia gama de soluciones digitales, incluida la nube, la ciberseguridad y la publicidad digital para empresas, así como servicios financieros móviles y de entretenimiento para millones de consumidores. Optus ofrece servicios de comunicaciones móviles a más de 10.4 millones de clientes y servicios de banda ancha a más de 1.1 millones de hogares y empresas. Además, Optus Sport conecta a cerca de 1 millón de fanáticos con contenido de la Premier League, fútbol internacional y fitness.

En esta publicación, analizamos cómo Optus usó Kinesis amazónica para ingerir y analizar datos relacionados con la red en un lago de datos en AWS y mejorar la experiencia del cliente y el proceso de planificación del servicio.

El desafío

Un desafío común para los proveedores de telecomunicaciones es formarse una visión precisa y en tiempo real de la calidad del servicio y los problemas experimentados por sus clientes. La calidad de la conectividad de la red doméstica y de banda ancha tiene un impacto significativo en la productividad y satisfacción del cliente, especialmente considerando la mayor dependencia de las redes domésticas para el trabajo, la conexión con familiares y amigos y el entretenimiento durante la pandemia de COVID-19.

Además, los equipos de planificación y operaciones de red a menudo no tienen acceso a los datos y conocimientos adecuados para planificar nuevas implementaciones y administrar su flota actual de dispositivos.

La plataforma de análisis de red proporciona información y datos de planificación y resolución de problemas a los equipos de Optus y sus clientes casi en tiempo real, lo que ayuda a reducir el tiempo medio para rectificar y mejorar la experiencia del cliente. Con los datos y la información correctos, los clientes tienen una mejor experiencia porque, en lugar de iniciar una llamada de soporte con muchas preguntas, el personal de soporte y el cliente tienen una visión actual y precisa de los servicios y la red doméstica del cliente.

Los equipos de propietarios de servicios dentro de Optus también pueden utilizar los conocimientos y las tendencias derivadas de esta plataforma para planificar mejor el futuro y brindar un servicio de mayor calidad a los clientes.

Consideraciones de diseño

Para abordar este desafío y sus requisitos, nos embarcamos en un proyecto para transformar nuestro sistema actual de procesamiento y recopilación de lotes en un sistema de procesamiento basado en flujo casi en tiempo real, e introducir API para obtener información para que los sistemas de soporte y las aplicaciones del cliente puedan mostrar la última instantánea del estado de la red y del servicio.

Teníamos los siguientes requisitos funcionales y no funcionales:

• La nueva plataforma debe ser capaz de soportar la captura de datos de futuros tipos de equipos del cliente, así como nuevas formas de ingestión (nuevos protocolos y frecuencia) y nuevos formatos de datos.
• Debe ser compatible con varios consumidores (una API casi en tiempo real para el personal de soporte y las aplicaciones de los clientes y los informes operativos y comerciales) para consumir datos y generar conocimientos. El objetivo es que la plataforma detecte problemas de forma proactiva y genere alertas adecuadas tanto para el personal de soporte como para los clientes.
• Una vez que llegan los datos, la información de los datos debe estar lista en forma de API en unos segundos (5 segundos como máximo).
• La nueva plataforma debe ser lo suficientemente resistente para continuar procesando cuando fallan partes de la infraestructura, como los nodos o las zonas de disponibilidad.
• Puede admitir un mayor número de dispositivos y servicios, así como una recopilación más frecuente de los dispositivos.
• Un pequeño equipo multifuncional de negocios y tecnología construirá y ejecutará esta plataforma. Necesitamos garantizar una infraestructura mínima y una sobrecarga operativa a largo plazo.
• La canalización debe tener una alta disponibilidad y permitir nuevas implementaciones sin tiempo de inactividad.

Resumen de la solución

Con el objetivo de la plataforma y las consideraciones de diseño en mente, decidimos utilizar servicios de orden superior y servicios sin servidor de AWS siempre que fuera posible, para evitar gastos operativos innecesarios para nuestro equipo y enfocarnos en las necesidades comerciales centrales. Esto incluye el uso de la familia de servicios de Kinesis para la ingestión y el procesamiento de secuencias; AWS Lambda para procesar; Amazon DynamoDB, Servicio de base de datos relacional de Amazon (Amazon RDS) y Servicio de almacenamiento simple de Amazon (Amazon S3) para la persistencia de datos; y Beanstalk elástico de AWS y Puerta de enlace API de Amazon para el servicio de aplicaciones y API. El siguiente diagrama muestra la solución general.

La solución ingiere archivos de registro de miles de equipos de red del cliente (enrutadores domésticos) en períodos predefinidos. El equipo del cliente solo puede enviar solicitudes HTTP PUT y POST simples para transferir archivos de registro. Para recibir estos archivos, utilizamos una aplicación Java que se ejecuta en un grupo de Auto Scaling de Nube informática elástica de Amazon (Amazon EC2) instancias. Después de algunas comprobaciones iniciales, la aplicación receptora realiza la limpieza y el formateo, luego transmite los archivos de registro a Secuencias de datos de Amazon Kinesis.

Usamos intencionalmente una aplicación de receptor personalizada en la capa de ingestión para brindar flexibilidad al admitir diferentes dispositivos y formatos de archivo.

Para comprender el resto de la arquitectura, echemos un vistazo a los conocimientos esperados. La plataforma produce dos tipos de información:

• Perspectivas individuales - Las preguntas respondidas en esta categoría incluyen:
  • ¿Cuántos errores ha experimentado un dispositivo de cliente en particular en los últimos 15 minutos?
  • ¿Cuál fue el último error?
  • ¿Cuántos dispositivos están conectados actualmente en la casa de un cliente en particular?
  • ¿Cuál es la tasa de transferencia / recepción capturada por un dispositivo de cliente en particular?
• Información básica - Pertenecientes a un grupo o a toda la base de usuarios, las preguntas de esta categoría incluyen:
  • ¿Cuántos dispositivos de clientes informaron interrupciones del servicio en las últimas 24 horas?
  • ¿Qué tipos de dispositivos (modelos) han experimentado la mayor cantidad de errores en los últimos 6 meses?
  • Después de la actualización del parche de anoche en un grupo de dispositivos, ¿han informado de algún error? ¿Fue exitoso el mantenimiento?

El carril superior de la arquitectura muestra la canalización que genera los conocimientos individuales.

La asignación de origen de eventos de la función Lambda está configurada para consumir registros del flujo de datos de Kinesis. Esta función lee los registros, los formatea y los prepara en función de los conocimientos necesarios. Finalmente, almacena los resultados en la ubicación de Amazon S3 y también actualiza una tabla de DynamoDB que mantiene un resumen y los metadatos de los datos reales almacenados en Amazon S3.

Para optimizar el rendimiento, configuramos dos métricas en el mapeo de origen de eventos de Lambda:

• Tamaño del lote - Muestra la cantidad de registros para enviar a la función en cada lote, lo que ayuda a lograr un mayor rendimiento
• Lotes simultáneos por fragmento - Procesa varios lotes del mismo fragmento al mismo tiempo, lo que ayuda a un procesamiento más rápido

Finalmente, la API se proporciona a través de API Gateway y se ejecuta en una aplicación Spring Boot alojada en Elastic Beanstalk. En el futuro, es posible que necesitemos mantener el estado entre las llamadas a la API, razón por la cual usamos Elastic Beanstalk en lugar de una aplicación sin servidor.

El carril inferior de la arquitectura es la canalización que genera informes básicos.

Utilizamos Análisis de datos de Amazon Kinesis, ejecutando computación con estado en transmisión de datos, para resumir ciertas métricas como tasas de transferencia o tasas de error en ventanas de tiempo dadas. Estos resúmenes luego se envían a un Aurora amazónica base de datos con un modelo de datos que sea adecuado para crear paneles y generar informes.

Luego, los conocimientos se presentan en paneles mediante una aplicación web que se ejecuta en Elastic Beanstalk.

Lecciones aprendidas

El uso de patrones sin servidor y servicios de orden superior, en particular Lambda, Kinesis Data Streams, Kinesis Data Analytics y DynamoDB, proporcionó mucha flexibilidad en nuestra arquitectura y nos ayudó a avanzar más hacia los microservicios en lugar de los grandes trabajos por lotes monolíticos.

Este cambio también nos ayudó a reducir drásticamente nuestros gastos generales de gestión operativa y de servicios. Por ejemplo, durante los últimos meses desde el lanzamiento, los clientes de esta plataforma no experimentaron ninguna interrupción del servicio.

Esta solución también nos permitió adoptar más DevOps y formas de trabajo ágiles, en el sentido de que un solo equipo pequeño desarrolla y ejecuta el sistema. Esto, a su vez, permitió a la organización ser más ágil e innovadora en este ámbito.

También descubrimos algunos consejos técnicos a lo largo del curso de desarrollo y producción que vale la pena compartir:

Resultados y beneficios

Ahora tenemos una visibilidad casi en tiempo real del rendimiento de nuestras redes fijas y móviles según la experiencia de nuestros clientes. En el pasado, solo teníamos datos que venían en modo por lotes con un retraso y también solo de nuestros propios equipos y sondas de red.

Con la vista casi en tiempo real de la red cuando ocurren cambios, nuestros equipos operativos también pueden llevar a cabo actualizaciones y mantenimiento en toda la flota de dispositivos del cliente con mayor confianza y frecuencia.

Por último, nuestros equipos de planificación utilizan estos conocimientos para formar una vista precisa y actualizada del rendimiento de varios equipos y servicios. Esto conduce a un servicio de mayor calidad para nuestros clientes a mejores precios porque nuestros equipos de planificación de servicios están capacitados para optimizar los costos, negociar mejor con los proveedores y proveedores de servicios y planificar el futuro.

Mirando hacia el futuro

Con la plataforma de análisis de red en producción durante varios meses y estable ahora, existe una demanda de más información y nuevos casos de uso. Por ejemplo, estamos estudiando un caso de uso de dispositivos móviles para administrar mejor la capacidad en eventos a gran escala (como eventos deportivos). El objetivo es que nuestros equipos se basen en datos y puedan reaccionar en tiempo casi real a las necesidades de capacidad en estos eventos.

Otra área de demanda se relaciona con el mantenimiento predictivo: buscamos introducir el aprendizaje automático en estas canalizaciones para ayudar a generar conocimientos de forma más rápida y precisa mediante el uso de la cartera de servicios de aprendizaje automático de AWS.

---

Sobre los autores

Rajagopal Mahendran es gerente de desarrollo en el equipo de innovación de TI de Optus. Mahendran tiene más de 14 años de experiencia en varias organizaciones que brindan aplicaciones empresariales de mediana a gran escala utilizando tecnologías probadas y de vanguardia en big data, aplicaciones de transmisión de datos, aplicaciones móviles y nativas de la nube. Su pasión es impulsar ideas innovadoras utilizando la tecnología para vivir mejor. En su tiempo libre, le encanta pasear por el monte y nadar.

Mostafa Safipur es arquitecto de soluciones en AWS con sede en Sydney. Trabaja con los clientes para obtener resultados comerciales mediante la tecnología y AWS. Durante la última década, ha ayudado a muchas organizaciones grandes en la región ANZ a construir sus cargas de trabajo de datos, digitales y empresariales en AWS.

Masudur Rahaman Sayem es un arquitecto de soluciones especializado para análisis en AWS. Trabaja con los clientes de AWS para proporcionar orientación y asistencia técnica sobre proyectos de análisis y datos, ayudándolos a mejorar el valor de sus soluciones cuando utilizan AWS. Es un apasionado de los sistemas distribuidos. También le gusta leer, especialmente los cómics clásicos.

Fuente: https://aws.amazon.com/blogs/big-data/how-optus-improves-broadband-and-mobile-customer-experience-using-the-network-data-analytics-platform-on-aws/