#

النقاط الرئيسية

• تفيد Circle K بأن فرز الحوادث أصبح أسرع مع Amazon Bedrock.

• تقول الشركة إن متوسط زمن الفرز انخفض من 45–60 دقيقة إلى أقل من خمس عشرة دقيقة.

• نشرت AWS دراسة الحالة في 2 نوفمبر 2026.

• يستخدم النظام الآن وكيلاً واحداً في Amazon Bedrock AgentCore Runtime.

• لا يزال المهندسون يتولون المعالجة، بينما يقوم النظام بالتحقيق ويقترح الإصلاحات.

مكاسب الفرز التي أبلغت عنها Circle K

نشرت AWS دراسة حالة عن فرز الحوادث لدى Circle K في 2 نوفمبر 2026. وقد كُتب النص بالتعاون مع مهندس DevOps السحابي في Circle K، Marek Klatowicz. ويصف كيف استخدمت Circle K Amazon Bedrock لتسريع تحليل الحوادث عبر بيئة AWS الخاصة بها.

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

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

كيف بُني سير العمل الأولي

تراقب Circle K بنيتها التحتية عبر حسابات AWS متعددة باستخدام Grafana. في البنية الأولية، كانت التنبيهات تنتقل عبر Amazon SNS وAmazon SQS وAWS Lambda إلى Amazon Bedrock Flows. ثم استخدم سير العمل وكلاء متخصصين لفحص البنية التحتية وسجلات OpenSearch ورمز GitHub.

تم استرجاع وثائق المنتج عبر Amazon Bedrock Knowledge Bases. ثم أنشأ النظام ملخصاً منظماً في Slack. وكان هذا الملخص يغطي السبب المحتمل والأدلة وملكية الخدمة والإجراء الموصى به. ويبدو أن تنسيق المخرجات صُمم لمساعدة المهندسين على الانتقال بسرعة من التنبيه إلى القرار.

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

لماذا انتقل الفريق إلى وكيل واحد

مع زيادة التحقيقات وأحجام البيانات، نقلت Circle K التحليل إلى وكيل واحد يعمل في Amazon Bedrock AgentCore Runtime. وتقول AWS إن نسخة AgentCore دخلت الإنتاج في أبريل 2026. أما نشر نوفمبر فهو دراسة حالة استرجاعية، وليس إعلاناً جديداً عن نشر.

يقوم AgentCore Gateway بوساطة الوصول إلى الأدوات ومصادر البيانات. وفي دراسة الحالة، استبدل هذا الإعداد التدفق السابق متعدد الخطوات بطبقة تحليل أكثر مركزية. ولا يدّعي المصدر أن التصميم الجديد أزال كل التعقيد. بل يقول فقط إن التحليل انتقل إلى وكيل واحد.

ويشير المقال أيضاً إلى تكامل مخطط مع AWS DevOps Agent. وسيتيح هذا التكامل تنفيذ إجراءات بسيطة فقط بعد موافقة المهندس في Slack. وتشمل الإضافات المقترحة Jira وConfluence وrunbooks. وتوصف هذه العناصر على أنها مخططة أو مقترحة، وليست تغييرات إنتاج مكتملة.

اعتبارات تشغيلية من دراسة الحالة

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

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

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

الخلاصة

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

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