كيف تعمل Optus على تحسين تجربة عملاء النطاق العريض والأجهزة المحمولة باستخدام منصة تحليلات بيانات الشبكة على AWS

هذه مشاركة مدونة ضيف شارك في كتابتها راجاجوبال ماهيندران، مدير التطوير في فريق Optus IT Innovation.

---

تعد Optus جزءًا من مجموعة Singtel، التي تعمل في واحدة من أسرع مناطق العالم نموًا وأكثرها ديناميكية، وتتواجد في 21 دولة. لا توفر Optus خدمات الاتصالات الأساسية فحسب، بل تقدم أيضًا مجموعة واسعة من الحلول الرقمية، بما في ذلك السحابة والأمن السيبراني والإعلانات الرقمية للمؤسسات، فضلاً عن الخدمات المالية الترفيهية والمتنقلة لملايين المستهلكين. توفر Optus خدمات الاتصالات المتنقلة لأكثر من 10.4 مليون عميل وخدمات النطاق العريض لأكثر من 1.1 مليون منزل وشركة. بالإضافة إلى ذلك، تعمل Optus Sport على ربط ما يقرب من مليون مشجع بمحتوى الدوري الإنجليزي الممتاز وكرة القدم الدولية واللياقة البدنية.

في هذا المقال، نلقي نظرة على كيفية استخدام Optus أمازون كينسيس لاستيعاب وتحليل البيانات المتعلقة بالشبكة في بحيرة البيانات على AWS وتحسين تجربة العملاء وعملية تخطيط الخدمة.

التحدي

يتمثل التحدي المشترك الذي يواجه مقدمي خدمات الاتصالات في تكوين رؤية دقيقة وفي الوقت الفعلي لجودة الخدمة والمشكلات التي يواجهها عملاؤهم. تؤثر جودة اتصال الشبكة المنزلية والنطاق العريض بشكل كبير على إنتاجية العملاء ورضاهم، لا سيما بالنظر إلى الاعتماد المتزايد على الشبكات المنزلية في العمل والتواصل مع العائلة والأصدقاء والترفيه خلال جائحة كوفيد-19.

بالإضافة إلى ذلك، غالبًا لا تتمكن فرق عمليات الشبكة والتخطيط من الوصول إلى البيانات والرؤى الصحيحة لتخطيط عمليات النشر الجديدة وإدارة أسطول الأجهزة الحالي.

توفر منصة تحليلات الشبكة استكشاف الأخطاء وإصلاحها وتخطيط البيانات والرؤى لفرق Optus وعملائها في الوقت الفعلي تقريبًا، مما يساعد على تقليل متوسط ​​الوقت لتصحيح تجربة العملاء وتحسينها. باستخدام البيانات والرؤى الصحيحة، يتمتع العملاء بتجربة أفضل لأنه بدلاً من بدء مكالمة دعم مع الكثير من الأسئلة، يتمتع موظفو الدعم والعميل برؤية حديثة ودقيقة للخدمات والشبكة المنزلية للعميل.

يمكن لفرق أصحاب الخدمة داخل Optus أيضًا استخدام الرؤى والاتجاهات المستمدة من هذا النظام الأساسي للتخطيط بشكل أفضل للمستقبل وتقديم خدمة عالية الجودة للعملاء.

متطلبات التصميم

ولمواجهة هذا التحدي ومتطلباته، شرعنا في مشروع لتحويل نظامنا الحالي لجمع الدُفعات ومعالجتها إلى نظام معالجة قائم على التدفق وفي الوقت الفعلي تقريبًا، وتقديم واجهات برمجة التطبيقات للحصول على رؤى حتى تتمكن أنظمة الدعم وتطبيقات العملاء من إظهار أحدث لقطة لحالة الشبكة والخدمة.

كان لدينا المتطلبات الوظيفية وغير الوظيفية التالية:

• يجب أن تكون المنصة الجديدة قادرة على دعم التقاط البيانات من الأنواع المستقبلية من معدات العملاء بالإضافة إلى طرق جديدة لاستيعاب (البروتوكولات الجديدة والتردد) والتنسيقات الجديدة للبيانات.
• يجب أن يدعم العديد من المستهلكين (واجهة برمجة التطبيقات (API) في الوقت الفعلي تقريبًا لموظفي الدعم وتطبيقات العملاء والتقارير التشغيلية والتجارية) لاستهلاك البيانات وإنشاء رؤى. الهدف هو أن تقوم المنصة باكتشاف المشكلات بشكل استباقي وإنشاء التنبيهات المناسبة لدعم الموظفين وكذلك العملاء.
• بعد وصول البيانات، يجب أن تكون الرؤى من البيانات جاهزة في شكل واجهة برمجة التطبيقات (API) في بضع ثوانٍ (5 ثوانٍ كحد أقصى).
• يجب أن يتمتع النظام الأساسي الجديد بالمرونة الكافية لمواصلة المعالجة عند فشل أجزاء من البنية التحتية، مثل العقد أو مناطق توافر الخدمات.
• يمكنه دعم عدد متزايد من الأجهزة والخدمات بالإضافة إلى التجميع المتكرر من الأجهزة.
• سيقوم فريق صغير متعدد الوظائف عبر الأعمال والتكنولوجيا ببناء هذه المنصة وتشغيلها. نحن بحاجة إلى ضمان الحد الأدنى من البنية التحتية والنفقات التشغيلية على المدى الطويل.
• يجب أن يكون المسار متاحًا بدرجة كبيرة ويسمح بعمليات النشر الجديدة دون توقف.

حل نظرة عامة

مع وضع هدف النظام الأساسي واعتبارات التصميم في الاعتبار، قررنا استخدام خدمات عالية المستوى وخدمات بدون خادم من AWS حيثما أمكن ذلك، لتجنب النفقات التشغيلية غير الضرورية لفريقنا والتركيز على احتياجات العمل الأساسية. يتضمن ذلك استخدام مجموعة خدمات Kinesis لاستيعاب البث ومعالجته؛ AWS لامدا للمعالجة الأمازون DynamoDB, خدمة قاعدة بيانات الأمازون (Amazon RDS) و خدمة تخزين أمازون البسيطة (Amazon S3) لاستمرارية البيانات؛ و AWS شجرة الفاصولياء المرنة و بوابة أمازون API للتطبيق وخدمة API. ويوضح الرسم البياني التالي الحل الشامل.

يستوعب الحل ملفات السجل من آلاف أجهزة شبكة العملاء (أجهزة التوجيه المنزلية) في فترات محددة مسبقًا. أجهزة العميل قادرة فقط على إرسال طلبات HTTP PUT وPOST البسيطة لنقل ملفات السجل. لتلقي هذه الملفات، نستخدم تطبيق Java الذي يعمل في مجموعة Auto Scaling الأمازون الحوسبة المرنة السحابية (أمازون EC2) مثيلات. بعد بعض الفحوصات الأولية، يقوم تطبيق جهاز الاستقبال بإجراء التنظيف والتنسيق، ثم يقوم بتدفق ملفات السجل إلى الأمازون كينسيس دفق البيانات.

نحن نستخدم عن عمد تطبيق جهاز استقبال مخصصًا في طبقة العرض لتوفير المرونة في دعم الأجهزة وتنسيقات الملفات المختلفة.

لفهم بقية البنية، دعونا نلقي نظرة على الرؤى المتوقعة. تنتج المنصة نوعين من الأفكار:

• رؤى فردية – الأسئلة التي تمت الإجابة عليها في هذه الفئة تشمل:
  • ما هو عدد الأخطاء التي واجهها جهاز عميل معين خلال آخر 15 دقيقة؟
  • ما هو الخطأ الأخير؟
  • كم عدد الأجهزة المتصلة حاليًا في منزل عميل معين؟
  • ما هو معدل النقل/الاستلام كما تم التقاطه بواسطة جهاز عميل معين؟
• رؤى أساسية - تتعلق بمجموعة أو بقاعدة المستخدمين بأكملها، وتشمل الأسئلة في هذه الفئة ما يلي:
  • كم عدد أجهزة العملاء التي أبلغت عن انقطاع الخدمة خلال الـ 24 ساعة الماضية؟
  • ما هي أنواع الأجهزة (الموديلات) التي شهدت أكبر عدد من الأخطاء خلال الأشهر الستة الماضية؟
  • بعد تحديث التصحيح الليلة الماضية على مجموعة من الأجهزة، هل أبلغوا عن أي أخطاء؟ هل كانت الصيانة ناجحة؟

يُظهر المسار العلوي في البنية المسار الذي يُنشئ الرؤى الفردية.

تم تكوين تعيين مصدر الحدث لوظيفة Lambda لاستهلاك السجلات من دفق بيانات Kinesis. تقوم هذه الوظيفة بقراءة السجلات والتنسيقات وإعدادها بناءً على الرؤى المطلوبة. وأخيرًا، يقوم بتخزين النتائج في موقع Amazon S3 ويقوم أيضًا بتحديث جدول DynamoDB الذي يحتفظ بالملخص والبيانات التعريفية للبيانات الفعلية المخزنة في Amazon S3.

لتحسين الأداء، قمنا بتكوين مقياسين في تعيين مصدر حدث Lambda:

• حجم الدفعة – يعرض عدد السجلات المراد إرسالها إلى الوظيفة في كل دفعة، مما يساعد على تحقيق إنتاجية أعلى
• دفعات متزامنة لكل قطعة - يعالج دفعات متعددة من نفس الجزء في وقت واحد، مما يساعد في المعالجة بشكل أسرع

أخيرًا، يتم توفير واجهة برمجة التطبيقات عبر API Gateway ويتم تشغيلها على تطبيق Spring Boot المستضاف على Elastic Beanstalk. في المستقبل، قد نحتاج إلى الحفاظ على الحالة بين استدعاءات واجهة برمجة التطبيقات (API)، ولهذا السبب نستخدم Elastic Beanstalk بدلاً من تطبيق بدون خادم.

الممر السفلي في البنية هو المسار الذي يقوم بإنشاء التقارير الأساسية.

نستخدم تحليلات بيانات Amazon Kinesis، تشغيل حساب الحالة على البيانات المتدفقة، لتلخيص مقاييس معينة مثل معدلات النقل أو معدلات الخطأ في نوافذ زمنية معينة. ثم يتم دفع هذه الملخصات إلى ملف أمازون أورورا قاعدة بيانات بنموذج بيانات مناسب لأغراض لوحة المعلومات وإعداد التقارير.

يتم بعد ذلك تقديم الرؤى في لوحات المعلومات باستخدام تطبيق ويب يعمل على Elastic Beanstalk.

الدروس المستفادة

إن استخدام الأنماط بدون خادم والخدمات ذات الترتيب العالي، ولا سيما Lambda وKinesis Data Streams وKinesis Data Analytics وDynamoDB، قد وفر قدرًا كبيرًا من المرونة في بنيتنا وساعدنا على التحرك بشكل أكبر نحو الخدمات الصغيرة بدلاً من الوظائف المجمعة الكبيرة.

وقد ساعدنا هذا التحول أيضًا على تقليل النفقات العامة لإدارة العمليات والخدمات بشكل كبير. على سبيل المثال، خلال الأشهر القليلة الماضية منذ الإطلاق، لم يواجه عملاء هذه المنصة أي انقطاع في الخدمة.

لقد مكننا هذا الحل أيضًا من اعتماد المزيد من DevOps وطرق العمل المرنة، بمعنى أن يقوم فريق صغير واحد بتطوير النظام وتشغيله. وهذا بدوره مكن المنظمة من أن تكون أكثر مرونة وابتكارًا في هذا المجال.

اكتشفنا أيضًا بعض النصائح الفنية خلال مسار التطوير والإنتاج والتي تستحق المشاركة:

النتائج والفوائد

لدينا الآن رؤية في الوقت الفعلي تقريبًا لأداء شبكاتنا الثابتة والمتنقلة كما يختبرها عملاؤنا. في الماضي، لم يكن لدينا سوى البيانات التي تأتي في الوضع الدفعي مع تأخير وأيضًا فقط من مجسات ومعدات الشبكة الخاصة بنا.

ومن خلال عرض الشبكة في الوقت الفعلي تقريبًا عند حدوث تغييرات، يمكن لفرقنا التشغيلية أيضًا إجراء عمليات الترقيات والصيانة عبر أسطول أجهزة العملاء بثقة وتكرار أعلى.

وأخيرًا، تستخدم فرق التخطيط لدينا هذه الأفكار لتكوين عرض دقيق وحديث لأداء مختلف المعدات والخدمات. يؤدي هذا إلى خدمة ذات جودة أعلى لعملائنا وبأسعار أفضل لأن فرق تخطيط الخدمة لدينا قادرة على تحسين التكلفة، والتفاوض بشكل أفضل مع البائعين ومقدمي الخدمات، والتخطيط للمستقبل.

واستشرافا للمستقبل

مع وجود منصة تحليلات الشبكة قيد الإنتاج لعدة أشهر واستقرارها الآن، هناك طلب على المزيد من الرؤى وحالات الاستخدام الجديدة. على سبيل المثال، نحن نبحث في حالة استخدام الهاتف المحمول لإدارة السعة بشكل أفضل في الأحداث واسعة النطاق (مثل الأحداث الرياضية). الهدف هو أن تعتمد فرقنا على البيانات وأن تكون قادرة على الاستجابة في الوقت الفعلي تقريبًا لاحتياجات القدرات في هذه الأحداث.

مجال آخر من مجالات الطلب يتعلق بالصيانة التنبؤية: نحن نتطلع إلى تقديم التعلم الآلي في خطوط الأنابيب هذه للمساعدة في دفع الرؤى بشكل أسرع وأكثر دقة باستخدام مجموعة خدمات AWS Machine Learning.

---

عن المؤلفين

راجاجوبال ماهيندران هو مدير التطوير في فريق Optus IT Innovation. يتمتع ماهيندران بأكثر من 14 عامًا من الخبرة في العديد من المؤسسات التي تقدم تطبيقات المؤسسات من النطاق المتوسط ​​إلى النطاق الكبير جدًا باستخدام التقنيات المتطورة المثبتة في البيانات الضخمة وتطبيقات البيانات المتدفقة والتطبيقات المحمولة والسحابية الأصلية. شغفه هو دعم الأفكار المبتكرة باستخدام التكنولوجيا من أجل حياة أفضل. في أوقات فراغه، يحب المشي في الأدغال والسباحة.

مصطفى صفيبور هو مهندس الحلول في AWS ومقره في سيدني. إنه يعمل مع العملاء لتحقيق نتائج الأعمال باستخدام التكنولوجيا وAWS. على مدار العقد الماضي، ساعد العديد من المؤسسات الكبيرة في منطقة ANZ في بناء أعباء عمل البيانات والرقمية والمؤسسية الخاصة بها على AWS.

مسعود رحمن صايم هو مهندس حلول متخصص للتحليلات في AWS. وهو يعمل مع عملاء AWS لتقديم التوجيه والمساعدة الفنية بشأن مشروعات البيانات والتحليلات، مما يساعدهم على تحسين قيمة حلولهم عند استخدام AWS. إنه شغوف بالأنظمة الموزعة. كما أنه يحب القراءة، وخاصة الكتب المصورة الكلاسيكية.

المصدر: https://aws.amazon.com/blogs/big-data/how-optus-improves-broadband-and-mobile-customer-experience-using-the-network-data-analytics-platform-on-aws/