Circle K تقلّص زمن تحليل الحوادث من 45–60 دقيقة إلى أقل من 15 دقيقة

عندما ينطلق تنبيه، لا يبدأ المهندس عادةً بإصلاح النظام فوراً. بل يفتح المقاييس أولاً، ويبحث عن الأسطر المطلوبة في السجلات، ويتحقق من حالة الحاويات، ويقرأ وثائق الخدمة، ويراجع أحدث التغييرات في الشفرة. كان هذا التحليل يستغرق في Circle K نحو 45–60 دقيقة. وقد أتمتت الشركة هذا الجزء تحديداً من العمل: يجمع وكيل السياق من عدة مصادر ويرسل إلى المهندس المناوب عبر Slack السبب المرجح للعطل والأدلة والخطوات التالية.

وفقاً لمقاييس Circle K الداخلية، انخفض متوسط زمن التحليل الأولي إلى أقل من 15 دقيقة، أي بنسبة 67–75%. وتُعالج الحالات البسيطة خلال 5–8 دقائق. هذه ليست تجربة مستقلة، بل مراجعة نشرتها AWS لعملية تطبيق خدمتها الخاصة؛ لذلك ينبغي النظر إلى الأرقام بوصفها نتيجة حققها فريق بعينه، لا وعداً ينطبق على أي بنية تحتية.

كيف تعمل عملية التحليل

تنتقل الإشارة من Grafana عبر Amazon SNS وSQS إلى Lambda. في الإصدار الأول، كان وكيلان متخصصان يعملان بالتوازي. يفحص الأول حالة مهام ECS وموازنات الحمل ومقاييس CloudWatch وسجلاتها. أما الثاني فيبحث عن أخطاء التطبيقات وآثار التتبع في OpenSearch، ويستخرج أيضاً من قاعدة المعرفة بطاقة الخدمة وتبعياتها.

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

لنتخيل ارتفاعاً مفاجئاً في استجابات HTTP 5xx. يكشف فحص البنية التحتية عمليات إعادة تشغيل للحاويات، وتُظهر السجلات رفض اتصالات PostgreSQL، فيما يكشف تحليل المستودع إنشاء اتصال جديد لكل طلب. وإذا كانت حملة تسويقية قد بدأت قبل العطل بوقت قصير، يربط النظام زيادة الحمل باستنفاد مجمع الاتصالات. وهكذا لا يتلقى المهندس المناوب سيلاً من الرسائل، بل فرضية قابلة للتحقق وخيارات للإصلاح: إعادة استخدام الاتصالات، أو إضافة RDS Proxy، أو تعديل آلية التوسع.

ما الذي تغير مع زيادة الحمل

عندما ازداد حجم السجلات والسياق، لم يعد الوقت المتاح للعقد المنفردة في Bedrock Flows كافياً. عزز الفريق التصفية أولاً وقلّص السياق المرسل، ثم نقل المنطق إلى Amazon Bedrock AgentCore Runtime. ودُمج الوكلاء الثلاثة في عملية واحدة تحتفظ بالحالة، فيما جرى توحيد الوصول إلى OpenSearch وقاعدة المعرفة وGitHub عبر AgentCore Gateway.

هناك ثلاثة قرارات مهمة عملياً. أولاً، يستطيع الوكيل تحسين استعلاماته أثناء التحقيق من دون فقدان السياق الذي عثر عليه بالفعل. ثانياً، تُظهر آثار OpenTelemetry مدة الخطوات ومواطن الاختناق. ثالثاً، تحصل الأدوات على صلاحيات وصول محدودة إلى البيانات وتُدار مركزياً.

ما يمكن تكراره من دون الارتباط بـ AWS

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

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