تقول Databricks أن وكيل AI SRE الخاص بها يعمل على تسريع التحقيقات في الحوادث

ماذا حدث

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

في منشور مدونة Databricks بتاريخ 24 أغسطس 2026، تصف الشركة AI SRE بأنه وكيل تصحيح داخلي للحوادث التي تؤثر على خدمات الإنتاج الخاصة بها. تقول Databricks إن مؤسستها الهندسية تدير مئات الخدمات الصغيرة عبر 1500 مجموعة Kubernetes وأكثر من 70 منطقة وثلاثة موفري خدمات سحابية. يقدم المنشور AI SRE كمنصة مشتركة لأكثر من 150 فريقًا، حيث يستطيع كل فريق إضافة معرفته التشغيلية الخاصة به والحفاظ عليها من خلال "دفاتر التشغيل الوكيلة".

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

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

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

تفيد تقارير Databricks أن AI SRE لديها أكثر من 250 مستخدمًا نشطًا أسبوعيًا، وتدعم أكثر من 150 فريقًا وتجري أكثر من 2000 تحقيق يوميًا. تقول إن المستخدمين يوفرون عدة ساعات من وقت تصحيح الأخطاء، ويصف الموظفون المقتبسون في المنشور تجميعًا أسرع للسياق وتحليلًا مبكرًا للسبب الجذري. هذه الأرقام والشهادات هي ادعاءات من Databricks؛ ولا يصف المصدر تقييمًا خارجيًا أو مقارنة مضبوطة مع التحقيقات السابقة أو معدل الخطأ في النظام.

تفاصيل المصدر: databricks.com ↗

لماذا يهم

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

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

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

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

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

The public evidence remains limited. Databricks does not identify the language model or models used, disclose investigation accuracy, quantify false leads, report how often engineers override recommendations or explain how “several hours” of savings was calculated. The source also does not establish that the system improves company-wide mean time to resolution through an independently measured study. Readers should treat the deployment and its reported results as Databricks’ account of an internal system, not as a general proof that AI agents can reliably debug production systems.

ماذا تشاهد بعد ذلك

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

The clearest next step is guided mitigation. Databricks says AI SRE currently concentrates on understanding what happened and why, while future work may help engineers take corrective action. That transition would materially raise the stakes: gathering evidence is different from changing configuration, rolling back a deployment or altering traffic. Important details to watch include approval requirements, permission boundaries, rollback mechanisms, audit logs and whether the agent can act only after a human confirms a specific step.

Databricks also says it is working on cross-incident learning. The proposed use is to identify recurring patterns, surface issues before they trigger alerts and reveal systemic reliability gaps. Such features could be useful if historical incident records are consistent and representative. They could also preserve outdated assumptions or amplify poorly diagnosed incidents. The source does not explain how past investigations are labeled, corrected or excluded when their conclusions are uncertain, so the quality-control process will matter as much as the retrieval technology.

Runbook maintenance will be another test. The platform’s model depends on teams encoding expert checks and updating them as services, dependencies and thresholds change. Databricks says runbooks were previously often stale or incomplete, which creates a risk that agentic versions could automate old procedures at greater speed. Evidence of review cadence, ownership, version control and testing in simulated incidents would help determine whether composability improves reliability or merely distributes maintenance work.

External validation is also missing. The post gives internal adoption figures and employee testimonials but no public benchmark, incident sample, baseline error rate or comparison across novice and experienced engineers. Future reporting should clarify how often AI SRE reaches the correct root cause, how often it produces an incomplete or misleading lead, how long investigations take with and without it, and whether performance varies by service or cloud provider.

Finally, the scope of access deserves scrutiny. AI SRE uses observability data, deployment information, code and incident history through controlled APIs, but Databricks does not spell out the security model or data-retention practices in this post. Organizations evaluating similar systems will need to know which secrets or sensitive operational details are exposed to the model, whether prompts and outputs are retained, how access is segmented between teams and what happens when an upstream data source is unavailable. Those unknowns will determine whether the reported speed gains translate into dependable production use.

الأدلة والاختبارات ذات الصلة