In che modo Optus migliora l'esperienza dei clienti mobili e a banda larga utilizzando la piattaforma Network Data Analytics su AWS

Nodo di origine: 886719

Questo è un post sul blog degli ospiti scritto in collaborazione da Rajagopal Mahendran, Development Manager presso Optus IT Innovation Team.


Optus fa parte del gruppo Singtel, che opera in una delle regioni più dinamiche e in più rapida crescita del mondo, con una presenza in 21 paesi. Optus fornisce non solo servizi di telecomunicazione di base, ma anche una vasta gamma di soluzioni digitali, tra cui cloud, sicurezza informatica e pubblicità digitale per le imprese, nonché servizi finanziari mobili e di intrattenimento a milioni di consumatori. Optus fornisce servizi di comunicazione mobile a oltre 10.4 milioni di clienti e servizi a banda larga a oltre 1.1 milioni di case e aziende. Inoltre, Optus Sport collega quasi 1 milione di fan alla Premier League, al calcio internazionale e ai contenuti di fitness.

In questo post, guardiamo come Optus ha utilizzato Cinesi amazzonica per acquisire e analizzare i dati relativi alla rete in un data Lake su AWS e migliorare l'esperienza del cliente e il processo di pianificazione del servizio.

La sfida

Una sfida comune per i fornitori di telecomunicazioni è quella di formare una visione accurata e in tempo reale della qualità del servizio e dei problemi riscontrati dai propri clienti. La qualità della rete domestica e della connettività a banda larga ha un impatto significativo sulla produttività e sulla soddisfazione dei clienti, soprattutto considerando la crescente dipendenza dalle reti domestiche per il lavoro, il collegamento con la famiglia e gli amici e l’intrattenimento durante la pandemia di COVID-19.

Inoltre, le operazioni di rete e i team di pianificazione spesso non hanno accesso ai dati e agli insight giusti per pianificare nuove implementazioni e gestire l'attuale parco di dispositivi.

La piattaforma di analisi di rete fornisce dati e approfondimenti sulla risoluzione dei problemi e sulla pianificazione ai team Optus e ai loro clienti in tempo quasi reale, il che aiuta a ridurre il tempo medio necessario per correggere e migliorare l'esperienza del cliente. Con i dati e gli approfondimenti giusti, i clienti hanno un'esperienza migliore perché invece di avviare una chiamata di supporto con molte domande, il personale di supporto e il cliente hanno una visione aggiornata e accurata dei servizi e della rete domestica del cliente.

I team dei proprietari dei servizi all'interno di Optus possono anche utilizzare le informazioni e le tendenze derivate da questa piattaforma per pianificare meglio il futuro e fornire un servizio di qualità superiore ai clienti.

Considerazioni sul design

Per affrontare questa sfida e i suoi requisiti, abbiamo avviato un progetto per trasformare il nostro attuale sistema di raccolta ed elaborazione batch in un sistema di elaborazione quasi in tempo reale basato su flusso e introdurre API per approfondimenti in modo che i sistemi di supporto e le applicazioni dei clienti possano mostrare l'ultima istantanea della rete e dello stato del servizio.

Avevamo i seguenti requisiti funzionali e non funzionali:

  • La nuova piattaforma deve essere in grado di supportare l’acquisizione di dati da futuri tipi di apparecchiature dei clienti, nonché nuove modalità di acquisizione (nuovi protocolli e frequenza) e nuovi formati di dati.
  • Dovrebbe supportare più consumatori (un'API quasi in tempo reale per il personale di supporto e le applicazioni dei clienti e il reporting operativo e aziendale) per consumare dati e generare approfondimenti. L'obiettivo è che la piattaforma rilevi in ​​modo proattivo i problemi e generi avvisi appropriati per il personale di supporto e per i clienti.
  • Dopo l'arrivo dei dati, le informazioni approfondite dai dati dovrebbero essere pronte sotto forma di API in pochi secondi (massimo 5 secondi).
  • La nuova piattaforma dovrebbe essere sufficientemente resiliente da continuare l'elaborazione quando parti dell'infrastruttura falliscono, come i nodi o le zone di disponibilità.
  • Può supportare un numero maggiore di dispositivi e servizi nonché raccolte più frequenti dai dispositivi.
  • Un piccolo team interfunzionale che si occupa di business e tecnologia costruirà e gestirà questa piattaforma. Dobbiamo garantire infrastrutture e costi operativi minimi nel lungo termine.
  • La pipeline dovrebbe essere altamente disponibile e consentire nuove distribuzioni senza tempi di inattività.

Panoramica della soluzione

Tenendo presente l'obiettivo della piattaforma e considerazioni di progettazione, abbiamo deciso di utilizzare servizi di ordine superiore e servizi serverless di AWS, ove possibile, per evitare inutili spese operative per il nostro team e concentrarci sulle esigenze aziendali principali. Ciò include l'utilizzo della famiglia di servizi Kinesis per l'acquisizione e l'elaborazione dei flussi; AWS Lambda per l'elaborazione; Amazon DynamoDB, Servizio di database relazionale Amazon (Amazon RDS) e Servizio di archiviazione semplice Amazon (Amazon S3) per la persistenza dei dati; E Beanstalk AWS elastico ed Gateway API Amazon per il servizio di applicazioni e API. Il diagramma seguente mostra la soluzione complessiva.

La soluzione acquisisce file di registro da migliaia di apparecchiature di rete dei clienti (router domestici) in periodi predefiniti. L'apparecchiatura del cliente è in grado solo di inviare semplici richieste HTTP PUT e POST per trasferire file di registro. Per ricevere questi file, utilizziamo un'applicazione Java in esecuzione in un gruppo Auto Scaling di Cloud di calcolo elastico di Amazon (Amazon EC2). Dopo alcuni controlli iniziali, l'applicazione ricevente esegue la pulizia e la formattazione, quindi trasmette i file di registro Flussi di dati di Amazon Kinesis.

Utilizziamo intenzionalmente un'applicazione ricevente personalizzata nel livello di acquisizione per fornire flessibilità nel supportare diversi dispositivi e formati di file.

Per comprendere il resto dell'architettura, diamo un'occhiata agli approfondimenti attesi. La piattaforma produce due tipologie di insight:

  • Intuizioni individuali – Le domande con risposta in questa categoria includono:
    • Quanti errori ha riscontrato un determinato dispositivo del cliente negli ultimi 15 minuti?
    • Qual è stato l'ultimo errore?
    • Quanti dispositivi sono attualmente collegati a casa di un determinato cliente?
    • Qual è la velocità di trasferimento/ricezione acquisita da un particolare dispositivo del cliente?
  • Approfondimenti di base – Relative a un gruppo o all'intera base di utenti, le domande in questa categoria includono:
    • Quanti dispositivi dei clienti hanno segnalato un'interruzione del servizio nelle ultime 24 ore?
    • Quali tipi di dispositivi (modelli) hanno riscontrato il maggior numero di errori negli ultimi 6 mesi?
    • Dopo l'aggiornamento della patch di ieri sera su un gruppo di dispositivi, sono stati segnalati errori? La manutenzione ha avuto successo?

La corsia superiore dell'architettura mostra la pipeline che genera i singoli approfondimenti.

La mappatura dell'origine evento della funzione Lambda è configurata per utilizzare record dal flusso di dati Kinesis. Questa funzione legge i record, li formatta e li prepara in base agli approfondimenti richiesti. Infine, memorizza i risultati nella posizione Amazon S3 e aggiorna anche una tabella DynamoDB che mantiene un riepilogo e i metadati dei dati effettivi archiviati in Amazon S3.

Per ottimizzare le prestazioni, abbiamo configurato due parametri nella mappatura dell'origine evento Lambda:

  • Dimensione del lotto – Mostra il numero di record da inviare alla funzione in ciascun batch, il che aiuta a ottenere un throughput più elevato
  • Batch simultanei per shard – Elabora più batch dallo stesso frammento contemporaneamente, il che aiuta a velocizzare l'elaborazione

Infine, l'API viene fornita tramite API Gateway e viene eseguita su un'applicazione Spring Boot ospitata su Elastic Beanstalk. In futuro, potrebbe essere necessario mantenere lo stato tra le chiamate API, motivo per cui utilizziamo Elastic Beanstalk anziché un'applicazione serverless.

La corsia inferiore dell'architettura è la pipeline che genera report di base.

Usiamo Analisi dei dati di Amazon Kinesis, eseguendo calcoli con stato sui dati in streaming, per riepilogare determinati parametri come velocità di trasferimento o tassi di errore in determinate finestre temporali. Questi riepiloghi vengono quindi inseriti in un file Amazon Aurora database con un modello di dati adatto a scopi di dashboarding e reporting.

Gli approfondimenti vengono quindi presentati in dashboard utilizzando un'applicazione Web in esecuzione su Elastic Beanstalk.

Le lezioni apprese

L'utilizzo di modelli serverless e servizi di ordine superiore, in particolare Lambda, Kinesis Data Streams, Kinesis Data Analytics e DynamoDB, ha fornito molta flessibilità alla nostra architettura e ci ha aiutato a spostarci maggiormente verso i microservizi piuttosto che verso grandi lavori batch monolitici.

Questo cambiamento ci ha anche aiutato a ridurre drasticamente i costi generali di gestione operativa e dei servizi. Ad esempio, negli ultimi mesi dal lancio, i clienti di questa piattaforma non hanno riscontrato alcuna interruzione del servizio.

Questa soluzione ci ha anche permesso di adottare più DevOps e modalità di lavoro agili, nel senso che un unico piccolo team sviluppa e gestisce il sistema. Ciò a sua volta ha consentito all’organizzazione di essere più agile e innovativa in questo ambito.

Nel corso dello sviluppo e della produzione abbiamo anche scoperto alcuni suggerimenti tecnici che vale la pena condividere:

Risultati e benefici

Ora abbiamo una visibilità quasi in tempo reale delle prestazioni delle nostre reti fisse e mobili sperimentate dai nostri clienti. In passato disponevamo solo di dati che arrivavano in modalità batch con ritardo e anche solo dalle nostre sonde e apparecchiature di rete.

Grazie alla visualizzazione quasi in tempo reale della rete quando si verificano cambiamenti, i nostri team operativi possono anche eseguire aggiornamenti e manutenzione sull'intera flotta di dispositivi dei clienti con maggiore sicurezza e frequenza.

Infine, i nostri team di pianificazione utilizzano queste informazioni per formare una visione accurata e aggiornata delle prestazioni di varie apparecchiature e servizi. Ciò porta a un servizio di qualità superiore per i nostri clienti a prezzi migliori perché i nostri team di pianificazione dei servizi sono in grado di ottimizzare i costi, negoziare meglio con venditori e fornitori di servizi e pianificare il futuro.

Guardando al futuro

Con la piattaforma di analisi di rete in produzione da diversi mesi e ora stabile, c’è richiesta di maggiori approfondimenti e nuovi casi d’uso. Ad esempio, stiamo esaminando un caso d'uso mobile per gestire meglio la capacità in occasione di eventi su larga scala (come eventi sportivi). L’obiettivo è che i nostri team siano guidati dai dati e in grado di reagire in tempo quasi reale alle esigenze di capacità in questi eventi.

Un'altra area di domanda riguarda la manutenzione predittiva: stiamo cercando di introdurre il machine learning in queste pipeline per contribuire a ottenere informazioni più rapide e precise utilizzando il portafoglio di servizi AWS Machine Learning.


Circa gli autori

Rajagopal Mahendran è Development Manager presso l'Optus IT Innovation Team. Mahendran ha oltre 14 anni di esperienza in varie organizzazioni che forniscono applicazioni aziendali su scala media o molto ampia utilizzando tecnologie comprovate e all'avanguardia in big data, applicazioni di dati in streaming, applicazioni mobili e native del cloud. La sua passione è alimentare idee innovative utilizzando la tecnologia per una vita migliore. Nel tempo libero ama passeggiare nel bush e nuotare.

Mostafà Safipur è un Solutions Architect presso AWS con sede a Sydney. Collabora con i clienti per realizzare risultati aziendali utilizzando la tecnologia e AWS. Negli ultimi dieci anni ha aiutato molte grandi organizzazioni nella regione ANZ a creare i propri carichi di lavoro dati, digitali e aziendali su AWS.

Masudur Rahaman Sayem è un Solution Architect specializzato per l'analisi presso AWS. Collabora con i clienti AWS per fornire indicazioni e assistenza tecnica su progetti di dati e analisi, aiutandoli a migliorare il valore delle loro soluzioni quando utilizzano AWS. È appassionato di sistemi distribuiti. Gli piace anche leggere, soprattutto i fumetti classici.

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

Timestamp:

Di più da AWS