Hvordan Optus forbedrer bredbånds- og mobilkundeoplevelsen ved at bruge Network Data Analytics-platformen på AWS

Dette er et gæsteblogindlæg, som er skrevet af Rajagopal Mahendran, udviklingschef hos Optus IT Innovation Team.

---

Optus er en del af The Singtel-gruppen, som opererer i en af ​​verdens hurtigst voksende og mest dynamiske regioner med tilstedeværelse i 21 lande. Optus leverer ikke kun centrale teletjenester, men også en bred vifte af digitale løsninger, herunder cloud, cybersikkerhed og digital annoncering til virksomheder, samt underholdning og mobile finansielle tjenester til millioner af forbrugere. Optus leverer mobilkommunikationstjenester til over 10.4 millioner kunder og bredbåndstjenester til over 1.1 millioner hjem og virksomheder. Derudover forbinder Optus Sport tæt på 1 million fans til Premier League, international fodbold og fitnessindhold.

I dette indlæg ser vi på, hvordan Optus brugte Amazon Kinesis at indtage og analysere netværksrelaterede data i en datasø på AWS og forbedre kundeoplevelsen og serviceplanlægningsprocessen.

Udfordringen

En fælles udfordring for teleudbydere er at danne sig et nøjagtigt, realtidsbillede af servicekvaliteten og problemer, som deres kunder oplever. Kvaliteten af ​​hjemmenetværk og bredbåndsforbindelse har en betydelig indvirkning på kundernes produktivitet og tilfredshed, især i betragtning af den øgede afhængighed af hjemmenetværk til arbejde, forbindelse med familie og venner og underholdning under COVID-19-pandemien.

Derudover har netværksdrift og planlægningsteams ofte ikke adgang til de rigtige data og indsigt til at planlægge nye udrulninger og administrere deres nuværende flåde af enheder.

Netværksanalyseplatformen giver fejlfinding og planlægningsdata og indsigt til Optus-teams og deres kunder i næsten realtid, hvilket hjælper med at reducere den gennemsnitlige tid til at rette op på og forbedre kundeoplevelsen. Med de rette data og indsigt får kunderne en bedre oplevelse, fordi i stedet for at starte et supportopkald med en masse spørgsmål, har supportpersonalet og kunden et aktuelt og præcist overblik over tjenesterne og kundens hjemmenetværk.

Tjenesteejerteams inden for Optus kan også bruge indsigten og tendenserne fra denne platform til bedre at planlægge fremtiden og levere service af højere kvalitet til kunderne.

Designovervejelser

For at imødegå denne udfordring og dens krav påbegyndte vi et projekt for at transformere vores nuværende batchindsamlings- og behandlingssystem til et stream-baseret, næsten-realtidsbehandlingssystem og introducere API'er til indsigt, så supportsystemer og kundeapplikationer kan vise det seneste øjebliksbillede af netværket og tjenestestatus.

Vi havde følgende funktionelle og ikke-funktionelle krav:

• Den nye platform skal være i stand til at understøtte datafangst fra fremtidige typer af kundeudstyr samt nye måder at indtage på (nye protokoller og frekvens) og nye dataformater.
• Det bør understøtte flere forbrugere (en næsten realtids-API til supportmedarbejdere og kundeapplikationer og drifts- og forretningsrapportering) til at forbruge data og generere indsigt. Målet er, at platformen proaktivt kan opdage problemer og generere passende advarsler til supportmedarbejdere såvel som kunder.
• Efter dataene ankommer, skulle indsigter fra dataene være klar i form af en API på få sekunder (maks. 5 sekunder).
• Den nye platform skal være robust nok til at fortsætte behandlingen, når dele af infrastrukturen svigter, såsom noder eller Availability Zones.
• Det kan understøtte et øget antal enheder og tjenester samt hyppigere afhentning fra enhederne.
• Et lille tværfunktionelt team på tværs af forretning og teknologi vil bygge og drive denne platform. Vi skal sikre minimal infrastruktur og driftsomkostninger på længere sigt.
• Pipelinen bør være yderst tilgængelig og give mulighed for nye implementeringer uden nedetid.

Løsningsoversigt

Med målet om platformen og designovervejelser i tankerne, besluttede vi at bruge tjenester af højere orden og serverløse tjenester fra AWS, hvor det var muligt, for at undgå unødvendige operationelle overhead for vores team og fokusere på kerneforretningens behov. Dette inkluderer brug af Kinesis-familien af ​​tjenester til stream-indtagelse og -behandling; AWS Lambda til forarbejdning; Amazon DynamoDB, Amazon Relationel Database Service (Amazon RDS), og Amazon Simple Storage Service (Amazon S3) for datapersistens; og AWS elastisk bønnestængel , Amazon API Gateway til applikation og API-servering. Følgende diagram viser den overordnede løsning.

Løsningen indtager logfiler fra tusindvis af kundenetværksudstyr (hjemmeroutere) i foruddefinerede perioder. Kundeudstyret er kun i stand til at sende simple HTTP PUT- og POST-anmodninger for at overføre logfiler. For at modtage disse filer bruger vi en Java-applikation, der kører i en Auto Scaling-gruppe af Amazon Elastic Compute Cloud (Amazon EC2) forekomster. Efter nogle indledende kontroller udfører modtagerapplikationen rensning og formatering, hvorefter den streamer logfilerne til Amazon Kinesis datastrømme.

Vi bruger med vilje en brugerdefineret modtagerapplikation i indtagelseslaget for at give fleksibilitet til at understøtte forskellige enheder og filformater.

For at forstå resten af ​​arkitekturen, lad os tage et kig på de forventede indsigter. Platformen producerer to typer indsigt:

• Individuelle indsigter – Spørgsmål besvaret i denne kategori omfatter:
  • Hvor mange fejl har en bestemt kundeenhed oplevet inden for de sidste 15 minutter?
  • Hvad var den sidste fejl?
  • Hvor mange enheder er i øjeblikket tilsluttet hos et bestemt kundehjem?
  • Hvad er overførsels-/modtagelseshastigheden som registreret af en bestemt kundeenhed?
• Grundlæggende indsigt – Vedrørende en gruppe eller hele brugerbasen omfatter spørgsmål i denne kategori:
  • Hvor mange kundeenheder har rapporteret serviceafbrydelser inden for de seneste 24 timer?
  • Hvilke enhedstyper (modeller) har oplevet det højeste antal fejl inden for de seneste 6 måneder?
  • Efter sidste nats patch-opdatering på en gruppe af enheder, har de rapporteret nogen fejl? Var vedligeholdelsen vellykket?

Den øverste bane i arkitekturen viser den pipeline, der genererer de enkelte indsigter.

Hændelseskildetilknytningen af ​​Lambda-funktionen er konfigureret til at forbruge poster fra Kinesis-datastrømmen. Denne funktion læser registreringerne, formaterne og forbereder dem baseret på den nødvendige indsigt. Endelig gemmer den resultaterne på Amazon S3-lokationen og opdaterer også en DynamoDB-tabel, der vedligeholder en oversigt og metadataene for de faktiske data, der er gemt i Amazon S3.

For at optimere ydeevnen konfigurerede vi to metrics i Lambda-hændelseskilden:

• Batch størrelse – Viser antallet af poster, der skal sendes til funktionen i hver batch, hvilket hjælper med at opnå højere gennemløb
• Samtidige batches pr. shard – Behandler flere batches fra samme shard samtidigt, hvilket hjælper med hurtigere behandling

Endelig leveres API'et via API Gateway og kører på en Spring Boot-applikation, der hostes på Elastic Beanstalk. I fremtiden skal vi muligvis holde tilstanden mellem API-kald, hvorfor vi bruger Elastic Beanstalk i stedet for en serverløs applikation.

Den nederste bane i arkitekturen er den pipeline, der genererer basisrapporter.

Vi anvender Amazon Kinesis Data Analytics, der kører stateful beregning på streamingdata for at opsummere visse metrics som overførselshastigheder eller fejlfrekvenser i givne tidsvinduer. Disse oversigter skubbes derefter til en Amazon Aurora database med en datamodel, der er egnet til dashboarding og rapporteringsformål.

Indsigten præsenteres derefter i dashboards ved hjælp af en webapplikation, der kører på Elastic Beanstalk.

Erfaringer

Brug af serverløse mønstre og tjenester af højere orden, især Lambda, Kinesis Data Streams, Kinesis Data Analytics og DynamoDB, gav en masse fleksibilitet i vores arkitektur og hjalp os med at bevæge os mere mod mikrotjenester frem for store monolit-batchjobs.

Dette skift hjalp os også med at reducere vores drifts- og servicestyringsomkostninger dramatisk. I løbet af de sidste mange måneder siden lanceringen har kunder af denne platform f.eks. ikke oplevet nogen serviceafbrydelser.

Denne løsning gjorde det også muligt for os at anvende flere DevOps og agile måder at arbejde på, i den forstand at et enkelt lille team udvikler og kører systemet. Dette gjorde det igen muligt for organisationen at være mere agil og innovativ på dette område.

Vi opdagede også nogle tekniske tips gennem udviklingen og produktionen, som er værd at dele:

Resultater og fordele

Vi har nu næsten-realtid synlighed af vores faste og mobile netværks ydeevne, som vores kunder oplever. Tidligere havde vi kun data, der kom i batch-mode med en forsinkelse og også kun fra vores egne netværkssonder og udstyr.

Med et næsten realtidsbillede af netværket, når der sker ændringer, kan vores operationelle teams også udføre opgraderinger og vedligeholdelse på tværs af flåden af ​​kundeenheder med højere tillid og hyppighed.

Endelig bruger vores planlægningsteams denne indsigt til at danne et nøjagtigt, opdateret ydelsesbillede af forskelligt udstyr og tjenester. Dette fører til service af højere kvalitet til vores kunder til bedre priser, fordi vores serviceplanlægningsteams er i stand til at optimere omkostningerne, bedre forhandle med leverandører og serviceudbydere og planlægge fremtiden.

Fremadrettet

Med netværksanalyseplatformen i produktion i flere måneder og stabil nu, er der efterspørgsel efter mere indsigt og nye use cases. For eksempel undersøger vi en mobil use case for bedre at styre kapaciteten ved store begivenheder (såsom sportsbegivenheder). Målet er, at vores teams skal være datadrevne og i stand til at reagere i næsten realtid på kapacitetsbehov i disse begivenheder.

Et andet efterspørgselsområde er omkring forudsigelig vedligeholdelse: vi søger at introducere maskinlæring i disse pipelines for at hjælpe med at skabe indsigt hurtigere og mere præcist ved at bruge AWS Machine Learning-portefølje af tjenester.

---

Om forfatterne

Rajagopal Mahendran er udviklingschef hos Optus IT Innovation Team. Mahendran har over 14 års erfaring i forskellige organisationer, der leverer virksomhedsapplikationer fra mellemstore til meget store ved hjælp af gennemprøvede til banebrydende teknologier inden for big data, streaming dataapplikationer, mobil og cloud native applikationer. Hans passion er at drive innovative ideer ved hjælp af teknologi til et bedre liv. I sin fritid elsker han buskvandring og svømning.

Mostafa Safipour er Solutions Architect hos AWS med base i Sydney. Han arbejder med kunder for at realisere forretningsresultater ved hjælp af teknologi og AWS. I løbet af det sidste årti har han hjulpet mange store organisationer i ANZ-regionen med at opbygge deres data-, digitale og virksomhedsarbejdsbelastninger på AWS.

Masudur Rahaman Sayem er Specialist Solution Architect for Analytics hos AWS. Han arbejder med AWS-kunder for at yde vejledning og teknisk assistance til data- og analyseprojekter, og hjælper dem med at forbedre værdien af ​​deres løsninger, når de bruger AWS. Han brænder for distribuerede systemer. Han kan også godt lide at læse, især klassiske tegneserier.

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