تحديات العمليات اليدوية في فرق الدعم

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

الحل: نظام تحليل مستقل مع حواجز أمان بشرية

للتغلب على هذه التحديات، طورت أديرانت نظاماً ذكياً لتحليل التذاكر يعتمد على بنية تحتية سحابية خالية من الخوادم (Serverless). يعمل النظام عبر دالة AWS Lambda واحدة تنطلق كل ساعة في أيام العمل باستخدام Amazon EventBridge. يتبع النظام خمس مراحل رئيسية: تحديد التذاكر غير المخصصة، إثراء البيانات من مصادر متعددة، تصنيف الطلب، اتخاذ الإجراء المناسب، والمراقبة والتحسين. يعتمد النظام على نموذج Amazon Nova Lite للوصول إلى تصنيف هيكلي دقيق للطلبات وتحديد الخطوات التالية المقترحة. يتم دمج هذا النموذج عبر واجهة Amazon Bedrock Converse API، مما يضمن التكامل السلس مع بيئة AWS الحالية دون الحاجة إلى مزودي خدمات خارجيين.

آلية عمل النظام وجمع السياق الذكي

يقوم النظام بجمع السياق التشغيلي من عدة مصادر داخلية لضمان دقة التحليل. يستخرج البيانات البيئية من Amazon Athena، ويجمع المعرفة التقنية من Confluence وMicrosoft SharePoint، كما يبحث عن تذاكر مشابهة تم حلها سابقاً في Jira. بعد تجميع هذه المعلومات، يرسلها إلى النموذج الذكي الذي يولد توصيات مبنية على البيانات. إذا كانت درجة الثقة في التصنيف مرتفعة بما يكفي، يقوم النظام آلياً بإعادة توجيه التذكرة وإشعار الفريق المعني عبر Microsoft Teams. أما إذا كانت درجة الثقة منخفضة، فيُعلَّم التذكرة للمراجعة البشرية، مما يضمن الحفاظ على جودة القرارات الحساسة. هذا النهج يوازن بين سرعة الأتمتة ودقة المراجعة البشرية.

أسباب اختيار أمازون نوفا لايت

اختارت أديرانت نموذج Amazon Nova Lite بعد تقييم عدة نماذج أساسية باستخدام بيانات تذاكر حقيقية. جاء هذا القرار بناءً على ثلاثة عوامل رئيسية. أولاً، أظهر النموذج قدرة فائقة على استخراج خطوات حل محددة وربط المشكلات الحالية بمشاكل سابقة مشابهة بشكل أفضل من النماذج الأخرى. ثانياً، يوفر تكاملاً أصلياً مع خدمات AWS مثل IAM وAWS SDK، مما يقلل من التعقيد التشغيلي والتكاليف المرتبطة بإدارة مزودين خارجيين. ثالثاً، كانت تكلفة النموذج مناسبة للتطبيق على نطاق واسع، حيث سمحت بتحليل التذاكر الروتينية وليس فقط الحالات ذات الأولوية العالية. خلال فترة التشغيل الأولية، بقيت تكلفة الاستدلال عبر Amazon Bedrock أقل من دولار واحد شهرياً، مما يجعل الحل اقتصادياً للغاية.

النتائج الأولية في بيئة الإنتاج

خلال الأسابيع 2.5 الأولى من التشغيل الفعلي، من 30 يونيو إلى 17 يوليو 2026، راجع النظام 109 تذاكر. أظهرت القياسات دقة في التوجيه تقارب 96%، حيث قورنت قرارات النظام بالفريق الذي قام فعلياً بحل كل تذكرة. بناءً على خط الأساس الذي تم قياسه قبل الأتمتة، تقدر أديرانت أن النظام يستعيد ما بين 8 إلى 14 ساعة عمل هندسية أسبوعياً. هذه الساعات المستعادة يتم إعادة توجيهها نحو مهام أكثر تعقيداً تتطلب حكماً بشرياً، مثل استكشاف الأخطاء وإصلاحها في البنية التحتية وتحسينات المنصة الاستباقية. تشير الشركة إلى أن هذه النتائج تمثل مرحلة أولية وليست معياراً طويل الأمد، لكنها تؤكد الجدوى العملية للنظام.

حالات عملية وتحسين الكفاءة

توضح الأمثلة العملية فاعلية النظام في سيناريوهات مختلفة. في حالة واحدة، وصل طلب يصف خطأ 404 في موقع Azure DevOps إلى طابور AWS الخاطئ. قام النظام بتصنيفه كمشكلة Azure، وتحديث حقل الفريق، وإشعار مقدم الطلب بإعادة التوجيه، مما منع تأخر الحل. في حالة أخرى، طلب مهندس إعداد وصول عن بعد خارج ساعات العمل. جمع النظام بيانات بيئة العميل مع مقال تقني من Confluence ونشر الإجراء كتعليق داخلي، مما سمح للمهندس بإكمال المهمة في أقل من 30 دقيقة دون بحث إضافي. كما ساعد النظام المهندسين الجدد في فهم سياق طلبات النشر التي تتطلب سكربتات PowerShell، مما وسع نطاق الخبرة العملية للفريق.

المصادر

• AWS Machine Learning BlogAderant builds intelligent ticket triage with Amazon Nova