Hvordan Optus forbedrer bredbånds- og mobil kundeopplevelse ved hjelp av Network Data Analytics-plattformen på AWS

Dette er et gjesteblogginnlegg skrevet av Rajagopal Mahendran, utviklingssjef ved Optus IT Innovation Team.

---

Optus er en del av The Singtel-gruppen, som opererer i en av verdens raskest voksende og mest dynamiske regioner, med tilstedeværelse i 21 land. Optus leverer ikke bare kjernetelekomtjenester, men også et omfattende utvalg av digitale løsninger, inkludert sky, cybersikkerhet og digital annonsering til bedrifter, samt underholdning og mobile finansielle tjenester til millioner av forbrukere. Optus leverer mobilkommunikasjonstjenester til over 10.4 millioner kunder og bredbåndstjenester til over 1.1 millioner hjem og bedrifter. I tillegg kobler Optus Sport nærmere 1 million fans til Premier League, internasjonal fotball og treningsinnhold.

I dette innlegget ser vi på hvordan Optus brukte Amazon Kinesis å innta og analysere nettverksrelaterte data i en datainnsjø på AWS og forbedre kundeopplevelsen og tjenesteplanleggingsprosessen.

Utfordringen

En vanlig utfordring for telekommunikasjonsleverandører er å danne seg et nøyaktig, sanntidsbilde av kvaliteten på tjenesten og problemer som kundene opplever. Kvaliteten på hjemmenettverk og bredbåndstilkobling har en betydelig innvirkning på kundeproduktivitet og -tilfredshet, spesielt med tanke på den økte avhengigheten av hjemmenettverk for arbeid, kontakt med familie og venner og underholdning under COVID-19-pandemien.

I tillegg har nettverksdrift og planleggingsteam ofte ikke tilgang til de riktige dataene og innsiktene for å planlegge nye utrullinger og administrere sin nåværende flåte av enheter.

Nettverksanalyseplattformen gir feilsøkings- og planleggingsdata og innsikt til Optus-team og deres kunder i nesten sanntid, noe som bidrar til å redusere gjennomsnittlig tid til å rette opp og forbedre kundeopplevelsen. Med riktig data og innsikt får kundene en bedre opplevelse fordi i stedet for å starte en supportsamtale med mange spørsmål, har støttepersonellet og kunden en oppdatert og nøyaktig oversikt over tjenestene og kundens hjemmenettverk.

Tjenesteeierteam innen Optus kan også bruke innsikten og trendene som er hentet fra denne plattformen til å planlegge bedre for fremtiden og gi tjenester av høyere kvalitet til kundene.

Designhensyn

For å møte denne utfordringen og dens krav, tok vi fatt på et prosjekt for å transformere vårt nåværende batchinnsamlings- og prosesseringssystem til et strømbasert, nesten sanntidsbehandlingssystem, og introdusere APIer for innsikt slik at støttesystemer og kundeapplikasjoner kan vise det siste øyeblikksbildet av nettverket og tjenestestatus.

Vi hadde følgende funksjonelle og ikke-funksjonelle krav:

• Den nye plattformen må være i stand til å støtte datafangst fra fremtidige typer kundeutstyr samt nye måter for inntak (nye protokoller og frekvens) og nye dataformater.
• Den skal støtte flere forbrukere (en nesten sanntids-API for støttepersonell og kundeapplikasjoner og drifts- og forretningsrapportering) for å konsumere data og generere innsikt. Målet er at plattformen proaktivt skal oppdage problemer og generere passende varsling til støttepersonell så vel som kunder.
• Etter at dataene kommer, skal innsikt fra dataene være klare i form av en API i løpet av noen få sekunder (maks. 5 sekunder).
• Den nye plattformen skal være spenstig nok til å fortsette behandlingen når deler av infrastrukturen svikter, for eksempel noder eller tilgjengelighetssoner.
• Den kan støtte et økt antall enheter og tjenester samt hyppigere innsamling fra enhetene.
• Et lite tverrfunksjonelt team på tvers av virksomhet og teknologi vil bygge og drifte denne plattformen. Vi må sikre minimal infrastruktur og driftskostnader på sikt.
• Rørledningen skal være svært tilgjengelig og tillate nye distribusjoner uten nedetid.

Løsningsoversikt

Med målet om plattformen og designhensyn i tankene, bestemte vi oss for å bruke høyere-orders tjenester og serverløse tjenester fra AWS der det er mulig, for å unngå unødvendige driftskostnader for teamet vårt og fokusere på kjernevirksomhetens behov. Dette inkluderer bruk av Kinesis-familien av tjenester for strøminntak og prosessering; AWS Lambda for behandling; Amazon DynamoDB, Amazon Relational Database Service (Amazon RDS), og Amazon enkel lagringstjeneste (Amazon S3) for datautholdenhet; og AWS elastisk bønnestengel og Amazon API-gateway for applikasjons- og API-servering. Følgende diagram viser den generelle løsningen.

Løsningen inntar loggfiler fra tusenvis av kundenettverksutstyr (hjemmerutere) i forhåndsdefinerte perioder. Kundeutstyret er kun i stand til å sende enkle HTTP PUT- og POST-forespørsler for å overføre loggfiler. For å motta disse filene bruker vi en Java-applikasjon som kjører i en Auto Scaling-gruppe av Amazon Elastic Compute Cloud (Amazon EC2) forekomster. Etter noen innledende kontroller, utfører mottakerapplikasjonen rensing og formatering, deretter strømmer den loggfilene til Amazon Kinesis datastrømmer.

Vi bruker med hensikt en tilpasset mottakerapplikasjon i inntakslaget for å gi fleksibilitet når det gjelder å støtte forskjellige enheter og filformater.

For å forstå resten av arkitekturen, la oss ta en titt på den forventede innsikten. Plattformen produserer to typer innsikt:

• Individuell innsikt – Spørsmål besvart i denne kategorien inkluderer:
  • Hvor mange feil har en bestemt kundeenhet opplevd i løpet av de siste 15 minuttene?
  • Hva var den siste feilen?
  • Hvor mange enheter er for øyeblikket koblet til et bestemt kundehjem?
  • Hva er overførings-/mottakshastigheten registrert av en bestemt kundeenhet?
• Grunnleggende innsikt – Når det gjelder en gruppe eller hele brukerbasen, inkluderer spørsmål i denne kategorien:
  • Hvor mange kundeenheter rapporterte tjenesteavbrudd i løpet av de siste 24 timene?
  • Hvilke enhetstyper (modeller) har opplevd det høyeste antallet feil de siste 6 månedene?
  • Etter gårsdagens patchoppdatering på en gruppe enheter, har de rapportert noen feil? Var vedlikeholdet vellykket?

Den øverste banen i arkitekturen viser rørledningen som genererer de individuelle innsiktene.

Hendelseskildetilordningen til Lambda-funksjonen er konfigurert til å konsumere poster fra Kinesis-datastrømmen. Denne funksjonen leser postene, formaterer og forbereder dem basert på den nødvendige innsikten. Til slutt lagrer den resultatene på Amazon S3-plasseringen og oppdaterer også en DynamoDB-tabell som opprettholder et sammendrag og metadataene til de faktiske dataene som er lagret i Amazon S3.

For å optimalisere ytelsen konfigurerte vi to beregninger i Lambda-hendelseskildekartleggingen:

• Partistørrelse, Gruppestørrelse – Viser antall poster som skal sendes til funksjonen i hver batch, noe som bidrar til å oppnå høyere gjennomstrømning
• Samtidige partier per shard – Behandler flere batcher fra samme shard samtidig, noe som hjelper med raskere behandling

Til slutt leveres API via API Gateway og kjører på en Spring Boot-applikasjon som er vert på Elastic Beanstalk. I fremtiden kan det hende vi må holde status mellom API-kall, og det er derfor vi bruker Elastic Beanstalk i stedet for en serverløs applikasjon.

Bunnbanen i arkitekturen er rørledningen som genererer basisrapporter.

Vi bruker Amazon Kinesis Data Analytics, kjører stateful beregning på strømmedata, for å oppsummere visse beregninger som overføringshastigheter eller feilfrekvenser i gitte tidsvinduer. Disse sammendragene blir deretter skjøvet til en Amazonas Aurora database med en datamodell som er egnet for dashboard- og rapporteringsformål.

Innsikten presenteres deretter i dashboards ved hjelp av en nettapplikasjon som kjører på Elastic Beanstalk.

Erfaringer

Bruk av serverløse mønstre og tjenester av høyere orden, spesielt Lambda, Kinesis Data Streams, Kinesis Data Analytics og DynamoDB, ga mye fleksibilitet i arkitekturen vår og hjalp oss med å bevege oss mer mot mikrotjenester i stedet for store monolitt batchjobber.

Dette skiftet hjalp oss også dramatisk å redusere drifts- og serviceadministrasjonskostnadene våre. For eksempel, i løpet av de siste månedene siden lanseringen, har ikke kunder av denne plattformen opplevd noen tjenesteavbrudd.

Denne løsningen gjorde oss også i stand til å ta i bruk flere DevOps og smidige måter å jobbe på, i den forstand at et enkelt lite team utvikler og kjører systemet. Dette gjorde det igjen mulig for organisasjonen å være mer smidig og innovativ på dette domenet.

Vi oppdaget også noen tekniske tips gjennom utviklingen og produksjonen som er verdt å dele:

Utfall og fordeler

Vi har nå nær-sanntid synlighet av våre faste og mobile nettverk ytelsen slik kundene våre opplever det. Tidligere hadde vi kun data som kom i batch-modus med en forsinkelse og også kun fra våre egne nettverksonder og utstyr.

Med nesten sanntidsvisning av nettverket når endringer skjer, kan våre driftsteam også utføre oppgraderinger og vedlikehold på tvers av flåten av kundeenheter med høyere tillit og frekvens.

Til slutt bruker planleggingsteamene våre denne innsikten til å danne et nøyaktig, oppdatert ytelsesbilde av forskjellig utstyr og tjenester. Dette fører til tjenester av høyere kvalitet for våre kunder til bedre priser fordi våre tjenesteplanleggingsteam er i stand til å optimalisere kostnadene, forhandle bedre med leverandører og tjenesteleverandører og planlegge for fremtiden.

Ser framover

Med nettverksanalyseplattformen i produksjon i flere måneder og stabil nå, er det etterspørsel etter mer innsikt og nye bruksområder. For eksempel ser vi på en mobilbrukssak for å bedre administrere kapasiteten ved store arrangementer (som sportsbegivenheter). Målet er at teamene våre skal være datadrevne og i stand til å reagere i nesten sanntid på kapasitetsbehov i disse hendelsene.

Et annet etterspørselsområde er prediktivt vedlikehold: vi ønsker å introdusere maskinlæring i disse rørledningene for å hjelpe til med å generere innsikt raskere og mer nøyaktig ved å bruke AWS Machine Learning-portefølje av tjenester.

---

Om forfatterne

Rajagopal Mahendran er utviklingssjef i Optus IT Innovation Team. Mahendran har over 14 års erfaring i ulike organisasjoner som leverer bedriftsapplikasjoner fra middels til veldig stor skala ved bruk av velprøvde til banebrytende teknologier innen big data, streamingdataapplikasjoner, mobil og skybaserte applikasjoner. Hans lidenskap er å drive innovative ideer ved å bruke teknologi for bedre levevilkår. På fritiden elsker han å gå og svømme.

Mostafa Safipour er en løsningsarkitekt ved AWS basert i Sydney. Han jobber med kunder for å realisere forretningsresultater ved hjelp av teknologi og AWS. I løpet av det siste tiåret har han hjulpet mange store organisasjoner i ANZ-regionen med å bygge sine data-, digitale og bedriftsarbeidsmengder på AWS.

Masudur Rahaman Sayem er spesialistløsningsarkitekt for Analytics hos AWS. Han jobber med AWS-kunder for å gi veiledning og teknisk assistanse i data- og analyseprosjekter, og hjelper dem med å forbedre verdien av løsningene deres når de bruker AWS. Han brenner for distribuerte systemer. Han liker også å lese, spesielt 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/