Cum îmbunătățește Optus experiența clienților în bandă largă și mobilă folosind platforma de analiză a datelor de rețea pe AWS

Republicat de Platon

Urmaritori: 0

Aceasta este o postare pe blog pentru invitați, scrisă în colaborare de Rajagopal Mahendran, manager de dezvoltare la Optus IT Innovation Team.

Optus face parte din grupul The Singtel, care operează într-una dintre regiunile cu cea mai rapidă creștere și cele mai dinamice din lume, cu prezență în 21 de țări. Optus oferă nu numai servicii de telecomunicații de bază, ci și o gamă largă de soluții digitale, inclusiv cloud, securitate cibernetică și publicitate digitală pentru întreprinderi, precum și servicii financiare de divertisment și mobile pentru milioane de consumatori. Optus oferă servicii de comunicații mobile pentru peste 10.4 milioane de clienți și servicii de bandă largă pentru peste 1.1 milioane de case și întreprinderi. În plus, Optus Sport conectează aproape 1 milion de fani la Premier League, fotbal internațional și conținut de fitness.

În această postare, ne uităm la modul în care Optus a folosit Amazon Kinesis pentru a ingera și analiza date legate de rețea într-un lac de date pe AWS și pentru a îmbunătăți experiența clienților și procesul de planificare a serviciilor.

Provocarea

O provocare comună pentru furnizorii de telecomunicații este de a forma o imagine exactă, în timp real, a calității serviciilor și a problemelor cu care se confruntă clienții lor. Calitatea rețelelor de domiciliu și a conectivității în bandă largă are un impact semnificativ asupra productivității și satisfacției clienților, mai ales având în vedere dependența crescută de rețelele de acasă pentru muncă, conectarea cu familia și prietenii și divertisment în timpul pandemiei de COVID-19.

În plus, operațiunile de rețea și echipele de planificare adesea nu au acces la datele și informațiile potrivite pentru a planifica noi lansări și pentru a-și gestiona flota actuală de dispozitive.

Platforma de analiză a rețelei oferă date și informații de depanare și planificare echipelor Optus și clienților acestora în timp aproape real, ceea ce ajută la reducerea timpului mediu pentru rectificarea și îmbunătățirea experienței clienților. Cu datele și informațiile potrivite, clienții au o experiență mai bună, deoarece în loc să înceapă un apel de asistență cu o mulțime de întrebări, personalul de asistență și clientul au o vedere actuală și precisă asupra serviciilor și a rețelei de domiciliu a clientului.

Echipele de proprietari de servicii din cadrul Optus pot folosi, de asemenea, informațiile și tendințele derivate din această platformă pentru a planifica mai bine viitorul și pentru a oferi clienților servicii de calitate superioară.

Considerații de proiectare

Pentru a face față acestei provocări și cerințelor acesteia, ne-am angajat într-un proiect de transformare a sistemului nostru actual de colectare și procesare a loturilor într-un sistem de procesare bazat pe flux, aproape în timp real și pentru a introduce API-uri pentru informații, astfel încât sistemele de asistență și aplicațiile clienților să poată afișa cel mai recent instantaneu al rețelei și al stării serviciului.

Am avut următoarele cerințe funcționale și nefuncționale:

Noua platformă trebuie să fie capabilă să susțină captarea datelor de la viitoarele tipuri de echipamente ale clienților, precum și noi modalități de asimilare (noi protocoale și frecvență) și noi formate de date.
Ar trebui să accepte mai mulți consumatori (un API aproape în timp real pentru personalul de asistență și aplicațiile clienților și raportarea operațională și de afaceri) pentru a consuma date și a genera informații. Scopul este ca platforma să detecteze proactiv problemele și să genereze alerte adecvate atât pentru personalul de asistență, cât și pentru clienți.
După ce sosesc datele, informațiile din date ar trebui să fie gata sub forma unui API în câteva secunde (maximum 5 secunde).
Noua platformă ar trebui să fie suficient de rezistentă pentru a continua procesarea atunci când părți ale infrastructurii eșuează, cum ar fi nodurile sau zonele de disponibilitate.
Poate suporta un număr crescut de dispozitive și servicii, precum și o colectare mai frecventă de pe dispozitive.
O mică echipă interfuncțională de afaceri și tehnologie va construi și rula această platformă. Trebuie să asigurăm infrastructură minimă și cheltuieli operaționale pe termen lung.
Conducta ar trebui să fie foarte disponibilă și să permită noi implementări fără timpi de nefuncționare.

Prezentare generală a soluțiilor

Având în vedere obiectivul platformei și considerentele de proiectare, am decis să folosim servicii de comandă superioară și servicii fără server de la AWS acolo unde este posibil, pentru a evita cheltuielile operaționale inutile pentru echipa noastră și pentru a ne concentra pe nevoile principale ale afacerii. Aceasta include utilizarea familiei de servicii Kinesis pentru asimilarea și procesarea fluxului; AWS Lambdas pentru procesare; Amazon DynamoDB, Serviciul de baze de date relaționale Amazon (Amazon RDS) și Serviciul Amazon de stocare simplă (Amazon S3) pentru persistența datelor; și AWS Elastic Beanstalk și Gateway API Amazon pentru difuzarea aplicațiilor și API. Următoarea diagramă prezintă soluția generală.

Soluția ingerează fișiere jurnal de la mii de echipamente de rețea ale clienților (routere de acasă) în perioade predefinite. Echipamentul clientului este capabil doar să trimită cereri simple HTTP PUT și POST pentru a transfera fișiere jurnal. Pentru a primi aceste fișiere, folosim o aplicație Java care rulează într-un grup Auto Scaling de Cloud Elastic de calcul Amazon (Amazon EC2). După câteva verificări inițiale, aplicația receptor efectuează curățarea și formatarea, apoi transmite fișierele jurnal către Fluxuri de date Amazon Kinesis.

Folosim în mod intenționat o aplicație de recepție personalizată în stratul de asimilare pentru a oferi flexibilitate în acceptarea diferitelor dispozitive și formate de fișiere.

Pentru a înțelege restul arhitecturii, să aruncăm o privire la perspectivele așteptate. Platforma produce două tipuri de perspective:

Perspective individuale – Întrebările la care s-a răspuns în această categorie includ:
- Câte erori a întâmpinat un anumit dispozitiv client în ultimele 15 minute?
- Care a fost ultima eroare?
- Câte dispozitive sunt conectate în prezent la o anumită casă de client?
- Care este rata de transfer/primire capturată de un anumit dispozitiv al clientului?
Informații de bază – Referitor la un grup sau la întreaga bază de utilizatori, întrebările din această categorie includ:
- Câte dispozitive ale clienților au raportat întreruperi ale serviciului în ultimele 24 de ore?
- Ce tipuri de dispozitive (modele) au întâmpinat cel mai mare număr de erori în ultimele 6 luni?
- După actualizarea patch-urilor de aseară pe un grup de dispozitive, au raportat vreo eroare? A avut succes întreținerea?

Banda de sus a arhitecturii arată conducta care generează perspectivele individuale.

Maparea sursei de evenimente a funcției Lambda este configurată pentru a consuma înregistrări din fluxul de date Kinesis. Această funcție citește înregistrările, formatează și le pregătește pe baza informațiilor necesare. În cele din urmă, stochează rezultatele în locația Amazon S3 și, de asemenea, actualizează un tabel DynamoDB care menține un rezumat și metadatele datelor reale stocate în Amazon S3.

Pentru a optimiza performanța, am configurat două valori în maparea sursei de evenimente Lambda:

Dimensiunea lotului – Afișează numărul de înregistrări de trimis către funcție în fiecare lot, ceea ce ajută la obținerea unui debit mai mare
Loturi concomitente pe fragment – Procesează mai multe loturi din același fragment simultan, ceea ce ajută la o procesare mai rapidă

În cele din urmă, API-ul este furnizat prin API Gateway și rulează pe o aplicație Spring Boot care este găzduită pe Elastic Beanstalk. În viitor, este posibil să fie nevoie să păstrăm starea între apelurile API, motiv pentru care folosim Elastic Beanstalk în loc de o aplicație fără server.

Banda de jos a arhitecturii este conducta care generează rapoarte de bază.

Noi folosim Analiza datelor Amazon Kinesis, care rulează calcule cu stare pe date în flux, pentru a rezuma anumite valori, cum ar fi ratele de transfer sau ratele de eroare în anumite ferestre de timp. Aceste rezumate sunt apoi împins la un Amazon Aurora bază de date cu un model de date potrivit pentru tablouri de bord și raportare.

Informațiile sunt apoi prezentate în tablouri de bord folosind o aplicație web care rulează pe Elastic Beanstalk.

Lecții învățate

Folosirea modelelor fără server și a serviciilor de ordin mai înalt, în special Lambda, Kinesis Data Streams, Kinesis Data Analytics și DynamoDB, a oferit multă flexibilitate în arhitectura noastră și ne-a ajutat să ne îndreptăm mai mult spre microservicii decât spre joburi mari monolit în lot.

Această schimbare ne-a ajutat, de asemenea, să reducem dramatic cheltuielile noastre operaționale și de gestionare a serviciilor. De exemplu, în ultimele câteva luni de la lansare, clienții acestei platforme nu au suferit nicio întrerupere a serviciilor.

Această soluție ne-a permis, de asemenea, să adoptăm mai multe DevOps și moduri agile de lucru, în sensul că o singură echipă mică dezvoltă și conduce sistemul. Acest lucru a permis organizației să fie mai agilă și mai inovatoare în acest domeniu.

Am descoperit, de asemenea, câteva sfaturi tehnice pe parcursul dezvoltării și producției, care merită împărtășite:

Rezultate și beneficii

Acum avem vizibilitate aproape în timp real a performanței rețelelor noastre fixe și mobile, așa cum au experimentat clienții noștri. În trecut, aveam doar date care veneau în modul lot cu întârziere și, de asemenea, numai de la sondele și echipamentele proprii ale rețelei.

Cu vizualizarea aproape în timp real a rețelei atunci când apar modificări, echipele noastre operaționale pot, de asemenea, să efectueze upgrade-uri și întreținere pe tot flota de dispozitive ale clienților cu o încredere și o frecvență mai mare.

În cele din urmă, echipele noastre de planificare folosesc aceste informații pentru a forma o imagine de performanță precisă și actualizată a diferitelor echipamente și servicii. Acest lucru duce la servicii de calitate superioară pentru clienții noștri la prețuri mai bune, deoarece echipele noastre de planificare a serviciilor sunt capabile să optimizeze costurile, să negocieze mai bine cu furnizorii și furnizorii de servicii și să planifice viitorul.

Privind înainte

Cu platforma de analiză a rețelei în producție de câteva luni și stabilă acum, există o cerere pentru mai multe informații și noi cazuri de utilizare. De exemplu, analizăm un caz de utilizare mobil pentru a gestiona mai bine capacitatea la evenimente la scară largă (cum ar fi evenimentele sportive). Scopul este ca echipele noastre să fie bazate pe date și capabile să reacționeze în timp aproape real la nevoile de capacitate în aceste evenimente.

Un alt domeniu de cerere este în jurul întreținerii predictive: căutăm să introducem învățarea automată în aceste conducte pentru a ajuta la obținerea informațiilor mai rapid și mai precis, utilizând portofoliul de servicii AWS Machine Learning.

Despre autori

Rajagopal Mahendran este manager de dezvoltare la Optus IT Innovation Team. Mahendran are peste 14 ani de experiență în diverse organizații care livrează aplicații de întreprindere de la scară medie până la scară foarte mare, folosind tehnologii de ultimă oră în big data, aplicații de streaming de date, mobile și aplicații native cloud. Pasiunea lui este să impulsioneze ideile inovatoare folosind tehnologia pentru o viață mai bună. În timpul liber, îi place să meargă în tufișuri și să înoate.

Mostafa Safipour este arhitect de soluții la AWS, cu sediul în Sydney. Lucrează cu clienții pentru a obține rezultate de afaceri folosind tehnologie și AWS. În ultimul deceniu, el a ajutat multe organizații mari din regiunea ANZ să-și construiască sarcinile de lucru de date, digitale și întreprinderi pe AWS.

Masudur Rahaman Sayem este arhitect de soluții de specialitate pentru Analytics la AWS. El lucrează cu clienții AWS pentru a oferi îndrumare și asistență tehnică pentru proiectele de date și analize, ajutându-i să-și îmbunătățească valoarea soluțiilor atunci când folosesc AWS. Este pasionat de sistemele distribuite. De asemenea, îi place să citească, în special cărți de benzi desenate clasice.