AI-translated from English; not yet reviewed by a fluent editor.

# عاد Claude. لكن على شركتك الاستعداد لاستعادة الخدمة

> انتهى عطل Claude في 22 سبتمبر. ويشرح دليل عملي كيف تحافظ الشركات على خدمة محدودة، وتصون العمل غير المكتمل، وتستعيد الأعمال المتراكمة بعد انقطاع الذكاء الاصطناعي.

By BIG CHANGE Editorial

Published: 2026-09-22T08:51:37.833Z
Updated: 2026-09-22T08:51:37.833Z
Canonical: https://bigchange.ai/blog/claude-outage-ai-business-continuity

![An intact desktop document machine sits beside an open ledger with an orange bookmark and an orderly stack of folders.](https://bigchange.ai/api/media/file/preserved-work-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. When an AI service pauses, a business still needs accessible records of unfinished work. The bookmarked ledger represents preserving the stopping place. Conceptual illustration, not evidence of damaged equipment or lost data.

شهد Claude ارتفاعًا في الأخطاء عبر نماذج متعددة في 22 سبتمبر. ويحدد التحديث النهائي للحادث من Anthropic فترة التأثر من 00:50 إلى 02:10 بالتوقيت العالمي، أي 80 دقيقة، وأعلن حل الحادث عند 02:35. وشملت المكونات المتأثرة المذكورة claude.ai وواجهة API وCode وCowork. ولا يقول السجل إن كل الطلبات فشلت، كما لا يتضمن تفسيرًا منشورًا للسبب الجذري. [سجل الحادث لدى Anthropic](https://status.claude.com/incidents/7g1qpkyz5gxh)

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

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

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

## اختر الخدمة التي تستطيع مواصلتها بلا ذكاء اصطناعي

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

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

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

تصف إرشادات Google الهندسية بشأن الحمل الزائد تقديم وظائف مخفضة، والحد من حركة الطلبات، وإعطاء الأولوية للطلبات المهمة حين تكون الموارد مقيدة. وهذه تقنيات راسخة للاعتمادية، لا تشخيص لعطل Claude. وعند تطبيقها على مكتب خدمة، فهي تدعم تقليصًا مدروسًا للنطاق حين يتعذر استمرار المعالجة المعتادة. [Google SRE: التعامل مع الحمل الزائد](https://sre.google/sre-book/handling-overload/)

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

![Two rightward arrows connect a lowered stop lever, a folder under a magnifying glass, and a tray of work beside a raised lever.](/api/media/file/pause-review-restart-inline-v1.png)

## احتفظ بسجل للعمل خارج المحادثة

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

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

أثناء الانقطاع، صنّف العمل إلى الفئات العملية التالية:

- جاهز للبدء: لم تبدأ أي معالجة أو خطوة خارجية.
- مُعدّ جزئيًا: يوجد تصنيف أو مسودة، لكن الخطوة التالية لم تكتمل.
- مكتمل ومؤكد: يسجل النظام المقصود الإجراء المطلوب.
- غير مؤكد: جرت محاولة تنفيذ إجراء لكن لا يوجد تأكيد.

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

تقول وثائق API لدى Anthropic إن الاستجابة المتدفقة قد تفشل بعد تلقي استجابة HTTP 200 أولية ناجحة. فظهور النص الأول أو تلقي تلك الحالة لا يثبت وصول الإجابة كاملة. اشترط أن يتعرف التكامل على الاكتمال وأن يحتفظ بالعمل الجزئي بوصفه جزئيًا. [وثائق أخطاء API لدى Claude](https://platform.claude.com/docs/en/api/errors)

## ضع حدًا للمحاولات المتكررة وحدد مسؤولًا عنها

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

توثق Anthropic أن حزم SDK الرسمية تعيد تلقائيًا المحاولة مرتين افتراضيًا عند الإخفاقات العابرة، مع زيادة فترات الانتظار واحترام توجيه retry-after عند وجوده. كما تميز وثائق الأخطاء بين مشكلات الخادم المؤقتة وإخفاقات المصادقة والأذونات والطلبات المشوهة. ولا يمكن افتراض أن تكرار الطلب نفسه سيعالج كل فئة. [سلوك إعادة المحاولة الموثق لدى Claude](https://platform.claude.com/docs/en/api/errors)

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

تشرح AWS كيف يمكن أن ينجح إجراء حتى إن لم يصل رده. وتستخدم واجهات API ذات خاصية idempotency معرّف طلب صريحًا للتعرف على التكرار ومنع الآثار الجانبية الإضافية. ويجب على الخدمة المستقبلة تنفيذ هذا العقد؛ فإرفاق رقم داخلي للحالة وحده لا يوفر هذه الحماية. [AWS: جعل إعادة المحاولة آمنة](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/)

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

## يحتاج النموذج الاحتياطي إلى وصف وظيفي أضيق

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

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

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

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

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

## استأنف العمل من طابور خضع للمراجعة

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

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

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

لنفترض في مثال عددي منفصل وصول 24 حالة في الساعة وتوقف المعالجة 30 دقيقة؛ عندها تتراكم 12 حالة. وإذا عالج المكتب بعدها 36 حالة في الساعة مع استمرار وصول 24 حالة جديدة، فسيحتاج إلى ساعة لتصفية التراكم. وهذه افتراضات توضيحية، لا قياسات لعطل Claude.

تبدأ إرشادات Google لأهداف مستوى الخدمة بالنتيجة التي تهم المستخدمين وبالتبعيات اللازمة لتقديمها. وقد يكون المقياس المفيد لهذا المكتب نسبة الحالات العاجلة التي تلقت ردًا مناسبًا ضمن المهلة الموعودة. فتوافر المزوّد مهم، لكن على الشركة أيضًا معرفة ما إذا كان عملاؤها تلقوا الخدمة. [Google SRE: تطبيق أهداف مستوى الخدمة](https://sre.google/workbook/implementing-slos/)

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

## تدرّب على انقطاع واحد قبل توسيع الأتمتة

يمكن لتمرين قصير على الطاولة كشف نقص الوصول أو المسؤولية من دون تعطيل العملاء الفعليين. استخدموا بضع حالات دعم خيالية واتبعوا التسلسل التالي:

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

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

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

## Sources

- [Claude Status: ارتفاع الأخطاء في نماذج متعددة](https://status.claude.com/incidents/7g1qpkyz5gxh) — يحدد سجل الحادث لدى المزوّد فترة تأثر مدتها 80 دقيقة ووقتًا لاحقًا لحل المشكلة. وقد قُرئ ملف JSON العام بصورة مستقلة. وهو يبلغ عن ارتفاع الأخطاء لا الفشل الشامل، ولا يتضمن رواية منشورة للسبب الجذري.
- [Claude Platform: أخطاء API](https://platform.claude.com/docs/en/api/errors) — تغطي الوثائق الحالية الأخطاء ومحاولات SDK الافتراضية والإخفاقات بعد بدء البث. ولا تثبت هذه الآليات اكتمال مهمة تجارية أو تمنع تكرار الإجراءات في الأدوات المتصلة.
- [AWS Builders’ Library: جعل إعادة المحاولة آمنة باستخدام واجهات API ذات خاصية idempotency](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) — شرح مالكوم فيتونبي للاستجابات غير المؤكدة ومنع التكرار. ويجب على الخدمة المستقبلة تنفيذ عقد API؛ فالمعرّف وحده غير كافٍ.
- [Google SRE: التعامل مع الحمل الزائد](https://sre.google/sre-book/handling-overload/) — إرشادات هندسية راسخة بشأن تقليل الوظائف والأولويات وضبط المحاولات. ويكيف المقال هذه المبادئ لمكتب خدمة افتراضي؛ وهي لا تشخّص سبب حادث Anthropic.
- [Google SRE Workbook: تطبيق أهداف مستوى الخدمة](https://sre.google/workbook/implementing-slos/) — يشرح أهداف الاعتمادية المستندة إلى نتائج المستخدمين والتبعيات الحرجة. أما المقياس المقترح للخدمة ومثال التراكم فهما تطبيقان توضيحيان، لا نتائج مرصودة أو هدفًا عامًا.