Hur Optus förbättrar bredbands- och mobilkundupplevelsen med hjälp av Network Data Analytics-plattformen på AWS

Detta är ett gästblogginlägg som samskrivits av Rajagopal Mahendran, utvecklingschef på Optus IT Innovation Team.

---

Optus är en del av The Singtel-gruppen, som verkar i en av världens snabbast växande och mest dynamiska regioner, med närvaro i 21 länder. Optus tillhandahåller inte bara centrala telekomtjänster utan också ett omfattande utbud av digitala lösningar, inklusive moln, cybersäkerhet och digital reklam till företag, samt underhållning och mobila finansiella tjänster till miljontals konsumenter. Optus tillhandahåller mobila kommunikationstjänster till över 10.4 miljoner kunder och bredbandstjänster till över 1.1 miljoner hem och företag. Dessutom ansluter Optus Sport nära en miljon fans till Premier League, internationell fotboll och fitnessinnehåll.

I det här inlägget tittar vi på hur Optus använde Amazon Kinesis att ta in och analysera nätverksrelaterad data i en datasjö på AWS och förbättra kundupplevelsen och serviceplaneringsprocessen.

Utmaningen

En vanlig utmaning för telekommunikationsleverantörer är att bilda en korrekt realtidsbild av servicekvaliteten och de problem som deras kunder upplever. Hemnätverk och bredbandsanslutningskvalitet har en betydande inverkan på kundens produktivitet och tillfredsställelse, särskilt med tanke på den ökade beroendet av hemnätverk för arbete, anslutning till familj och vänner och underhållning under COVID-19-pandemin.

Dessutom har nätverksdrift och planeringsteam ofta inte tillgång till rätt data och insikter för att planera nya utbyggnader och hantera deras nuvarande maskinpark.

Nätverksanalysplattformen ger felsökning och planeringsdata och insikter till Optus-team och deras kunder i nästan realtid, vilket hjälper till att minska tiden för att rätta till och förbättra kundupplevelsen. Med rätt data och insikter har kunderna en bättre upplevelse, för i stället för att starta ett supportsamtal med många frågor har supportpersonalen och kunden en aktuell och korrekt bild av tjänsterna och kundens hemnätverk.

Serviceägarteam inom Optus kan också använda de insikter och trender som härrör från denna plattform för att bättre planera för framtiden och erbjuda kunder av högre kvalitet.

Designhänsyn

För att ta itu med denna utmaning och dess krav inledde vi ett projekt för att omvandla vårt nuvarande batchinsamlings- och bearbetningssystem till ett strömbaserat, nära realtidsbehandlingssystem och introducera API: er för insikter så att stödsystem och kundapplikationer kan visa den senaste ögonblicksbilden av nätverks- och tjänstestatus.

Vi hade följande funktionella och icke-funktionella krav:

• Den nya plattformen måste kunna stödja datafångst från framtida typer av kundutrustning samt nya sätt för intag (nya protokoll och frekvens) och nya dataformat.
• Det bör stödja flera konsumenter (ett API i nästan realtid för supportpersonal och kundapplikationer och operativ och affärsrapportering) för att konsumera data och generera insikter. Målet är att plattformen proaktivt ska upptäcka problem och generera lämplig varning för såväl supportpersonal som kunder.
• När data har anlänt bör insikter från data vara klara i form av ett API på några sekunder (maximalt 5 sekunder).
• Den nya plattformen bör vara tillräckligt elastisk för att fortsätta bearbetningen när delar av infrastrukturen misslyckas, såsom noder eller tillgänglighetszoner.
• Det kan stödja ett ökat antal enheter och tjänster samt mer frekvent insamling från enheterna.
• Ett litet tvärfunktionellt team över företag och teknik kommer att bygga och driva denna plattform. Vi måste säkerställa minimal infrastruktur och driftsomkostningar på lång sikt.
• Rörledningen ska vara mycket tillgänglig och möjliggöra nya distributioner utan stillestånd.

Lösningsöversikt

Med tanke på plattformen och designhänsyn i åtanke bestämde vi oss för att använda högre ordningstjänster och serverlösa tjänster från AWS där det är möjligt för att undvika onödiga operativa omkostnader för vårt team och fokusera på kärnverksamhetens behov. Detta inkluderar att använda Kinesis familj av tjänster för strömintag och -behandling; AWS Lambda för bearbetning; Amazon DynamoDB, Amazon Relational Databas Service (Amazon RDS) och Amazon enkel lagringstjänst (Amazon S3) för uthållighet av data; och AWS elastisk bönstjälk och Amazon API Gateway för applikation och API-servering. Följande diagram visar den totala lösningen.

Lösningen tar in loggfiler från tusentals kundnätverksutrustning (hemroutrar) under fördefinierade perioder. Kundutrustningen kan bara skicka enkla HTTP PUT- och POST-förfrågningar för att överföra loggfiler. För att ta emot dessa filer använder vi ett Java-program som körs i en grupp för automatisk skalning av Amazon Elastic Compute Cloud (Amazon EC2) -instanser. Efter några första kontroller utför mottagarprogrammet rensning och formatering och sedan strömmar loggfilerna till Amazon Kinesis dataströmmar.

Vi använder avsiktligt en anpassad mottagarapplikation i intagningsskiktet för att ge flexibilitet i stöd för olika enheter och filformat.

För att förstå resten av arkitekturen, låt oss ta en titt på de förväntade insikterna. Plattformen producerar två typer av insikter:

• Individuella insikter - Frågor som besvaras i denna kategori inkluderar:
  • Hur många fel har en viss kundenhet upplevt under de senaste 15 minuterna?
  • Vad var det senaste felet?
  • Hur många enheter är för närvarande anslutna till ett visst kundhem?
  • Vad är överförings- / mottagningshastigheten som fångas av en viss kundenhet?
• Grundläggande insikter - När det gäller en grupp eller hela användarbasen inkluderar frågorna i denna kategori:
  • Hur många kundenheter rapporterade servicestörningar under det senaste dygnet?
  • Vilka enhetstyper (modeller) har upplevt flest fel under de senaste sex månaderna?
  • Har de rapporterat några fel efter uppdateringen på en grupp enheter igår kväll? Gick underhållet framgångsrikt?

Den översta banan i arkitekturen visar rörledningen som genererar individuella insikter.

Kartläggningen av händelsekällan för Lambda-funktionen är konfigurerad för att konsumera poster från Kinesis dataström. Denna funktion läser poster, format och förbereder dem baserat på de insikter som krävs. Slutligen lagrar den resultaten på Amazon S3-platsen och uppdaterar också en DynamoDB-tabell som håller en sammanfattning och metadata för den faktiska informationen som lagras i Amazon S3.

För att optimera prestanda konfigurerade vi två mått i Lambda-händelsekällmappningen:

• Satsstorlek - Visar antalet poster som ska skickas till funktionen i varje batch, vilket hjälper till att uppnå högre genomströmning
• Samtidiga satser per skär - Behandlar flera satser från samma skärv samtidigt, vilket hjälper till med snabbare bearbetning

Slutligen tillhandahålls API: et via API Gateway och körs på en Spring Boot-applikation som är värd på Elastic Beanstalk. I framtiden kan vi behöva behålla tillståndet mellan API-samtal, varför vi använder Elastic Beanstalk istället för en serverlös applikation.

Den nedre banan i arkitekturen är rörledningen som genererar basrapporter.

Vi använder Amazon Kinesis Data Analytics, kör statlig beräkning på strömmande data, för att sammanfatta vissa mätvärden som överföringshastigheter eller felfrekvenser i givna tidsfönster. Dessa sammanfattningar skjuts sedan till en Amazon-Aurora databas med en datamodell som är lämplig för dashboarding och rapportering.

Insikterna presenteras sedan i instrumentpaneler med hjälp av en webbapplikation som körs på Elastic Beanstalk.

Lärdomar

Med hjälp av serverlösa mönster och tjänster av högre ordning, i synnerhet Lambda, Kinesis Data Streams, Kinesis Data Analytics och DynamoDB, gav vi mycket flexibilitet i vår arkitektur och hjälpte oss att gå mer mot mikrotjänster snarare än stora monolitiska batchjobb.

Det här skiftet hjälpte oss också att dramatiskt minska våra omkostnader för drift och servicehantering. Under de senaste månaderna sedan lanseringen upplevde kunderna på denna plattform till exempel inga servicestörningar.

Denna lösning gjorde det också möjligt för oss att anta fler DevOps och smidiga sätt att arbeta, i den meningen att ett enda litet team utvecklar och driver systemet. Detta i sin tur gjorde det möjligt för organisationen att vara mer smidig och innovativ inom den här domänen.

Vi har också upptäckt några tekniska tips genom utveckling och produktion som är värda att dela:

Resultat och fördelar

Vi har nu synlighet i realtid av våra fasta och mobila nätverk som våra kunder upplever. Tidigare hade vi bara data som kom i batch-läge med en fördröjning och också bara från våra egna nätverkssonder och utrustning.

Med den närmaste realtidsbilden av nätverket när förändringar inträffar kan våra operativa team också utföra uppgraderingar och underhåll över hela kundenheterna med högre förtroende och frekvens.

Slutligen använder våra planeringsteam dessa insikter för att bilda en korrekt, uppdaterad prestandavy över olika utrustning och tjänster. Detta leder till högre kvalitet för våra kunder till bättre priser eftersom våra serviceplaneringsteam gör det möjligt att optimera kostnaderna, bättre förhandla med leverantörer och tjänsteleverantörer och planera för framtiden.

Ser framåt

Med nätverksanalysplattformen i produktion i flera månader och stabil nu finns det efterfrågan på mer insikter och nya användningsfall. Vi tittar till exempel på ett mobilt användningsfall för att bättre hantera kapacitet vid stora evenemang (till exempel sportevenemang). Målet är att våra team ska vara datadrivna och kunna reagera i realtid på kapacitetsbehov i dessa händelser.

Ett annat område med efterfrågan är kring prediktivt underhåll: vi vill introducera maskininlärning i dessa rörledningar för att hjälpa till att få insikter snabbare och mer exakt genom att använda AWS Machine Learning-portföljen med tjänster.

---

Om författarna

Rajagopal Mahendran är utvecklingschef på Optus IT Innovation Team. Mahendran har över 14 års erfarenhet av olika organisationer som levererar företagsapplikationer från medelstora till mycket stora skalor med beprövad till banbrytande teknik inom big data, direktuppspelning av applikationer, mobila och molninbyggda applikationer. Hans passion är att driva innovativa idéer med hjälp av teknik för ett bättre liv. På sin fritid älskar han buskevandring och simning.

Mostafa Safipour är lösningsarkitekt vid AWS baserad i Sydney. Han arbetar med kunder för att förverkliga affärsresultat med hjälp av teknik och AWS. Under det senaste decenniet har han hjälpt många stora organisationer i ANZ-regionen att bygga sina data-, digital- och företagsarbetsbelastningar på AWS.

Masudur Rahaman Sayem är specialiserad lösningsarkitekt för AWS. Han arbetar med AWS-kunder för att ge vägledning och teknisk hjälp om data- och analysprojekt, vilket hjälper dem att förbättra värdet på sina lösningar när de använder AWS. Han brinner för distribuerade system. Han gillar också att läsa, särskilt klassiska serietidningar.

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