Bagaimana Optus meningkatkan pengalaman pelanggan broadband dan seluler menggunakan platform Analisis Data Jaringan di AWS

Node Sumber: 886719

Ini adalah posting blog tamu yang ditulis bersama oleh Rajagopal Mahendran, Manajer Pengembangan di Tim Inovasi TI Optus.


Optus adalah bagian dari grup Singtel, yang beroperasi di salah satu kawasan dengan pertumbuhan tercepat dan paling dinamis di dunia, dengan kehadiran di 21 negara. Optus tidak hanya menyediakan layanan telekomunikasi inti, tetapi juga beragam solusi digital, termasuk cloud, keamanan siber, dan periklanan digital untuk perusahaan, serta layanan hiburan dan keuangan seluler bagi jutaan konsumen. Optus menyediakan layanan komunikasi seluler ke lebih dari 10.4 juta pelanggan dan layanan broadband ke lebih dari 1.1 juta rumah dan bisnis. Selain itu, Optus Sport menghubungkan hampir 1 juta penggemar ke Liga Premier, sepak bola internasional, dan konten kebugaran.

Dalam posting ini, kita melihat bagaimana Optus digunakan Amazon Kinesis untuk menyerap dan menganalisis data terkait jaringan di data lake di AWS dan meningkatkan pengalaman pelanggan dan proses perencanaan layanan.

Tantangan

Tantangan umum bagi penyedia telekomunikasi adalah untuk membentuk pandangan yang akurat dan real-time tentang kualitas layanan dan masalah yang dialami oleh pelanggan mereka. Kualitas jaringan rumah dan konektivitas broadband memiliki dampak signifikan terhadap produktivitas dan kepuasan pelanggan, terutama mengingat meningkatnya ketergantungan pada jaringan rumah untuk bekerja, terhubung dengan keluarga dan teman, serta hiburan selama pandemi COVID-19.

Selain itu, operasi jaringan dan tim perencanaan sering kali tidak memiliki akses ke data dan wawasan yang tepat untuk merencanakan peluncuran baru dan mengelola armada perangkat mereka saat ini.

Platform analitik jaringan menyediakan data dan wawasan pemecahan masalah dan perencanaan kepada tim Optus dan pelanggan mereka secara hampir real-time, yang membantu mengurangi waktu rata-rata untuk memperbaiki dan meningkatkan pengalaman pelanggan. Dengan data dan wawasan yang tepat, pelanggan memiliki pengalaman yang lebih baik karena alih-alih memulai panggilan dukungan dengan banyak pertanyaan, staf dukungan dan pelanggan memiliki pandangan terkini dan akurat tentang layanan dan jaringan rumah pelanggan.

Tim pemilik layanan dalam Optus juga dapat menggunakan wawasan dan tren yang berasal dari platform ini untuk merencanakan masa depan yang lebih baik dan memberikan layanan berkualitas lebih tinggi kepada pelanggan.

Pertimbangan desain

Untuk mengatasi tantangan ini dan persyaratannya, kami memulai proyek untuk mengubah sistem pengumpulan dan pemrosesan batch kami saat ini menjadi sistem pemrosesan hampir real-time berbasis aliran, dan memperkenalkan API untuk wawasan sehingga sistem pendukung dan aplikasi pelanggan dapat menunjukkan snapshot terbaru dari jaringan dan status layanan.

Kami memiliki persyaratan fungsional dan non-fungsional berikut:

  • Platform baru harus mampu mendukung pengambilan data dari jenis peralatan pelanggan di masa depan serta cara penyerapan baru (protokol dan frekuensi baru) dan format data baru.
  • Ini harus mendukung banyak konsumen (API yang hampir real-time untuk staf pendukung dan aplikasi pelanggan serta pelaporan operasional dan bisnis) untuk menggunakan data dan menghasilkan wawasan. Tujuannya adalah agar platform secara proaktif mendeteksi masalah dan menghasilkan peringatan yang tepat untuk mendukung staf serta pelanggan.
  • Setelah data tiba, insight dari data tersebut akan siap dalam bentuk API dalam beberapa detik (maksimum 5 detik).
  • Platform baru harus cukup tangguh untuk melanjutkan pemrosesan saat bagian infrastruktur gagal, seperti node atau Availability Zone.
  • Ini dapat mendukung peningkatan jumlah perangkat dan layanan serta pengumpulan yang lebih sering dari perangkat.
  • Tim lintas fungsi kecil di seluruh bisnis dan teknologi akan membangun dan menjalankan platform ini. Kita perlu memastikan infrastruktur minimal dan overhead operasional dalam jangka panjang.
  • Pipeline harus sangat tersedia dan memungkinkan penerapan baru tanpa waktu henti.

Ikhtisar solusi

Dengan mempertimbangkan tujuan platform dan pertimbangan desain, kami memutuskan untuk menggunakan layanan tingkat tinggi dan layanan tanpa server dari AWS jika memungkinkan, untuk menghindari overhead operasional yang tidak perlu bagi tim kami dan fokus pada kebutuhan bisnis inti. Ini termasuk menggunakan rangkaian layanan Kinesis untuk penyerapan dan pemrosesan streaming; AWS Lambda untuk diproses; Amazon DynamoDB, Layanan Database Relasional Amazon (Amazon RDS), dan Layanan Penyimpanan Sederhana Amazon (Amazon S3) untuk persistensi data; dan Pohon Kacang Elastis AWS dan Gerbang API Amazon untuk aplikasi dan penyajian API. Diagram berikut menunjukkan solusi keseluruhan.

Solusinya menyerap file log dari ribuan peralatan jaringan pelanggan (router rumah) dalam periode yang telah ditentukan. Peralatan pelanggan hanya mampu mengirimkan permintaan HTTP PUT dan POST sederhana untuk mentransfer file log. Untuk menerima file-file ini, kami menggunakan aplikasi Java yang berjalan dalam grup Auto Scaling dari Cloud komputasi elastis Amazon (Amazon EC2) instans. Setelah beberapa pemeriksaan awal, aplikasi penerima melakukan pembersihan dan pemformatan, kemudian mengalirkan file log ke Aliran Data Amazon Kinesis.

Kami sengaja menggunakan aplikasi penerima kustom di lapisan penyerapan untuk memberikan fleksibilitas dalam mendukung perangkat dan format file yang berbeda.

Untuk memahami arsitektur lainnya, mari kita lihat wawasan yang diharapkan. Platform ini menghasilkan dua jenis wawasan:

  • Wawasan individu โ€“ Pertanyaan yang dijawab dalam kategori ini meliputi:
    • Berapa banyak kesalahan yang dialami perangkat pelanggan tertentu dalam 15 menit terakhir?
    • Apa kesalahan terakhir?
    • Berapa banyak perangkat yang saat ini terhubung di rumah pelanggan tertentu?
    • Berapa tingkat transfer/penerimaan yang ditangkap oleh perangkat pelanggan tertentu?
  • Wawasan dasar โ€“ Berkenaan dengan grup atau seluruh basis pengguna, pertanyaan dalam kategori ini meliputi:
    • Berapa banyak perangkat pelanggan yang melaporkan gangguan layanan dalam 24 jam terakhir?
    • Jenis perangkat (model) mana yang mengalami jumlah kesalahan tertinggi dalam 6 bulan terakhir?
    • Setelah pembaruan tambalan tadi malam pada sekelompok perangkat, apakah mereka melaporkan kesalahan? Apakah pemeliharaan berhasil?

Jalur teratas dalam arsitektur menunjukkan jalur yang menghasilkan wawasan individu.

Pemetaan sumber peristiwa dari fungsi Lambda dikonfigurasi untuk menggunakan rekaman dari aliran data Kinesis. Fungsi ini membaca catatan, memformat, dan menyiapkannya berdasarkan wawasan yang diperlukan. Terakhir, ini menyimpan hasil di lokasi Amazon S3 dan juga memperbarui tabel DynamoDB yang menyimpan ringkasan dan metadata dari data aktual yang disimpan di Amazon S3.

Untuk mengoptimalkan kinerja, kami mengonfigurasi dua metrik dalam pemetaan sumber peristiwa Lambda:

  • Ukuran batch โ€“ Menunjukkan jumlah catatan untuk dikirim ke fungsi di setiap batch, yang membantu mencapai throughput yang lebih tinggi
  • Batch bersamaan per pecahan โ€“ Memproses beberapa batch dari shard yang sama secara bersamaan, yang membantu pemrosesan lebih cepat

Terakhir, API disediakan melalui API Gateway dan berjalan pada aplikasi Spring Boot yang dihosting di Elastic Beanstalk. Di masa mendatang, kami mungkin perlu menjaga status di antara panggilan API, itulah sebabnya kami menggunakan Elastic Beanstalk alih-alih aplikasi tanpa server.

Jalur bawah dalam arsitektur adalah jalur yang menghasilkan laporan dasar.

Kami menggunakan Analisis Data Amazon Kinesis, menjalankan komputasi stateful pada data streaming, untuk meringkas metrik tertentu seperti kecepatan transfer atau tingkat kesalahan dalam jangka waktu tertentu. Ringkasan ini kemudian didorong ke Amazon Aurora database dengan model data yang sesuai untuk keperluan dashboarding dan pelaporan.

Wawasan tersebut kemudian disajikan di dasbor menggunakan aplikasi web yang berjalan di Elastic Beanstalk.

Pelajaran yang dipetik

Menggunakan pola tanpa server dan layanan tingkat tinggi, khususnya Lambda, Kinesis Data Streams, Kinesis Data Analytics, dan DynamoDB, memberikan banyak fleksibilitas dalam arsitektur kami dan membantu kami bergerak lebih ke layanan mikro daripada pekerjaan batch monolit besar.

Pergeseran ini juga membantu kami secara dramatis mengurangi biaya operasional dan manajemen layanan kami. Misalnya, selama beberapa bulan terakhir sejak diluncurkan, pelanggan platform ini tidak mengalami gangguan layanan apa pun.

Solusi ini juga memungkinkan kami untuk mengadopsi lebih banyak DevOps dan cara kerja yang gesit, dalam arti bahwa satu tim kecil mengembangkan dan menjalankan sistem. Hal ini pada gilirannya memungkinkan organisasi untuk menjadi lebih gesit dan inovatif dalam domain ini.

Kami juga menemukan beberapa tip teknis selama pengembangan dan produksi yang layak untuk dibagikan:

Hasil dan manfaat

Kami sekarang memiliki visibilitas hampir real-time dari kinerja jaringan tetap dan seluler kami seperti yang dialami oleh pelanggan kami. Di masa lalu, kami hanya memiliki data yang datang dalam mode batch dengan penundaan dan juga hanya dari probe dan peralatan jaringan kami sendiri.

Dengan tampilan jaringan yang hampir real-time saat terjadi perubahan, tim operasional kami juga dapat melakukan peningkatan dan pemeliharaan di seluruh armada perangkat pelanggan dengan keyakinan dan frekuensi yang lebih tinggi.

Terakhir, tim perencanaan kami menggunakan wawasan ini untuk membentuk tampilan kinerja yang akurat dan terkini dari berbagai peralatan dan layanan. Ini mengarah pada layanan berkualitas lebih tinggi bagi pelanggan kami dengan harga yang lebih baik karena tim perencanaan layanan kami diaktifkan untuk mengoptimalkan biaya, bernegosiasi lebih baik dengan vendor dan penyedia layanan, dan merencanakan masa depan.

Melihat ke depan

Dengan platform analitik jaringan dalam produksi selama beberapa bulan dan stabil sekarang, ada permintaan untuk lebih banyak wawasan dan kasus penggunaan baru. Misalnya, kami sedang mencari kasus penggunaan seluler untuk mengelola kapasitas dengan lebih baik di acara berskala besar (seperti acara olahraga). Tujuannya adalah agar tim kami didorong oleh data dan mampu bereaksi hampir secara real time terhadap kebutuhan kapasitas dalam acara ini.

Area permintaan lainnya adalah seputar pemeliharaan prediktif: kami ingin memperkenalkan machine learning ke dalam pipeline ini untuk membantu mendorong wawasan lebih cepat dan lebih akurat dengan menggunakan portofolio layanan AWS Machine Learning.


Tentang penulis

Rajagopal Mahendran adalah Manajer Pengembangan di Tim Inovasi TI Optus. Mahendran memiliki lebih dari 14 tahun pengalaman di berbagai organisasi yang menghadirkan aplikasi perusahaan dari skala menengah hingga skala sangat besar dengan menggunakan teknologi mutakhir yang telah terbukti dalam data besar, aplikasi data streaming, seluler, dan aplikasi asli cloud. Semangatnya adalah untuk memperkuat ide-ide inovatif menggunakan teknologi untuk kehidupan yang lebih baik. Di waktu luangnya, dia suka berjalan di hutan dan berenang.

Mostafa Safipur adalah Arsitek Solusi di AWS yang berbasis di Sydney. Dia bekerja dengan pelanggan untuk mewujudkan hasil bisnis menggunakan teknologi dan AWS. Selama dekade terakhir, dia telah membantu banyak organisasi besar di wilayah ANZ membangun data, digital, dan beban kerja perusahaan mereka di AWS.

Masudur Rahaman Sayem adalah Arsitek Solusi Spesialis untuk Analytics di AWS. Dia bekerja dengan pelanggan AWS untuk memberikan panduan dan bantuan teknis pada proyek data dan analitik, membantu mereka meningkatkan nilai solusi mereka saat menggunakan AWS. Dia bersemangat tentang sistem terdistribusi. Dia juga suka membaca, terutama buku komik klasik.

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

Stempel Waktu:

Lebih dari AWS