Cách Optus cải thiện trải nghiệm băng thông rộng và di động của khách hàng bằng cách sử dụng nền tảng Phân tích dữ liệu mạng trên AWS

Dấu thời gian: ngày 1 tháng 2021 năm 5 13:XNUMX CH
Nút nguồn: 886719

Đây là bài đăng trên blog dành cho khách do Rajagopal Mahendran, Giám đốc Phát triển tại Nhóm Đổi mới CNTT của Optus, đồng viết.

Optus là một phần của Tập đoàn Singtel, hoạt động tại một trong những khu vực phát triển nhanh nhất và năng động nhất thế giới, với sự hiện diện tại 21 quốc gia. Optus không chỉ cung cấp các dịch vụ viễn thông cốt lõi mà còn cung cấp một loạt các giải pháp kỹ thuật số, bao gồm đám mây, an ninh mạng và quảng cáo kỹ thuật số cho các doanh nghiệp, cũng như các dịch vụ giải trí và tài chính di động cho hàng triệu người tiêu dùng. Optus cung cấp dịch vụ liên lạc di động cho hơn 10.4 triệu khách hàng và dịch vụ băng thông rộng cho hơn 1.1 triệu hộ gia đình và doanh nghiệp. Ngoài ra, Optus Sport kết nối gần 1 triệu người hâm mộ với Premier League, bóng đá quốc tế và nội dung thể dục.

Trong bài đăng này, chúng tôi xem xét cách Optus sử dụng Amazon Kinesis để nhập và phân tích dữ liệu liên quan đến mạng trong kho dữ liệu trên AWS, đồng thời cải thiện trải nghiệm của khách hàng và quy trình lập kế hoạch dịch vụ.

Các thách thức

Một thách thức chung đối với các nhà cung cấp viễn thông là hình thành một cái nhìn chính xác, theo thời gian thực về chất lượng dịch vụ và các vấn đề mà khách hàng của họ gặp phải. Chất lượng kết nối mạng băng thông rộng và mạng gia đình có tác động đáng kể đến năng suất và sự hài lòng của khách hàng, đặc biệt khi xem xét sự phụ thuộc ngày càng nhiều vào mạng gia đình cho công việc, kết nối với gia đình và bạn bè cũng như giải trí trong đại dịch COVID-19.

Ngoài ra, các nhóm lập kế hoạch và vận hành mạng thường không có quyền truy cập vào dữ liệu và thông tin chi tiết phù hợp để lập kế hoạch triển khai mới và quản lý nhóm thiết bị hiện tại của họ.

Nền tảng phân tích mạng cung cấp dữ liệu khắc phục sự cố và lập kế hoạch cũng như thông tin chi tiết cho các nhóm Optus và khách hàng của họ trong thời gian gần như thực, giúp giảm thời gian trung bình để khắc phục và nâng cao trải nghiệm của khách hàng. Với dữ liệu và thông tin chi tiết phù hợp, khách hàng có trải nghiệm tốt hơn vì thay vì bắt đầu cuộc gọi hỗ trợ với rất nhiều câu hỏi, nhân viên hỗ trợ và khách hàng có cái nhìn hiện tại và chính xác về các dịch vụ cũng như mạng gia đình của khách hàng.

Các nhóm chủ sở hữu dịch vụ trong Optus cũng có thể sử dụng thông tin chi tiết và xu hướng bắt nguồn từ nền tảng này để lập kế hoạch tốt hơn cho tương lai và cung cấp dịch vụ chất lượng cao hơn cho khách hàng.

Cân nhắc thiết kế

Để giải quyết thách thức này và các yêu cầu của nó, chúng tôi đã bắt tay vào dự án chuyển đổi hệ thống thu thập và xử lý lô hiện tại của mình thành hệ thống xử lý gần thời gian thực, dựa trên luồng và giới thiệu API để hiểu rõ hơn để các hệ thống hỗ trợ và ứng dụng của khách hàng có thể hiển thị ảnh chụp nhanh mới nhất về trạng thái mạng và dịch vụ.

Chúng tôi có các yêu cầu chức năng và phi chức năng sau:

  • Nền tảng mới phải có khả năng hỗ trợ thu thập dữ liệu từ các loại thiết bị của khách hàng trong tương lai cũng như các cách tiếp nhận mới (giao thức và tần suất mới) và các định dạng dữ liệu mới.
  • Nó sẽ hỗ trợ nhiều người tiêu dùng (API gần thời gian thực cho nhân viên hỗ trợ và các ứng dụng của khách hàng cũng như báo cáo hoạt động và kinh doanh) để sử dụng dữ liệu và tạo thông tin chi tiết. Mục đích là để nền tảng chủ động phát hiện các vấn đề và đưa ra cảnh báo phù hợp để hỗ trợ nhân viên cũng như khách hàng.
  • Sau khi dữ liệu đến, thông tin chi tiết từ dữ liệu sẽ sẵn sàng ở dạng API sau vài giây (tối đa 5 giây).
  • Nền tảng mới phải đủ linh hoạt để tiếp tục xử lý khi các phần của cơ sở hạ tầng bị lỗi, chẳng hạn như các nút hoặc Vùng sẵn sàng.
  • Nó có thể hỗ trợ số lượng thiết bị và dịch vụ tăng lên cũng như thu thập thường xuyên hơn từ các thiết bị.
  • Một nhóm nhỏ đa chức năng về kinh doanh và công nghệ sẽ xây dựng và vận hành nền tảng này. Chúng tôi cần đảm bảo cơ sở hạ tầng tối thiểu và chi phí hoạt động trong thời gian dài.
  • Đường ống phải có tính sẵn sàng cao và cho phép triển khai mới mà không có thời gian ngừng hoạt động.

Tổng quan về giải pháp

Khi cân nhắc đến mục tiêu của nền tảng và thiết kế, chúng tôi đã quyết định sử dụng các dịch vụ cấp cao hơn và dịch vụ không có máy chủ từ AWS nếu có thể, để tránh chi phí hoạt động không cần thiết cho nhóm của chúng tôi và tập trung vào các nhu cầu kinh doanh cốt lõi. Điều này bao gồm việc sử dụng dòng dịch vụ Kinesis để nhập và xử lý luồng; AWS Lambda để xử lý; Máy phát điện Amazon, Dịch vụ cơ sở dữ liệu quan hệ của Amazon (Amazon RDS) và Dịch vụ lưu trữ đơn giản của Amazon (Amazon S3) để duy trì dữ liệu; Và Cây đậu đàn hồi AWS và Cổng API Amazon để phục vụ ứng dụng và API. Sơ đồ sau đây cho thấy giải pháp tổng thể.

Giải pháp nhập các tệp nhật ký từ hàng nghìn thiết bị mạng của khách hàng (bộ định tuyến gia đình) trong các khoảng thời gian được xác định trước. Thiết bị của khách hàng chỉ có khả năng gửi các yêu cầu HTTP PUT và POST đơn giản để truyền tệp nhật ký. Để nhận các tệp này, chúng tôi sử dụng ứng dụng Java đang chạy trong nhóm Auto Scaling của Đám mây điện toán đàn hồi Amazon (Amazon EC2). Sau một số kiểm tra ban đầu, ứng dụng nhận thực hiện làm sạch và định dạng, sau đó truyền các tệp nhật ký tới Luồng dữ liệu Amazon Kinesis.

Chúng tôi chủ ý sử dụng ứng dụng bộ thu tùy chỉnh trong lớp nhập để cung cấp tính linh hoạt trong việc hỗ trợ các thiết bị và định dạng tệp khác nhau.

Để hiểu phần còn lại của kiến ​​trúc, chúng ta hãy xem những hiểu biết dự kiến. Nền tảng tạo ra hai loại thông tin chi tiết:

  • Thông tin chi tiết cá nhân – Các câu hỏi được trả lời trong danh mục này bao gồm:
    • Một thiết bị của khách hàng cụ thể đã gặp phải bao nhiêu lỗi trong 15 phút qua?
    • Lỗi cuối cùng là gì?
    • Có bao nhiêu thiết bị hiện đang được kết nối tại nhà của một khách hàng cụ thể?
    • Tốc độ truyền/nhận do một thiết bị cụ thể của khách hàng ghi lại là bao nhiêu?
  • Thông tin chi tiết cơ bản – Liên quan đến một nhóm hoặc toàn bộ cơ sở người dùng, các câu hỏi trong danh mục này bao gồm:
    • Có bao nhiêu thiết bị của khách hàng báo cáo gián đoạn dịch vụ trong 24 giờ qua?
    • Loại thiết bị (kiểu máy) nào gặp nhiều lỗi nhất trong 6 tháng qua?
    • Sau bản cập nhật vá lỗi đêm qua trên một nhóm thiết bị, họ có báo lỗi gì không? Bảo trì có thành công không?

Làn đường trên cùng trong kiến ​​trúc hiển thị quy trình tạo ra thông tin chi tiết riêng lẻ.

Ánh xạ nguồn sự kiện của hàm Lambda được định cấu hình để sử dụng các bản ghi từ luồng dữ liệu Kinesis. Chức năng này đọc các bản ghi, định dạng và chuẩn bị chúng dựa trên những hiểu biết cần thiết. Cuối cùng, nó lưu trữ kết quả ở vị trí Amazon S3 và cũng cập nhật bảng DynamoDB duy trì bản tóm tắt và siêu dữ liệu của dữ liệu thực tế được lưu trữ trong Amazon S3.

Để tối ưu hóa hiệu suất, chúng tôi đã định cấu hình hai chỉ số trong ánh xạ nguồn sự kiện Lambda:

Cuối cùng, API được cung cấp qua API Gateway và chạy trên ứng dụng Spring Boot được lưu trữ trên Elastic Beanstalk. Trong tương lai, chúng tôi có thể cần giữ trạng thái giữa các lệnh gọi API, đó là lý do tại sao chúng tôi sử dụng Elastic Beanstalk thay vì ứng dụng serverless.

Làn dưới cùng trong kiến ​​trúc là quy trình tạo báo cáo cơ sở.

Chúng tôi sử dụng Phân tích dữ liệu Amazon Kinesis, chạy tính toán trạng thái trên dữ liệu truyền trực tuyến, để tóm tắt một số chỉ số nhất định như tốc độ truyền hoặc tỷ lệ lỗi trong các khoảng thời gian nhất định. Những tóm tắt này sau đó được đẩy đến một Amazon cực quang cơ sở dữ liệu với mô hình dữ liệu phù hợp cho mục đích báo cáo và bảng điều khiển.

Thông tin chi tiết sau đó được trình bày trong bảng điều khiển bằng ứng dụng web chạy trên Elastic Beanstalk.

Bài học kinh nghiệm

Việc sử dụng các mẫu serverless và dịch vụ bậc cao hơn, cụ thể là Lambda, Kinesis Data Streams, Kinesis Data Analytics và DynamoDB, đã mang lại rất nhiều tính linh hoạt trong kiến ​​trúc của chúng tôi và giúp chúng tôi hướng tới các vi dịch vụ nhiều hơn thay vì các công việc theo lô lớn nguyên khối.

Sự thay đổi này cũng giúp chúng tôi giảm đáng kể chi phí quản lý hoạt động và dịch vụ. Ví dụ: trong vài tháng qua kể từ khi ra mắt, khách hàng của nền tảng này không gặp phải bất kỳ sự gián đoạn dịch vụ nào.

Giải pháp này cũng cho phép chúng tôi áp dụng nhiều cách thức làm việc linh hoạt và DevOps hơn, theo nghĩa là một nhóm nhỏ duy nhất phát triển và vận hành hệ thống. Điều này đến lượt nó đã cho phép tổ chức trở nên nhanh nhẹn và đổi mới hơn trong lĩnh vực này.

Chúng tôi cũng đã khám phá ra một số mẹo kỹ thuật trong quá trình phát triển và sản xuất đáng để chia sẻ:

Kết quả và lợi ích

Giờ đây, chúng tôi có khả năng hiển thị gần như theo thời gian thực về hiệu suất mạng di động và cố định như trải nghiệm của khách hàng. Trước đây, chúng tôi chỉ có dữ liệu ở chế độ hàng loạt với độ trễ và cũng chỉ từ thiết bị và đầu dò mạng của chính chúng tôi.

Với chế độ xem mạng gần như theo thời gian thực khi có thay đổi, các nhóm vận hành của chúng tôi cũng có thể tiến hành nâng cấp và bảo trì trên toàn bộ nhóm thiết bị của khách hàng với độ tin cậy và tần suất cao hơn.

Cuối cùng, các nhóm lập kế hoạch của chúng tôi sử dụng những thông tin chi tiết này để hình thành chế độ xem hiệu suất chính xác, cập nhật của các thiết bị và dịch vụ khác nhau. Điều này dẫn đến dịch vụ chất lượng cao hơn cho khách hàng của chúng tôi với mức giá tốt hơn vì các nhóm lập kế hoạch dịch vụ của chúng tôi có thể tối ưu hóa chi phí, đàm phán tốt hơn với các đại lý và nhà cung cấp dịch vụ cũng như lập kế hoạch cho tương lai.

Nhìn về phía trước

Với nền tảng phân tích mạng đã được sản xuất trong vài tháng và hiện đã ổn định, nhu cầu về thông tin chi tiết và trường hợp sử dụng mới ngày càng tăng. Ví dụ: chúng tôi đang xem xét trường hợp sử dụng trên thiết bị di động để quản lý năng lực tốt hơn tại các sự kiện quy mô lớn (chẳng hạn như các sự kiện thể thao). Mục đích là để các nhóm của chúng tôi được định hướng dữ liệu và có thể phản ứng trong thời gian gần như thực đối với nhu cầu năng lực trong các sự kiện này.

Một lĩnh vực khác có nhu cầu là bảo trì dự đoán: chúng tôi đang tìm cách đưa công nghệ máy học vào các quy trình này để giúp cung cấp thông tin chuyên sâu nhanh hơn và chính xác hơn bằng cách sử dụng danh mục dịch vụ AWS Machine Learning.

Giới thiệu về tác giả

Rajagopal Mahendran là Giám đốc Phát triển tại Nhóm Đổi mới CNTT của Optus. Mahendran có hơn 14 năm kinh nghiệm trong các tổ chức khác nhau cung cấp các ứng dụng doanh nghiệp từ quy mô trung bình đến quy mô rất lớn bằng cách sử dụng các công nghệ tiên tiến đã được chứng minh trong dữ liệu lớn, ứng dụng truyền dữ liệu, ứng dụng di động và đám mây gốc. Niềm đam mê của anh ấy là thúc đẩy những ý tưởng sáng tạo sử dụng công nghệ để có cuộc sống tốt đẹp hơn. Khi rảnh rỗi, anh ấy thích đi dạo trong bụi và bơi lội.

Mostafa Safipour là Kiến trúc sư giải pháp tại AWS có trụ sở tại Sydney. Anh ấy làm việc với khách hàng để hiện thực hóa kết quả kinh doanh bằng cách sử dụng công nghệ và AWS. Trong thập kỷ qua, anh ấy đã giúp nhiều tổ chức lớn trong khu vực ANZ xây dựng khối lượng công việc dữ liệu, kỹ thuật số và doanh nghiệp của họ trên AWS.

Masudur Rahaman Sayem là Kiến trúc sư giải pháp chuyên gia cho Analytics tại AWS. Anh ấy làm việc với các khách hàng của AWS để cung cấp hướng dẫn và hỗ trợ kỹ thuật về các dự án dữ liệu và phân tích, giúp họ nâng cao giá trị của các giải pháp khi sử dụng AWS. Anh ấy đam mê các hệ thống phân tán. Anh ấy cũng thích đọc, đặc biệt là truyện tranh cổ điển.

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

Dấu thời gian:

Thêm từ AWS